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

「開発工程を別々に担当してはいけない」は思いのほか多数のブックマークを頂いた。コメントやブックマークを拝見しながらあれやこれや考えた。わたしの飛躍する思考というか雑な議論で辟易している方もいらっしゃるかとは思うがもう少しお付き合いいただければ幸いである。

わたしの経験は、このブログの読者の皆さんはご存知かもしれないが、ソフトウェア製品の開発経験に偏っている。米国系ハードウェアベンダーでコンパイラやRDBMS製品を開発していた。その後西海岸のソフトウェアベンダーに転職してそこでRDBMS製品の開発に従事した。そしてOSSの可能性を信じてミラクル・リナックスの設立に参加したのが約7年前である。顧客向けアプリケーション、例えば社内システム構築（人事、財務、購買などなど）の経験はない。

さて先の「開発工程を別々に担当してはいけない」ではいろいろな論点をごった煮風に突っ込んだものだから分かりにくくなったので、いくつか細かく分けて考えてみる。

人月のワナ。

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

この場合の正しくは、ある実装した価値、通常は機能で近似するかと思うのだけど、それに見合った価格が支払われるべきである。単位機能を実装する工数が少なければ少ないほど、利益があがるので、ソフトウェア開発における生産性向上のインセンティブが発生する。人がソフトウェアを作る以上、一人一人の専門性、技術を向上させることに高いインセンティブが発生する。企業にとっても、未経験者（安い人材）を雇用し、その利ざやで稼ぐのではなく、より専門性の高い人間を雇用し、その生産性の高さで利益をあげることに、そして教育やトレーニングに投資すること（生産性や品質の向上に繋がる）に合理性が発生する。

ソフトウェアである機能を実装するために、設計、プログラミング、テストという工程があったとして、それを工程ごとに分離して、それぞれを単能化することによって生産性を向上するという、古典的な工場モデルがソフトウェア生産に適用可能なのか。ひたすらネジを取り付けるだけの自動車工場なんていうのがいまどきありうるのか。ソフトウェアの設計とプログラミングそしてテストというのがそもそも分離可能な工程なのか？

わたしは、そのような工程を単純に分離することは難しいし、分離することは専門性を高めることには繋がらないと思っている。分離することによって、生産性が向上するという証拠もほとんどみたことがない。ソフトウェアを実装する能力を高めるためには、渾然一体のプロセスである、設計、プログラミング、テストを等しく経験しなければならないと考えている。その経験を積むことによって一人一人の専門性すなわち生産性が向上していくと考えている。

テストとプログラミングをするものは分けるべきだと言う議論ももちろんあるが、ここでいうテストは実装の妥当性を評価するいわゆる内部テストに相当する部分で、仕様の妥当性を検証する統合テストあるいは受け入れテストのところではない。昨今ではテスト駆動型開発という手法で広く取り入れられている方式である。

ということで、工程分離することによって生産性が向上するという可能性が少ない、むしろ悪化すると考えている。一方で機能による分離では生産性向上がみこめると考えている。

ITゼネコンうんぬんかんぬんはまた別のお話なのでいつの日か別にお話することにしたい。