PMBOKでプロジェクトを平和に進めたい!

はじめに

インテリア商材を販売する会社の社内SEです。少し前から複数部門が絡む長期プロジェクトのかじ取りをしなくてはいけなくなりました。
これまでは場当たり的に対応してきましたが、この対応で正解なのか？と悩むことも多いです。
最近PMBOKというプロジェクトフレームワークの存在を知ったので、上手く適用して少しでもストレスを減らしていきたいです。

PMBOK（Project Management Body of Knowledge）とは？

プロジェクトマネジメントの標準を示すガイドであり、プロジェクトマネージャーがプロジェクトを成功させるためのフレームワーク。最新は第７版。

プロジェクトマネジメントの12原則とプロジェクトパフォーマンス領域

プロジェクトが健全な状態にあるか？を定めるために「プロジェクトパフォーマンス領域」が設定されています。

パフォーマンス領域	理想的な状態（目指すべきゴール）
1. ステークホルダー	🔹 関係者全員がプロジェクトの目的や意義を理解し、自発的に関与・協力している状態。 🔹 ステークホルダーとの関係が信頼ベースで築かれ、調整や合意形成がスムーズに進む。
2. チーム	🔹 チームが自律的に動き、責任を持って成果を出す状態。 🔹 信頼関係があり、健全なコミュニケーションとコラボレーションが行われている。
3. 開発アプローチとライフサイクル	🔹 プロジェクトの性質に応じて**最適な開発アプローチ（アジャイル／ウォーターフォール／ハイブリッドなど）**が選ばれ、 🔹 段階的に価値を提供できる進め方が実践されている。
4. 計画	🔹 計画が現実的かつ柔軟に作られており、変化に対応しやすい構造になっている。 🔹 チームやステークホルダーに常に共有され、活用されている。
5. プロジェクト作業	🔹 作業が効率よく進行し、必要なアウトプットが期待通りの品質とタイミングで提供されている。 🔹 作業の優先順位が明確で、ムダなく進行している。
6. デリバリー（成果の提供）	🔹 プロジェクトの成果が明確な価値（業務改善、利益、顧客満足など）を生み出している状態。 🔹 **「作って終わり」ではなく、「使われ、活かされる」**成果物が提供されている。
7. 測定	🔹 プロジェクトの状況が定量的に把握されており、メトリクスに基づく合理的な意思決定がされている。 🔹 計画と実績のギャップが分かりやすく、早期に対策が打てる。
8. 不確実性	🔹 リスクや不確実性が予測・可視化され、対策が計画的に実施されている。 🔹 想定外の事象にも迅速かつ柔軟に対応できる仕組みがある（≒レジリエンスが高い）。

プロジェクトマネジメントの12原則

上記のプロジェクトパフォーマンス領域を理想的な状態に近づけるための基本的な行動指針として、「12の原則」が提示されています。これらは、プロジェクトマネージャーがどのように振る舞い、意思決定を行うべきかの指針となります。

1. スチュワードシップを発揮する

スチュワードシップとは「管理人」や「執事」の意味です。プロジェクトマネージャーが倫理的かつ責任を持ってプロジェクトを遂行し、組織や社会に価値を提供しなければなりません。
スチュワードシップを発揮するためには、以下の6つの観点から取り組むことが求められます。

① 倫理観を持つ

プロジェクトマネージャーは、倫理的に正しい判断を下さないといけません。
たとえば「納期のプレッシャーに負けて品質の低い製品を納品する」のではなく、「リスクを正直に説明し、関係者と適切な調整を行う」ようにする必要があります。

② 結果に責任を持つ

