【書籍紹介】「人月の神話」フレデリック・P・ブルックス Jr.
前回は富士通がIBMメインフレームの機密情報の入手をめぐる書籍を紹介した。今回は、そのIBMメインフレームの原点となったSystem/360およびそのOSであるOS/360開発についての書籍を紹介する。
著者は、System/360、およびオペレーティングシステムOS/360の開発チームのリーダーであった。その時の経験をもとに出版されたのが「The Mythical Man-Month」(1975年)である。1982年の日本語版では「ソフトウェア開発の神話」というタイトルだったが、1996年に出版された原書発行20周年記念増補版は原書名の直訳である「人月の神話」となった。「人月」は「1人の1か月の労働力」の意味である。その後、出版社を変えて2002年に新装版が出版され、現在入手できるのは2014年に丸善出版から発売されたものだ。2002年版との違いは縦書きから横書きになったことと、誤植の修正のみで内容の差はない。
System/360とOS/360の開発にかかった費用はおよそ50億ドルと言われる。これだけ大規模なコンピュータプロジェクトは世界で初めてのことであり、多くの問題点が明らかになった。
最も有名な言葉は「遅れているプロジェクトに人員を投入するとさらに遅れる」だろう。現在では、人員を増強するときは事前教育やコミュニケーションに細心の注意が払われる。それでも、一時的な効率低下は避けられないし、配慮なしに人員を増強するケースもまだまだ多い。
もう1つの有名な言葉が「銀の弾丸は存在しない」である。原文は「There is no silver bullet」で、「特効薬はない」と訳されることもある。「銀の弾丸を使えば狼男を一発で倒せる」という言い伝えに由来する。これ以来、コンピュータ業界では「銀の弾丸」はほとんど常に「あり得ない方法」という否定的な意味で使われるようになった。詳しくは、以前Windows Server World誌に書いたコラムを公開しているので、そちらを読んで欲しい。
System/360の開発が難航したこと、その後のマルチユーザーシステム「Multics」の経験から「ソフトウェア工学」の重要性が認識されるようになったという。
Multicsは、マサチューセッツ工科大学(MIT)や、AT&Tベル研究所、ゼネラルエレクトリック社(GE)が参加したプロジェクトで、1台のコンピュータを多人数で使う「タイムシェアリングシステム(TSS)」の開発プロジェクトだった。Multicsは、斬新で高度なシステムだったが、あまりにも複雑でベル研究所が最初に離脱、GE社はコンピュータ部門ごとハネウエルに売却した。そして、ハネウエルはMulticsを商品化したものの、商業的には成功しなかった。
Multicsの失敗は、多人数で多くの機能を実装する巨大プロジェクトだったことにあると考えたベル研究所のケン・トンプソンは、小型でシンプルなOSを独自に設計する。これが後のUNIXである。
UNIXの思想はLinuxに受け継がれ、1人または少数の人間が基本構造を決めることで、必要以上に複雑になることを抑えている。つまり「複雑なものは避けて、単純なものを採用しろ」ということである。実際のLinuxシステムは相当複雑になっているが、カーネル部はリーナス・トーバルズ氏ら少数の人間で管理されている。
一方で、巨大で複雑なシステムの進捗を管理する手法も進歩した。基本的なアイデアは、「複雑なものは単純なものに分割せよ」ということである。IBMは現在もOS/360の後継システムz/OSの開発を続けている。マイクロソフトのWindowsも厳密に組織的に管理された開発プロジェクトだと思われる。
結果的に異なる開発管理手法を採用したLinuxとWindowsだが、問題点の認識はいずれもOS/360プロジェクトにあると考えてよいだろう。
さて、著者のフレデリック・ブルックスはこんなことを言っているそうである。
この本は「ソフトウェア工学のバイブル」と呼ばれている。なぜなら誰もがこの本を読んでいるが、誰もこの本で述べていることを実践しないからである(出典: Wikipedia「人月の神話」)。なるほど、聖書に書いてあることを正しく実践している人は少数派だろう。
出版から35年以上を経て、今でも成り立つこともあれば、成り立たないこともある。プロジェクト全体を通しての「銀の弾丸」は存在しないが、単純なコーディングだけなら生産性は劇的に向上している。マイクロソフトのVisual Studioに代表される統合開発環境は、リアルタイムに文法をチェックしてくれるし、ライブラリ関数の引数のヒントも出してくれる。ソースコード管理システムやテストツールも充実してきた。
一方で、以前よりは格段に進歩しているものの、プロジェクト管理やコミュニケーションについてはまだまだ改善の余地がある。これは、自動化できる部分とできない部分の差である。
大規模なソフトウェア開発に携わる人はぜひ読んで欲しい1冊である。
本記事は2012年4月4日付で「Computer World」に掲載された記事に若干の修正を加えました。