専門家が教えるPMBOKの理論と実践
PMBOKには、あらゆるプロジェクトに適用できる原理・原則が記されています。この記事では「スチュワードシップ」「テーラリング」などのキーワードも含めて解説します。
PMBOKはプロジェクトマネジメントの知識体系をまとめたガイドブック。実質的な世界標準であり、この分野の共通言語です。2025年11月上旬時点の最新版は第7版。価値の実現を重視し、あらゆるプロジェクトに適用できる原理・原則が示されています。
本稿では「12の原理・原則」を徹底解説。抽象論のみならず、具体的な実践のアプローチも紹介します。記事の監修者はRidgelinez（戦略から実装まで支援する総合プロフェッショナルファーム）のプロジェクト経験豊富なエキスパートたち。同社の尾形順一氏は、日本プロジェクトマネジメント協会および大学の講師も務めています。原理・原則を内面化して、一流のプロジェクトマネージャーをめざしましょう。
プロジェクトマネジメントの原理・原則
スチュワードシップ
勤勉で、敬意を払い、面倒見の良いスチュワードであること
第1の原理・原則は、基本姿勢に関するものです。この文言は、専門家としての責任感と誠実な対応を重視しています。
スチュワードとは、執事のこと。家事使用人よりも財産管理人に近いイメージです。標題の「スチュワードシップ」は預かった資産を管理運用する「受託責任」を意味します。ここでは、以下4つの要素が含まれます。
- 誠実さ
- 面倒見の良さ
- 信頼されること
- コンプライアンス
PMBOKには明記されていませんが、もっとも大切なのは「誠実さ」でしょう。この要素は古今東西を問わず、人間の美徳とされてきました。誠実ならば自ずと信頼を得て、面倒見も良くなる。コンプライアンスに反する行為もしません。
これからテクノロジーが進化しても、プロジェクトマネージャーに必要な資質は変わりません。むしろAIやロボットが発達するほど、温かな人間性が求められるはずです。
チーム
協働的なプロジェクトチーム環境を構築すること
第2の原理・原則は、チームづくりに関するものです。プロジェクトを推進するためには、同じ目標に向かって協力しあうチームが欠かせません。この協働的な環境をつくるには、以下4つの要素が必要です。
- チームの合意
- 組織構造
- プロセス
- 役割と責任
すべて満たして当然のようですが、欠けていることに気づかないケースもあります。たとえば、経験豊富なメンバーがシステム更改プロジェクトに再集結する場合。「役割分担は前回と同じ」と思いこんだままプロジェクトが進み、新たな領域の業務に誰も着手しない場合があるのです。
このような事態を防ぐため、あらかじめメンバーの「役割と責任」を明確化してください。その際は「※RACIチャート」の活用をおすすめします（下図参照）。そのうえで各メンバーの専門スキル・知識・経験・多様性を最大限に活用しましょう。
※RACIチャート：プロジェクトを構成する各タスクについて、チーム内の「誰が」「どのような役割で携わるのか」を明確化する図表
ステークホルダー
ステークホルダーと効果的に関わること
第3の原理・原則は、ステークホルダー（利害関係者）に関するものです。「効果的に関わる」と言うは易く、行うは難し。大半のプロジェクトマネージャーが不十分でしょう。
ステークホルダーとのエンゲージメント（深い関与・つながり）を強化すれば、プロジェクトの成功と価値提供の最大化につながります。その一方、正しく関与しないと脅威を生み出しかねません。たとえば、他部門を管掌する役員に反対されて、プロジェクトが止まるおそれもあります。
社内の関係者はもちろん、サプライヤー・顧客・エンドユーザー・規制機関などもステークホルダーです（上図参照）。プロジェクトマネージャーはすべての利害関係者を洗い出し、適切な手法で味方を増やしましょう。
具体的には、ステークホルダーリストの作成をおすすめします。その一覧表に各ステークホルダーの特徴やキーパーソンを明記。密に報告すべき対象や説得すべき対象などを整理します。その後は組織内外の力学を分析し、入念な根回しを。相手によっては、会食も手段のひとつです。
価値
価値に焦点を当てること
第4の原理・原則は、第7版を象徴するコンセプトです。プロジェクトの目的は価値の実現であり、成果物の提供ではありません。「十分な価値を提供できなければ、計画通りにプロジェクトが完了しても意味がない」とPMBOKは戒めています。
価値はプロジェクト成功の究極の指標ですが、人や組織によって認識が異なります。システム開発会社などの営利企業の場合、「価値≒経済的価値」と解釈してもいいでしょう。参考として、価値の定義を等式で示します。
価値（Value）＝受益（Benefit）－費用（Cost）
システム思考
システムの相互作用を認識し、評価し、対応すること
第5の原理・原則は、考え方の枠組みに関するものです。前回の記事では「価値実現システム」の内部にプロジェクトが配置されていました。ここでは、一つひとつのプロジェクトも動的なシステムと考えます。
各プロジェクトは独立した要素ではありません。周りとつながり、互いに影響し合っています。社内の定常業務はもちろん、社会情勢や市場動向など外部環境の影響も受けます。それらの相互作用に対応するため、「システム思考」で全体を捉えなければなりません。
システム思考とは「変化は常にある」という認識で全体像を捉え、さまざまな要素とのつながりを把握すること。この考え方で変化に対応すれば、プロジェクトのパフォーマンスに好影響を与えるでしょう。
リーダーシップ
リーダーシップを示すこと
第6の原理・原則は、すべてのメンバーが対象です。プロジェクトの成功にリーダーシップは欠かせません。それは権威や権限とは無関係で、誰もが発揮すべきもの。決められたスタイルはなく、状況に合わせて変える必要があります。
状況に応じたスタイルを選ぶ際は「SL理論」が役立ちます。この理論ではリーダーの基本行動を「指示的／協業的」に大別。この2軸を組み合わせて、リーダーシップのスタイルを「指示」「コーチング」「支援」「委任」の4つに分類しています（下図参照）。
近年のトレンドは、コーチングや支援型のリーダーシップです。こと細かな指示はせず、任せっきりでもない。アジャイル開発におけるサーバント・リーダーシップに近いスタイルです。PMBOKは「モチベーションを高め、熱意や共感を伝える方法を考えることが重要」と示しています。
テーラリング
状況に基づいてテーラリングすること
第7の原理・原則は、PMBOK全体に言及するものです。プロジェクトマネジメントには、絶対的な最善の方法はありません。状況に応じて、さまざまなアプローチを組み合わせる必要があります。
そこで重要なのが「テーラリング」です。原義は紳士服などの「仕立て」のこと。顧客の体型や要望に合わせてスーツを仕立てるように、組織やプロジェクトの実情に合わせて方法を調整することを意味します。
上図が示すように、テーラリングには3つの階層があります。たとえば、富士通の標準開発プロセス体系（SDEM）は組織レベルのテーラリング。自社の特性に合わせて「セキュリティ」「知的財産」の知識エリアなどを追加し、PMBOKを補完しています。
ただし、削除型のテーラリングは危険です。「うちはステークホルダーが少ないから、顧客以外は気にしない」などと、他の原理・原則を疎かにしてはいけません。まずは基本を忠実に守ってください。
品質
プロセスと成果物に品質を組み込むこと
第8の原理・原則は、品質の多面性を示すものです。まず「成果物に品質を組み込む」のは、誰もが理解できるでしょう。あらかじめ成果物の受け入れ基準を設定し、品質を測定・見える化する。システム開発における一般的な手段はテストです。
しかし、それが最善の方法でしょうか？ 最終工程でエラーや欠陥を修正するよりも、設計や要件定義の段階で予防できたほうが良いですよね？ だから、検査より予防を重視して、効果的なプロセスを構築する。それが「プロセスに品質を組み込む」ことです。
複雑さ
複雑さに対処すること
第9の原理・原則は、避けがたい変化に関するものです。プロジェクトにはさまざまな不確定要素があり、すべて計画通りに進めることは不可能です。そんな不確かさのひとつが「複雑さ」です。
たとえば、人の振る舞い。人間関係に悩んで離職したり、モチベーションが下がったりするメンバーがいるかもしれません。また、第5の原理・原則で解説した「システムの相互作用」も複雑さの一因になります。つまり、プロジェクト内の複数の個別要因、およびプロジェクトシステム全体の結果として複雑さが生じるのです。
したがって、プロジェクトチームは変化に気を配り続け、その影響を少なくする手段をとる必要があります。何かが起こることを前提にして、複雑さに対応する能力を高めましょう。
リスク
リスク対応を最適化すること
第10の原理・原則は、前項に続くもの。リスクとは「不確かさ」という大きな概念の構成要素であり、発生が不確実なものごとを意味します。マイナスのリスク（脅威）だけでなく、プラスのリスク（好機）もあります。
たとえば、上下に変動する為替リスク。海外から部品を調達してプロダクトをつくる場合、為替レートの変動が調達コストに直接影響します。つまり、プラスマイナス両面のリスクが潜んでいるわけです。このようなリスクの許容度は組織によって異なり、時間経過により発生確率や影響度合いは変動します。
プロジェクトマネージャーは価値提供への影響を評価しながら、効果的・効率的・適切な対応をしてください。具体的なリスクマネジメントの方法は今後の記事で紹介します。
適応力と回復力
適応力と回復力を持つこと
第11の原理・原則も、不確かさを前提にしたものです。大半のプロジェクトは難題や阻害要因に直面します。それらを乗り越えるためには、適応力と回復力が必要です。
後者の原語である「Resilience」は、近年さまざまな分野で重視されるキーワード。悪影響を緩和して、失敗から素早く回復する力を意味します。個人レベルでは、ストレスを抱えても落ちこまず、困難を乗り越える力をさします。
プロジェクトチームが適応力と回復力を高めるには、多角的な専門知識と継続的な改善が必要です。具体的には「各分野の専門家を集めて、多様性を活かす」「アジャイル開発でPDSAサイクルを回す」といった方法があげられます。
変革
想定した将来の状態を達成するために変革できるようにすること
第12の原理・原則は、チェンジマネジメントに関する内容です。上記の長文を要約すると「望ましい将来を実現したい」「そのために変革する」。ステークホルダーやリーダーシップなど、他の原理・原則とも関連します。
現代は状況の変化に合わせて、変わり続けることが求められています。しかし、すべてのプロジェクトメンバーやステークホルダーが柔軟に対応できるわけではありません。むしろ短期間に多くのことを変えようとすると、変化への抵抗を招く可能性があります。それさえも柔軟に対応しながら、組織としてのチェンジマネジメントを考えてください（下図参照）。
たとえば、抵抗勢力に対する説得もそのひとつ。組織のチェンジマネジメントのフレームワークとして「組織的変革管理:OCM（Organizational Change Management）」があります。その他にもステークホルダーを味方にするエンゲージメント、メンバーの意欲を高める動機づけアプローチが変革の助けになります。
実践のススメ
以上、12の原理・原則を解説してきました。これらに優先順位はなく、内容は多岐にわたります。あらゆるプロジェクトに適用できる反面、どこから手をつけていいのか悩むかもしれません。そこで本項では、実践のアプローチを示します。
まずは、手帳や張り紙などに12の原理・原則を書いてください。その文面を毎日確認して「実践できているか？」を自問自答。広い視野で全体を見つめ直します。自身の現在地がよくわかるのは、プロジェクトマネジメントにつまずいたとき。そこで改善点が明確になり、守るべき原理・原則が浮き彫りになるでしょう。
あなたが若手メンバーなら、他の方法もあります。それは社内のプロジェクトマネージャーを注意深く観察すること。どれほどのベテランでも完全無欠ではありません。「何が不十分で、どんな問題が起きているのか」を実例から学び、他山の石としましょう。
要求事項のまとめ方
「要求」と「要件」の違い
ここからは抽象的な原理・原則ではなく、具体的な実務に即した知見をお伝えします。システム開発において「要求」と「要件」の区別は必須です。混同しないように、それぞれの定義を解説しましょう。
まず「要求」とは、システムで実現したい大枠を定めるもの。開発の目的や発注者のニーズです。主体はビジネス側（顧客や営業部門）です。
次に「要件」とは、要求を実現するために必要な機能・性能など。要求のない要件はありえません。たとえば「新幹線の予約アプリがほしい」という要求を受けた場合、以下のような要件に分解できます。
- 新幹線の時刻表を閲覧できる
- 新幹線の乗車予約ができる
- 新幹線の座席指定ができる
- クレジットカード決済ができる
- 同時アクセス数10万名に耐えられる
- 二要素認証を備える
要件定義の主体は、ビジネス側とシステム側（開発部門）の双方です。どちらか一方が独断で要件を決めてはいけません。一般的にはシステム側が主導して、ビジネス側の合意を得るケースが多いでしょう。
取りまとめのポイント
プロジェクトを成功させるためには、要求と要件の明確化が欠かせません。それはビジネス側とシステム側が一体となって作り上げるもの。その際のポイントを以下にまとめます。
顧客と密にコミュニケーションをとる
顧客（ステークホルダー）とオープンな対話を続けて、真のニーズと期待を深く理解してください。これは第3の原理・原則に通じるものであり、もっとも重要なポイントです。
全関係者からのレビューと合意を得る
定義された要求と要件は、すべての関係者（顧客・開発チーム・テスト担当者・運用担当者など）にレビューしてもらい、最終的な合意を得てください。これにより後工程での手戻りを防ぎ、プロジェクト全体の方向性を一致させることができます。
ビジネス目標との整合性を常に確認する
すべての要求と要件は、ビジネス目標の達成に貢献すべきものです。「なぜこの機能が必要なのか？」「この機能がビジネスにどのような価値をもたらすのか？」を常に問いかけ、無関係な要件や優先度の低い要件を見極めてください。これが不十分だとプロジェクトが遅延したり、開発コストが増えたりします。
明確な記述を徹底し、誤解の余地をなくす
誰が読んでも同じ解釈ができるように、具体的かつ客観的に要件を定義してください。「できるだけ早く」「使いやすく」といった抽象的な表現はさけ、具体的な数値や振る舞いを記述しましょう。特にウォーターフォール（予測型）の開発において、曖昧な表現は禁物です。
優先順位をつけて、スコープを管理する
限られたリソース内で最大の効果を出すために、要件に優先順位をつけてください。PMBOKには記載されていませんが、MoSCoW（Must／Should／Could／Won’t）のフレームワークが役立ちます。これはビジネス価値や実現可能性などを考慮して「必須」「推奨」「可能」「不要」の4段階に分類するもの。「必須」の割合が増えないように、各25％程度に振り分けましょう。
以上が要求・要件を取りまとめる際のポイントです。続いての段階はスコープマネジメント。現場の実態をまじえて、徹底解説します。くわしくは次回に――。
よくある質問（FAQ）
はい。規模・業種・開発アプローチ（予測型／適応型）を問わず、あらゆるプロジェクトに適用可能です。ただし、状況によって最適解は異なります。原理・原則をもとに、PMBOKの方法論を調整しましょう。
システム開発における「要求」とは、ビジネス側が達成したい目的や期待です。一方、「要件」は要求を実現するための具体的な条件です。詳細は本文『「要求」と「要件」の違い』を参照してください。
|
＜お役立ち資料＞ Lychee RedmineでできるPMBOK この記事で紹介した「PMBOK（ピンボック）」と、Lychee Redmineの活用方法を結びつけて解説した資料です。 この資料でわかること
|
監修者プロフィール
 |
