今回は、ちょっとカッコいいタイトルにしましたが、作業方法ではなくて、「判断基準」のお話です。
受託開発をしていて、一番、判断に悩む問題は、「どこまで丁寧に作るのか？」「どこはシンプルな作りで構わないのか？」ということだと思います。
理想像は、全ての機能において、「かゆいところに手が届く」ように作られていることなのでしょう。
こう考えている若手SEは、多いはずです。
これは現実問題としては、有り得ないことなのです。
しかしながら、実現する方法が全くないというわけではありません。
それは、どこの開発会社もやってきた、そして、現在もやっている方法ですが、元となるフレームワーク自体に徹底的に注力し、「良いもの」にして、使い回すという方法です。
部品として、再利用できるものを増やしておくのです。
この場合、「良いもの」とは、
・プログラムがシンプルである。
・操作性が良い。
・ミスが防げる。
・何かあったとき、直ぐに問題の箇所がわかる。
ということを指します。
フレームワークで実現できることだけであれば、何の問題もありません。
しかし、フレームワーク外として個別に作り込みを要求される機能は、必ず存在します。
そのとき、それを機能の重要さや、使用頻度に関係なく、一律に「丁寧に作るべきだ」と考えてしまうことは、生産性を低め、結果としてシステムの効果を下げてしまいます。
実際には、この判断基準をどう考えるか、というのが若手SEが成長する一つのステップなのかもしれません。
結局は、一定のコストと時間の中で、実現できることを絞り、選択しなければならないからです。
しかし、若手SEは、全ての機能に対して同じように「操作性が良いもの」「多機能なもの」を提供しようとします。
そのため、
「納品直前に理想のシステムが実現できないことがわかる」
「既に多くの工数費やしてしまって、後戻りできない状態でやっと気が付く」
といった状態に陥ります。
そこには、いろいろな理由があるでしょう。
「理想のプログラムは高機能で難易度が高く、ハイレベルの技術者が要求されるが結局、そこまで人員が手配できなかった」
「大抵において、プロジェクトには、予想外のトラブルや問題が起きるものなので、そちらに工数がかかってしまった」
など、など。
そして、志半ばで倒れてしまう。
であれば、各機能に対して、最初から徹底的に、優先順位付けしておけば、お客様にも迷惑がかからなかった。
ということがよくあるのです。
残念なことですが。
技術でも工数でも、必ずバッファを持つ、といったスケジュール管理も大事ですが、何に力を入れて、何をシンプルにするかといった、運用側のことを考えた「勘」がSEには要求されるのです。
わたしがいつも考えているのは、次の2点です。
1）その機能を入れ込むのに何時間かかるか？技術者の能力は合っているか？
2）その機能を入れることによって、節約できるお客様の時間はどれくらいか？
つまり、システム開発としてのROIを考えて判断するのです。
例えば、システムの初期稼動時にしか使わないような機能は、操作性や機能を重視する必要はありません。
それよりも、入力ミスをしてしまう可能性を無くすことに注力すべきです。
また、使用頻度の低い機能であれば、操作を忘れても、画面を見ればわかるように、メッセージを入れることに気を使います。
毎日、毎日、複数の人が頻繁に使う機能については、操作性を良くし、操作ミスに対してすぐにアラームが発生するように、そして、10秒でも、5秒でも節約して、作業ができることに注力します。
結局、そのシステムが稼働して、1年、2年というスパンで見た場合の「運用コスト」と「開発コスト」を比較して考えるのです。
つまり、システム開発は、トータルコストで考えるのです。
Vol.00137