仕事術
プロジェクトの進め方と鉄の三角形 — 「できるだろう」が崩れる理由
スコープ・時間・コスト・品質はつながっていて、一つを動かせば他が動く。タスクが増えたら人を増やすか納期をずらすか品質を落とすしかない、という制約を、鉄の三角形と計画錯誤・ブルックスの法則から論理的に整理する。鉄の三角形シミュレータつき。

プロジェクトの進め方を考えるとき、最初に押さえておきたい原則があります。スコープ(やること)・時間(納期)・コスト(人や費用)・品質は互いにつながっていて、一つを動かせば必ず他のどれかが動くということです。だからタスクが増えたら、人を増やすか、納期をずらすか、品質(やる範囲)を削るか、そのどれかを選ぶしかありません。それを考えずに「このくらいできるだろう」で進むと、後でどこかが破綻します。本記事では、この関係を「鉄の三角形」で整理し、なぜ人はその制約を無視してしまうのかを、計画錯誤やブルックスの法則といった知見から論理的に見ていきます。
鉄の三角形とは何か
鉄の三角形(Iron Triangle、トリプル・コンストレイント)は、プロジェクトマネジメントの古典的なモデルです。三辺がそれぞれスコープ・時間・コストを表し、その内側に品質が置かれます。PMBOK などでも基本概念として扱われています。
このモデルが言っているのは単純なことです。三辺は連動しているので、一辺を変えれば、他の辺か、内側の品質が必ず影響を受ける。三つとも固定したまま、作業量だけを増やすことはできません。
| 変えたいこと | 動かせる選択肢 |
|---|---|
| スコープを増やす(機能・作業を足す) | 納期を延ばす / 人を増やす / 品質を下げる |
| 納期を早める | スコープを削る / 人を増やす / 品質を下げる |
| コストを抑える(人を減らす) | 納期を延ばす / スコープを削る |
重要なのは、どれを固定し、どれを変動させるかを先に決めておくことです。納期が絶対なら、スコープか人を動かす。スコープが絶対なら、納期か人を動かす。すべてを固定する約束は、物理的に守れません。
論理で追う ── 作業量と人と時間の関係
単純化すると、必要な作業量(仕事の総量)は「人数 × 期間」でこなされます。作業量を W、人数を N、期間を T とすると、ごく粗い近似で W ≒ N × T です。ここからわかることは明快です。
- W(スコープ)が増えれば、N(人)か T(期間)を増やすしかない
- N も T も増やせないなら、W を減らす(やる範囲を削る)しかない
- どれも動かさずに W だけ増やすと、こなしきれず品質か納期が崩れる
「タスクが増えたのに、人も納期もそのまま」という状態は、この式が成り立たないことを意味します。にもかかわらず進めてしまうと、見えないところ(品質、残業、後工程)がしわ寄せを引き受けることになります。
人を増やせば解決、とは限らない ── ブルックスの法則
では人を増やせばいいかというと、そう単純でもありません。フレデリック・ブルックスは『人月の神話』で、「遅れているソフトウェアプロジェクトに人を投入すると、さらに遅れる」と述べました。これがブルックスの法則です。
理由は 2 つあります。新しく入った人が戦力になるには教育の時間がかかること、そして人数が増えるほど連携(コミュニケーション)のコストが増えることです。連絡経路の数は人数の二乗に近い勢いで増えるため、ある点を超えると、増員による上積みより調整の負荷のほうが大きくなります。
つまり「人を増やす」は有効な選択肢ですが、増やした分がそのまま速度にならない。この効きの鈍さは、下のシミュレータで体感できます。
シミュレータ
鉄の三角形を動かしてみる
作業量(スコープ)・人数・連携コストを変えると、完了までの日数がどう動くかを試せます。人を増やしても、連携コストのぶん日数は人数に反比例しては減りません。正確な予測ではなく、トレードオフの感覚を掴むための道具です。
完了までの日数(見込み)
29.5 日
名目 4 人でも、連携コストで実効は 3.4 人ぶん。人数を増やすほど 1 人あたりの効きは小さくなります。
タスクが 20% 増えたら
人数そのままなら 35.4 日 に延びます。同じ納期を保つには 6 人 が必要になる計算です。
人を 2 倍にしても
単純計算なら 12.5 日 ですが、連携コストを入れると実際は 17.8 日。半分にはなりません。
スコープ・時間・人(コスト)・品質のうち、何かを動かさずに作業量だけ増やすことはできません。増えた分は、必ずどこかが引き受けます。
なぜ「考えずに」進めてしまうのか
制約を無視して「できるだろう」と進めてしまうのは、本人がいい加減だからとは限りません。むしろ、人間に共通する認知の癖が背景にあります。代表的なものを挙げます。
計画錯誤(Planning Fallacy)
Kahneman と Tversky が示した有名な傾向で、人は自分の作業にかかる時間を過小に見積もる癖を持ちます。過去に同じ作業で遅れた経験があっても、今回は大丈夫だと考えてしまう。個々のタスクを楽観的に見積もると、積み上がった全体は大きくずれます。
楽観バイアスと「ベストケース」での計画
多くの見積もりは、割り込みも手戻りもない理想状態を前提にしがちです。しかし実際には、割り込みや予定外の対応が必ず混ざります。割り込みが集中を崩し、見積もりを狂わせる構造は 集中の割り込みが奪うもの で扱っています。ベストケースで立てた計画は、平均的にすら達成されないことが多くなります。
パーキンソンの法則
「仕事は、与えられた時間をすべて使うまで膨張する」という経験則です。余裕を持って納期を設定しても、その余裕は別の作業や手戻りで埋まり、結局ぎりぎりになりがちです。バッファが見えにくいところで消えていくため、進捗が楽観的に見えてしまいます。
コミットメントのエスカレーション
一度「できます」と言ってしまうと、後から「やはり厳しい」と言い出しにくくなります。すでに費やした労力(サンクコスト)や、約束を撤回することへの抵抗から、無理だとわかっても突き進んでしまう。これは個人の意思の弱さではなく、状況がそうさせる力学です。
制約が「見えない」から
スコープ・時間・人の関係を式やモデルとして意識していないと、「タスクが増えた」という事実が「どこかを動かす必要がある」という判断に結びつきません。鉄の三角形を知っているかどうかで、同じ追加依頼への反応が変わります。制約は、知っていて初めて見えるということです。
見積もりを現実に近づける
こうした癖への対処は、精神論ではなく仕組みで行うのが現実的です。
- 参照クラス予測:今回の意気込みではなく、過去の似た作業が実際どれだけかかったかを基準にする。
- 幅で見積もる:1 点の数字ではなく「最短〜最長」で出し、楽観側に固定しない。
- バッファを明示する:不確実性に対する余裕を、隠さず一箇所にまとめて見えるようにする。
- 割り込みを織り込む:稼働の全部を計画作業に充てない。割り込みや会議の時間を最初から差し引く。会議の時間コストは 会議のコスト構造 で試算できます。
タスクが増えたときの交渉
途中でタスクが増えるのは普通のことです。問題は、増えた事実を黙って飲み込むことです。鉄の三角形を共通言語にすると、依頼者と建設的に話せます。
- 「この作業を足すと、納期を ◯ 日延ばすか、別の項目を外す必要があります。どちらにしますか」
- 「人を増やす案もありますが、立ち上げに時間がかかるので、今回の納期には間に合いにくいです」
- 「品質基準を下げて速く出す選択もあります。後で手直しするコストと比べて判断しましょう」
こうした提示は、断りでも反抗でもなく、トレードオフを可視化して相手に選んでもらう行為です。選択肢を並べる形にすると、感情的な対立になりにくくなります。指標で進捗や負荷を見えるようにしておくと、こうした交渉の根拠にもなります(参考: KGI と KPI を正しく設計する)。
チェックリスト
- スコープ・時間・コスト・品質のうち、何を固定し何を動かせるか決めたか
- 見積もりは過去の実績(参照クラス)に基づいているか
- 見積もりを 1 点ではなく幅で出しているか
- 割り込み・会議・手戻りの時間を最初から差し引いたか
- タスクが増えたとき、どこを動かすかを相手に提示したか
- 増員の効果を、連携コストを踏まえて控えめに見ているか
まとめ
- スコープ・時間・コスト・品質は連動する。一つ動かせば他が動く(鉄の三角形)
- 作業量が増えたら、人・納期・スコープのどれかを動かすしかない。全固定は守れない
- 人を増やしても連携コストで効きは鈍る(ブルックスの法則)
- 「考えずに進める」背景には計画錯誤・楽観バイアス・パーキンソンの法則・コミットメントのエスカレーションがある
- 対処は精神論でなく仕組みで。参照クラス予測・幅見積もり・バッファの明示・割り込みの織り込み
- タスク増は黙って飲まず、トレードオフを可視化して相手に選んでもらう
一次情報・参考
- Brooks, F. P. (1975). The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley.
- Kahneman, D., & Tversky, A. (1979). Intuitive Prediction: Biases and Corrective Procedures. Management Science.
- Kahneman, D. (2011). Thinking, Fast and Slow. Farrar, Straus and Giroux.(計画錯誤・参照クラス予測)
- Parkinson, C. N. (1955). Parkinson's Law. The Economist.
- Project Management Institute — PMBOK Guide(トリプル・コンストレイント)
- Standish Group — CHAOS Report(プロジェクト成否の統計)