『人月の神話』（にんげつのしんわ、英: The Mythical Man-Month: Essays on Software Engineering）は、フレデリック・ブルックスが著したソフトウェア工学とソフトウェアプロジェクト管理の書籍である。
概要
ブルックスの考察は、自身がIBM で OS/360 というオペレーティングシステムの開発に携わったときの失敗に基づいている。
プロジェクト管理者がソフトウェアプロジェクト管理において、繰り返し何度もこのような誤りを犯すという傾向があるため、ブルックスは自分の本について、次のような皮肉を述べている。
この本は「ソフトウェア工学の聖書」と呼ばれている。なぜなら、誰もがこの本を読んでいるが、誰もこの本で述べていることを実践しないからである。
最初に刊行されたのは1975年である。1995年に20周年記念版として再刊された。20周年記念版では、『銀の弾などない——ソフトウェアエンジニアリングの本質と偶有的事項』という論文 (エッセイ) と著者による解説が、収められている。1977年に出版された日本語訳の書籍では『ソフトウェア開発の神話』という書名であった。1996年、2002年に出版された日本語訳の書籍では『人月の神話 狼人間を撃つ銀の弾はない』の書名であった（ISBN 978-4-89471-665-0）。
本書の表紙と第1章「タールの沼」には、タールの沼と複数の獣たちの絵が描かれている（参照: #問題の所在—表紙とタールの沼）。また本書の20周年記念版で、新たに追加された第16章「銀の弾などない」の扉には、狼人間の絵が描かれている。
本書の目次
2002年に出版された日本語訳の書籍より目次を記す。なお第16章から第19章は、二十周年記念版で新たに追加された章である (初版には無かった章である) 。
人月の神話——狼人間を撃つ銀の弾はない
問題の所在—表紙とタールの沼
本書の表紙には、タールの沼と複数の獣たちの絵が描かれている。
太古の昔から、タールの沼に落ちた巨大な獣が死にもの狂いで岸に這い上がろうとしている光景ほど、鮮烈なものはない。恐竜やマンモス、それにサーベル・タイガーが、タールに捕らえられまいとしてもがく様が目に浮かぶ。激しくもがけばもがくほど、タールは一層絡みつき、どんなに力強い獣でも、また賢く器用な獣でも、ついには沈んでいってしまう。
大規模システムプログラム開発は、過去十年以上もの間そうしたタールの沼のようなものだった。そして、多くの強大な獣たちが、その中へ乱暴に突き落とされてきた。たいていは稼働システムを作り、這い上がってきたものの、目標とスケジュール、それに予算にかなったものはほとんどなかった。
規模の大小、また大量動員あるいは少数精鋭であろうとも、開発チームは次から次へとタールでがんじがらめになってしまう。問題を引き起こす原因は、一つだけではないように思われる。原因が一つだけなら、足のどれか一本くらいはタールから抜けるはずだ。だが、同時かつ相互に影響し合う要因が重なり合っているのなら、動きがどんどん遅くならざるをえない。この問題が執拗でやっかいなのは、誰にとっても驚異であり、その本質を理解することは困難である。しかし、問題を解決しようというならば、理解するように努めなくてはならない。 — フレデリック・P・ブルックス Jr.、滝沢徹、牧野祐子、宮澤昇、2002年、p.4
本書で述べられている見解
以下では、ブルックスが本書で述べている見解を説明する。
人月の神話（第二章）
まず、ブルックスは、次のような問題を指摘する。
時間が足りなかったせいで失敗したプログラミング・プロジェクトは、その他のすべての原因で失敗したプログラミング・プロジェクトよりも多い。
そして、その原因は、「人月」という考え方を使って見積もりをしているからであるとする。ブルックスは、人月の問題点を次のように指摘している。
私たちが使っている見積もり手法は、コスト計算を中心に作られたものであり、労力と進捗を混同している。人月は、人を惑わす危険な神話である。なぜなら、人月は、人と月が置き換え可能であることを暗示しているからである。
つまり、人月を使ってスケジュールを見積もることで、その見積もりが失敗し、スケジュールが遅れてしまうのである。そういう事態に陥ってしまった場合、スケジュールの遅れを取り戻すために、プロジェクトの人員を増やすという対策が取られることが多い。しかし、それでは、火に油を注ぐことになってしまうとブルックスは主張する。彼は、それを「ブルックスの法則」と呼び、以下のように定義している。
ブルックスの法則：遅れているソフトウェア・プロジェクトに人員を投入しても、そのプロジェクトをさらに遅らせるだけである。
そして、ブルックスは、その法則が成り立つ理由を以下のように分析している。
ソフトウェア・プロジェクトに人員を追加すると、全体として必要となる労力が、次の3つの点で増加する。すなわち、再配置そのものに費やされる労力とそれによる作業の中断、新しい人員の教育、追加の相互連絡である。
したがって、人員を追加することで、遅れているプロジェクトに対処することはできない。そこで、ブルックスは、スケジュールが遅れているときには、
- スケジュールを立て直す
- 仕事の規模を縮小する
ことを提案している。ちなみに、ブルックスは、次のような目安で、スケジュールを運用している。
私の大まかなやり方は、スケジュールの1/3を設計に、1/6をコーディングに、1/4をコンポーネント・テストに、1/4をシステム・テストに割り当てるというものである。
外科手術チーム（第三章）
外科手術チームでは、一人の外科医が指揮を執る。そして、その外科医は最も重要な作業を行う。一方、他のメンバーは、その外科医を補助したり、それほど重要ではない仕事をする。このやり方は、ソフトウェアプロジェクトにも活用できる。つまり、一人の「優秀な」プログラマが、重要なシステム・コンポーネントを開発し、他のメンバーが、そのプログラマに対して、必要なものを提供する。
コンセプトの完全性（第四章）
ブルックスは、システム開発において、コンセプトを統合することの重要性を指摘する。
コンセプトが統合されたシステムは、より速く作り上げられるし、より速くテストできる。
そして、コンセプトを統合するためには、次のことが必要であると主張する。
基本設計と実装を分離することは、非常に大きなプロジェクトでコンセプトを統合するうえで、非常に強力な方法である（これは、小さなプロジェクトにおいても当てはまる）。
さらに、基本設計（アーキテクチャ）と実装を分離するためには、次のことが必要である。
コンセプトを統合するためには、設計は、一人の人間から、合意の取れている小さなグループへと進まなければならない。
つまり、システムの基本設計は、一人または少数のアーキテクトがするのである。したがって、誰かが「非常に気の利いた」考えを思いついたとしても、その考えがシステム全体の設計にうまく適合しないのであれば、却下される。
セカンドシステム症候群（第五章）
セカンドシステムは、人間が設計したものの中で、最も危険である。なぜなら、作り込みすぎてしまうというのが、一般的な傾向だからである。
パイロットシステム（第十一章）
ブルックスは、パイロットプラントという考え方を紹介する。
化学エンジニアは、プロセスを実験台から工場にそのまま持ち込まない。彼らは、規模を拡大し、保護されていない環境で操作するという経験を積むために、パイロット・プラントを作る。
そして、ブルックスは、その考え方をソフトウェア・プロジェクトでも活用するべきであると主張する。
この中間の手順は、プログラミング製品にも同じように必要である。しかし、ソフトウェア・エンジニアは、実際の製品の納品に着手する前に、規則として試作のシステムを実地テストにかけるということをいまだに行っていない。
ブルックスによると、最初に作られるシステムは、粗悪である。
多くのプロジェクトでは、最初に作られたシステムは、ほとんど使えない。なぜなら、遅すぎるし、大きすぎるし、使いにくいからである。これら3つがすべて揃っている場合もある。
ブルックスは、そこから次のように主張する。
使い捨てであるはずのファーストシステムをユーザに納品すれば、時間稼ぎにはなるだろう。しかし、結局は、ユーザを激しく苦しめ、再設計をしているときにシステムをサポートしている開発者をイライラさせ、製品の評判が取り返しのつかないほど悪くなるだけである。
そのため、次のようなことが起こる。
したがって、捨てるプランを立てるべきである。いずれにせよ、そうするだろう。
ファーストシステムが捨てられた後に開発されるシステムをセカンドシステムという。このセカンドシステムは、ファーストシステムより洗練されている。このセカンドシステムを製品として納品するべきである。
その他
- 進捗の追跡
「プロジェクトは、どのようにして一年も遅れるようになるのか…一日ずつ」
- 多くの方面において増加する遅延が蓄積して、全体として大幅な遅延という結果になってしまう。細かい粒度でのそれぞれのマイルストーンごとに継続的に注意することが、各水準の管理 (マネジメント) では必要である。
- マニュアル
- 主席アーキテクトが作成したアーキテクチャは、マニュアルとして役割を果たす。したがって、マニュアルは、システムの外部仕様を詳細に記述していなければならない。ここで「詳細に記述する」とは、利用者がシステムを使用するときに見えるものをすべて記述するということである。そして、マニュアルは、実装担当者やシステム利用者から意見が寄せられたときには、改訂するべきである。
- 形式に即した文書
- 全てのソフトウェアプロジェクト管理者は、形式に即した文書の小さな中核となるセットを作成するべきである。この形式に即した文書の小さなセットは次の役割を果たす。
- プロジェクトの目標群に向けた道標
- プロジェクトの目標群をどのようにして達成するかについての道標
- 目標群の達成を担当する人物を明らかにする
- 目標のそれぞれについて、達成することを予定している時期
- 目標のそれぞれについて、必要となる費用
- 形式に即した文書の小さなセットはまた、プロジェクトの遂行に不整合があることも明確に示す。こうした不整合は、形式に即した文書の小さなセットが無い場合は、その存在を認識することが難しい。
- プロジェクトの見積り
- ソフトウェアプロジェクトの時間の見積りをするときには、コンパイラ (製品としての品質水準をもつソフトウェア) を開発することは、アプリケーションソフトウェアを開発することよりも、3倍難しい作業であるということを憶えておくべきである。そしてシステムプログラム (オペレーティングシステム、製品としての品質水準をもち且つシステムとして統合されたソフトウェア) を開発することは、コンパイラを開発することよりも、さらに3倍難しい作業である。
- また、1週間の作業のうち何時間を、技術的な問題に取り組むことに費すかについて、心に留めておくべきである。このことは管理に費す時間や技術的ではない問題 (会議や療養休暇など) に費す時間について考えることよりも、重要なことである。
- コミュニケーション
チームは、できるだけたくさんの方法で、お互いに連絡を取るべきである。非公式には、いつものプロジェクト会議で、技術的なブリーフィングで、共有の公式プロジェクトワークブックで（そして、電子メールで）。
- プログラマは、何かを仮定するべきではない。つまり、プログラマは、自分が実装する機能について曖昧なところがあれば、自分で勝手に想像するのではなく、アーキテクトに機能の意図するところを明確にするために質問をするべきである。
- コードの凍結とシステムのバージョン
- ソフトウェアは、目に見えない。そのため、新しいシステムは、それが完成したときには、まだ十分に理解されていない。利用者がそれを使うようになったときに、初めて理解されるのである。つまり、利用者は、新しいシステムを使うことを通して、そのシステムを深く理解するのである。そして、システムについての理解が深まると、利用者は、システムに異なる要求をするかもしれない。そして、システムは、利用者が変更した要求に合わせて、変更されるべきである。システム要求の変更は、ある時点までは可能であるが、ある時点を境にして、コードが凍結されるべきである。なぜなら、そうしなければ、システムは、永久に完成しないからである。そして、そのとき受け入れられなかった変更要求は、そのシステムの次のバージョンまで延期される。
- 切れ味のいいツール
- プログラマは、それぞれ個別のツールを使うべきではない。プロジェクトでは、指定されたツールを作る担当者を決めておくべきである。ツール作成担当者は、プロジェクトチームが行っている仕事のために、高度にカスタマイズされたツールを作成する。たとえば、仕様を基にしてコードを生成するコードジェネレータを作るなどである。また、システム全体で使われるツールは、共通ツールチームで開発するべきである。なお、共通ツールチームは、プロジェクトマネージャの監督下におかれる。
- ソフトウェア開発の費用を抑える
- ブルックスは、ソフトウェア開発の費用を抑えるうえで、二つの方法を挙げている。
- システムのアーキテクチャが完成してから、プログラマをプロジェクトに参加させる(なぜなら、システムの基本設計を完成させるには、何ヶ月もかかることが多いため、そのときにプロジェクトに参加したところで、プログラマは何もすることがないからである)。
- ソフトウェアをすべて開発するのではなく、「すぐに手に入る」ソフトウェアがすでにあれば、それを購入する。
- 銀の弾などない——ソフトウェアエンジニアリングの本質と偶有的事項
- ブルックスが1986年に発表した論文である。『人月の神話 20周年記念版』では、第16章として収められた。「銀の弾丸」として魔法のようにすぐに役に立ちプログラマの生産性を倍増させるような技術や特効薬は、今後10年間 (1986年の時点から10年の間) は現れないだろう。そもそも、ソフトウェア開発の複雑性には、「本質的な複雑性」と「偶有的な複雑性」とがある。これまで、ソフトウェア開発者は、高水準プログラミング言語、タイムシェアリングシステム、統一されたプログラミング環境により、偶有的な複雑性の多くをやっつけてきた。しかし、現在 (1986年) のプログラマは、ほとんどの時間を本質的な複雑性に取り組むことに費している。
- ブルックスは、次のことを提案している。
- 購入できるものをあえて構築しないようにするための大市場の利用。
- ソフトウェア要件の確立に際し、開発循環計画の一部として、迅速なプロトタイピングを使用すること。
- 実行と使用とテストが行われるにつれて、より多くの機能をシステムに追加しながら、ソフトウェアを有機的 (系統的) に成長させること。
- 若い世代の素晴らしいコンセプトデザイナーを発掘し、育てること。
— (フレデリック・P・ブルックス Jr.、滝沢徹、牧野祐子、宮澤昇、2002年、第16章、P.166)
- 「銀の弾などない」再発射
- 詳細は銀の弾などない#「銀の弾などない」再発射を参照。ブルックスが『銀の弾などない』の9年後に発表した論文である。『人月の神話 20周年記念版』では、第17章として収められた。『銀の弾などない』で主張した「銀の弾はない」という見解は、変わらない。また、オブジェクト指向プログラミングは成長が遅かったが、少しずつ成果が出ている。
- 「人月の神話」から二十年を経て
- ブルックスが『人月の神話』の初版を出版してから20年後に書いたエッセイである。『人月の神話 20周年記念版』では、第19章として収められた。『人月の神話』の初版を書いた当時と変わらず現在も正しいこと、今になってみると間違っていたと思うこと、もう時代遅れになっていること、ソフトウェア・エンジニアリングにおいて本当に新しいこと、などについて書かれている。なお、「コンセプトの完全性」は正しかったと述べているが「パイロットシステム」については誤りであったと述べている。
引用
第二章
- カレンダーの時間が足りなかったせいで失敗したプログラミング・プロジェクトは、その他のすべての原因で失敗したプログラミング・プロジェクトよりも多い。
- More programming projects have gone awry for lack of calendar time than for all other causes combined.
- 私たちが使っている見積もり手法は、コスト計算を中心に作られたものであり、労力と進捗を混同している。人月は、人を惑わす危険な神話である。なぜなら、人月は、人と月が置き換え可能であることを暗示しているからである。
- Our estimating techniques, built around cost-accounting, confuse effort and progress. The man-month is a fallacious and dangerous myth, for it implies that men and months are interchangeable.
- 多数の人々の中で、仕事を再配分することによって、さらなるコミュニケーションの労力が発生する。すなわち、教育と相互連絡である。
- Partitioning a task among multiple people occasions extra communication effort ― training and intercommunication.
- 私の大まかなやり方は、スケジュールの1/3を設計に、1/6をコーディングに、1/4をコンポーネント・テストに、1/4をシステム・テストに割り当てるというものである。
- My rule of thumb is 1/3 of the schedule for design, 1/6 for coding, 1/4 for component testing, and 1/4 for system testing.
- ブルックスの法則：遅れているソフトウェア・プロジェクトに人員を投入しても、そのプロジェクトをさらに遅らせるだけである。
- Brooks's Law: Adding manpower to a late software project makes it later.
- ソフトウェア・プロジェクトに人員を追加すると、全体として必要となる労力が、次の3つの点で増加する。すなわち、再配置そのものに費やされる労力とそれによる作業の中断、新しい人員の教育、追加の相互連絡である。
- Adding people to a software project increases the total effort necessary in three ways: the work and disruption of repartitioning itself, training the new people, and added intercommunication.
第三章
- 非常に優秀なプロのプログラマは、下手なプログラマの10倍の生産性がある。たとえ、同じ訓練と2年間の経験を経ているとしても（ザックマン、グラント、エリックソン）。
- Very good professional programmers are ten times as productive as poor ones, at same training and two-year experience level. (Sackman, Grant, and Erickson)
- 主任プログラマと外科手術チームの組織を採用すると、コミュニケーションが徹底的に削減されるので、少人数で設計することで、製品の統合性が見込める。また、多人数で開発することで、全体的な生産性も見込める。
- A chief-programmer, surgical-team organization offers a way to get the product integrity of few minds and the total productivity of many helpers, with radically reduced communication.
第四章
- 「概念上の統合性は、システム設計における最重要事項である」。
- "Conceptual integrity is the most important consideration in system design."
- コンセプトを統合するためには、設計は、一人の人間から、合意の取れている小さなグループへと進まなければならない。
- To achieve conceptual integrity, a design must proceed from one mind or a small group of agreeing minds.
- 「基本設計と実装を分離することは、非常に大きなプロジェクトでコンセプトを統合するうえで、非常に強力な方法である」（これは、小さなプロジェクトにおいても当てはまる）。
- "Separation of architectural effort from implementation is a very powerful way of getting conceptual integration on very large projects." [Small ones, too.]
- コンセプトが統合されたシステムは、より早く作り上げられるし、より早くテストできる。
- A conceptually integrated system is faster to build and to test.
第五章
- セカンドシステムは、人間が設計したものの中で、最も危険である。なぜなら、作り込みすぎてしまうというのが、一般的な傾向だからである。
- The second is the most dangerous system a person ever designs; the general tendency is to over-design it.
第六章
- たとえ設計チームが大きなものであっても、小さな決定を一貫させるためには、一人か二人の人間が設計をすることになる。
- Even when a design team is large, the results must be reduced to writing by one or two, in order that the minidecisions be consistent.
- 重要なのは、設計者が、実装する人の質問に対して、電話で応答して説明することである。そして、そのやりとりを記録して公開することは、必須事項である（電子メールは、今や選択肢の一つである）。
- It is important to allow telephone interpretations by an architect in response to implementers' queries; it is imperative to log these and publish them. [Electronic mail is now the medium of choice.]
第七章
- チームは、できるだけたくさんの方法で、お互いに連絡を取るべきである。非公式には、いつものプロジェクト会議で、技術的なブリーフィングで、共有の公式プロジェクトワークブックで（そして、電子メールで）。
- Teams should communicate with one another in as many ways as possible: informally, by regular project meetings with technical briefings, and via a shared formal project workbook. [And by electronic mail.]
第八章
- プログラミングは、プログラムサイズの累乗で、増大する。
- Programming increases goes as a power of program size.
- 発表されているいくつかの研究によると、およそ1.5乗である（ベームのデータは、これと完全に一致していないが、1.05乗～1.2乗の誤差である）。
- Some published studies show the exponent to be about 1.5. [Boehm's data do not at all agree with this, but vary from 1.05 to 1.2.]
- 適切な高水準言語を使えば、プログラミングの生産性が、5倍も上昇する可能性がある。
- Programming productivity may be increased as much as five times when a suitable high-level language is used.
第十二章
- 高水準言語とインタラクティブ・プログラミングが広く採用されていないのは、ひとえに怠惰と無気力である。
- Only sloth and inertia prevent the universal adoption of high-level language and interactive programming.
- 高水準言語を使うことで、生産性が向上するだけでなく、デバッグ作業も楽になる。なぜなら、バグが少なく、おまけに見つけやすいからである。
- High-level language improves not only productivity but also debugging; fewer bugs and easier to find.
初版のエピローグ
- ソフトウェアシステムは、（異なる部品の種類の数の点から言えば、）人間が作ったものの中で、おそらく最も難解で複雑なものである。
- Software systems are perhaps the most intricate and complex (in terms of number of distinct kinds of parts) of the things humanity makes.
- 今後長い間、ソフトウェア・エンジニアリングというタールの沼は、厄介なものであり続けるだろう。
- The tar pit of software engineering will continue to be sticky for a long time to come.
参考文献
- The Mythical Man-Month : essays on software engineering, Brooks, F. P., Addison Wesley, 1975, ISBN 978-0201006506
- The Mythical Man-Month : essays on software engineering (Anniversary Edition with four new chapters), Brooks, F. P., Addison Wesley, 1995, ISBN 978-0201835953
関連項目
外部リンク
