人月の神話−第2章

概略

前文

• スケジュールに時間的余裕のないことが原因でうまくいかなかったソフトウェアプロジェクトは、それ以外の原因で失敗したプロジェクト全部を合わせたものより多い。
• 見積もり技術がきちんとできていない
  • 「すべてうまくいくだろう」という暗黙の前提
  • 「人」と「月」とが相互に交換可能だという過程
• スケジュールの進捗がきちんと監視されていない
• スケジュールの遅延が発覚した場合、自然（かつ伝統的）な対応として要員を追加
  • この対応は事態を悪化、それもかなりひどくする

楽観主義

• プログラマはみんな楽観主義者である
• システムプログラム開発のスケジュールの根底にある第一の誤った前提とは、「みんなうまくいくに違いない」、すなわち、「各仕事にはかかるべき時間しかかからない」と思い込むこと

人月

• 第二の誤った考え方は、見積もりとスケジューリングに使われる仕事の単位、すなわち「人月」そのものである
• コストは実際に人数と月数の積に比例する。が、進捗はそうではない。したがって、仕事の大きさを測る単位としての人月は、疑うべき危険な神話なのだ。人月とは、人と月とが互いに交換できるという意味だからである。
• 要員を追加することが、スケジュールを長引かすことはあっても、短くすることはないのである。

システムテスト

• 実際のスケジュールの半分がたいていテストのために使われていた
• システムテストに十分な時間を割り当てないと、とくに悲惨な結果をもたらす

スケジュール変更の悲劇

• 遅れているソフトウェアプロジェクトへの要員追加はさらに遅らせるだけだ
• 人数を多くして月数を減らしても実行可能なスケジュールは得られない

思ったこと・感じたこと

「人月」は一般的に使われている用語であり、仕事をしていても「○人月」だとか「△人日」だとかいう言葉はよく聞きます。しかし、コストを見積もるときには問題のない単位であっても、仕事の大きさを測る単位としては必ずしも適切ではない、ということなのですね。

「仕事の大きさ」というものを考えるとしても、ウォーターフォールなやり方とアジャイルなやり方では全然考え方が違ったりするのでしょうか。そのあたりはまだ全然くわしくないので、これから学んでいきたいです。