フレームワーク活用ガイドひとことで言うと#
プロジェクトの複雑さを技術・組織・環境の3領域で多軸評価し、その結果に応じて管理手法・体制・報告頻度を適切に選択するフレームワーク。すべてのプロジェクトを同じやり方で管理するのではなく、複雑さのレベルに合わせてテーラリングする発想である。
押さえておきたい用語#
- 技術的複雑性（Technical Complexity）
- 使用技術の新規性、システム間連携の多さ、要件の不確実性など技術面の難しさを指す。
- 組織的複雑性（Organizational Complexity）
- 関与するチーム数、意思決定階層の深さ、部門間の利害対立など人と組織の難しさを指す。
- 環境的複雑性（Environmental Complexity）
- 規制変更、市場の変動、外部ベンダー依存などプロジェクト外部の不確実性を指す。
- テーラリング（Tailoring）
- プロジェクト管理の標準プロセスを、そのプロジェクトの特性に合わせてカスタマイズすること。PMBOKやPRINCE2でも推奨される考え方。
プロジェクト複雑性評価の全体像#
こんな悩みに効く#
- すべてのプロジェクトに同じ管理プロセスを適用し、軽いプロジェクトは管理過剰、重いプロジェクトは管理不足になっている
- 「このプロジェクトは難しい」と言いたいが、感覚論でしか説明できない
- PMOがプロジェクトにどのレベルの支援を提供すべきか判断基準がない
- プロジェクト失敗時に「事前に複雑さを評価していれば防げた」と毎回反省する
基本の使い方#
技術・組織・環境それぞれに2〜3個の評価軸を設定する。
技術的複雑性:
- 技術の新規性（チームにとって初めての技術か）
- 要件の不確実性（要件が確定しているか、探索的か）
- システム間連携の数
組織的複雑性:
- 関係部門・チームの数
- 利害の対立度（部門間の目標が矛盾していないか）
- 地理的分散（同一拠点か、リモートか、海外か）
環境的複雑性:
- 規制・法令の厳しさ
- 外部ベンダー依存度
- 市場やビジネス環境の変動速度
PMとチームリーダーが集まり、各軸を**1（低）〜4（高）**で評価する。
- 1: 既知・安定・少数
- 2: 概ね既知だが一部不確実
- 3: 新規要素が多い、または不確実性が高い
- 4: 未知・高変動・大規模
- 個人評価 → グループ議論の順で進めるとバイアスが減る
全軸の平均スコアを算出し、レベルを分類する。
- 低複雑性（平均 〜1.5）: 軽量管理。チェックリストベースで十分
- 中複雑性（平均 1.5〜2.5）: 標準管理。定期報告とリスク管理を実施
- 高複雑性（平均 2.5〜）: 厳密管理。専任PM、週次ステアリング、外部レビューを検討
- 総合スコアが低くても、特定の軸が4の場合は要注意（その軸がリスクの集中点になる）
レベルごとに管理手法・体制・報告頻度を変える。
| 項目 | 低複雑性 | 中複雑性 | 高複雑性 |
|---|---|---|---|
| PM体制 | 兼務PM | 専任PM | 専任PM＋PMO支援 |
| 報告頻度 | 月次 | 隔週 | 週次 |
| リスク管理 | チェックリスト | リスクレジスター | リスクレジスター＋定量分析 |
| 変更管理 | 口頭承認 | 変更依頼書 | 変更管理委員会 |
| 手法 | ウォーターフォール可 | ハイブリッド推奨 | アジャイル＋厳密ガバナンス |
具体例#
PMOが年間12プロジェクトを管理する企業で、すべてのプロジェクトに同一の管理テンプレート（月次報告、四半期レビュー、軽量リスク管理）を適用していた。
2つのプロジェクトが同時期に走っていた。
| 評価軸 | プロジェクトA（社内ツール改善） | プロジェクトB（新規SaaS開発） |
|---|---|---|
| 技術の新規性 | 1 | 4 |
| 要件の不確実性 | 1 | 3 |
| 関係部門の数 | 2 | 4 |
| 利害の対立度 | 1 | 3 |
| 規制の厳しさ | 1 | 3 |
| 外部依存度 | 1 | 2 |
| 平均スコア | 1.2（低） | 3.2（高） |
プロジェクトAは月次管理で問題なく完了。一方、プロジェクトBは月次レポートの間に3つの重大リスクが顕在化し、発覚が遅れて納期が4か月超過。追加コストは2,000万円。
反省を踏まえ、複雑性評価を全プロジェクトの立ち上げ時に義務化。プロジェクトBのような高複雑性案件には週次ステアリングと専任PMを配置するルールに改めた。
金融機関のIT部門が8つのプロジェクトを抱えており、「アジャイルに移行したい」という方針が出た。しかし全プロジェクトを一斉に移行するリソースはない。
複雑性評価を全8プロジェクトに実施し、結果を3段階に分類した。
- 低複雑性（3件）: 定型的な保守・改修。ウォーターフォールのままで問題なし
- 中複雑性（3件）: 要件がやや流動的。ハイブリッド（反復型＋マイルストーン管理）が適切
- 高複雑性（2件）: 技術の新規性と要件の不確実性が高い。アジャイルの効果が最も大きい
高複雑性の2件からアジャイル移行を開始。スクラムを導入し、2週間スプリントで要件の不確実性に対応した結果、前年度の類似プロジェクトと比較して納期遵守率が**60% → 90%**に改善。
一方、低複雑性プロジェクトに無理にアジャイルを適用していた部門は「スプリントプランニングが無駄」という声が上がっていた。複雑性に応じた手法選択の重要性が組織全体に浸透した。
シード期のスタートアップ（6名）がMVPを3か月で開発する計画を立てた。初期の複雑性評価結果は以下のとおり。
| 評価軸 | スコア | 理由 |
|---|---|---|
| 技術の新規性 | 3 | ML推論エンジンが未経験 |
| 要件の不確実性 | 3 | ユーザー検証前 |
| システム連携 | 3 | 外部API 4本 |
| 関係部門 | 1 | 全員同一チーム |
| 外部依存度 | 3 | ML推論はサードパーティAPI |
| 平均 | 2.6（高） |
3か月で「高複雑性」のプロジェクトを回すのは現実的でないため、CTOが評価結果を見ながら意図的にスコアを下げる判断をした。
- ML推論をサードパーティAPIのまま使い、自前エンジン開発は延期 → 技術の新規性 3→1
- 外部API連携を2本に絞り、残り2本はフェーズ2に延期 → システム連携 3→1
- MVP対象ユーザーを10社に限定し、要件をインタビューで確定 → 要件の不確実性 3→2
再評価後の平均は1.6（中〜低）。軽量な管理で3か月以内にMVPをリリースし、10社中7社が有料プラン移行の意思を示した。複雑性評価は「難しさを測る」だけでなく、「意図的に複雑さを下げる」ための指針としても機能する。
やりがちな失敗パターン#
- 評価を一人で行う — PMだけの主観で評価すると、技術的複雑性を過小評価しがち。エンジニア、ビジネス、PMOの3者で合議すると精度が上がる
- 総合スコアだけ見る — 平均が2.0（中）でも、特定軸が4なら高リスク。レーダーチャートの「歪み」に注目する
- 評価結果を管理方針に反映しない — 「高複雑性」と判定しても、従来どおりの月次報告では意味がない。評価とテーラリングはセットで実施する
- 複雑さを「悪」と捉える — 複雑なプロジェクトは価値が大きいことも多い。目的は複雑さを排除することではなく、複雑さに見合った管理をすること
まとめ#
プロジェクト複雑性評価は、技術・組織・環境の3領域で複雑さを定量化し、管理手法を適切にテーラリングするためのフレームワークである。すべてのプロジェクトを同じテンプレートで管理するのは、軽い案件には過剰、重い案件には不足という二重の問題を生む。評価結果は「静的な判定」にとどめず、複雑さを意図的に下げる設計判断の入力にも使えるのが大きな利点である。