30年前の本がいまでも売れている理由

　筆者は、これまでソフトウェア開発関連の翻訳書を何冊か出したことがあります。そのため、よく人から「何万部ぐらい売れたんですか？」と聞かれたりします。こうした質問の口ぶりからすると、1冊本を出版すれば半永久的に書店の棚に並び、売れ続けると思われているように感じます。しかし、現実はそんなにうまくはいきません。文芸書籍などに比べるとわずかに寿命は長いものの、華々しく書棚で平積みになるのは出版直後の1カ月ほど。それを過ぎると棚差しになって背中だけを向け、半年も売れないと書店から消えてしまう……。そんなものです。

　しかし、こうした移り変わりの激しいソフトウェア開発関連の専門書の中に、30年以上も前に出版されたのにもかかわらず、いまでも売れ続けている「お化け本」が2冊あります。

　それは、グレンフォード・マイヤーズが1978年に出した『ソフトウェア・テストの技法』と、フレデリック・ブルックスが1975年に書いた『ソフトウェア開発の神話（第2版から「人月の神話」）』です。

　30年以上前の本がいまだに売れているということは、良書であると同時に、ソフトウェアのテスト手法と開発技術が当時からほとんど進歩していない証拠でもあります。「コンピュータ・システムの処理能力や機能は、30年前に比べて飛躍的に進歩した……」とよく耳にしますが、この“飛躍的な進歩”は、ハードウェアの高性能化、低価格化が革命的に進んだ結果であり、ソフトウェアの開発自体は“30年前からほとんど進歩していない”というのが現実です。特に、生産性については昔から1000ステップ/人月という値がほとんど変わっていません。

　今回のコラムでは超ベストセラー本、『ソフトウェア開発の神話』が出版されるに至った経緯、出版後のソフトウェア開発の変化、同書の周辺トピックスを紹介したいと思います。これが分かると、ソフトウェア開発という名の「モンスター」の正体をはっきりと把握でき、対策も見えてくると思います。

　1963年、“ソフトウェア開発史上最大”、というより人類が初めて体験した非常に大きな出来事がありました。それは、IBMが本格的に仮想記憶を採用したメインフレーム用のオペレーティング・システム「OS/360」の開発プロジェクトを立ち上げたことです。人類が作ったモノの中で、圧倒的に複雑で巨大な人工物がソフトウェアだといわれていますが、1966年に完成するまで要したOS/360の総開発工数は5000人年だったそうです。また、ピーク時には1000人以上のエンジニアが従事していたとのことですので、人類史上、最も複雑で巨大なプロジェクトといえるでしょう。

　FORTRANの登場が1957年、COBOLが1960年、東京オリンピックの開催が1964年、「ソフトウェア・エンジニアリング」という言葉が初めて使用されたのが1968年でした。当時、サブルーチンの考え方が、ソフトウェアを開発するうえで「画期的」であると話題になったそうです。そのころは、システマチックに、また、工学的にソフトウェアを開発する発想はなく、アセンブリ言語で職人芸的に、芸術的にソフトウェアを作るのが主流でしたから。

　さすがに、結成した瞬間に崩壊することが分かり切っている5000人年の超巨大プロジェクトなどいまでは誰も立ち上げようとしません（しかも、それほど大規模なプロジェクトだったのにもかかわらず、OS/360開発にはきちんとした開発プロセスが存在しなかったそうです）。

　ご存じのとおり、結果的にビジネスとして大成功を収めたOS/360ですが、ソフトウェア開発の面から見るとかなり厳しい状況であったことが想像できます。スケジュールは遅れ、バグを修正するたびに新たなバグを作り込み、キーになる技術者が燃え尽きて退職し、プロジェクトは大混乱……。人ごとながらゾッとします。

　さて、ここまでOS/360開発の話をしてきましたが、実はこの人類史上最大の難関プロジェクトのマネージャが、ほかならぬフレデリック・ブルックスだったのです（有名な話ですね）。

　OS/360のドタバタ劇の余熱が冷めた10年後の1975年、その難関プロジェクトの経験を基にブルックスが書いたエッセイ集が『The Mythical Man-Month（邦題「ソフトウェア開発の神話」）』です。

　「人月（Man-Month）」を“マンモス”に掛けて、表紙にはマンモスや恐竜の絵が描いてありました。ソフトウェアの開発は、マンモスや恐竜と同様、飼い慣らすことが非常に困難であるというのがブルックスのメッセージなのでしょう。同書には、ソフトウェア開発プロジェクトがなぜ混乱するのか、なぜ遅れるのか、なぜ品質が良くならないのかが臨場感あふれるタッチで描かれています。そこに書いてある事例やノウハウは、現代のソフトウェア開発でも当てはまることが非常に多く、いつしか「ブルックスの法則」と呼ばれるようになりました。

　今回は、このブルックスの法則の中からいくつか有名な法則を紹介します。

　同書のタイトルにもなった法則がこれです。例えば、「12人×12カ月≠24人×6カ月」ということで、非常に重要な法則なのですが、意外に知られていませんし、人と月が交換可能であると信じているプロジェクト・マネージャもたくさんいます。

　世の中の「作業」には図1に示すように、分業可能なものと分業不可能なものがあります。ソフトウェアの開発は、「穴を掘る」や「皿を洗う」のように人数が倍になると時間が半分になる作業とは正反対であり、「家を建てる」と「子供を産む」の中間に位置するのではないかというのがプロの意見です。このため、開発エンジニアの人数を2倍にしても、期間は半分にはなりません。

　では、開発期間を短縮するには、技術者の数をどの程度増やせばよいのでしょうか？ ブルックスは「開発要素（人数、期間、コスト）の短縮が10％以内の場合、ほかの開発要素をそれだけ増やす必要がある」といっています。すなわち、開発期間を10％短縮したい場合、人数を10％増やせばよいことになります。

　10％といわず思い切って、開発期間を半分にしたい場合はどうでしょう？ ブルックスは「開発要素の短縮が10％以上の場合、『n²分の1の法則』を適用する必要がある」と述べています。すなわち、開発期間を半分に短縮するには、人数を4倍に増やさなければならないということになります。

　それでは、この法則に従い人数を4倍にしたとします。果たしてこれですべてがうまくいくのでしょうか？ 当然、そんなことはありません。期間が短縮できたとしても、“ソフトウェアの品質は必然的に極めて悪くなる”ということを十分に認識しておく必要があります。

　これは、非常に有名な法則なので聞いたことのある人は多いはずです。遅れを取り戻す場合、ごく一般的な対策が「増員」でしょう。しかし、“増員すると余計に遅れる”という「マーフィーの法則」みたいに逆説的な内容が非常に鮮烈で、大きなインパクトを持っており、ソフトウェア技術者の脳裏に深く刻まれました。ブルックスは「遅延回復のために人員を追加すると、『作業の再配分』『新規要員の教育』『コミュニケーション・パスの急激な増加』の3つの問題が発生するため、遅れがますます拡大する」と原因を分析しています。

　とはいえ、遅延回復には開発エンジニアを増員することが不可欠です。その場合、この法則を十分理解し、遅れが最小になるよう、また「助っ人」の効果が最大になるように配慮する必要があります。

　さて、今回は「ブルックスの法則」の中から2つの法則を紹介しました。いろいろ学ぶべきことが多いですね。というわけで、次回も引き続きいくつかの法則を見ていこうと思います。お楽しみに！