はじめに（人月の神話とは）
- フレデリック・ブルックスが著したソフトウェア工学とソフトウェアプロジェクト管理の書籍
- 1975年に発行し、未だに「バイブル」として増刷され続けられている
- 本書について、著者であるフレデリック・P・ブルックス氏はこんな言葉を残しています
この本は「ソフトウェア工学のバイブル」と呼ばれている。なぜなら、誰もがこの本を読んでいるが、誰もこの本で述べていることを実践しないからである。
出所：wikipedia
結構読みづらい...
古いためか読みにくいので、インターネット上に色々と本書についての記事がまとまっているのでそれらも参考にしつつまとめていきます。
引用記事：
* 『人月の神話』新人エンジニアにオススメする技術書
* 読まれない名著「人月の神話」を本気で読み込んでみた（まとめ）
今回は、重要と言われている2章と16章についてのみとなります。
人月の神話とは（まとめ）
以下、引用しながら
人月の神話で何が言いたいのか、簡単にいうと以下なのかと思う。
人月の神話というのは、ソフトウェア開発の”単位”である「人月」という概念が、神話に過ぎない（つまり、意味をなさない）という悲しい真実を軸に、ソフトウェア開発が如何に困難を伴うものであるかを説いた名著です。一言でいえば、10人月の仕事＝1人で10か月かかる仕事は、「人月という単位が絶対であれば”10人で1ヶ月”でできるハズ」だが、そんなことは起こりえない、というお話です。そして、この状況を打破し、遅延したプロジェクトに100人投入して一瞬でシステムを完成させるような「魔法の道具（＝狼男に決定打を与える”銀の弾”）」は存在しないと結論付けられます。
引用記事のtakai-minoru氏は以下記載をしている。
言っていることは大変正しいのだが、コスト、スケジュールを考えたときなかなか難しいなと思う。
1人で開発すれば6週間かかるという見積もりに対してそこに3人を投入するというのは安全な組織体制づくりの話であって、開発期間を短くするということには直接的には寄与しない。いやいや、と考える人がいるかもしれないが、そう考える人はパーキンソンの法則がなぜ生じるのかについて説明ができるだろうか。
この世はそんなに単純なモデルでは表せられないのである。もっと言えば、1人より3人の方が作業効率が上がるとも言い切れない。この『人月の神話』でも言及されているブルックスの法則というものもある。人同士の相性もあれば、個々人の能力の差もある。そこが噛み合わなければ作業効率は下がる可能性すらある。
-
パーキンソンの法則
- 仕事の量は、完成のために与えられた時間をすべて満たすまで膨張する。
- とある仕事に1週間の時間を与えられたとしたら、1週間かかる必要のない仕事も1週間かかってしまうのです。夏休みの宿題が2ヶ月かかるはずもない量なのに2ヶ月かかってやっているのと同じこと
-
ブルックスの法則
- 遅れているソフトウェアプロジェクトへの要員追加はさらに遅らせるだけ。
工数見積もりによって表現された情報は非常に単純化されたモデルであり、開発現場の実世界を表現しきれていないということである。このような不正確なモデルに頼って計画を立ててしまうから失敗してしまうのである。うまくいくのはたまたまなのである。工数はあくまで参考情報でしかない。Wikipediaと一緒である。信じてはいけない。
そもそも工数見積もりは必要なのかという議論もある。見積もりをすること自体は良いかもしれないが、どのような考えで見積もるのか、個人ではなくチームで見積もることはできないのか、工数とは別の指標で見積もれないかといったことを考えるのもよいのかもしれない。アジャイル開発やスクラムでは工数見積もりを行わずに作業計画を立てる方法も確立されていたりする。見積もりが難しいと感じたら、見積もりの仕方を考え直してもよいのかもしれない。
見積もりの仕方を考える必要がある。奥が深いのである。
銀の弾などないーーソフトウェアエンジニアリングの本質と偶有的事項（16章）
民話の中の悪夢に登場する怪物のうちでも狼人間ほど恐ろしいものはない。というのも、狼人間は慣れ親しんでいるものを不意に恐怖に変えてしまうからだ。だから、私たちはこの狼人間を魔法のように鎮めることができる銀の弾を探し求める。
この一説は、本書のメインテーマである「システム開発」の話として、以下のように続けられます。
慣れ親しんだソフトウェアプロジェクトにもこうした性質が若干あり（中略）ふだんは無害でまともなのだが、スケジュールの遅延、膨れ上がった予算、そして欠陥製品と知った怪物にもなりえる。そして私たちは銀の弾、すなわちコンピュータハードウェアのコストと同じようにソフトウェアのコストも急激に小さくしてくれる特効薬を求める必死の叫び声を聞くのである。
しかし、これから10年間という水平線を見渡すと、銀の弾などはどこにも見当たらない。
ソフトウェア開発のむずかしさ
ソフトウェア開発における「むずかしさ」は、本質的なものと偶有的なものに分けられる、とブルックス氏は述べます。
本質的なむずかしさとは、ソフトウェア開発に固有のものです。具体的には「複雑性（ややこしい）」「同調性（他と合わせる必要がある）」「可変性（常に変化することが求められる）」「不可視性（リアルなものとして捉えられない）」の４つが挙げられます。
一方、偶有的なむずかしさとは、事象としては実際に難しいものの、別にソフトウェア開発だから難しいってわけではない、というような事象です。これは、ソフトウェア開発の歴史の中で、少しずつ解決されてきました。（もちろん、この”偶有的むずかしさ”さえも、まだ完全に解決していないが故に「銀の弾がない」という結論に至っているわけですが）
現在進行形（我々からすると、過去進行形ですが・・・）の技術を見ても、改善にはつながるだろうが、銀の弾として魔法のような効果はもたらし得ない、ということです。
どうすればよいのか
「本質的な課題に向き合う」
人月の神話（第2章）
まずは...
ソフトウェア業界に限らず、今日でも、ありとあらゆる状況で使われる「人月」という単位。これは、人（人数）と月（時間）が交換可能であるという前提で用いられます。
要するに「20人月かかる仕事」というと、1人でやると20ヶ月、2人でやると10ヶ月、5人でやると4ヶ月、10人でやると2ヶ月、20人でやると1ヶ月かかる。ということを意味しています。
勘の良い方はお気づきだと思いますが、上記はつまり（1ヶ月の稼働が20日だとすると）「400人でやれば1日」と言っています。これって、現実的じゃないよね？と思うのが最初の一歩です。
仕事（この場合は「家を建てる」）を”プロセス”に分解し、その順序・必要リードタイムを明確にしたうえで、それぞれのプロセス内で「人月」を算出することが最初の一歩です。プロセスに分解したとしても「人月は交換可能ではない」というのが人月の神話のメインテーマです
縦軸が月、横軸が人です。
ソフトウェア構築は、本来システム的な作業ー複雑な相互関係における作業の遂行ーであり、コミュニケーションを図るための労力は大きく、分担によってもたらされた各個人の作業時間短縮をすぐに上回ってしまう。だから、要員を追加することが、スケジュールを長引かすことはあっても、短くすることは無いのである。
得意先の希望する納期に合わせた間違ったスケジューリングは、他のどのエンジニアリング分野よりも、ソフトウェアエンジニアリングで頻繁に行われている。
そして、この「希望納期に合わせた間違ったスケジューリング」は、プロジェクト後半での「大幅な納期遅れ」を招き、その結果「大量の要員追加」というデスマーチへまっしぐら・・・ということになります。
顧客が何を言ったかということに依らず、常に「正しい見積もり」を行うことが、破綻しないシステム開発を行うための鍵だ、ということですね。