はじめに
以前記載した「PMBOK 第7版をもっとラフに理解してみる」の続きです。
今回は「プロジェクト・マネジメントの12原則」についてまとめたいと思います。
12原則（Principles）
| No. | 原則 | 内容（ざっくり要約） |
|---|---|---|
| 1 | チームを尊重し関係を築く | 信頼関係が成果を生む |
| 2 | 顧客価値にフォーカスする | 「何を作るか」より「なぜ作るか」 |
| 3 | リーダーシップを発揮する | 指示だけでなく導く |
| 4 | チームの適応性と柔軟性を育てる | 状況に応じた変化対応力 |
| 5 | システム思考を活用する | プロジェクトを全体で考える |
| 6 | リスクを積極的に扱う | 不確実性をチャンスに変える |
| 7 | 情報に基づく意思決定 | 感情よりデータを重視 |
| 8 | 関係者と連携し続ける | ステークホルダーは味方に |
| 9 | 価値を継続的に提供する | 小さく届けてフィードバックを得る |
| 10 | 品質に責任を持つ | 「とりあえず納品」はNG |
| 11 | 組織に適応したアプローチを取る | 型にこだわらず柔軟に |
| 12 | 継続的に改善する | 昨日より今日、今日より明日よくする |
01. チームを尊重し関係を築く（信頼関係が成果を生む）
スチュワードシップ（信頼される責任者であれ）。
「プロジェクトを任せて大丈夫」と思われる存在になること。
- 曖昧なことを曖昧なままにしない
- 判断の根拠を言語化する
- 誰かのせいにしない
現場で言うと
→「この人に任せとけば、まぁ大丈夫だろ」の“安心感”づくり。
02. チームの適応性と柔軟性を育てる（状況に応じた変化対応力）
チーム（協働する環境を作る）。
強いチームは “命令でなく、共通目的で動く”。
- チームが安心して議論できる空気を作る（心理的安全性）
- 情報は隠さずオープンに
- 成果の功績はチームへ、失敗の責任はリーダーが引き取る
現場で言うと
→「言ってくれてありがとう」と言える人が強い。
03. 関係者と連携し続ける（ステークホルダーは味方に ）
ステークホルダー（期待値コントロール）。
合意・理解・納得の差を可視化し、ズレを小さく保つ。
- 「相手がどう思っているか」を定期的に確認する
- “説明した” ではなく “伝わった” かが重要
現場で言うと
→ 期待値調整は 早く・こまめに・軽く。
04. 顧客価値にフォーカスする（「何を作るか」より「なぜ作るか」）
価値（アウトプットよりアウトカム）。
「作ったもの」ではなく、「発生する成果」こそ価値。
- NG: 要件を満たしてるからOK
- OK: 利用され、効果が出て初めて成功
現場で言うと
→ 仕様を守るより、「本当に使われるか？」を常に問う。
05. 情報に基づく意思決定（感情よりデータを重視）
システム思考（全体で見る）。
部分最適に陥らず “影響範囲” と “因果” を見る。
例）
バグ対応が遅い → ×エンジニアが悪い
→ ○レビュー手順、キックオフ、優先度管理の問題かもしれない
現場で言うと
→ 「この問題の根っこは何？」と聞ける人が強い。
06. リーダーシップを発揮する（指示だけでなく導く）
リーダーシップ（導く力）。
求められているのは 管理係ではなく、意思決定する人。
- 現場の状況を見て判断する
- 判断理由を透明に説明する
- 時に「決めて、引っ張る」
現場で言うと
→ 優しさと決断力はセットである。
07. 組織に適応したアプローチを取る（型にこだわらず柔軟に）
テーラリング（手法は“選ぶ”もの）。
ウォーターフォール / アジャイル / ハイブリッド を状況で設計する。
- 不確実性が高い → 小さく検証型
- 仕様が固まっている → 合意形成型
現場で言うと
→ 「何を使うか」ではなく「なぜそうしたか」が説明できれば勝ち。
08. 品質に責任を持つ（「とりあえず納品」はNG）
品質（はじめから作り込む）。
最後にテストして品質を作るのは“遅い”。
- 要件 → 設計 → 実装 → テスト
- 全工程での品質保証が必要
現場で言うと
→ 品質は「文化」であって「作業」ではない。
09. 価値を継続的に提供する（小さく届けてフィードバックを得る）
複雑性（制御不能＝前提）。
プロジェクトは 人と変化 で成り立つ → 複雑性は避けられない。
- 変化点が増えたら“整理”の時間を入れる
- 予測できないことは「ある前提」で準備する
現場で言うと
→ カオスが来ても、慌てず脈を取れ。
10. リスクを積極的に扱う（不確実性をチャンスに変える）
リスク（良い変化も悪い変化も含む）。
リスク =「悪」ではなく 変動の幅。
- 負のリスク 例: バグ、遅延、仕様変更
- 正のリスク 例: 成果物が予想より高性能、コスト削減
現場で言うと
→ リスクは「管理するもの」ではなく「使いこなすもの」。
11. システム思考を活用する（プロジェクトを全体で考える）
適応（変化に応答する）。
計画は「守るもの」ではなく「更新するもの」。
- 定例で状況を見て“今の計画が最適か”を見直す
現場で言うと
→ 「計画を直せる人」が強い。
12. 継続的に改善する（昨日より今日、今日より明日よくする）
学習（学んで進化し続ける）。
ふりかえりは “反省” ではなく “進化” の儀式。
- KPT
- YWT
- レトロスペクティブ
現場で言うと
→ 経験は、振り返って初めて“資産”になる。
おわりに
頭ではわかっているけど、現実では耳が痛い事ばかりですね。
自身のプロジェクト振り返りとして、チェックリストにすると良さそう
参考（感謝）
- AIに壁打ちしながら