50年前の古典「人月の神話」から今も学ぶこととは
株式会社アイリッジ取締役の渡辺智也（わたなべともや）です。
※X（旧Twitter）もやっています！
みなさんは「人月の神話」という本を知っていますか？
フレデリック・ブルックスが1975年に著した、ソフトウェア開発プロジェクト管理に関する本なのですが、私がアイリッジに入社した後に同僚のエンジニアから「この本は読むべき」と薦められたものです。
この本はソフトウェア開発の複雑さと、従来の管理手法の限界を指摘しています。初版から約50年経った今でもエンジニアの基本の書として読み継がれています。
今回はこの「人月の神話」について触れながら、エンジニアと協力して価値を生み出す上で、ビジネスサイドの人間が果たすべき役割や持つべき考え方を整理してみました。
１．「人月」という考え方が「神話」とされる理由
「人月」とは、一人の人間が1ヶ月間働いた量を表す単位のことを指します。
例えば、10人月のプロジェクトは、理論上、10人で1ヶ月、または1人で10ヶ月かかるとされます。
ところが、ブルックスはこの考え方自体が「神話」であると本のなかで指摘しています。
それはなぜなのでしょうか。
主な理由として4点があげられています。
①人数が増えるとコミュニケーションが複雑になる
プロジェクトに人員を追加すると、チームメンバー間のコミュニケーションが複雑になります。10人のチームには45の潜在的なコミュニケーションパスがありますが、50人では1,225にも増加します。「一人追加したら早くプロダクト開発が終わるでしょ？」というのは大いなる誤解だということがわかります。
②全ての作業を均等に分けられるわけではない
すべての作業を均等に分割できるわけではありません。
例えば、子供を産むのに9ヶ月かかるなら、9人の女性を1ヶ月で産ませることはできません。「一人追加したら分業できて早く仕事が進むでしょ？」ということも誤解だということですね。
③順番に行わなえればならない作業がある
ソフトウェア開発には順序依存的なタスクが多く存在し、並行して進められない作業があります。人が増えることは、行程そのものにポジティブなインパクトがあるかどうかは必ずしもつながらない、ということです。
④新しいメンバーが仕事に慣れるまで時間がかかる
新しいメンバーがプロジェクトに慣れるまでには時間がかかり、短期的には生産性が低下する可能性があります。一人追加したからといって、その人が翌日即戦力となって貢献してくれるわけではない、ということです。
これらの理由から、単純に人数を増やせば作業が早く終わるというわけではないのです。
２．「人月の神話」から得られる教訓とは
いずれの「神話」も、確かに…と思うものばかりですが、さらにこの本で示されている教訓もいくつか紹介しましょう。
①「遅れているソフトウェアプロジェクトに人員を追加すると、さらに遅れる」（ブルックスの法則）
これは、新メンバーの教育や統合にかかる時間と労力が、短期的には生産性を低下させるためです。
②優れたソフトウェアには一貫した設計思想が必要
優れたソフトウェアは、一貫した設計思想（概念的整合性）を持つ必要があります。つまり、ひとりもしくは数名の優秀な設計者が一貫して関わることが重要だ、ということですね。
③2番目のシステム開発では機能を詰め込みすぎる傾向がある
開発者は、2番目のシステムで過剰な機能を盛り込みがち、という教訓です。
これは、最初のシステムで抑制した欲求が、2番目で噴出するためだといわれています。エンジニア、開発者ならでは、の欲求ですよね。
④早い段階での試作と繰り返しの開発が重要
「計画を立てる計画を立てよ」というアプローチを提唱し、早期のプロトタイピングと反復的な開発の重要性を強調しています。
⑤銀の弾丸は存在しない
こうした教訓をふまえ、ということですが、ソフトウェア開発の複雑さを一気に解決する魔法の解決策（銀の弾丸）は存在しない、とブルックスは表現しています。
特に最後の⑤は、今も肝に銘じて経営をしているなぁ、と思うところですね。
３．「人月の神話」からの学びを自分なりに活かすには
この本は約50年前に書かれたものですが、技術が進歩した今でも多くの点で当てはまります。エンジニアだけでなく、ビジネスサイドの私たちにも重要な示唆を与えてくれます。
例えば、プロジェクトの規模や期間を見積もる際には、単純に人数と時間を掛け合わせるのではなく、チーム内のコミュニケーションや作業の性質を考慮する必要があります。また、問題が発生したときに安易に人員を増やすのではなく、まず現状のプロセスを見直すことが大切です。
私はビジネスサイドとして日頃からプロジェクトメンバーと関わることがありますが、「人月の神話」の学びを活かすには以下のような点かと思っています。
エンジニアとの密なコミュニケーションを心がけ、技術的な制約や可能性を理解する
例えばプロジェクトの早い段階でエンジニアに技術的な観点からの実現可能性や課題を共有してもらう時間を設け、早期にプロジェクトのリスクを洗い出しておくことでビジネスサイドが技術的な制約を理解した上で、より現実的な要求や提案ができるようになります。
プロジェクトの計画段階で、エンジニアの意見を積極的に取り入れる
例えばプロジェクトの見積もり会議にエンジニアを参加させ、技術的な観点から必要な工数や潜在的なリスクについて意見を求めます。また、プロジェクトのスケジュールを作成する際、エンジニアと共に各フェーズの所要時間を検討し、適切なバッファを設けます。これにより、より現実的で実行可能なプロジェクト計画を立てることができ、後々の大幅な遅延や変更を防ぐことができます。
「銀の弾丸」を求めるのではなく、継続的な改善と学習を重視する組織文化を育てる
「失敗」を学びの機会として捉え、プロジェクト終了後に必ずレトロスペクティブを行い、改善点を次のプロジェクトに活かします。
これらの点に注意を払うことで、ビジネスサイドとエンジニアリングサイドの協働がより効果的なプロジェクト管理とチーム運営を可能にするでしょう。
ぜひ皆さんも「人月の神話」を読んでみてください。エンジニアとビジネスサイドの橋渡しをする上で、貴重な視点を得られるはずです。