プロジェクト遅延の真実
完成日に完成しないのは、目標が静止していないからです。
目標性能や目標品質は、最初に決めたまま変化しないということはまずありません。
フライイヤー(ハエの一生にたとえられるくらい短い)が支配するビジネスの現場では、要求仕様自体が時々刻々と変化します。これが亀です。
有能な技術者が束になって、数々の障害を乗り越えてずんずん突き進みます。開発プロセスはアキレスです。
アキレスがスタートするとき、目標地点は亀=要求仕様の居る場所です。
アキレスは有限の時間で亀の居る場所へたどり着くことができます。つまり見積もり可能なプロセスの実現です。優秀なエンジニアが集まっているので、亀の要求仕様の変化をごく短時間で満たす開発をおこなうことができます。つまりアキレスは亀よりも足が速いのです。
ところが、この有限の時間の間に亀は進んでしまいます。時に大胆に、時に慎重に。いずれにしても、元居た場所からは違う場所に居ます。
再びアキレスは新しい亀の居場所を目標に走り出します。短い時間で到着することができるでしょう。小さな見積もりは高い精度です。
ところがどっこい、アキレスが亀の居た場所へ着いたときには、亀はもう別の場所にいます。さっきよりは移動距離は短いですが。
みたびアキレスは走りますが、到着すると亀は進んでしまっています。
何度繰り返しても、アキレスは亀に追いつくことができません・・・
アキレスと亀のお話は、有限と無限の根っこに関連してややこしや～©なだぎ、なのですが、実際の開発現場では間抜けな要因が加わることで、本当に「完成しないステム開発」が発生するのです。
100万行のシステムを1年で開発するような場合、120万行書いて10ヶ月経過しても、完成度が60％程度というのはよくある話です。
工程表では80％の進捗ですが、それは投入工数であって、実現機能の割合ではありません。
ユビキタスな80-20問題によって、残りたった20％の機能実現のために、全体の80％の工数がかかるかもしれません。つまり200万行書いてもまだ完成しないかもしれません。
しかも、何も無いところから書き始める100行と、120万行のソースのあちこちを矛盾無く、エンバグしないように修正する100行では、かかる工数がぜんぜん違います。ブロック塀は半日で作れますが、それを震度８に耐えるように耐震化する工事は調査だけで1週間かかるのと同じことです。
上記では、アキレスは有能カツ優秀な技術者集団を仮定しましたが、間抜けな素人集団であった場合、亀が静止していても自己演出によってアキレスと亀が発生します。
– 間抜けなアキレスは100％の工数で90％しか実現できない
– 残った10％を解決するのに、2倍3倍の工数がかかる
– さらに投入工数の10%程度のエンバグを発生させる
そういう状況では、亀の方からアキレスに歩み寄る必要が生じます。歩み寄ってもエンバグ率によっては完成しないシステムになります。
機能を削減して動かなくするための細工でエンバグするというつける薬のない連中も実在します。
これらの例のどれに当てはまるかを正しく認識している人がどこかに居れば、システムは完成します。そうでない場合は不幸なデスマーチとなるのは必定なのです。預言者でなくても結末を予言することができます。