プロジェクトマネージャーは、プロジェクトの成功とその影響について責任を持たなければいけません。ここでいう"責任"というのは「失敗したら減給！」などという話ではなく、プロジェクトを完了させたときに本来目指していた結果（例えば、売上UPなど）へ繋がることに責任を持つということです。
例えば、何か大きな考慮漏れが発覚し予定していなかった大きな工数が発生するような場合に、「納期が遅れると上に怒られるから、とりあえす黙っておいて、爆弾抱えたままでもいいからとりあえず完了させちゃおう」のようなことをしてはいけません。
プロジェクトは終わったとしても結局爆弾が爆発して全部お釈迦という結果が待っています。
適切なリスク管理を行い、必要ならば計画を見直すことが責任を持った行動になります。

③ 持続可能性を考える

プロジェクトマネージャーは、持続可能なマネジメントを行わないといけません。
「プロジェクトを早く終わらせるためにメンバーを酷使する」のではなく、「持続的なパフォーマンスを維持できるように計画的な労務管理を行う」ようにします。

④ ステークホルダーと信頼関係を築く

プロジェクトに関わるすべてのステークホルダー（利害関係者）と信頼関係を築かなければいけません。
定期的にステークホルダーとコミュニケーションを取り、「ステークホルダーの意見を無視して独断で進める」ことのないように、「ステークホルダーと対話し、相互に納得できる解決策を見つける」ことが大事です。意見の対立があった場合は、誠実に調整します。

⑤ チームを育成し、サポートする

単なる管理者ではなく、チームの成長を支援し、適切な環境を提供するリーダーであらねばいけません。
チームメンバーが成長できる機会を提供、心理的安全性を確保することで、メンバーが自律的に動けるよう支援しなければいけません。

⑥ ガバナンスを遵守する

組織のガバナンス（ルールや方針）を尊重し、適切な手順で進めなければいけません。
「コンプライアンス違反をしてでも納期を守る」のではなく、「ルールを守りながら最適な解決策を模索する」ことが大事です。

2. チームを協働させる

プロジェクトチームが効果的に機能し、最適な成果を生み出せるようにしなければいけません。チームが円滑に協力し、最大のパフォーマンスを発揮するためには、以下の7つの要素が重要となります。

① 信頼と心理的安全性を確保する

メンバーが自由に意見を言える環境を作ること。
失敗を恐れずに挑戦できる、疑問があれば率直に質問できる、意見の対立があっても議論できることが大事です。リーダーが率先してオープンな姿勢を示し、「失敗を責めない」文化を作りましょう。

② 明確なビジョンと目標を共有する

同じ方向を向いて協働するためには、「プロジェクトの目的」や「ゴール」を明確にする必要があります。
プロジェクトの目的を伝え、明確な作業スケジュールを定めます。機能を作ることが目標ではなく、それによって会社が何かしらの利益を得ることが目標ということを共有しましょう。

③ チームメンバーの役割と責任を明確にする

役割と責任が曖昧だと、作業の重複や抜け漏れが発生しやすくなるので、「誰が、何をするのか？」を明確にドキュメント化し、メンバー同士の役割を尊重し合う文化を作りましょう。

④ コラボレーションを促進する

チームメンバーが積極的に協力し合う環境を作ること。
ペアプログラミングやコードレビュー、週次ミーティングによる仕事内容を共有などを行い、困っているメンバーをチーム全体でサポートする文化を作りましょう。

⑤ 多様性を尊重し、強みを活かす

異なるスキルやバックグラウンドを持つメンバーの多様性を活かすこと。
経験のあるメンバーが新人(未経験メンバー)をサポートし、全員のスキル向上を促します。ただし文化や価値観の違いを尊重することが大切です。

⑥ 効果的なコミュニケーションを実施する

コミュニケーション不足による認識のズレや誤解を防ぐこと。
聞く力を鍛え、相手の意図を正しく理解します。ミーティングで決まったことは議事録にまとめて、全員が共通認識を持てるようにしましょう。言語コミュニケーション（表情や態度）も意識すること。

⑦ 健全なコンフリクト（意見の対立）を管理する

