某システムの某機能、処理速度(検索結果の表示)が遅いことが、現場で浮き上がってきた。原因は、
- データベースのテーブル構造。
- 業務で必要とされている機能の内容。
- ロジック。
だろうが、やはり一番致命的なのは、DBのテーブル構造かと。良くない構造を無理矢理押し通していることから、ロジックが複雑になっている上、データベースの機能を使って実現し辛い機能要件を満たすために、さらに非効率な処理が含まれている。結果、スピードが遅いという形で結果が出てしまう。
根本的な設計の見直しについては、既に昨年の春、行き詰まっていたこの機能を引き受けた際に「開発リーダー」に進言しているが、「予定を変えることは出来ない」の一点張りで拒否された。だが、結局不具合やその他の問題で予定はずれてしまった上、結果も上記のように良くないものに終わっている。やはりあそこで、予定を少々調整してでも、根底部分の見直しをかけるべきだったのだとおもう。
開発リーダーさんには、それくらいの交渉や努力をしてほしかった。
後から判ったことだが、多分彼は、対外的交渉が苦手だったのだろう。だが、それがシステム全体の品質低下につながる。で、結局カットオーバーしてから、二次開発といっていいほどの改修を加えないといけなくなる。
自分が同じ立場でチームメンバーから進言された際に、最良の選択が出来るかどうかは判らないけど、何かをやるときのタイミングと、メリハリの有るアクションというのがいかに大事かということは、今回よくわかった。