神話の人月

神話の人月

初版
著者	フレッド・ブルックス
言語	英語
主題	ソフトウェア プロジェクト管理
出版社	アディソン・ウェズリー
発行日	1975
出版地	アメリカ合衆国
番号	978-0-201-00650-6 (1975年版)、978-0-201-83595-3 (1995年版)
デューイ十進分類法	001.6/425
LCクラス	QA76.6 .B75

『The Mythical Man-Month: Essays on Software Engineering』は、フレッド・ブルックスによるソフトウェア エンジニアリングとプロジェクト管理に関する書籍で、1975 年に初版が出版され、その後 1982 年と 1995 年に版が出版されました。その中心となるテーマは、スケジュールが遅れているソフトウェア プロジェクトに人員を追加すると、プロジェクトがさらに遅れるというものです。この考え方はブルックスの法則として知られており、第 2 システム効果やプロトタイピングの推奨とともに提示されています。

ブルックスの観察は、 IBMでOS/360の開発を管理していたときの彼の経験に基づいています。彼は、スケジュールが遅れているプロジェクトにプログラマーを追加したのですが、後に彼は、その決定が直感に反してプロジェクトをさらに遅らせたと結論づけました。また、彼は、ALGOL コンパイラーの作成に関わる 1 つのプロジェクトには、関わる労働者の数に関係なく 6 か月かかると断言するという間違いも犯しました (実際にはもっと長くかかりました)。マネージャーがプロジェクト開発でこのような間違いを繰り返す傾向があることから、ブルックスは、彼の著書は「誰もが引用し、一部の人が読み、少数の人がそれに従う」ため「ソフトウェア エンジニアリングのバイブル」と呼ばれていると冗談を言いました。^[1]

この作品は1975年に初めて出版され（ISBN 0-201-00650-2）、^[2] 1982年に訂正を加えて再版され、1995年には記念版として4つの追加章を加えて再版され（ISBN 0-201-83595-9 ）、著者の解説付きの エッセイ「銀の弾丸はない」の再版も含まれていた。  

ブルックスは、スケジュールの失敗の原因をいくつか論じています。最も長く議論されているのは、ブルックスの法則に関するものです。 遅れているソフトウェア プロジェクトに人員を追加すると、プロジェクトはさらに遅れます。人月は、 1 人の作業者が 1 か月間に行う作業を表す仮想的な作業単位です。ブルックスの法則は、人月で有用な作業を測定できる可能性は神話であると主張しており、これが本書の中心となっています。

複雑なプログラミング プロジェクトは、作業者間のコミュニケーションや、タスクとそれを実行する作業者間の一連の複雑な相互関係を確立することなく作業できる個別のタスクに完全に分割することはできません。

したがって、スケジュールが遅れているプロジェクトにさらに多くのプログラマーを割り当てると、プロジェクトはさらに遅れることになります。これは、新しいプログラマーがプロジェクトについて学習するために必要な時間と、コミュニケーションのオーバーヘッドの増加により、カレンダー上で利用可能な時間がますます消費されるためです。n人の人々が互いにコミュニケーションを取る必要がある場合、n が増加するにつれて、彼らの成果は減少し、n がマイナスになると、人が追加されるごとにプロジェクトはさらに遅れます。

• グループ相互通信式: n ( n − 1)/2。
• 例: 50 人の開発者の場合、通信チャネルは 50 × (50 – 1)/2 = 1,225 になります。

ブルックスは、 『The Mythical Man-Month』の記念版に「銀の弾丸はない - ソフトウェア エンジニアリングの本質と偶然」という章を追加し、さらに「『銀の弾丸はない』の再燃」という章でその考察をさらに深めました。

ブルックス氏は、特効薬は存在しないと主張している。「技術面でも管理手法面でも、生産性、信頼性、簡素性において10年以内に1桁（10倍）の改善を約束する単一の開発は存在しない。」

この議論は、偶然の複雑さと本質的な複雑さの区別に依存しており、これはアムダールの法則が「並列化可能」と「厳密に直列」の区別に依存しているのと同様です。

セカンドシステム効果とは、建築家が 2 番目のシステムを設計する場合、時間的な制約により最初のシステムに追加しなかったすべての追加要素を組み込む傾向があるため、そのシステムが設計者にとって最も危険なシステムになるというものです。したがって、エンジニアは 2 番目のシステムに着手する場合、過剰設計になりやすいことに留意する必要があります。

著者は、適度に複雑なシステムには、減らすことのできない一定の数のエラーが存在すると観察しています。観察されたエラーを修正しようとすると、他のエラーが導入される傾向があります。

Brooks 氏は、「質問: 大規模なソフトウェア プロジェクトが 1 年遅れるのはなぜか? 答え: 1 日ずつ遅れている!」と書いています。さまざまな面で少しずつ遅れが積み重なって、最終的には全体的な大きな遅れにつながります。管理の各レベルで、小さな個々のマイルストーンを達成することに継続的に注意を払う必要があります。