意見の対立を避けずオープンに話し合うこと！
ただし、感情的にならず、論理的な議論を心がけることが大事。対立を避けるために、本音を言わないのは良くない。

3. ステークホルダーと関わる

プロジェクトの成功に影響を与えるすべての関係者と適切にコミュニケーションを取り、期待を管理し、協力関係を築くこと。ステークホルダーとの関係を適切に管理するためには、以下の5つのステップが効果的。

① ステークホルダーの特定

プロジェクトに関係するすべてのステークホルダーを洗い出す。
誰がプロジェクトに影響を与えるのか？ 誰がプロジェクトの影響を受けるのか？ を明確にする。

② ステークホルダーの分類

影響度や関心度によって分類し、どのステークホルダーを優先的に対応すべきかを明確にする。
高影響・高関心（システム利用部門の責任者など）：最優先で対応し、密接な関係を築く
低影響・高関心（社長、執行役員など）：積極的に関与し、フィードバックを得る

③ ステークホルダーとの関係を構築

定期的なミーティングを開催する、ステークホルダーの懸念事項をヒアリングし適切に対応する、プロジェクトの進捗状況を分かりやすく報告するなど、
ステークホルダーとの関係を強化するために、コミュニケーション戦略を策定する。

④ ステークホルダーの期待を管理

ステークホルダーの期待が現実とかけ離れないように期待を適切に管理し、調整すること。
何が実現可能かを明確にし、変更が発生した場合は、関係者に迅速に共有し、合意する。都度発生する課題は一覧にまとめ、解決状況、ボールの持ち主などをチームで明確に共有する。

⑤ 継続的な関与とフィードバックの収集

進行に応じて、ステークホルダーとの関係も変化するため、継続的に関与し、フィードバックを受け取ること。
システムが完全に出来上がる前でも、動作がわかるプロトタイプが出来たタイミングなどで、定期的なレビュー会議を開催し、ステークホルダーの意見を確認する。

4. 価値を重視する

プロジェクトが生み出す成果が、組織やステークホルダーにとって本当に価値のあるものかを常に意識し、最大限の価値を提供すること!
「スケジュール通りに終わる」ことが目的ではなく、「価値を生み出す」ことが本当の目的。また、どれだけ完璧なシステムを作っても、ステークホルダーが求めていないものなら意味がない。
価値を最大化するためには、以下の5つの観点が重要。

① 価値の定義を明確にする

「何を作るか？」ではなく、「どんな成果を生むか？」を考えること!
例えば"アプリを作ること"が目的ではなく、アプリを通じて"会社のファンを増やすこと"が目的であるというようなこと。

② 価値提供を測定する

プロジェクトがどれだけの価値を生み出しているかを測定すること！
例えば業務ツールであれば、それによる作業ミスの低下率や作業時間の短縮率など。

③ ステークホルダーの期待を調整する

ステークホルダーの期待と、プロジェクトの成果を一致させること。プロジェクトの途中でも定期的にステークホルダーと確認を行い、最終的な価値を意識しながら優先順位を決める。

④MVP（Minimum Viable Product）で早く価値を届ける

全機能を開発してからリリースするのではなく、「まずは必要最低限の機能を実装し、価値を提供する」 ことが重要。

⑤ROI（投資対効果）を意識し、無駄を省く

「やったほうが良い機能」ではなく、「本当に必要な機能」を優先し、費用対効果の低い機能は、後回しにする。

5. システム思考を適用する

プロジェクトを個別のタスクや要素の集合としてではなく、全体としてどのように相互作用し、価値を生み出すかを考えること。以下5つの具体的な方法でシステム思考をプロジェクトマネジメントに適用する。

① システム全体の関係性を理解する

システムは「要素」だけで成り立っているのではなく、それらがどのように相互作用するかが重要。そのシステムの利用前後にどのような運用が発生するのかまで考える。

② 因果関係を分析し、問題の根本原因を特定する

