見積もりはアテにならない

2019年12月31日

paizaの こちらの記事を読んでみて、
思う事がありました。

非エンジニアに多い、エンジニアと開発業務に対する4つの勘違い

こちらでは、見積りの難しさについて 書かれています。

いつまでに出来上がるか 正確にはわからない。
人数を増やせば早く出来るわけではない。
これらはまさに 『人月の神話』で語られている事です。
フレデリック・ブルックス氏が 40年前から語っていた有名な話です。

本当に 正確な見積もりというのは、わからないものです。
正確な見積もりを行えるとしたら、
案件を聞いた時点で、出来上がりのプログラムが 頭に浮かんでいて、
それを書き出すだけが 作業として残っている場合なんですよね。
さらに言えば、そのプログラムを書く作業の状況まで、
瞬時にシミュレーション出来ている場合です。

しかし、人間の頭というものは、
そこまで処理能力が あるわけでもなく、
実際に作る物の形は、試行錯誤のうえで作り上げられるものなので、
結局は アテにならないものです。

人月で工数計算するというのも、おかしな話です。
人によって能力差があり、何人いれば何日で出来るという計算が
不可能なのは もちろんの事ですが、
人月計算で工数を計り、ギリッギリのスケジュールで見積もりをし、
制作もカツカツの状態だと、当然 よい物が出来るわけがありません。

『見た目や出力が合っていればシステム的にもOK、ではない』
と、リンク先のブログでは 語られていますが、まさにその通りです。
プログラミングやコーディングと言うのは、
単に 渡された仕様書通りに文字起こしするだけの作業ではなく、
正しい結果が出力されるように考える必要があるのです。

それなのに、
『この機能をちょっと付け加えたいんだけど、いつまでに出来る?』
なんて言われても、わかるわけがありません。
現物のコードが スパゲティかもしれないのは もちろんの事、
既存のソースで、前後の処理で 何をやっているのかを考慮する事も重要です。

ただ単に 見積もり優先で やってしまうと、
出力だけは仕様通りではあるが、内部の処理が正しくなく、
仕様書やテスト仕様書に書かれてある 想定内の入力にしか 対応しておらず、
想定外の入力を行ったら、正しく出力できないどころか、
最悪、SQLインジェクションなどの脆弱性を残す結果となるでしょう。

本当は 思考を要求される重要な製造工程なのに、
プログラミングという作業を 単なる文字起こしと勘違いされ、
カツカツのスケジュールの中で 量産作業を行わせる。
ゼネコン構造の最底辺の業種に なってしまった事が、
日本のIT業界が 遅れてしまっている要因であるようにも思えます。

Pocket