人月の神話
情報
訳者：滝沢徹
書評：人月の神話 書評
解読「第２章：人月の神話」
スケジュールに比較的余裕のないことが原因でうまくいかなかったソフトウェアプロジェクトは、それ以外の原因で失敗したプロジェクト全部を合わせたものよりも多い。時間の余裕のないことがしばしば惨憺たる結果の原因になっているのはなぜだろうか。
第2章の書き出しである。悲しいかな、炎上するプロジェクトというのは得てして時間の余裕のなさによるものだと思う。デッドラインが後ろへ後ろへと押し出されていき、「こんだけ押し出せるなら」という楽観視がさらなる遅れを生む。悪循環という名の地獄絵図が描かれていく。
そんな地獄絵図が生み出される理由について、冒頭には５つの理由が記されている。
- 見積もり技術がきちんとできていないこと
- 見積もり技術が努力と進捗とを誤って混同し、「人」と「月」とが相互に交換可能だという仮定を隠していること
- ソフトウェアのマネージャーが見積もりに自信がないため、往々にして思いやりある頑固さに欠けていること
- スケジュールの進捗がきちんと監視されていないこと
- スケジュールの遅延が発覚したとき、自然な対応として人員を追加すること
エンジニアの皆様は、胸に手を当てれば思い当たる節があるのではないだろうか。スケジュール監視（第四の理由）については別賞で論じられていくようだが、この問題について、様々な視点で読み解かれていく。
それぞれ解読していきたい。
最初は楽観主義について。本著において、プログラマは下記であると言及されている。
プログラマはみんな楽観主義者である。
ブログ主も最初に書いてしまったが、楽観視が原因でさらなる原因を生むことは無視できないくらいよくある事象なのである。その楽観主義により遅れが生じる理由が、下記の通り言語化されている。
単一の仕事においては、みんなうまくいくだろうという前提は、スケジュールに確率的影響を与える。まさに計画通りに事が運ぶかもしれない。なぜなら、起こりうる遅延に関して確立分布があり、そして「遅延なし」に対してもある有限の確率値が割り当てられるからだ。しかし、大規模プログラム開発は多くの仕事から構成されており、そのうちのいくつかは最初から最後まで連鎖している。
大規模開発においては100をくだらないタスクがあり、その全てが連鎖している（同時並行しては行えない。できるだけ並行して行うように工夫するが……）。そのタスクが全て成功することはない。これは断言できる。
しかも厄介なのは一つ遅延すれば他のタスクにも影響を及ぼすということ、そして遅延するタスクが一つだけとは限らないということだ。それらを計画段階で考慮していないため、得てして遅延という事象が発生するのである。
次に人月という考え方について。
人月というのは見積もりで使われる単位のことを指し、一人で仕事に当たれば一ヶ月かかる場合は一人月となる。二人月であれば二人で二ヶ月、三人月であれば三ヶ月というように見積もりは行われる。
しかし、この考え方を本著では下記のように表現している。
仕事の大きさを測る単位としての人月は、疑うべき危険な神話なのだ。
この人月という単位は、人と月が交換可能であるという前提の下で成立している。しかしこの前提が成立するのは、下記のケースのみであるようだ。
多くの作業者の間でコミュニケーション（意思疎通）を図らなくても、仕事が分担できる場合だけである。
とはいえそんなことはあり得ない。多岐にわたるシステム開発のタスクは分担されていくのだが、それぞれの進捗や課題は綿密に情報交換されることが求められる。これらの情報が一切共有されない現場は間違いなく炎上する。
これらコミュニケーションの労力も仕事量に追加しなければならない。この労力による負担は、下記の２つの部分からなると説明されている。
- 教育・訓練
- 相互コミュニケーション
教育・訓練について。それぞれの要員に対して、当人の技術力や、チームとして完遂すべき目標、チームのルールや計画について周知し教育することが求められる。新人の場合は、何も前提知識がない状態からの教育が必要となる。誰もが新人教育された経験というものがあるであろう。
相互コミュニケーションについて。その労力について、下記のような計算式があるようだ。
人がn人いれば、n(n-1)/2に比例する。
３人ならば２人の時に比べて３倍。４人ならば２人の時に比べて６倍となる。これらは各個人のちょっとした努力では埋められないくらいに多大なる影響をもたらす。このことを念頭に入れて、プロジェクトは計画されるべきなのだ。
次にみんな大好きシステムテストについて。
作り上げたシステムは最終的にテストし、バグを見つけ、改修して……を繰り返してバグ０を目指す。バグ０でいきなり作り出されるシステムは存在しない。そんな超重要な工程であるシステムテストにかける時間というのは、発見されたエラーの数と難易度に依存するのだが、それらは開発時点では予想することは不可能である。
となるとどうやって見積もれば良いのかという話になるが、本著では下記のような目安が紹介されている。
1/3 計画
1/6 コーディング
この目安の重要な点は下記の３つ。
- 計画に当てている割合が多い
- スケジュールの半分を完成したコードのテスト、デバッグにあてている
- 見積もりが容易
計画というのは所謂、設計の段階のことを指す。ここで新しい技術の調査や研究も行うとなると、時間は足りない。スケジュールの半分はテストを使うというのは、筆者の経験則によるところが大きいようだ。
また、システムテストで遅延が発生するというのは、大抵の場合リリースの直前ということが多く、致命的な遅延に発展するということも珍しくない。
次にまだ若い業界であるITにおいて致命的に足りていない勇気のない見積もりについて。
得意先の希望する納期に合わせた間違ったスケジューリングは、他のどのエンジニアリング分野よりも、ソフトウェアエンジニアリングで頻繁に行われている。
悲しい。実感以上にそういった被害はたくさんあるのだろう。その解決策としては下記の２つ。
- 生産性やバグ発生率の数量化、見積もり基準などを開発すること
- １の内容を公にすること
最後にスケジュール変更の悲劇について。
スケジュールに遅延が生じた場合、変更が必要となる。その対応としては下記４つが上げられる。
１と２の解決策については破滅的であるとされている。新しく追加された人員に対して、教育・訓練も行い必要があり、従来のタスク分担を新たに追加人員に対しても行う必要がある。人員追加に伴う工数も計算も見積もらなければならないのだ。
この人員追加による事態の悪化は、さらなる人員追加という悲劇の連鎖を生み出す。そんな状況を防ぐために覚えておかなければならないフレックスの法則というものがある。
送れているソフトウェアプロジェクトへの要員追加は、さらにプロジェクトを遅らせるだけだ。
この法則が知れ渡って、人月の神話が払拭されることを願う。
第２章ではスケジュール遅延が発生する要因として、様々な側面から書きのような項目が挙げられている。
- 楽観主義
- 人月の神話
- システムテスト
- スケジュール変更の悲劇
それぞれエンジニア現場でよくある事例をベースに分かりやすく説明されている。ここではそれほど詳しく書けないので、是非とも本著を読んで欲しい。