問題の「症状」ではなく「根本原因」を特定すること！
「なぜ？」を5回繰り返して発生した問題の「本当の原因」を特定し、短期的な対処（応急処置）ではなく、長期的に持続可能な解決策を考える。

③ システム全体のフィードバックループを考慮する

繰り返すことで望ましい効果を拡大する正のフィードバックループは意識的に強化する。繰り返すことで負の影響をもたらす負のフィードバックループは早めに対処する。
（正のフィードバックループ例）
アジャイル開発のフィードバックループ：定期的なユーザー評価 → 改善を実施 → 使いやすさ向上 → さらに良い評価が得られる
（負のフィードバックループ）
技術的負債の増加：「開発速度を上げるために一時的にコードの質を下げる」→ 保守性が悪化 → 修正コストが増加 → さらに時間がかかる

④ シナリオを想定し、変化に対応できる柔軟性を持つ

システムは常に変化するため、「想定外」を減らすこと!
ユーザーの運用内容を理解して想像し、複数のシナリオを想定し、リスクを事前に洗い出す。プログラムについてもドメイン駆動設計などを意識して「変更があっても対応できる設計」を考える。

⑤ 全体最適を考え、部分最適に陥らない

個々の部分を最適化するだけではなく、全体としての最適化を意識すること!
機能を作らないことで開発が1日短縮できる代わりに運用で月１日の運用コストが発生するくらいなら、開発を１日行うほうが全体としてのコストが短縮できる。

6. リーダーシップを発揮する

単なる指示や管理ではなく、チームを鼓舞し、主体的に行動し、ステークホルダーとの協力関係を築くこと！
リーダーシップは「役職」ではなく「行動」であり、チームメンバー全員がリーダーシップを発揮できる。
リーダーシップを発揮するための下記４つを実践する。

① 明確なビジョンと目標を示す

プロジェクトを達成することでどのようなメリットがあるかというところを明確に伝える。SMARTな目標を設定し、達成基準を明確にする。

② チームメンバーを信頼し、権限を委譲する

リーダーの役割は「すべてを自分でやること」ではなく、「チームが最大の力を発揮できる環境を作ること」 。
チームメンバーに裁量を与え、「指示」ではなく「支援」を意識し、必要に応じて、適切なアドバイスを提供する。

③ 積極的にコミュニケーションを取る

チームメンバーやステークホルダーとの円滑なコミュニケーションを心がけること！
1on1ミーティングを定期的に実施し、メンバーの悩みを聞く、チーム内の情報共有を活発にする、プロジェクトの進捗や課題を適切に報告する。

④ モチベーションを高める

チームのモチベーションを維持し、働きやすい環境を作ること!
成果を認め適切に評価する、メンバーの成長をサポートする、成功体験を積ませチームの士気を上げる。

⑤ 変化に適応し、柔軟に対応する

計画通りに進まないときに、変化に柔軟に対応しチームを適切に導くこと！
状況が変わっても無理やり最初の計画を押し通すのではなく、「変化は当たり前」という文化のもと計画変更が必要な場合は、早めに判断し、チームと共有する。なるべくアジャイルなアプローチを活用して柔軟に対応できるようにする。

7. テーラリングを行う

プロジェクトの特性に応じて、適切なプロジェクトマネジメント手法を選択・調整し、最適な形にカスタマイズすること!
小規模プロジェクトでは重厚なプロジェクト管理手法は不要となるし、大規模プロジェクトではリスク管理やステークホルダー管理がより重要となる。それぞれの性質に合わせて最適な方法を選ぶ必要がある。
以下、5つのステップでテーラリングを適切に実施する。

① プロジェクトの特性を理解する

プロジェクトの規模やリスクの大きさからどのようなアプローチが適切かを判断する。
大規模プロジェクトであればアジャイル開発で対応する、小規模プロジェクトであれば簡易なドキュメント作成で済ませるなど。

