人月の神話メモChapter2

人月の神話 メモ
第2章

人月の神話

　おいしい料理には時間がかかります。当店がお客様をお待たせしてしまうとしたら、
それはより良いサービスでご満足していただくためなのです。
ニューオーリンズのレストラン「アントワーヌ」のメニューから

プロジェクト失敗の要因

  1. 失敗したソフトウェアプロジェクトの原因は、スケジュールに時間的余裕のないことが過半数。
  2. 見積もり技術がきちんとできていない。
  3. 努力と進捗おを誤って混同し、「人」と「月」とが相互に交換可能だという仮定を隠している。
  4. ソフトウェアのマネージャーが見積もりに自信がない。
  5. スケジュールの進捗がきちんと監視されていない。
  6. スケジュールの遅延が発覚した場合、要員を追加する。

楽観主義

  1. システムプログラマは楽観的。
  2. 誤った前提として、「みんなうまくいくに違いない」i.e.「各仕事にはかかるべき時間しかかからない」
  3. システムプログラムはタスクが複雑に絡み合っているので全部うまくいくことはまずあり得ない
    • 各仕事が9割うまくいくとしてもすべてがうまくいく確率は0.9のn乗　n=7でも50%をきる。
  4. ドロシー・セイヤーズ著「創作者の心」では、創作活動を以下の三つの段階に分けている
    • アイディア
      • 時間と空間の制約を受けずに、作者の頭の中で完成した形
    • 実現(インプリメンテーション)
      • 時間と空間の制約を受ける
    • 相互作用(インタラクション)
      • 創作が完成するのは、それを用いて誰かが制作者の心と相互に影響しあった時
素材 + 設計 ---(実現) --->　製品
素材と設計どちらがかけても製品はできない
  • 人間は設計の欠陥には気付きにくい(自分の間違いは見つけにくい、また、プライドが邪魔をする)
  • 工業製品では素材の物理的限界で実現の困難さに気付く
  • システムプログラムでは、素材(プログラム言語)が柔軟なので、実現の困難さ(設計がダメであること)に気づきにくい

勇気のない見積もり

  • 見積もりに対する定量的な基準がない
  • お客さんが適当に作業完了予定を決めても、実際の完了はコントロールできない
  • ソフトウェアマネージャーは、自分の勘でも、希望的見積もりよりまだましだと思い堂々と主張するよう。
  • 今は仕方がないが、ちゃんとデータとって定量的に分析を。
  • 筆者の経験則では

仕事の大きさを測る単位としての人月は、疑うべき危険な神話

  • なぜ？
    • 人と月が交換可能になるのは、多くの作業者の間でコミュニケーションを図らなくても、仕事が分担できる場合だけである。
      • システムプログラムでは、タスクが連続していてなかなか分担できない
      • 人を増やしてもコミュニケーションによる効率低下が起きる
      • 教育・訓練が考慮されていない

本文中の例:

3人×4ヶ月=12人月 の仕事で、チェックポイントはは1月ごとにABCD
A完了まで6ヶ月かかったとすると...
当初予定:
     1月   2月   3月   4月
      A     B     C     D
　|3人月|3人月|3人月|3人月|

現状
     1月   2月   ?月   ?月   ?月
            A     B     C     D
　|3人月|3人月|  ?  |  ?  |  ?  |
解決策1
仕事を予定通り終えなければならないと考える。Aに関してのみ当初の見積もりが甘かったと考える。
解決策2
仕事を予定通り終えなければならないと考える。AのみならずBCDも当初の見積もりが甘かったと考える。
解決策3
スケジュールを立て直す。新しいスケジュールはたっぷり時間を取る。ハードウェアエンジニアP・ファッグの忠告「小さな挿し木はするな」
解決策4
仕事を収縮する。
●よくある失敗1:解決策1
Aだけ2倍の人月かかったが、BCDは当初の予想通りの人月が必要だろう(楽観的)

	 1月   2月               4月
 　           A     B     C     D
　　|3人月|3人月|  3? |  3? |  3? |

当初の納期に間に合わせるため
一月当たり
3 * 3 / ( 4 - 2 ) =4.5人 -> 2人増員する
3月にはどうなるのか？：
　新人2名に業務知識を教えるのに、古参1名が教師となって1月かかるとすると3人月よけいに工数がかかる
　更にタスク分割のやり直しやシステムテストの増加で1人月かかると

     1月   2月    3月               4月
            A            B     C     D
　　|3人月|3人月|進捗なし|  2? |  3? |  3? |

当初の納期に間に合わせるため
一月当たり
8 / ( 4 - 3 ) = 8人 -> 3人増員する
新人3名に業務知識を教えるのに……となりあれ？大変だ！

●よくある失敗2:解決策2
Aに2倍の人月がかかるということは、BCDも2倍の人月が必要だろう

	 1月   2月               4月
            A     B     C     D
　|3人月|3人月|  6? |  6? |  6? |

当初の納期に間に合わせるため
一月当たり
6 * 3 / ( 4 - 2 ) = 9人 -> 6人増員する
3月にはどうなるのか？：
新人6名に業務知識を教えるのに、古参2名が教師となって1月かかる
とすると8人月よけいに工数がかかる
更にタスク分割のやり直しやシステムテストの増加で1人月
コミュニケーションによる効率低下で1月1人月かかるとすると

     1月   2月    3月               4月
            A            B     C     D
　|3人月|3人月|進捗なし|  7? |  7? |  7? |

当初の納期に間に合わせるため
一月当たり
21 / ( 4 - 3 ) = 21人 -> 12人増員する
新人12名に業務知識を教えるのに……

ブルックスの法則:
遅れているソフトウェアプロジェクトへの要員追加は更に遅らせるだけだ
よって、
スケジュールが遅れたら、より少ない人数でより長い期間をかける、あるいは機能を削るが正解。(解決策3または4)
実際には機能を削ることが多い。