Q. IT土方検定「以下の文から、現場の状況と乖離している箇所を述べよ」
A.
-
「3ヶ月経過した時点で全体の50%が完了していた」
→ 実際は20～30%ほどしか完了していない。 -
「途中から増員するメンバーの作業効率は最初から作業している要因の70%」
→ 嘘。もし増員メンバが未経験者なら、いきなり70%も出せるわけがない。もし増員メンバが経験者のベテランなら、絶対に他の案件も抱えているので半分以上のリソースが割けるわけがない。仮に70%割ける想定で予定が組まれていたとしても、引継ぎに必ず不足があるし、本人の心理的にもヘルプより元業務を優先したくなる。 -
「最初の6人のグループの作業効率は残り2ヶ月も変わらないものとする」
→ あり得ない。追加作業者は、誰から作業を教わるのか？分からないことは誰に聞くのか？
最後の1つは『人月の神話』で（おそらく初めて）提示された主張だと思う。この本の表題論文の中で、人月という概念（=人と月が交換できるという考え）が神話だとして批判されている。面白かったのでまとめる。
『人月の神話』 要旨
この論文の主題は「なぜプロジェクトが遅れるのか」である。
著者ブルックスは、プロジェクトが遅れる原因として、以下の5つを挙げている。
- すべてうまくいくだろうという前提（楽観主義）
- 人と月が相互に交換可能という考え（人月）
- 見積もりに対する自信のなさ（勇気のない見積もり）
- スケジュールの進捗がきちんと監視されていないこと
- スケジュールの遅延が発生した場合に採られるる「要因を追加する」という対応（スケジュール変更の悲劇）
論文の中では4以外について詳細に記載されているため、それぞれについてまとめる。
1. 楽観主義
創作物はまず最初アイデアとして、時間と空間の制約を受けずに作者の頭の中で完成した形で生まれる。アイデアの不完全さや不整合は、実現段階になってはじめて明白になる。特にプログラムについては、他の創作活動にあるようなメディア（=ハード）の制約による困難（「ペンキがこすれてしまう」「電気回路が焼き付いてしまう」）がないため、実現が難しいことはないと考えてしまう。
感想：だからこそ設計は楽しくて実装はつまらない（自分もそう思う）。設計時点では間違いがほぼ明らかになることがないから。
2. 人月
「人月」という単位を用いると、仕事の大きさは以下の式で表される。
人数 × 月数
仕事の大きさは人と月の掛け算なので、人と月は交換可能として扱われる。例えば、仕事の大きさが10の場合、2人で5ヶ月仕事をするのと、5人で2ヶ月仕事をするのは同じことである。ただこれは、作業者の間でコミュニケーションを取らなくても仕事が分担できる場合だけ。女性がどれほどたくさん動員されたところで、子供が10月10日かかるのと同じように、システム開発には当てはまらない。
コミュニケーションには、「教育・訓練」「相互コミュニケーション」の2つがある。
「教育・訓練」：テクノロジー、仕事のゴール、統括的戦略、作業計画の教育
「相互コミュニケーション」：お互いの仕事の個別調整。人の組み合わせのパターンだけ労力は増大する。
感想：相互コミュニケーションはめちゃくちゃ分かる。いわゆる「根回し」の時間もここに該当しそう。
3. 勇気のない見積もり
データの裏付けがなく見積もりを勘に頼っているため、自身の見積もりを堂々と主張できず、得意先の希望する納期に合わせてスケジューリングしてしまう。解決策は、生産性の数量化や見積もりの基準を開発すること。
感想：日本人なら分かるが、アメリカ人も忖度することがあるとは知らなかった。
5. スケジュール変更の悲劇
要因を増やすという解決策は悲劇を招く。2の人月の神話と似た話だが、ここでは「追加」に焦点があてられている。
プロジェクトが進行形で遅れている場合、取りうる選択肢は「要因を増やす」「スケジュールを立て直す」「仕事を縮小する」があるが、ブルックス曰く、「仕事を縮小する」が唯一の取りえる手段である。「スケジュールを立て直す」の選択肢は、別のコスト（おそらく顧客との信頼関係の低下など）があるため、実際は採られにくい。
「要因を増やす」は最悪で、追加された人はどんなに優秀でも経験者の1人から仕事に関する教育・訓練を受ける必要がある。これに1ヶ月かかるとすると、1人＋追加要因数の人月はもとの見積もりにはなかった仕事が増える。また、分割していた仕事をさらに細かく分割する必要が出てくるため、システムテスト（結合テスト）をより長くしなくてはならない。
感想
そもそも人月という考えはどこから来たのか。この本の別の論文「銀の弾などない」では、ソフトウェア開発のアナロジーの変遷が語られる。
この論文によると、ソフトウェア開発は、
書くもの → 構築するもの
に変化したらしい。
「構築」はソフトウェアを建築に見立てたアナロジーで、これによって「仕様書」「コンポーネント」「足場固め」という建築の概念がソフトウェアに持ち込まれた。おそらく「人月」もここで持ち込まれたのではないか。建築でいう「人工」の概念がソフトウェア版として変化して持ち込まれたような気がする。
「銀の弾などない」では、建築のアナロジーがとらえ損なている側面についても述べられている（前もって正確に指定できない、複雑すぎて欠陥なしで作れない、等）。これらを踏まえて、ブルックスは新たなアナロジーを提案している。
→ 育成するもの
これはソフトウェア開発を生命に見立てている。ソフトウェアは不完全で生まれてきて、徐々に色々なものを身につけていく。その成長の方向性は開発者が全て決められるわけではない。実際には開発のしやすさやユーザーのニーズによって自然と形作られていく。そして時間とともに徐々に衰え、やがて誰にも使われなくなったとき、そのソフトウェアは「死」を迎えるのだ。
