なぜ、人月か

結局、それしか直接費が存在しないからなんだよな。成果報酬型といったところで成果を計る基準で変わるわけで受注する方のリスクが高すぎて仕事にならない。お客にとっては成功するのが当たり前なのだから、曖昧模糊とした成果に対して費用など払いたくはあるまい（実際には予想を上回る失敗はあっても、その逆はないわけだからなおさらだ）。結局、人月というのは誰にとっても良い落としどころということなのだろう。

「人月の神話」で問題視されていたことは、単純化してしまえば実費ベースでは生産性の高さが反映されないという一点に尽きるわけだが、JUASに結果を見る限り平均的な生産性がプロジェクトの成否を分けているようには見えない。事実として業務アプリの開発には（フレームワークやミドルウェア部分を除き）高度な技術的内容は必要ないわけで、そういう意味で少なくとも業務アプリの分野においては「人月の神話」の意義は存在しないに等しい（その反面、高度な業務知識が求められるが、それは要件定義や基本設計フェイズの重要性を示すものであり、開発の問題ではない）。

さて、人月を妥当な結論とみなすのであれば、我々システム屋に求められることは何だろうか。それはおそらく平均的なプロジェクトよりどれだけ「早く・安く・旨く」仕上げられるかということにかかってくる……かと思われるのだが、恐らくそうではなくて、ここまで失敗率の高い世界においては確実に成功させることこそが何よりの利点である以上、目標は求められる品質・規模*1での平均的なプロジェクトの金額・期間を死守したうえで終わらせるという、ただ一点に尽きる（差額は生産者余剰なので企業の利益とすれば良い）。もし、何の裏づけもなく平均的なプロジェクトよりも金額・期間を下げるようなことがあれば、それは単にプロジェクトの失敗確率を上げているだけのことである（そして金額・期間を下げることを裏付けるような銀の弾丸はこの業界において見つかっていないし、もし見つかっていたとしたらその会社はボロ儲けしているはずである）。

となれば、重要なのは品質・規模という変数を与えた上での平均的なプロジェクト金額・期間を求めることであるわけでJUASの公表結果は大きな意味を持っていることになる。

*1:通常であればここにリスクが入るが、リスクをどう捕らえるべきかまだ見えていないので今のところ入れていない。