2011/2/17
ちょうど、一年ほど前に、
開発工数と期間（納期）と人数の関係について
ということを書いた。
あれから、「COCOMOモデル」という考え方があることは、その後知った。
ただ知っておくことは別に悪い事とは思わない。
自分なりに必要か必要でないかを判断できると思えるくらいの理解はしておいてよいと思う。
で、その結果、
この考え方に私は非常にあきらめと違和感を感じた。
それは、なぜか？
「機能なんて定まっていない」
からだ。
そもそも、なぜ機能が定められないうちから工数を見積もりたいのか？
提供する価値とコストと納期（締め切り）のよいバランスをとりたいからだ。
そのために必要な、作為的変数としての工数なのだ。
すべてが変動だと言うから、「工数」という固定がほしくなる。
数学的にすべてが変動の式に答えはないし、軸がないものでは議論が進まない。
でも、現実はどうだろうか？
コストと締め切りは、多少の変動はあるものの、
全体から見れば「固定」といえる範囲のものではなかろうか？
（少なくとも私の場合はそうだった。）
だったら、「価値」しか変動になりえない。
お客が「工数」が知りたいということを言ってくることがあるが、
別に工数なんて知りたくないと思う。露骨に「コスト」を求めても答えないし、こちらからも明確に提示したくないから、
「工数」という曖昧な言葉でまずはお互いをよく知る話題をつくりませんか？という意味で使われるに過ぎないと思っている。
実際、たいていの企業や利用部門にとってコストと締め切りの変動よりも、「価値」の変動のほうが受け入れやすい。
それに、機能を定めたからといって、必ずそれが実現できるとも限らないではないか？
そして、ある機能を作るときに、エンジニアは「3日案」、「1週間案」、「3週間案」のように複数の案を持っている場合がある。
これらの表面的な機能はどれも同じだ。
違うのは、カバーできる規模だったり、拡張性だったりする。
工数は、3日から15日案がありますが、どれにします？と聞いても誰も、よい答えはもっていない。
また、多くのリスク要素の中の1つ、２つが失敗しただけですべてのバッファを食いつぶすほど、
現在、定められているコストと納期は厳しい。
だったら、現実問題としてその時点で「価値」の変動を受け入れてもらわなければならない。
そして、すべてが八方ふさがりになったときに最終手段として3日案の適用があったりする。
さらに、「期間」と「コスト」が固定なプロジェクトを連続的に繰り返すで、「永久ベータ版」というのだとおもう。
いったいどこまで続ければいいのだろうか？
「期間」と「コスト」が許す限りだ。
そして、これは、連続的に繰り返された結果、世に言う「変更に強いシステム」ということにもなる。
なんのことはない、「期間」と「コスト」は技術的な裏付けなどなにもいらず、
期間 ＝会計管理上の制約
コスト＝お財布の中身
で決めてしまえばよい。
できることしかできないと割り切ってしまい、
それを連続的にすることで、最後には「最初はできない」はずであったことが、
できるようになっているということがよいプロジェクトマネジメントなのではないだろうか？
初めから、予算は1000万、締め切り10ヶ月と決まっていても、
予算200万、期間2ヶ月の開発を5回にわけることと何がちがうのだろうか？
むしろ、妥当な機能が4回目の繰り返しでできることがわかれば、
5回目をやらなくていいので200万円の値引きと、2ヶ月の期間短縮で「うはうは」ではないか？
と私なりには思うのである。
ただし、工数管理はいらないかと言えば、それはない。
予定としての工数管理をしないだけで、結果としての工数管理はする。
そして
「機能なんて定まっていない」
状態から抜け出せたときに、初めて「予定工数」をこれまでの経験から使うだけである。
ただ、管理という視点ではなく、開発者という視点に立てば、
予定工数が導けて、その工数通りにできるときは、そのエンジニアにとっては「開発」ではなく「作業」になっていますが・・・
Posted in 
