フレームワーク活用ガイドひとことで言うと#
新しいプロジェクトの依頼を**「受付→評価→承認→着手」の標準プロセスで管理する**仕組み。「誰でも好きなときにPJ依頼を出せてしまう」状態を整理し、限られたリソースを最も価値の高いPJに集中させる。
押さえておきたい用語#
- インテーク（Intake）
- 新規のプロジェクト依頼や提案を正式に受け付ける窓口・プロセスを指す。
- ビジネスケース
- プロジェクトの投資対効果（ROI）・目的・リスクを記載した提案書。インテーク評価の中核となる文書。
- ポートフォリオ
- 組織が同時に実行するプロジェクト群の全体集合を指す。インテークはポートフォリオに新しいPJを追加するかどうかの判断プロセスである。
- リソースキャパシティ
- 組織が投入できる人材・予算・設備などの上限。新PJの承認はキャパシティとの照合が前提になる。
プロジェクト・インテークプロセスの全体像#
こんな悩みに効く#
- 部門ごとに勝手にPJを立ち上げ、リソースが分散している
- 「社長案件」が突然割り込んで、進行中のPJが止まる
- どのPJ依頼が優先されるべきか、判断基準がない
基本の使い方#
PJ依頼の入口を1つに統一する。フォームには以下を含める。
- 依頼者・依頼日: 誰がいつ依頼したか
- PJ名称・目的: 何を達成したいか（1〜2文）
- スコープ概要: どこまでやるか（主要な成果物）
- 期待効果: 数値化できるビジネス効果（売上○%増、コスト○万円削減）
- 概算予算・期間: 大まかな規模感
- 緊急度: なぜ今やる必要があるか
フォームはGoogleフォーム、JIRA、Notionなどチームの標準ツールに統合する。
PMOが受け付けた依頼を評価基準に沿ってスコアリングする。
| 評価軸 | 配点 | 評価の観点 |
|---|---|---|
| 戦略整合性 | 30点 | 経営方針・年度計画との合致度 |
| ROI | 25点 | 投資対効果の大きさ |
| リソース影響 | 20点 | 既存PJへの影響・人材の確保可能性 |
| 緊急度 | 15点 | 遅延による機会損失・リスク |
| 実現可能性 | 10点 | 技術的・組織的な実行可能性 |
合計100点満点でスコアを出し、70点以上を承認候補、50〜69点を保留、49点以下を却下候補として審議に持ち込む。
月次のポートフォリオレビュー会議で、新規依頼の審議を行う。
- PMOがスコアリング結果と推薦意見をプレゼン
- 経営層がリソースキャパシティと照合し、承認/保留/却下を判定
- 承認されたPJにはPMを任命し、キックオフの日程を設定
- 却下・保留のPJには理由を添えて依頼者にフィードバック
具体例#
状況: 従業員200名のIT企業。各部門がバラバラにPJを立ち上げ、同時進行PJが 28件 に膨張。エンジニアの 72% が2つ以上のPJを兼任し、どのPJも中途半端な状態。
インテークプロセスの導入
- 全PJ依頼をインテークフォーム経由に一本化
- PMOが月次で評価し、経営会議で承認（月最大3件に制限）
- 既存の28件も再評価し、12件を中止・統合
| 指標 | 導入前 | 導入1年後 |
|---|---|---|
| 同時進行PJ数 | 28件 | 15件 |
| PJ完了率（年間） | 45% | 78% |
| エンジニア兼任率 | 72% | 35% |
| PJあたり平均リードタイム | 8か月 | 5か月 |
「やらないことを決める」ことで、やるべきPJに集中できるようになった。
状況: 従業員500名のメーカー。社長が出張先で他社の事例を見るたびに「うちもやろう」とPJを指示。年間 8件 の「社長案件」が割り込み、その都度進行中のPJが止まる。現場のモチベーションは低下の一途。
インテークプロセスで社長案件も標準化
- 社長にもインテークフォームの記入を依頼（秘書がサポート）
- 「社長案件でも評価プロセスは同じ」というルールを経営会議で合意
- ただし社長案件には「緊急枠」を月1件分設け、通常プロセスと分離
社長案件は年 8件 → 4件 に半減。残りの4件は「フォームを書いてみたら、冷静に考えるとROIが低かった」と社長自身が判断して取り下げた。現場からは「やっと計画通りに仕事ができる」との声。
状況: 20名のスタートアップ。営業・CS・経営陣からの「これ作って」が開発チームに直接飛び込み、週 3〜5件 の依頼が未整理のまま積み上がる。開発リーダーが「何から手をつければいいかわからない」状態。
軽量版インテークの導入
- Notionに「依頼テンプレート」を作成（項目は「何を・なぜ・いつまでに・効果見込み」の4つだけ）
- 毎週月曜に開発リーダー＋PO＋CEOの3名で15分のインテーク会議
- 依頼をS/M/Lで分類し、Sは即着手、M/Lは月次で優先順位を決定
飛び込みの割り込みは 週3〜5件 → 週1件 に減少。開発チームの計画遂行率は 48% → 82% に改善。「依頼がちゃんと評価されるので、営業側も本当に必要なものだけ出すようになった」とCEOが評価。
やりがちな失敗パターン#
- フォームが重すぎて誰も出さなくなる — 初期段階では5項目以内に絞る。詳細はPMOが後からヒアリングすればよい
- 評価基準がないまま「声の大きい人」で決まる — スコアリング基準を明文化し、定量的に判断する。政治的な判断を減らすことがインテークの目的
- 承認されたPJのフォローがない — インテークは「着手まで」の管理。着手後のモニタリングは別の仕組み（ハートビート、ダッシュボード）に接続する
- 「緊急」を乱用する — 全ての依頼が「緊急」になると優先順位が機能しない。「緊急」の定義（例：1か月以内に着手しないと○○万円の損失）を明確にする
まとめ#
インテークプロセスは「やるべきPJを選び、やらないPJを決める」ための仕組みだ。依頼の窓口を一本化し、評価基準に基づいてスコアリングし、限られたリソースを最も価値の高いPJに集中させる。プロセスの重さはチーム規模に合わせて調整し、20名のスタートアップなら15分の週次会議で十分機能する。