② プロジェクトのニーズに合わせて適切な手法を選択する

要件が明確なプロジェクトであればウォーターフォール型（計画重視）、仕様変更が多いプロジェクトにはアジャイル型（柔軟な変更対応）を選択するなど。

③ 不要なプロセスを削減し、最適化する

小規模開発であれば細かいWBSでタスク管理をする必要はない。必要に応じて導入するプロセスを決める。

④ 実施後に継続的に見直す

一度決めたら終わりではなく、プロジェクトの進行に応じて調整が必要。メリットが薄いと感じたプロセスは削減し、メリットがありそうなプロセスであればいつでも追加する。

⑤ ステークホルダーと合意を得る

適用する管理プロセスをステークホルダーと共有し、合意を取ること!
仕様変更が発生しそうなプロジェクトで、アジャイル開発で進めることを決めたのであれば、仕様が決まっているところまで開発を進めて、そこから再度仕様を詰めるなどの予定を共有しておく。

8. 品質を構築する

計画的かつ継続的に品質を確保しながら開発を進めること！後から品質をチェックするのではなく、最初から品質を設計する。

① 品質マネジメント計画を立てる

「ソースコードのカバレッジ80%以上のテストを行う」「コードレビューを最低1人以上行う」「開発の最終段階でリファクタリングするというルールを導入」など品質を保つために具体的に何をするのか？といった品質方針を決める。

②プロセスの品質管理（QA）

PHPStanのような静的コード解析など、開発の進め方自体に品質を組み込み、問題を未然に防ぐ。
自動テストの組み込みや標準化された開発プロセス、コーディング規約などを採用する。

③成果物の品質管理（QC）

単体テスト、結合テスト、システムテスト、ユーザーテストを実施、実際のユーザーに使ってもらい、フィードバックを得る。

④継続的な品質改善（PDCAサイクル）

品質は 「一度達成すれば終わり」ではなく、継続的に改善すること。

9.複雑性に対応する

プロジェクトの環境が常に変化し、不確実性や相互依存が増す中で適切に対応できるようにすること。
大きなプロジェクトになるにつれ、
・技術的な複雑性（システムの規模が大きく、相互依存が多い）
・組織的な複雑性（多くのステークホルダーが関与）
・市場や環境の変化（要件の変動、競争、規制）
といった複雑性が高まるため、「単純な手順通りの管理」ではなく、変化に適応する柔軟なマネジメントが求められる。

① システム思考を活用する

プロジェクトの相互依存関係を理解し、リスクを事前に管理する。例えば「ECサイトのリニューアル」で検索機能を改修する場合、検索機能そのものの仕様の他に、商品DBの負荷増大でレイテンシが発生する可能性など、変更が、どこに影響を与えるか？をシステム全体で考える必要がある。

② 適応型（アジャイル）アプローチを採用する

機能単位で動作確認し、段階的にリリースなど、リスクを小さな単位に分割し、影響を最小限にする。
「変化を前提にした計画を立てる」ことで、複雑性の影響を最小限にする！

③ ステークホルダー間の透明性を高める

定期的なレビュー会議で認識ズレを防いだり、誰が何を決めるのか？を明確にして責任を明確にするなど、情報共有を強化し複雑な調整をスムーズにする。

10.リスクに適応する

単にリスクを洗い出すだけではなく、変化するリスク環境の中で適切な判断を下し、柔軟に対応すること。

① リスクを予測し、事前に計画する

プロジェクト開始前に、「どんなリスクがあるか？」 を洗い出し、影響度を評価する。例えば「旧受注システムから新受注システムに焼き直し」などであれば、
・旧システムの仕様書が残っておらず仕様設計に時間がかかる⇒影響度：高、発生確率：高
　(対応策)現行システムのソースコードを解析し、ブラックボックスを解消
・新システム内の商品マスタ情報を利用することによる発注書商品名の変更が発注作業に影響を及ぼす⇒影響度：高、発生確率：中
（対応策）発注書商品名が大きく変わらないような仕組みを検討。事前に仕入先発注テストを行う。
など。