Ridgelinez株式会社 プロジェクトマネジメントおよびアジャイルDevOpsの専門家。日立製作所、デロイトトーマツコンサルティングなどを経て現職。大規模アジャイルおよびアジャイルシフト、DXにともなう組織的変革管理（OCM）において、数多くの実践経験を有する。日米欧のプロジェクトマネジメントおよびアジャイル標準に精通し、日米欧3団体の最上位認定を保有。企画・要件整理・設計・開発・テスト・運用・内製化まで、実践型の伴走を行う。これまでに40件以上のプロジェクトマネジメントを経験。日本プロジェクトマネジメント協会のPMBOK講座のほか、私立大学でもプロジェクトマネジメント論の講師を務める。 【保有学位】 【保有資格】 |
 |
Ridgelinez株式会社 富士通システムソリューションズに入社後、フィールドSEとして流通業や運輸業などの基幹システム再構築プロジェクトに参画。富士通へ転籍後、プロジェクトマネージャーとして、総合商社・専門商社の基幹システム再構築プロジェクトを担当。2021年、アジャイル開発プロジェクトの実践経験を活かし、部門全体のアジャイル普及に向けた商談プロセス・商材の標準化や、アジャイル研修の設計・作成と講師などの活動を行う。2024年より現職。 【保有資格】 |
 |
Ridgelinez株式会社 大手IT企業でパッケージ導入のプロジェクトマネージャーを皮切りに、経営指標の可視化プロジェクトなどに従事。PwCコンサルティングや日清オイリオグループでは、ウォーターフォール開発からアジャイル開発への移行を推進。経営指標、営業、生産、研究まで幅広いビジネス領域でアジャイル手法を導入・改善。これまでに20件以上のアジャイルプロジェクトを成功に導く。また、17名のチームを率いる課長として、コーチング、プロジェクトマネジメント、営業支援、コンサルティング、研修講師の役割を兼務。500時間以上のコーチング経験を活かして、組織改革をリードした。特にアジャイル開発を活用した組織変革において、確かな実績を積み重ねる。 【保有資格】 |
30日無料トライアルをはじめる
- 多機能ガントチャート/カンバン/バックログ/リソース管理/CCPM/レポートなど
- ・ クレジットカード登録不要
- ・ 期間終了後も自動課金なし
- ・ 法人の方のみを対象
このサイトはreCAPTCHAによって保護されており、Googleのプライバシーポリシーと利用規約が適用されます。
Lychee Redmine活用
プロジェクト管理手法
仕事効率化・生産性アップ