2. 第8版 6つの原理原則（詳細解説）
第8版は、第7版で12個あった原理原則を 6個に再編 した。本ファイルが本資料集の中核。 各原則について「定義」「なぜ必要か」「現場での使い方」「よくある逸脱（アンチパターン）」 「セルフチェック」の5点セットで解説する。
図：6原則の全体像（何を目指すか／どう遂行するか）
原則1：ホリスティックな視点を採用する
システム思考で相互作用をみて、動的に調整する
- 定義：プロジェクトを個別要素の集合ではなく、相互に影響し合う「システム」として捉える。 スコープ・スケジュール・コスト・品質・リスク・ステークホルダーは独立変数ではなく、 ひとつを動かせば他が動く連動関係にある。
- なぜ必要か：部分最適（例：スケジュール短縮だけを追う）が、品質低下・チーム疲弊・ ステークホルダー不満という別の問題を引き起こすことを防ぐため。
- 現場での使い方
- 変更管理の際、「この変更がスコープ以外の何に影響するか」を必ず一段掘って確認する
- 週次レビューで「進捗」だけでなく「進捗が生んだ副作用」を確認する議題を設ける
- リスク登録簿を「単発リスク」ではなく「リスク間の依存関係」まで書く
- よくある逸脱
- ガントチャートの遅延だけを見て、原因（チームの負荷過多・要件のブレ）を追わない
- コスト削減の判断を、品質やチームの持続可能性への影響を検討せずに単独で行う
- セルフチェック
- [ ] 直近の意思決定で、影響が及ぶ範囲を関係者マップ上で確認したか
- [ ] 「動的に調整する」＝一度決めた計画に固執せず、フィードバックで軌道修正しているか
原則2：価値に注力する
複数視点で価値の仮説を検査・適応し続ける
- 定義：プロジェクトの目的は「計画通りに実行すること」ではなく「価値を生み出すこと」。 価値は最初から確定した事実ではなく 仮説 であり、進行中に検証（inspect）し 必要なら方向転換（adapt）する。
- なぜ必要か：計画順守が自己目的化し、途中で前提が崩れているのに誰も止めない 「予定通り失敗」を防ぐため。
- 現場での使い方
- スプリントレビュー／マイルストーンレビューで「予定通り進んだか」より先に 「この成果物はまだ価値を生む前提が成立しているか」を問う
- スポンサー・エンドユーザー・運用チームなど 複数の視点 から価値を評価する場を作る （PMだけ／開発チームだけの評価に留めない）
- 価値仮説をKPIやリーディングインジケーターとして明文化し、定期的に見直す
- よくある逸脱
- 要件定義時に固定した「価値」を、途中の市場変化があっても再検証しない
- ステークホルダーが1人（例：発注者）だけで、エンドユーザー視点が抜けている
- セルフチェック
- [ ] 「なぜこの成果物を作るのか」を関係者に説明できる状態が今も成立しているか
- [ ] 価値の再検証を行う定例の場（レビュー・チェックポイント）があるか
原則3：プロセスと成果物に品質を組み込む
成果物・プロセス・マネジメント活動に品質を組み込む
- 定義：品質は最後の検査工程で確保するものではなく、成果物そのもの／それを作る プロセス／プロジェクトを管理する活動そのもの の3層すべてに組み込む。
- なぜ必要か：品質を「工程の最後にまとめてチェックする」設計だと、手戻りコストが 最大化し、かつ問題の根本原因（プロセスの欠陥）が放置される。
- 現場での使い方
- 成果物レベル：Definition of Done／受入基準を最初に合意する
- プロセスレベル：レビュー・ペアワーク・自動テストなど「作りながら検証する」仕組みを組む
- マネジメント活動レベル：会議運営・報告フォーマット・意思決定プロセス自体の質も 継続的に見直す対象とする
- よくある逸脱
- QAフェーズを最後にまとめて置き、途中工程では品質を問わない
- 「進捗管理」の質（報告の正確性・意思決定の速さ）を誰も評価対象にしていない
- セルフチェック
- [ ] 受入基準は成果物を作り始める前に合意済みか
- [ ] プロジェクト運営そのもの（会議・報告・意思決定）の質を振り返る仕組みがあるか
原則4：説明責任を果たせるリーダーとなる
全員が判断に参加し、行動する
- 定義：説明責任（アカウンタビリティ）はPM一人に集約されるものではなく、 チーム全員が自分の担当領域の判断について説明責任を持ち、行動する 状態を作ること。 リーダーの役割は「全部自分で決める」ことではなく、その状態を成立させること。
- なぜ必要か：意思決定がPMに一極集中すると、判断の速度が落ち、現場の情報が 正しく反映されない。また、当事者意識が育たず「指示待ち」が横行する。
- 現場での使い方
- 権限と責任の範囲（RACI等）を明文化し、担当者が自分の裁量で判断できる領域を作る
- 判断の結果（成功・失敗）を個人攻撃ではなく学習材料として扱う心理的安全性を確保する
- PM自身も「説明責任を果たすリーダーの一人」として、判断の根拠を可視化する
- よくある逸脱
- 全ての判断がPM経由になり、現場が「聞かないと動けない」状態になる
- 責任の所在が曖昧で、問題発生時に誰も説明責任を取らない
- セルフチェック
- [ ] チームメンバーは自分の担当範囲で誰の承認も得ずに判断できる領域を持っているか
- [ ] PM自身、判断の根拠を求められたら即座に説明できる状態にあるか
原則5：すべてのプロジェクト領域に持続可能性を統合する
変化し続けられるチーム・プロダクト・プロセスを作る
- 定義：持続可能性（サステナビリティ）を環境配慮だけの話に限定せず、 チームの持続可能性（燃え尽きない）／プロダクトの持続可能性（保守・拡張し続けられる）／ プロセスの持続可能性（無理な短期最適化に依存しない） の3つとして扱う。
- なぜ必要か：短期のデリバリー速度を優先しすぎると、チームの疲弊・技術的負債の蓄積・ 無理な進め方の定着という形で、後々のプロジェクト全体の遂行能力を損なう。
- 現場での使い方
- 稼働状況（残業・休暇取得率）を進捗指標と同じ重みでモニタリングする
- 技術的負債・ドキュメント不備など「将来のコスト」を可視化し、計画に組み込む
- 「今回だけの特別対応」を繰り返さない。繰り返すなら正式なプロセス変更として扱う
- よくある逸脱
- デリバリー速度を守るために毎スプリント残業が発生している状態を放置する
- 技術的負債をバックログの最下位に置き続け、実質的に対応しない
- セルフチェック
- [ ] チームの負荷は健全な水準に収まっているか（数値で確認しているか）
- [ ] 今のやり方を今後半年〜1年続けても、チーム・プロダクトは劣化しないか
原則6：権限付与された文化を構築する
成果のために必要な指摘と対話ができる環境を作る
- 定義：権限付与（エンパワーメント）とは単に「裁量を渡す」ことではなく、 成果に必要であれば、上下関係や立場を越えて指摘・対話ができる文化 を作ること。
- なぜ必要か：裁量だけを渡しても、心理的安全性がなければ「まずいことに気づいても 言えない」状態になり、問題は手遅れになるまで表面化しない。
- 現場での使い方
- 「悪いニュースを最初に報告した人を評価する」運用を明示的に作る
- ふりかえり（レトロスペクティブ）で立場に関係なく指摘し合えるグラウンドルールを設ける
- PM・スポンサーに対しても、チームからの異議申し立てチャネルを用意する
- よくある逸脱
- 権限は渡しているが、上位者への異議申し立てが実質的に不可能な空気がある
- 問題の早期報告者が「面倒を増やした人」として扱われる
- セルフチェック
- [ ] チームメンバーはPMやスポンサーの判断に対して異議を言える状態にあるか
- [ ] 直近、悪いニュースが「起きてから」ではなく「起きる前」に共有された事例があるか
6原則の相互関係（早見図）
原則1（全体視点）と原則2（価値）は「何を目指すか」、原則3〜6は 「どう遂行するか（品質・リーダーシップ・持続可能性・文化）」という関係で捉えると 覚えやすい。
第7版12原則との対応表（要検証・学習用仮説）
⚠️ 第7版の12原則は公式に確立された情報。一方、それが第8版の6原則に 具体的にどう統合されたかは公式ガイド原文で確認できていないため、 以下は学習用の仮説であり、公式の統合方針そのものではない。第7版を 先に学んだ受講者向けのブリッジとして使い、公式ガイド入手後に検証すること （07_scope_and_references.md 参照）。
| 第7版 12原則（確立情報） | 対応する第8版原則（仮説） |
|---|---|
| Stewardship（責任ある管理） | 原則4：説明責任を果たせるリーダーとなる |
| Team（協働するチーム環境） | 原則6：権限付与された文化を構築する |
| Stakeholders（ステークホルダーとの関わり） | 原則6：権限付与された文化を構築する |
| Value（価値への注力） | 原則2：価値に注力する |
| Systems Thinking（システム思考） | 原則1：ホリスティックな視点を採用する |
| Leadership（リーダーシップ行動） | 原則4：説明責任を果たせるリーダーとなる |
| Tailoring（状況に応じた調整） | 原則としては明示的な後継なし。04のプロセス基準表側の運用機能として再統合された可能性 |
| Quality（品質の作り込み） | 原則3：プロセスと成果物に品質を組み込む |
| Complexity（複雑性への対応） | 原則1：ホリスティックな視点を採用する |
| Risk（リスクへの最適対応） | 原則としては明示的な後継なし。原則1の相互作用把握、または40プロセス側（04）に吸収された可能性 |
| Adaptability and Resiliency（適応力と回復力） | 原則5：すべてのプロジェクト領域に持続可能性を統合する |
| Change（変化を可能にする） | 原則5：すべてのプロジェクト領域に持続可能性を統合する |
この表から読み取れる仮説：6原則への統合は単純な「2個をまとめて1個」ではなく、 ①価値・品質・システム思考のように1対1に近い対応が残るもの、②Stewardship・ Leadership・Team・Stakeholdersのように複数がリーダーシップ／文化の原則に集約 されるもの、③Tailoring・Riskのように独立した原則としては後継が無く、 プロセス側の機能に溶け込んだ可能性があるもの、の3パターンに分かれる。 公式ガイドで確認する際は特に③の2つを優先的に検証すること。
演習：自分のプロジェクトに当てはめる
- 直近のプロジェクトを1つ選び、6原則それぞれのセルフチェックに◯✕をつける
- ✕がついた原則について、「なぜそうなったか」を1行で書く
- 次のプロジェクトで、✕を1つでも◯に変えるための具体的なアクションを決める
（07_training_curriculum.md のWeek2・3でこの演習をワークショップ化している。原則1〜3をWeek2で、原則4〜6をWeek3で扱うため、本演習は2回に分けて実施する）