名著だと思うものの、プログラミング初心者などが読むと間違った受け取り方をしかねない、読み方が難しい本だと思ったため自分が読んで得たものなどをまとめました。
概要
人月の神話は1975年に書かれたもので1995年に時代に合わせて追記された、古くも今なお読まれているもの。
古いため一部訂正があるので読むなら19章の追記分まで読むのが必須。
追記も1995年であるため、古い情報か今なお通用する情報か判断できない段階であれば読むのを避けるのが無難。
まとめ
（ハードウェア関連の話や現在は当てはまらないものは除外している）
以下各章ごとのまとめ
第2章
・結果が惨憺たるものにならないようにするためには急かすことの出来ない仕事もある
・アイデア自体に間違いはつきものなのでバグは発生する
・人月は間違った危険な神話である
なぜなら「人」と「月」が相互に交換可能ということを示している（交換可能なわけがない）
・人が増えればその分コミュニケーションコストが増加する
・著者の目安では、全体のスケジュールに対して
デザインに1/3、コーディングに1/6、単体テストに1/4、システムテストに1/4を割り当てる
・ブルックスの法則
遅れているプロジェクトへの要員追加はさらにプロジェクトを遅らせるだけである
原因は「作業再配分とそれによる中断」「新しい要員の訓練（プロジェクトの仕様説明など）」「新たに発生するコミュニケーションコスト」
-> 追記部分にて 早期の追加であればプラスになることもある
第3章
・優秀なプログラマは10倍も生産性が高い
・少数精鋭が理想
だが、少数精鋭で大きなシステムに取り組むと開発が遅れすぎる
しかし人を闇雲に投入すると、非効率でコストばかりかかって進捗は遅くコンセプトが統合されていないシステムが出来上がる
適切に少数に切り分けたチームが必要
第4章
・コンセプトの完全性こそシステムデザインにおいて最も重要な考慮点
コンセプトの完全性を得るには、デザインは1人ないし互いに意見が同じ少人数の頭脳グループで考え出さなければならない
システムにコンセプトの完全性を求めるならば、誰かがコンセプトをコントロールしなくてはならない
・コンセプトが統合されているシステムは、より早く開発されテストができる
第5章
・実現者にも想像の責任があり、アーキテクトはただ提案するに留める
自分が指定するものの実現方法が提案できるようにしておく
しかし、いい方法があれば受け入れられるようにしておく
第6章
・デザインチームに要員がたくさんいても、細かな決断まで一貫性を持たせるため、結果的に1人か2人で書くことにする
・正確さのための定義と、わかりやすさのための定義の両方が必要
・プロジェクトマネージャの最良の友は日々の敵でもある独立した製品テスト期間
第7章
・「右手がやっていることを左手が知らない」ことが問題の原因になる
チームは可能な限り多くの方法で互いにコミュニケーションをとるべき
・チームの各メンバーは全資料を読むべき
-> 追記部分にて否定 P265付近 カプセル化（適切に隠蔽）して適切に必要な情報を知るべき
Wikiなどで資料を読める状態にはする必要がある
・組織の目的は必要となるコミュニケーションと調整作業の量を減らすこと
コミュニケーションを不要にするための作業の分担と機能の専門家を具体化したものが組織
第8章
・プロジェクト全体の労力やスケジュールは単にコーディング時間を見積もって他の比率をかけ合わせても正確に見積もりはできない
プログラミング作業はプログラムサイズの累乗になる
・ICL社のデータによると、プログラマがプログラミングやデバッグには労働時間の50％程度しか割り当てていなかった
別のデータでは完成したOSの生産性が人年あたり600行だった
・プログラミングの生産性は適切な高水準言語が仕様されると5倍も向上する可能性がある
第9章
・データやテーブルの表現をやり直すことで戦略的突破が実現されることは多い
第10章
・ソフトウェアプロジェクトに関して決定的に重要な文書は
目的、ユーザーマニュアル、内部文書、スケジュール、予算、組織図、フロアスペース配分
第11章
・1つは捨て石にするつもりで
-> 追記部分にて、前時代の話で現在は違うと否定
・メンテナンスコストは利用者数に影響を大きく受ける
利用者が多いと見つかるバグも多くなるため
また、発見されるバグの数は一度下がってから再び上昇する（ユーザーが訓練され利用範囲が広がる）
・副作用をなくすようなデザイン方法をとればメンテナンス費用の多大な削減ができる
第14章
・プロジェクトはどうして1年も遅れるか？1度に1日ずつ
・どの遅延がどの程度問題かを理解するにはクリティカルパススケジューリングに変わるものはない
第15章
・プログラムにはテストケースを用意すべき
有効な入力データ、境界線上のデータ、明らかに無効なデータ
・フローチャートは過大評価されている
時代遅れで、ほとんどのプログラマがプログラムを書いた後に書いている
個人的な所感
約50年前とは思えないほど今でも通用することが多々書かれている。
1975年からずっと言われているようなことは理解して吸収しておけるに越したことはない。
内容はまとめで書いたとおりなのでそれ以外のところで付け足すと、
50年前からすでに「"人月"なんてまだ言ってるの？」という話なのだが未だに"人月"を信じている人が多いのは面白い。
ただ一方で、外注や下請けなどで「これだけの人をこれだけの期間動かしているのでこれだけの費用がかかります」という説明を非エンジニアにするには人月は便利な道具ではあるので
「人月」を信じて計画を建てるのは愚かだが、あくまで言葉として適切に使えるとよいと思う。