目次
人と月の交換法則を語る前に、まずは「前提」を揃えよう
本日は、名著「人月の神話」の 第2章「人月の神話」を読み解きます。本のタイトルと同じ章題がつけられたこの章は、非常に重要な意味を持ちます。
連載記事一覧は、コチラの最下段から
人と月は交換可能なのか？と論じる前に・・・
ソフトウェア業界に限らず、今日でも、ありとあらゆる状況で使われる「人月」という単位。これは、人（人数）と月（時間）が交換可能であるという前提で用いられます。
要するに「20人月かかる仕事」というと、1人でやると20ヶ月、2人でやると10ヶ月、5人でやると4ヶ月、10人でやると2ヶ月、20人でやると1ヶ月かかる。ということを意味しています。
勘の良い方はお気づきだと思いますが、上記はつまり（1ヶ月の稼働が20日だとすると）「400人でやれば1日」と言っています。これって、現実的じゃないよね？と思うのが最初の一歩です。
大工さんを100人集めても、家は1日ではつくれない
もっと身近な具体例で考えてみましょう。「家を建てる」という場合に、100人日（5人月）かかるとしましょう。それを3人の大工さんで2ヶ月弱で作る、というのが一般的だとした場合に、100人連れていたら1日でできる、、、ハズがないですね。当たり前です。
ただ、勘違いしてはいけないのは、「人月の神話」の主題はそこにはない、ということです。
まずは、プロセスにわけて考えてから
ボトルネック、とか、クリティカルパスとか、そういう話が大前提としてあります。例えば「土台ができてからじゃないと、上に柱が立てられない」とかいうのはクリティカルパスの話です。「仕様が決まってから、資材が納品されるまでのリードタイムは一定以上に短縮できない」というのはボトルネックでしょうね。そもそも、「資材が全部いっぺんに届いても、作業スペースが無いから一度には作れない」みたいなのも”現実的な制約事項”として存在しますね。
これらを解決するのは「人と月が交換可能かどうか」とは別の話です。仕事（この場合は「家を建てる」）を”プロセス”に分解し、その順序・必要リードタイムを明確にしたうえで、それぞれのプロセス内で「人月」を算出することが最初の一歩です。
※プロセス分解については、関連記事もご参照ください
プロセスに砕いたとしても「人と月とは交換不可能」という話
上記のように、プロセスに分解したとしても「人月は交換可能ではない」というのが人月の神話のメインテーマです。こういう前提を揃えずに、金科玉条の如く「人と月は交換できないのだ！」とか言うのは、頭悪い感じがするので気を付けましょう。ほんとに。
ということで、ようやく本題です。お待たせしました！
目盛りに”数字”がないから分かりにくい
本章は、非常に良いことを言っているのですが、大変残念なことに「読者に優しくない」ので伝わらない、典型例だと思っています。
というのも、「図表の目盛りに数字（メジャー）が記入されていない」ことに加えて、「対比すべき複数のグラフが同一見開き内に無い（同じ紙の裏表に印刷されている）」という致命的な問題があります。アホかと。
こちらで、目盛り（メジャー）を追加して、横に並べてみました。これでメッセージがクリアに伝わると思います。
仕事の種類によって「交換できる度合い」が変わる
まず、明確に理解すべきは、仕事が「完全に分割可能」か「コミュニケーションをしながら、という前提で分割可能」か、が大きな分岐点であるということです。
完全に分割可能な仕事は、1人でやって10時間なら、10人でやって1時間です。例えば、封筒の宛名書きとかってそんな感じでしょうかね。あるいは、物流倉庫の仕分けとか。これは「完全に交換できる」と言えます。ここに分類される仕事には、いわゆる「単純作業」が多いです。（下図 左側）
一方、コミュニケーションが必要な場合は、1人でやって10時間を、10人でやっても2時間かかる、と考えてください。例えば、書店の新店オープン準備で売り物の本を並べる、とかはこの類かもしれません。もちろん、ある程度手順にはなっているでしょうが、「これは、このカテゴリで良いのか？」とか「新刊エリアと旧書エリアに重複配置すべきか」とかは、その場その場で考えないといけないでしょう。この時に、1人で10時間かかるものを、10人で1時間、ということにはなりません。相互に、どこまで進んだかを確認しながら、それは全体方針に沿っているのか、などをキチンと理解しながら進める必要があります。そうすると「ある程度は交換できるが、完全な交換はできない」ということになります。（下図 右側）
交換しようとすると、破綻するものもある
次に理解すべきは「交換しようとすると、とんでもないことになるタイプの仕事」があるということです。
言葉で説明するよりも、下図の右側をご覧いただいたほうが早いでしょう。
複雑な相互関連を持つ仕事の場合、一定人数を超えると「コミュニケーションにかかるコストが、人を追加したことによる分割効果を上回る（＝非効率になる）」ということです。本文より引用します。
ソフトウェア構築は、本来システム的な作業ー複雑な相互関係における作業の遂行ーであり、コミュニケーションを図るための労力は大きく、分担によってもたらされた各個人の作業時間短縮をすぐに上回ってしまう。だから、要員を追加することが、スケジュールを長引かすことはあっても、短くすることは無いのである。
「要員を追加することが、スケジュールを長引かすことはあっても、短くすることは無いのである」。なんか、もう、ごめんなさいしか出てきません。ごめんない。
さらに、システムテストでコケるという罠
個人的には、この章で覚えるべきは、上記まででOKだと思いますが、後半も少しだけ解説しておきます。
システム開発の後半に「システムテスト」というものがあります。要は「それ、ちゃんと（仕様通りに）動くの？」って確認するわけですね。しかし、バグというのは楽観的に考えれば”存在しないもの”なわけですので、基本的に、ここは、実態よりも圧倒的に短く見積もられる、ということになります。
そのための打開策として、以下の比率で見積もるべしとブルックス氏は述べます。
- 1/3 計画
- 1/6 コーディング
- 1/4 単体テストおよび初期システムテスト
- 1/4 すべてのコンポーネントを統合して行うシステムテスト
要は、半分（1/4+1/4）は、テストに充てろ、ということです。また、計画もコーディングの2倍を費やせと言っています。え、まぢで？やりすぎじゃね？と思ったあなたは、タールの沼の入り口にいますので、1章から読み直しましょう。
そして、この見積もりができない最大の原因を、ブルックス氏は以下のように看破します。
得意先の希望する納期に合わせた間違ったスケジューリングは、他のどのエンジニアリング分野よりも、ソフトウェアエンジニアリングで頻繁に行われている。
そして、この「希望納期に合わせた間違ったスケジューリング」は、プロジェクト後半での「大幅な納期遅れ」を招き、その結果「大量の要員追加」というデスマーチへまっしぐら・・・ということになります。
顧客が何を言ったかということに依らず、常に「正しい見積もり」を行うことが、破綻しないシステム開発を行うための鍵だ、ということですね。
以上、本書のメインテーマである「人月の神話」について解説しました。次回は、開発体制のお話である「第3章：外科手術チーム」の解説です。
連載記事一覧は、コチラの最下段から