② 発生したリスクに素早く対応する

リスクが実際に発生したときに、どう対応するかを決めておくことで、慌てず対応できるようにする。
リスク対応戦略の種類には以下の４つがある。

戦略	説明	例
回避（Avoid）	リスクの原因を取り除く	開発スケジュールを事前に余裕を持たせる
軽減（Mitigate）	リスクの影響を小さくする	自動テストを導入し、バグを早期発見する
転嫁（Transfer）	リスクを他者に移す	クラウドサービスの利用で障害リスクを軽減
受容（Accept）	リスクを許容する	仕様変更を受け入れ、柔軟に対応する

③ リスクを継続的に監視し、適応する

プロジェクトが進むにつれて、新しいリスクが発生するため、定期的にリスクを見直す。また「リスクが発生した後」にも、適切な対応を行う。
リスク監視リストを作成し定期的にチェック。リスクの発生状況を可視化し早めに対策を打つ。新しいリスクが発生した場合は即座に対応策を検討する。

11. 適応力と回復力を持つ

現代のプロジェクトは、不確実性が高く、計画通りに進まないことが当たり前なので、変化やトラブルが発生したときに、柔軟に対応し、プロジェクトを軌道に乗せ続ける（正常な状態に戻す）ことが大事。

① 変化を前提とした計画を立てる

「計画通りに進まないこと」を前提に、柔軟な対応ができる仕組みを作る。

施策	内容
スコープを柔軟に管理する	WBS（Work Breakdown Structure）を小さく分割し、優先順位を明確にする
段階的な計画立案（ローリングウェーブ計画）	すべてを最初に決めず、状況に応じて詳細化する
アジャイルの導入	短期間のスプリントを繰り返し、変更に対応する

② トラブル発生時の対応力を強化する

事前に「どんな問題が起こるか？」を洗い出して対策を用意するなどし、問題が発生しても、プロジェクトを止めずに進められるようにしておく。

③ 継続的な改善と学習を行う

過去の失敗から学び、同じ問題を繰り返さないこと!
プロジェクト終了後に「何が良かったか？何を改善すべきか？」を分析する、「過去のトラブル対応事例」を記録し、ナレッジとして活用など、学びを活かし、次回のトラブルを防ぐ仕組みを作る。

12. 変革を促進する

単に「計画通りに進める」ことだけでなく、「組織や社会にポジティブな変化を起こす」こと＝変革（Transformation）を推進すること!

「変革を促進する」ための4つの視点

観点	内容	具体的な例
① 現状を見直し、変えるべき課題を見つける	「今のやり方のままで良いのか？」という視点を持つ	手作業の工程が多い業務を自動化する提案をする
② ステークホルダーに変化の必要性を伝える	なぜ変えるのかを説明し、納得してもらう	「今変えなければ将来的に業務が回らなくなる」などの根拠を提示
③ 小さな変化から始める（スモールスタート）	大きな変化を段階的に進める	まず1部署だけで新ツールを試し、徐々に全社展開
④ チームが前向きに変化を受け入れる風土を育てる	「変わること＝リスク」ではなく、「良くするチャンス」と捉えられるようにする	チームで振り返りや対話の場を持つ

「抵抗」にどう向き合うか？

変革にはつきものの「抵抗」

• 「今のやり方のほうが慣れてる」
• 「新しいことを覚えるのが面倒」
• 「失敗したらどうしよう」
  ⇒　重要なのは「押しつけ」ではなく「巻き込み」。メリットを伝えて、まずはスモールスタートで始めてみる。効果がちゃんと出たなら拡張、出ないのであれば再思考するなど、「変化の押しつけ」ではなく「一緒に良くする」姿勢が大事。