吉岡さんのblogの、

ソフトウェアの作り方を考える

より。

私のバックボーンからすれば、

多くの人が指摘しているようにソフトウェアの価値をかかった工数（人月）で評価するというのはまるっきりナンセンスである。熟練者が一ヶ月で作成できるものを初心者が6ヶ月かかったとすると、後者に6倍お金が払われるか、それだけの価値があるか。もちろんない。

この主張は全てがナンセンスに見える。

多くの人々が、人月見積りを否定しようとする。これについては以前、

悪いのは「人月」じゃないだろ

というエントリを書いている。また、同じような趣旨で仙石氏のエントリ、

なぜ人月見積もりが優れているのか

というのもある。要約すれば、「人月」というのは単なる工数モデリングの手法に過ぎないわけだから、運用さえ間違えなければ比較的robustな方法でそうそう悪いものではないということ。

「人月」はあくまでもモデルであるから、その精度を上げるための工夫はするべきで、「熟練者が一ヶ月で作成できるものを初心者が6ヶ月かかったとすると、後者に6倍お金が払われる」なんてのは、ナンセンスな運用だ。だいたいに「人月」を否定したがる奴等は、そういった極端に間違った例を持ち出したがるが、そんな調子でやればどんな見積り方法だって破綻する。「10人妊婦がいれば1ヶ月で赤ちゃんが産まれるか」みたいな、馬鹿げた批判をするのだが、それは論法自体が無茶だ。

というような話は、リンク先のエントリを見てもらうこととして、ここでは別の側面についての話を書こうと思う。

吉岡さんはいわゆる「業務アプリケーション」の経験はないらしい。一度触れて下さるとよくわかるのだけど、この世界はその世界に触れたことのない人達からすれば、「まるで理屈が通じない」ような気がする世界なのだ。それは別に「顧客の気まぐれ」とか「エンジニアの能力」だとか「いわゆるITゼネコン」といった「政治的」な話としてではなく、純粋にソフトウェアとして見た場合の話として、

把握するべき「状態」が爆発してしまい、
複雑系になってしまっている

という点で常識外れなのだ。複雑系になってしまっているものだから、複雑系でない世界での理屈が通じにくい。だから「まるで理屈が通じない」というように見えるわけだ。

DBMSや言語処理系は、業務アプリケーションと比較すると、「状態変数」と「状態」は著しく少ない。言語処理系に至っては、主な状態変数は1つだけだし、状態の数だって知れている(完全に把握されている)。また、それらは「自然科学的必然」で規定される部分が少なくない。ところが、業務アプリケーションは状態変数も状態もいきなり増える上、自然科学的には不条理としか言いようがないことで規定されてしまうこともある。

そうなると、テストケースを完全に挙げることすら容易でなくなる。実装の時もそういった多数の状態変数と状態の数だけの実装が必要になる。これは何を引き起こすかと言えば、

ある程度以上の能力の人では、
能力の高さと生産性の高さの相関が崩れることが少なくない

ということを起こすのだ。これは、仮にすごーーーーーーーーーーーく能力の高い人がいたにしても、生産性は程々のところで飽和してしまうということ。

業務アプリケーション開発の場合、必要な機能をコツコツ一つづず開発しないといけないので、生産性は「1行分実装すれば1行分実装される」というところに落ちついてしまうのだ。また、個々の処理としてはそんなに複雑ではないから、個々の処理は誰でも経験や能力に関係なくすぐ書けるのだが、逆にそうであるがゆえに誰がやってもそんなに生産性は変わらないし、工夫の余地も少ない。これがミドルウェア系だと、「うまく頭を使えば1行分の実装が何100行分の実装になる」的な生産性向上があったりするのだが、業務アプリケーションはそうは行かない。

もちろん業務アプリケーション開発でもそういった場面がないわけではないのだが、ミドルウェア系ほどはそういった場面が多くない。だから「6倍」なんてことはまず起きない。私の経験でも、「桁違いの生産性」が叩き出せたのはミドルウェア系の開発の時だけで、業務アプリケーションの下流工程では、高々数倍でしかない。下流工程だと、「入社半年の新人君」と「バリバリのベテラン」との違いであっても、そんなに大きくないのだ。

だからそういった意味では、まるっきり

土方と同じ

と言えなくもない。逆にそんなことだから、下流工程は適当に人月で見積ってしまっても、そこそこ破綻するようなことはなかったりする。まぁこれは私が主張する「人月はそう悪くない」というのとは、ちょっと意味が違うのではあるけど、結果としてはそうなってしまう。

現実はさらにこの上に「政治」みたいなものが関わって来たりするので、ますますカオスなことになってしまうから、「土方度」は高くなってしまうわけだけど、この辺は「ソフトウェア工学」とはちょっと違うので、またいつか別の機会に。

そんなわけで、いわゆる「情報工学系」の人達やミドルウェア開発ばかりをしていた人達が思うことと、「業務アプリケーション」の世界は、「政治」の類を抜きにしてもまるっきり違うのだ。そういった「状態変数」と「状態」の爆発をうまく対処する理論や手法があれば、「人月はナンセンス」と言える時代も来るのだろうが、今のところは無理であり、「人月よりも優れた見積り方法」と呼ばれるものも、ソフトウェアを生産するという観点からは机上の空論ですらなかったりしてしまう。

まぁそんなわけで、「人月のワナ」というのは、

1. 運用の誤り
2. ドメインの違い
3. 政治

あたりを無視しているという罠。

補足

はてぶで「ソフトウェア工学の通用しない世界」というコメントがついていたのだが、これは半分正しく半分正しくない。私はこの問題は「理屈が通用しない」というニュアンスでは捉えていない。むしろ、「理屈が至らない」と捉えている。「小さい問題」で現実的なアルゴリズムが、「大きい問題」の時には通用しなくなるということは珍しくない。そういったことに近いのではないかと考えているのだ。