ユーザーフレンドリーなシステムを作るには、システムの概念的整合性が必要ですが、これはアーキテクチャと実装を分離することによってのみ実現できます。ユーザーに代わって行動する 1 人のチーフ アーキテクト (または少数のアーキテクト) が、システムに何を取り入れ、何を除外するかを決定します。アーキテクトまたはアーキテクトのチームは、システムが何をすべきかについてのアイデアを考案し、このビジョンがチームの他のメンバーに理解されていることを確認する必要があります。誰かの斬新なアイデアは、システム全体の設計にシームレスに適合しない場合は、取り入れられない場合があります。実際、ユーザーフレンドリーなシステムを確保するために、システムは意図的に、その能力よりも少ない機能を提供する場合があります。つまり、システムが複雑すぎて使用できない場合、多くの機能が使用されず、誰もそれらを学ぶ時間がないということです。

チーフアーキテクトはシステム仕様のマニュアルを作成します。マニュアルにはシステムの外部仕様、つまりユーザーが目にするすべての内容が詳細に記述されている必要があります。実装チームやユーザーからのフィードバックに応じてマニュアルを変更する必要があります。

新しい種類のシステムを設計する場合、チームは使い捨てのシステムを設計します (意図的かどうかは関係ありません)。このシステムは「パイロット プラン」として機能し、その後システムの完全な再設計につながる手法を明らかにします。パイロットシステムの配布は顧客に苦痛を与えるだけで、システムの評判、さらには会社の評判までも損なう可能性があるため、この 2 番目のよりスマートなシステムを顧客に配布する必要があります。

すべてのプロジェクト マネージャーは、プロジェクトの目的、その達成方法、達成者、達成時期、コストを定義する正式な文書の小規模なコア セットを作成する必要があります。これらの文書により、他の方法では見つけにくい矛盾が明らかになることもあります。

プロジェクト時間を見積もる際には、プログラミング製品（有料顧客に販売できるもの）とプログラミング システムは、単純な独立した社内プログラムよりも 3 倍も作成が難しいことを覚えておく必要があります。^[3]管理業務やその他の非技術的なタスク（会議、特に「スタンドアップ」または「全員参加」の会議など）ではなく、技術的な問題に実際に費やす作業時間が週のどのくらいになるかに留意する必要があります。

災害を回避するには、プロジェクトに携わるすべてのチームが、できるだけ多くの方法 (電子メール、電話、会議、メモなど) で互いに連絡を取り合う必要があります。実装者は、何かを想定するのではなく、完全に間違っている可能性のある想定で作業を進める前に、アーキテクトに実装する機能の意図を明確にするよう依頼する必要があります。アーキテクトは、プロジェクトの全体像を策定し、それを他の人に伝える責任があります。

手術中の外科チームが、最も重要な作業を行う外科医 1 名によって率いられ、それほど重要でない部分の補助をチームに指示するのと同じように、重要なシステム コンポーネントの開発を「優秀な」プログラマーに任せ、チームの残りのメンバーが適切なタイミングで必要なものを提供するというのは合理的であるように思われます。さらに、Brooks 氏は、「優秀な」プログラマーは一般に、平凡なプログラマーの 5 ～ 10 倍の生産性があると述べています。

ソフトウェアは目に見えません。したがって、多くのことは、新しいシステムで一定量の作業が行われ、ユーザーがそれを体験できるようになって初めて明らかになります。この体験から洞察が得られ、ユーザーのニーズやユーザーのニーズに対する認識が変わります。したがって、システムは、ユーザーの変更された要件を満たすように変更する必要があります。これは、ある時点までしか実行できません。そうでなければ、システムが完成しない可能性があります。ある日付では、システムへのそれ以上の変更は許可されず、コードは凍結されます。変更のすべての要求は、システムの 次のバージョンまで延期する必要があります。

各プログラマーが独自の特別なツールセットを持つのではなく、各チームには、チームが行っている仕事に合わせて高度にカスタマイズされたツールを作成できる指定のツール作成者が必要です (例: 仕様に基づいてコードを作成するコード生成ツール)。さらに、システム全体のツールは、プロジェクト マネージャーの監督の下、共通のツール チームによって構築される必要があります。

Brooks が書いているソフトウェア開発コストを削減する手法は 2 つあります。

• 実装者は、システムのアーキテクチャが完成した後にのみ雇用される可能性があります (このステップには数か月かかる場合があり、その間、時期尚早に雇用された実装者は何もすることがない可能性があります)。
• ブルックスが言及するもう 1 つの手法は、ソフトウェアをまったく開発せず、可能な場合は単に「既製品」を購入するというものです。

• アンチパターン
• コードリファクタリング
• コンウェイの法則
• ホフスタッターの法則
• ライナスの法則、「十分な数の目玉があれば、すべてのバグは浅い」という主張は『伽藍とバザール』で述べられている。
• ピープルウェア: 生産性の高いプロジェクトとチーム
• ソフトウェア開発プロセス

• ブルックス、フレデリック P. (1975)。『神話の人月』アディソン・ウェスレー。ISBN 0-201-00650-2。
• ブルックス、フレデリック P. (1983 )。「神話の人月」。PC マガジン。2 (4): 210–240。
• ブルックス、フレデリック P. (1995)。「第 17 章 『銀の弾丸はない』の再燃」。The Mythical Man-Month (記念版)。Addison- Wesley。ISBN 0-201-83595-9。

Wikiquote にフレッド・ブルックスに関する引用があります。

• ノースカロライナ大学チャペルヒル校の公式ウェブサイト
• 組織とチームのパターン
• ヘクター・コレアによる「神話の人月」と「銀の弾丸はない - 本質と偶然」の章のレビュー
• 『神話の人月』からの抜粋