はじめに

以前記載した「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に壁打ちしながら