「今期はこの12本のプロジェクトをすべて進めます。どれも重要です」
経営会議でこう宣言された瞬間、その組織の12本のプロジェクトはほぼ全部が遅れることが決まる。人もお金も時間も有限なのに、優先順位がつけられていないからだ。そして「どれを先にやるか」という本来は経営が下すべき判断が、現場のPMやエンジニア一人ひとりに押し付けられる。
単一のプロジェクトをうまく回すPMは多い。しかし組織として複数のプロジェクトを抱えたとき、問題はプロジェクトの「中」ではなく「間」で起きる。共有されたエンジニアの奪い合い、他プロジェクトの遅延による連鎖停止、報告書を集めるだけのPMO、そして誰も止められない新規案件の増殖。
本稿では、複数プロジェクトを束ねるポートフォリオ管理の5つの論点を、行動経済学・認知科学・成功する組織の実践知・AI活用の4軸で解体する。
論点① 「全部やる」と決めた組織が全部失敗する理由
なぜ優先順位をつけられないのか:「選ばないことの心理的な安さ」
経営が優先順位をつけないのは、怠慢ではない。選ぶことには痛みが伴い、選ばないことには痛みが伴わないからだ。
優先順位をつけるとは、どれかのプロジェクトを「後回し」にすることだ。後回しにされた事業部長は不満を持ち、そのプロジェクトを推してきた役員の面子も潰れる。行動経済学の「損失回避」により、この目の前の対立は強い損失として感じられる。一方、全部を「重要」として承認すれば、その場では誰も傷つかない。損失は数ヶ月後、全プロジェクトの遅延という形で、責任の所在が曖昧なまま現れる。
さらに「計画錯誤」が組織レベルで働く。各プロジェクトの計画は単体では実現可能に見えるが、全部を同時に走らせたときのリソースの合計を誰も計算していない。結果、組織の実際の処理能力を大きく超える量の仕事が承認される。
図1|同じ人数で「同時に進める本数」を変えたとき、半年後の完了本数
同時4本
同時8本
同時12本
※説明用のモデル。同時進行が増えるほど切り替えコストと待ち時間が増え、「全部が9割で止まる」状態になる。着手数を絞ったほうが、結果的に多くが完了する
この現象はリトルの法則(待ち行列理論)でも説明できる。処理能力が一定のとき、同時に抱える仕事の量が増えるほど、1件あたりの完了までの時間は比例して延びる。12本を同時に進めれば、どれも12倍近い時間がかかる。そして市場の変化や担当者の異動によって、完了前に価値を失うプロジェクトが出てくる。
具体的な実践策
【「同時進行の上限(WIP制限)」を組織で決める】
組織が同時に進められるプロジェクトの数に上限を設ける。目安は「専任でアサインできるチームの数」だ。上限を超える新規案件は、既存案件が完了するまで「待機リスト」に入る。トヨタ生産方式やカンバンで知られるWIP(仕掛品)制限の考え方を、ポートフォリオに適用する。
【「強制順位づけ」で同率1位を禁止する】
優先度を「高・中・低」で分類すると、ほぼすべてが「高」になる。代わりに、全プロジェクトに1位から12位までの重複なしの順位をつけることを経営会議のルールにする。同率は認めない。順位があれば、リソースが衝突したときの判断は自動的に決まる(上位が優先)。順位づけの議論そのものは苦しいが、その苦しみを経営会議で一度だけ引き受ければ、現場で毎日繰り返されていた奪い合いが消える。
【AIによる「ポートフォリオ全体の負荷試算」】
全プロジェクトの必要工数・期間・担当チームをAIに入力し、「これらを計画通り同時進行した場合、チーム別・月別の必要工数と、実際に投入できる工数の差を試算してください。超過する月とチームを特定し、着手時期をずらした場合のシナリオを3つ提案してください」とプロンプトを投げる。「全部やる」が物理的に不可能であることを、感覚ではなく数字で経営会議に示せる。
論点② 共有リソースの奪い合いを調停する仕組み
なぜ奪い合いが起きるのか:「共有地の悲劇」
社内に1人しかいないデータベースの専門家、セキュリティに詳しいエンジニア、業務を熟知したベテラン担当者。こうした希少な人材を複数のプロジェクトが同時に必要とするとき、各PMは自分のプロジェクトのために少しでも多くの時間を確保しようとする。
これは経済学でいう「共有地の悲劇(Tragedy of the Commons)」だ。各PMにとって、共有リソースを多く確保することは合理的だ。しかし全員がそうすると、共有リソースは疲弊し、全プロジェクトが待たされる。さらに、調停の仕組みがない組織では、声の大きいPMや、役職の高いスポンサーを持つプロジェクトが勝つ。重要度ではなく政治力で配分が決まってしまう。
図2|1人のエキスパートを3プロジェクトが取り合う構造
「週3日ほしい」
「週2日ほしい」
「週2日ほしい」
エキスパートXさん:要求合計 週7日 / 稼働可能 週5日
調停ルールがないと → 本人が板挟みになり、残業で吸収するか、声の大きいPMの案件が優先される
具体的な実践策
【「本人に調停させない」を鉄則にする】
最もやってはいけないのは、取り合われている本人に「どれを優先するか」を決めさせることだ。本人は誰の依頼も断りにくく、結果として残業で吸収し、燃え尽きる。調停は必ずリソースの所属長かPMOが行い、本人には決定済みの配分だけを伝える。本人の負担は作業そのものだけにする。
【「リソース調停会議」を週15分で固定する】
共有リソースの配分を、毎週決まった時間に15分だけ決める場を作る。参加者は各PMと共有リソースの所属長。判断基準はポートフォリオの順位だけ。判断の場とルールが決まっていれば、PM同士が廊下で交渉する必要がなくなる。政治力で決まっていた配分が、ルールで決まるようになる。
【希少リソースの「ボトルネック表」を作る】
複数のプロジェクトから同時に必要とされている人材を一覧にし、要求合計と稼働可能時間の差を可視化する。差が慢性的に大きい人材は、組織としての構造的なボトルネックだ。この表は「その人のスキルを他の人に移す育成」や「外部調達」に投資する根拠になる。
【AIによる配分案の自動生成】
共有リソースの稼働可能時間・各プロジェクトの要求・ポートフォリオ順位・各タスクの締め切りをAIに入力し、「順位と締め切りを守りつつ、この人材の週次の配分案を作成してください。どうしても満たせない要求があれば、影響と代替案を示してください」とプロンプトを投げる。調停会議には、ゼロから議論するのではなくAIが作った配分案を叩き台として持ち込むことで、15分で決着がつく。
論点③ プロジェクト間の依存関係マップ――遅延の連鎖を先に見る
なぜ連鎖が見えないのか:「自分のプロジェクトの範囲しか見ない」
プロジェクトAで基盤のAPIを作り、プロジェクトBとCはそのAPIを使って画面を作る。このときAが1ヶ月遅れると、BとCも自動的に1ヶ月遅れる。ここまでは誰でも分かる。問題は、この依存関係が各プロジェクトの計画書には書かれていても、ポートフォリオ全体の地図としてはどこにも存在しないことだ。
各PMは自分のプロジェクトの範囲で最善を尽くしている。しかし認知科学でいう「狭い枠組み(Narrow Framing)」により、自分の判断が他プロジェクトに与える影響は視野に入らない。Aのチームが「品質を優先して2週間延ばそう」と判断したとき、それがBとCを合わせて4週間分止めることを、Aのチームは知らない。
図3|1つの遅延がポートフォリオ全体に波及する連鎖
2週間遅延
2週間停止
2週間停止
Bの公開日に連動
→機会損失
実際の影響:B・Cの待機コスト(チーム2つ×2週間)+Dのキャンペーン延期による売上機会の損失
具体的な実践策
【依存関係を「受け渡し物」で定義する】
「AとBは関連している」という曖昧な記述では役に立たない。依存関係は「Aが何を・いつまでに・Bに渡すか」という受け渡し物(デリバラブル)単位で定義する。「AはユーザーAPIの仕様書を6月10日までにBに渡す」「AはAPIの検証環境を7月1日までに公開する」。受け渡し物の一覧が、ポートフォリオ全体の依存関係マップになる。
【「依存元」に影響を見せる】
依存関係マップの最大の価値は、上流のプロジェクト(依存元)に「あなたの遅延が誰をどれだけ止めるか」を見せることだ。Aのチームが遅延を判断するとき、マップ上でBとCが止まることが見えていれば、判断の重みが変わる。遅延の連絡を下流に即座に届ける義務をルール化する。
【AIによる依存関係の抽出と影響シミュレーション】
全プロジェクトの計画書・課題管理表・議事録をAIに入力し、「これらの資料から、プロジェクト間の依存関係(どのプロジェクトがどのプロジェクトの何を待っているか)を抽出し、表にまとめてください。さらにプロジェクトAが2週間遅れた場合に影響を受けるプロジェクトと期間を試算してください」とプロンプトを投げる。散らばった資料に埋もれていた依存関係を、人手では難しい速さで地図にできる。
論点④ 「価値を出すPMO」と「報告書作りPMO」の差
なぜPMOは報告書作りに堕ちるのか:「測れる活動」への逃避
PMO(Project Management Office)は、本来は組織全体のプロジェクトの成功確率を上げるための部門だ。しかし多くの組織で、PMOは各プロジェクトから進捗報告を集め、フォーマットを整えて経営層に提出するだけの部門になっている。現場から見れば「報告書を書かされる手間が増えただけ」であり、PMOは嫌われ、形骸化する。
なぜこうなるのか。報告書の収集・集計は、やったことが目に見えて、成果として示しやすいからだ。一方、プロジェクトの失敗を未然に防いだ、リソースの衝突を調停した、という価値は見えにくい。人も組織も、評価されやすい活動に引き寄せられる。これは先述した「代理指標への置き換え」が部門単位で起きている状態だ。
図4|「報告書作りPMO」と「価値を出すPMO」
| 観点 | ❌ 報告書作りPMO | ✅ 価値を出すPMO |
|---|---|---|
| 主な仕事 | 進捗報告の収集とフォーマット整備 | 優先順位づけ・リソース調停・依存関係の管理 |
| 現場との関係 | 報告を求める側(現場の負担) | 障害を取り除く側(現場の味方) |
| 経営への提供物 | 全案件の状況一覧(信号機の色) | 「今、判断してほしいこと」と選択肢 |
| 評価指標 | 報告書の提出率・期限遵守率 | ポートフォリオ全体の完了率・解消したブロッカー数 |
| 現場の声 | 「また報告書か」 | 「PMOに相談すれば止まっていた件が動く」 |
具体的な実践策
【PMOの評価指標を「活動」から「成果」に変える】
PMOの評価を「報告書の提出率」から、「ポートフォリオ全体の期限内完了率」「PMOが解消したブロッカーの件数と平均解消日数」に変える。評価が変われば行動が変わる。報告書を集めることでは評価されないと分かれば、PMOは自然と現場の障害を取り除く方向に動き出す。
【報告書は「自動化」し、人の時間は「判断支援」に使う】
進捗データはプロジェクト管理ツールから自動集計できる。PMO担当者が手作業で報告書を整える時間をなくし、その時間を「止まっている案件の原因を聞きに行く」「経営に判断を求める論点を整理する」ことに使う。報告の手間を減らすことが、PMOの価値を上げる第一歩になる。
【経営会議の資料を「判断事項」から始める】
PMOが経営会議に出す資料の1ページ目は、全案件の信号機一覧ではなく「今月判断してほしい事項:3件」にする。信号機の一覧は付録に回す。経営層の時間を「状況を眺めること」から「意思決定すること」に使わせることこそ、PMOの最大の付加価値だ。
【AIによるポートフォリオ報告の自動生成と論点抽出】
各プロジェクトの週次報告をAIに一括で入力し、「全プロジェクトの状況を要約したうえで、経営層の判断が必要な論点を重要度順に3つ抽出してください。各論点について選択肢と推奨案、判断しない場合の影響を整理してください」とプロンプトを投げる。報告書の集計という作業はAIに任せ、PMOの担当者はAIが出した論点の妥当性を確かめ、関係者と調整することに集中できる。
論点⑤ 「新規プロジェクトを止める」という最も価値ある判断
なぜ止められないのか:「始めることの快楽」と「止めることのタブー」
組織は新しいプロジェクトを始めることには熱心だが、止めることには極めて消極的だ。新規案件の承認は「前向きな意思決定」として歓迎され、提案者は評価される。一方、既存案件の中止や新規案件の却下は「後ろ向き」と見なされ、誰も言い出したがらない。
行動経済学的には、ここに2つのバイアスが重なっている。1つは「楽観バイアス」。新規提案は常に最良のシナリオで語られるため、魅力的に見える。もう1つは、一度始めたものに対する「サンクコスト効果」。そして見落とされがちなのが、止めるコストはプロジェクトが進むほど高くなるという事実だ。着手前に止めればコストはゼロ。要件定義後なら数百万円、開発途中なら数千万円が無駄になる。最も安く止められるのは、始める前だ。
図5|「止める」判断のタイミングと、そこまでに失うコスト
※総予算に対する、中止までに投じた費用の割合のイメージ。後になるほど失う額も、サンクコストによる「止めにくさ」も増す
具体的な実践策
【新規案件に「入場審査(ステージゲート)」を設ける】
新規プロジェクトは、着手前に必ず審査を通す。審査で問う質問は4つに絞る。①これをやらなかった場合、具体的に何が困るか ②成功をどの数字で判定するか ③既存プロジェクトのどれより優先するのか(順位を明示させる) ④着手したら、どのプロジェクトからリソースを移すのか。特に③④が答えられない提案は、「全部やる」状態を悪化させるだけなので、待機リストに回す。
【「1つ始めるなら1つ止める」ルール】
WIP制限が上限に達している状態で新規案件を承認する場合、既存のどれか1つを止めるか延期することを条件にする。このルールがあると、新規提案者は「既存のどれより重要か」を論証しなければならず、提案の質が上がる。経営層も、承認の瞬間に「何を諦めるか」を意識せざるを得なくなる。
【「却下」を記録し、評価する】
審査で却下・延期した案件を記録し、四半期ごとに「止めたことで守られたリソース」を報告する。止めた判断を成果として可視化することで、「止めること=後ろ向き」という組織のタブーを少しずつ解いていく。半年後に「あのとき止めて正解だった」と振り返れる事例が出てくれば、文化は変わる。
【AIを「悪魔の代弁者」として審査に入れる】
新規提案書をAIに入力し、「あなたはこの提案に懐疑的な役員です。この提案の前提の弱い部分、楽観的すぎる見積もり、既存プロジェクトとの重複や競合を厳しく指摘してください。また、この案件をやらない場合の現実的な代替策も提示してください」とプロンプトを投げる。提案者の熱意に押されがちな審査の場に、感情に左右されない反対意見を必ず1つ持ち込む仕組みになる。
5つの論点に共通する原則――ポートフォリオ管理とは「諦めることの設計」である
全部やる組織の失敗、共有リソースの奪い合い、依存関係の連鎖、報告書作りのPMO、止められない新規案件。5つに共通するのは、「何かを選ぶことは、何かを諦めること」という事実から組織が目を背けているという点だ。
優先順位をつければ、後回しにされる案件が出る。リソースを配分すれば、満たされない要求が出る。新規案件を審査すれば、却下される提案が出る。どれも痛みを伴う。だから多くの組織は判断を先送りし、その痛みを現場に、つまり板挟みになるPMやエンジニアに押し付ける。
成功している組織がやっているのは、この痛みを経営と仕組みの側で引き受けることだ。順位を経営会議で一度決める、調停を週15分の会議で行う、依存関係を地図にする、PMOを判断支援の部門にする、新規案件を入口で絞る。これらはすべて、個人に押し付けられていた「選ぶ苦しみ」を、組織のルールに置き換える仕組みだ。
そしてAIは、この仕組みを動かすための計算と整理を担う。全体の負荷試算、配分案の作成、依存関係の抽出と影響の試算、報告からの論点抽出、提案への反対意見の提示。人間が感情や政治で避けてきた「全体を見た冷静な計算」を、AIが先に差し出してくれる。最終的に決めるのは人間だが、判断の材料がそろっていれば、判断はずっと早く、正しくなる。
まとめ:ポートフォリオ管理の5つの論点
| 論点 | 根本原因(認知メカニズム) | 今日から始める打ち手 | AIの活用法 |
|---|---|---|---|
| ⑯全部やる組織 | 損失回避・組織レベルの計画錯誤 | WIP制限+同率なしの強制順位づけ | 全体の負荷を試算し着手時期のシナリオを提案 |
| ⑰共有リソースの奪い合い | 共有地の悲劇・政治力による配分 | 本人に調停させない+週15分の調停会議 | 順位と期限に基づく配分案を作成 |
| ⑱依存関係の連鎖 | 狭い枠組み(自分の範囲しか見ない) | 受け渡し物単位で依存を定義+依存元に影響を見せる | 資料から依存関係を抽出し遅延の影響を試算 |
| ⑲PMOの価値 | 測れる活動への逃避(代理指標) | 評価指標を成果に変更+資料を判断事項から始める | 週次報告の要約と経営判断の論点抽出 |
| ⑳新規案件を止める | 楽観バイアス・止めることのタブー | 4問の入場審査+1つ始めるなら1つ止める | 懐疑的な役員役として提案の弱点を指摘 |
今日から一つだけ始めるとすれば、自組織で進行中のプロジェクトを書き出し、同率なしで1位から順位をつけてみることを勧める。おそらく途中で手が止まる。その「決められない箇所」こそが、現場で毎日起きている奪い合いと遅延の発生源だ。順位をつける苦しみを一度引き受けることが、ポートフォリオ管理の出発点になる。