katapedia

人月の神話

第1章 タールの沼

プログラミングの作業は、「私たちの奥深くに備わっている創造性の欲求を満たしてくれる」。また、「私たちが人間として共通に持っている感覚を楽しませてくれる」。そこには、5つの種類の喜びがある。

• ものを作る喜び。
• 他の人々にとって、便利なものを作る喜び。
• 連動する部品のものをパズルのように組み合わせる魅力。
• 常に学ぶ喜び。そして、繰り返しの仕事がない喜び。
• とても素直な媒体で仕事をする喜び。それは、純粋な思考物である。しかし、それでもなお、その媒体は、文字オブジェクトができない方法で、存在し、運動し、仕事をするのである。

プログラミングの作業には、特別な苦悩が本来的に備わっている。

• プログラミングをするうえで、完全性の要求に合わせることは、もっとも大変なことである。
• 他の人が方針を決めるため、自分自身がコントロールできないもの（特にプログラム）に頼らなくてはいけない。つまり、権限と責任が釣り合っていないのである。
• 創造性は、「つらい仕事をするというつまらない時間」と一緒ににやって来る。プログラミングも例外ではない。
• 終わりに近づくにつれて、プログラミング・プロジェクトは、ゆっくりとまとまる。
• 製品は、完成するまでの間、常に老朽化の危機に瀕している。紙に描かれた虎は、実際に使われることが望まれないかぎり、本物の虎には敵わない。

第2章 人月の神話

• カレンダーの時間が足りなかったせいで失敗したプログラミング・プロジェクトは、その他のすべての原因で失敗したプログラミング・プロジェクトよりも多い。
• おいしい料理には、時間がかかる。急がせると、必ず結果を損なってしまうような仕事がある。
• プログラマは、みんな楽観主義で、「すべてうまくいくだろう」と思っている。
• プログラマは、純粋な思考物で開発する。したがって、実装にあたって、困難をほとんど予測できない。
• しかし、人間の考えは、それ自体が不完全である。そのため、バグを抱えることになる。
• 私たちが使っている見積もり手法は、コスト計算を中心に作られたものであり、労力と進捗を混同している。人月は、人を惑わす危険な神話である。なぜなら、人月は、人と月が置き換え可能であることをほのめかしているからである。
• 多数の人々の中で、仕事を再配分することによって、さらなるコミュニケーションの労力が発生する。すなわち、教育と相互連絡である。
• 学問として、私たちには、見積もりデータが不足している。
• スケジュールの見積もりは、不確かである。そのため、私たちは、しばしばマネジメントや顧客の圧力から、スケジュールの見積もりを頑なに擁護することができない。
• ブルックスの法則：遅れているソフトウェア・プロジェクトに人員を投入しても、そのプロジェクトをさらに遅らせるだけである。
• ソフトウェア・プロジェクトに人員を追加すると、全体として必要となる労力が、次の3つの点で増加する。すなわち、再配置そのものに費やされる労力とそれによる作業の中断、新しい人員の教育、追加の相互連絡である。

第3章 外科チーム

• 非常に優秀なプロのプログラマは、下手なプログラマの10倍の生産性がある。
• 小さく抜け目のないチームには、人数ができるだけ少ないのが一番である。

第4章 貴族政治、民主主義、システム設計

• 「コンセプトの統合性(integrity)は、システム設計における最重要事項である」。
• コンセプトを統合するためには、設計は、一人の人間から、合意の取れている小さなグループへと進まなければならない。
• 「基本設計と実装を分離することは、非常に大きなプロジェクトでコンセプトを統合するうえで、非常に強力な方法である」（これは、小さなプロジェクトにおいても当てはまる）。
• 「システムのコンセプトを統合するためには、誰かがそのコンセプトをコントロールしなければならない。そして、これは、貴族主義であり、そこに弁解の余地ない」。

第5章 セカンドシステム症候群

• 早い時期からの絶え間のないコミュニケーションによって、はっきりとした責任の分担を曖昧にすることなく、設計者は文書を読む量が少なくなり、開発者は設計に自信を持つようになる。

第6章 指示を伝える

• たとえ設計チームが大きなものであっても、小さな決定を一貫させるためには、一人か二人の人間が設計をすることになる。

第7章 バベルの塔は、なぜ失敗したのか

• バベルの塔プロジェクトは、コミュニケーションの不足とそれによる結果のせいで、失敗した。

第8章 予告ホームラン

• 単にコーディングの時間を見積もり、それをその他のタスクの係数と掛けるだけでは、プログラミングプロジェクトの全体的な労力やスケジュールを正確に予測することはできない。
• プログラミングは、プログラムの規模の累乗で、増大する。（およそ1.5乗）

第9章 5ポンドの袋に入った10ポンド

• 全体的なシステムとユーザ志向の態度を育てることは、おそらくプログラミング・マネージャの一番重要な機能であるだろう。

第10章 ドキュメントの仮説

• 書類の渦の中では、少数のドキュメントが、重要な軸になる。そして、その軸を中心として、すべてのプロジェクト・マネジメントがまわるのである。この少数のドキュメントが、マネージャにとって最も重要な個人ツールである。

第11章 一つは捨てる計画

• プログラマの役割は、実際の製品を届けるということではなく、ユーザの要求を満足させることである

変更を見越した組織作りの計画

• 広く使われているプログラムを保守するために費やされる全体的な生涯コストは、だいたい開発コストの40%かそれ以上である。
• 不具合を修正すると、他の不具合が起こる可能性が、相当（20～50％）ある。

第12章 切れ味のいいツール

• システムのデバッグは、天文学と同じように、昔からだいたい夜に行われる。

第13章 全体と部分

• システムをデバッグしている間は、一度に加えるコンポーネントは一つにするべきである。

第14章 大失敗を生み出す

• 「プロジェクトは、どのようにして一年も遅れるようになるのか…一日ずつ」
• 日々のスケジュールの遅れは、見分けがつきにくく、防ぎにくく、災難よりも補いにくい。
• 厳しいスケジュールで、大規模プロジェクトをコントロールするためには、まずマイルストーンとその日付からなるスケジュールを立てることである。
• マイルストーンは、具体的で、明確で、ナイフの刃のような切れ味で定義された測定可能な事柄でなければならない。
• プログラマは、マイルストーンの進み具合について、めったに嘘をつかない。マイルストーンが非常に鋭いために、プログラマが自分に嘘をつけないのであれば。
• スケジュールが何度も遅れると、やる気がなくなってしまう
• やる気は、すばらしいプログラミングチームに必要不可欠である。それは、すばらしい野球チームとまったく同じである。
• 見直しのテクニックを持っていなければならない。そのテクニックによって、本当の状況が白日の下に晒されるのだ。そして、このために、マイルストーンのスケジュールと完全なドキュメントが鍵となるのである。
• ヴィソツキー：「計画的なデータ」（上司のデータ）と「見積もりのデータ」（最低レベルのマネージャのデータ）の両方をマイルストーン報告書に入れることが、非常に便利であることがわかった

第15章 もう一方の顔

• フローチャートは、プログラム・ドキュメンテーションの中で、最も過大評価されている。非常に詳細なフローチャートは、不愉快であるだけでなく、高水準言語で書かれるようになったことで、時代遅れなものになってしまった

エピローグ

• ソフトウェアシステムは、（異なる部品の種類の数の点から言えば、）人間が作ったものの中で、おそらく最も難解で複雑なものである。
• 今後長い間、ソフトウェア・エンジニアリングというタールの沼は、厄介なものであり続けるだろう。

https://sites.google.com/site/sicpjp/omake/manmonth