PMBOKのプロジェクト憲章の変遷

ビジネス

～承認の文書から、チームを動かす約束へ～

かつて「プロジェクト憲章（Project Charter）」といえば、上層部が発行し、プロジェクトマネジャーに正式な権限を与える上意下達的な「通行手形」のようなものでした。しかし、PMBOK第7版ではこの扱いが大きく変わり、同時に「チームチャーター（Team Charter）」という新しい概念が登場します。本記事では、PMBOKにおけるプロジェクト憲章の変遷を通じて、その意味と活用の方向性を整理します。

はじめに

プロジェクト憲章は長らく「プロジェクトを公式に開始するための承認文書」として扱われてきました。特にPMBOK第5版・第6版では、プロジェクト憲章は立上げプロセス群における最初の成果物であり、スポンサーの承認を経てプロジェクトマネジャー（PM）に権限を与えるもの、という明確な位置づけがありました。

しかしPMBOK第7版では、従来のように「プロジェクト憲章を作成する」という個別プロセスは廃止され、代わりに「価値をどう届けるか」という観点から、プロジェクト全体の合意形成やチームの自律性を重視する構造に変わっています。さらに、現場運営のための新しい概念として「チームチャーター（Team Charter）」が明確に示されました。

この変化は、単なる用語の変更ではありません。プロジェクトマネジメントそのものの思想が、「命令と統制」から「価値の共創と合意」にシフトしていることを意味していると解釈できます。

1．第6版までのプロジェクトチャーター（憲章）とは？

PMBOK第5版・第6版では、プロジェクト憲章（Project Charter）は非常に重要な公式文書でした。定義はシンプルで、「プロジェクトを正式に承認し、PMに権限を与える文書」です。

プロジェクト憲章の主な役割（第6版まで）

  • プロジェクトの目的・背景・期待される成果を明記する
  • ビジネス上の正当性（なぜやるのか）を示す
  • スポンサーの承認と責任範囲を明文化する
  • プロジェクトマネジャーに与えられる権限と裁量を定義する
  • 主要なステークホルダー、要求事項、成功基準を記録する

この文書が承認された瞬間から、PMは公式に「プロジェクトを動かす権限」を得る、という扱いでした。特に官公庁や大規模なシステム開発など、ガバナンスが強い組織では、プロジェクト憲章はほぼ「契約的な重み」を持った文書として使われてきました。

一方で、現場レベルでは次のような課題もありました。

  • 憲章は上層部とPMの間で作成・承認されるため、現場メンバーが内容をそもそも知らない
  • 「お偉い人のハンコをもらうための儀式」と化し、実際の判断材料として使われない
  • 一度作って承認された後は、ほとんど更新されない（＝古い前提のまま残る）

つまり、第6版までのプロジェクト憲章は「権限付与」と「外向きの正統性」には強かった一方で、「現場での運営指針」としてはほとんど機能しないことが多かったのです。

2．第7版のプロジェクトチャーターとチームチャーターとは？

PMBOK第7版では、ガイド全体の前提が大きく変わりました。従来のような「49のプロセス」と「10の知識エリア」という構造は姿を消し、代わりに「原則（Principles）」と「パフォーマンス領域（Performance Domains）」、そして「価値提供システム（System for Value Delivery）」という考え方が導入されています。

この転換に伴って、「プロジェクト憲章を作成する」という個別プロセスは示されなくなりました。

とはいえ、プロジェクト憲章そのものが無意味になったわけではありません。第7版では、プロジェクト憲章は次のような位置づけになります。

  • プロジェクト開始のための合意や認可（Authorization to Proceed）を記録する手段
  • プロジェクトの目的・価値・期待成果を関係者間で共有するためのベース
  • 組織として「このプロジェクトはやる」と内外に示す宣言

つまり、第7版では「憲章＝決まった様式のドキュメント」ではなく、「プロジェクトの存在意義を合意するためのアーティファクト（成果物の一形態）」として扱われます。形式が固定されていない、という点が大きな違いです。必要ならスライド1枚や簡易の合意メモでもよい、という考え方です。

もう一つの主役：チームチャーター（Team Charter）

第7版で新しく明確に打ち出されたのが、チームチャーター（Team Charter）です。これはプロジェクト憲章とは目的が異なります。

チームチャーターは、チーム内部の運営やふるまいのルールを明文化した「チームの約束ごと」です。主な内容は以下のようなものです。

  • チームのミッション・価値観・行動指針
  • メンバーそれぞれの役割と責任（R&R）
  • 意思決定の方法（合意形成、最終判断者、エスカレーションの経路）
  • コミュニケーションルール（会議頻度、報告方法、使用ツール）
  • コンフリクト（衝突）が起きたときの解決手順
  • 成功の定義（何をもって「できた」とみなすか）

これによって、現場で働くメンバーが日常的に参照できる運営ガイドが明確になります。「プロジェクト憲章が上から与えられるもの」だとすれば、「チームチャーターはチーム自身が合意してつくるもの」です。

3．それぞれの比較

観点第6版までのプロジェクト憲章第7版におけるプロジェクト憲章チームチャーター
主目的プロジェクトの正式承認とPMへの権限付与価値提供開始のための合意と方向性の共有チーム運営のルールと協働の約束
作り手 / 承認者スポンサーが承認、PMが関与スポンサーとPMの間で合意PMとチームメンバー全員で合意
性質上層部の権威を示す公式文書フォーマット自由な合意記録現場の行動指針・ワーキングアグリーメント
現場での参照頻度低い（保管されがち）必要に応じて共有・再確認高い（日常的に使う、定期的に更新）
更新基本的に固定前提が変われば調整可スプリントごと・定期レビューで更新

この比較から分かるのは、PMBOKが「承認の文書」と「運営の文書」を分離し、それぞれの役割を明確化したということです。プロジェクト憲章はプロジェクトの存在意義と外部正当性を示し、チームチャーターは現場の自律性と日々の運営品質を支えるという二層モデルになった、と言えます。

4．変更された背景の考察

1）プロセス主義から価値主義へ

PMBOK第7版は「プロセスを守れば成功する」という従来の前提を手放し、「価値を届けられるか」を最優先に置いています。これは、PMIが第7版で掲げている「価値提供システム（System for Value Delivery）」という思想に表れています。プロジェクトは、単に納品物を作るのではなく、ステークホルダーに価値を届ける手段である、という考え方です。

2）組織ガバナンスとチームガバナンスの分離

現代のプロジェクトは、1つの部署や1つのチームでは完結しません。企業内外の複数のグループが関わる前提です。そのため、組織としての承認・投資判断（プロジェクト憲章）と、現場チームの具体的な動き方（チームチャーター）を分けて設計する必要がありました。

3）チームの自律性と心理的安全性の重視

高い成果を出すチームが持っているのは「従順さ」ではなく「心理的安全性」だ、というのは今では一般的な知見になりました。チームチャーターは、どう議論し、どうぶつかり、どう決めるかを先に合意することで、無駄な摩擦やサイロ化を防ぎます。つまり、マネジメントのスタイルを「命令と報告」から「合意と共創」へ変える仕組みです。

4）アジャイル実務の正式な取り込み

アジャイルの現場では昔から「ワーキングアグリーメント（Working Agreement）」「チーム合意書」といった形で、チーム内の振る舞いルールを明文化する文化がありました。PMBOK第7版はこの実務を正面から取り込み、チームチャーターとして体系化しています。ウォーターフォール型とアジャイル型の橋渡しが、ようやくPMBOKの本体に入ってきたとも言えます。

5．改善された点

第7版でのこの変化は、「プロジェクト憲章を弱めた」のではなく、むしろ現場への効力を高めました。具体的には次の点が改善されています。

  • 柔軟性： プロジェクト憲章の形式が固定ではなくなり、組織文化や事業スピードに合わせてテーラリングできる。
  • 実効性： チームチャーターによって、日々の意思決定や役割分担、コミュニケーションのルールが明文化される。
  • 透明性： 「誰が何をどう決めるのか」がチーム全員に共有されるため、属人性や“声の大きい人ルール”を抑えられる。
  • オーナーシップ： チーム自身が合意して作った約束事なので、メンバーの主体性と納得感が高い。
  • 整合性： 組織としての目的（プロジェクト憲章）と、現場のオペレーション（チームチャーター）が分離しつつもつながる構造になった。

要するに、第7版は「形式的な承認書」としてプロジェクト憲章を残しつつ、その下で動く現場に対しては、より機能する武器（チームチャーター）を与えた、と言えます。

6．活用するためにはどのように行動すべきか？

では、この新しい考え方を現場で活かすには、マネジャーやチームはどう動くべきでしょうか。ポイントは次の5つです。

  1. プロジェクト憲章を「存在意義の宣言」として運用する。
    予算やスコープを並べるだけではなく、「このプロジェクトは何のために存在するのか」「どんな価値を届けるのか」を明確にする。
  2. チームチャーターはチーム全員で作る。
    マネージャーが一方的に配布するのではなく、キックオフやスプリント0で話し合いながら合意する。作成プロセスそのものがチームビルディングになる。
  3. 定期的に見直す。
    チームチャーターは固定文書ではない。レトロスペクティブやマイルストーンのたびに、現状とズレていないかをアップデートする。
  4. 両チャーターの一貫性を確認する。
    「プロジェクトとして目指している価値」と「チームが毎日やっている運営ルール」にズレがないかを確認し、必要なら両方を更新する。
  5. 文化として根付かせる。
    どちらのチャーターも、SharePointやファイルサーバの奥に眠らせず、日常の会話や意思決定・レビューの場で引き合いに出す。「言葉として生きているか？」が判断基準になる。

7．まとめ

PMBOKにおけるプロジェクト憲章の扱いは、第6版と第7版で明確に変化しました。第6版までは、プロジェクト憲章は「上層部の承認とPMへの権限付与」を目的とする公式文書でした。これは、いわばプロジェクトの通行手形であり、組織的な正統性を保証するものでした。

一方、第7版では憲章は「特定フォーマットの必須文書」ではなくなり、組織や状況に応じて柔軟に定義できる合意の枠組みとして扱われます。そして現場運営に関しては、チーム自らが役割・ルール・意思決定の型を合意する「チームチャーター」が明確に示されました。

これは、プロジェクトマネジメントの重心が「命令と統制」から「価値と共創」へ移ったことを意味します。

Project Charter は存在意義と方向性を示し、Team Charter は日々の行動と協働を支える。 この2つを両輪として運用することで、プロジェクトはよりスムーズに、より自律的に、そしてより価値に向かって進むことができます。

参考文献・出典

  • PMI（Project Management Institute）.
    『A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Sixth Edition』, 2017.
    特に「4.1 プロジェクト憲章の作成（Develop Project Charter）」において、プロジェクト憲章を 「プロジェクトを正式に承認し、プロジェクトマネジャーに権限を与える文書」と定義している。
  • PMI（Project Management Institute）.
    『A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Seventh Edition』, および『The Standard for Project Management』, 2021.
    第7版ではプロセス中心モデルを離れ、「価値提供システム（System for Value Delivery）」の中で、 プロジェクト開始のための合意とチームの自律性（Team Charter）を重視している。 特に「Team Performance Domain」において、チームチャーターを 「チームの価値観・合意事項・運営ガイドラインを明確にするもの」と説明している。
  • PMI & Agile Alliance.
    『Agile Practice Guide』, 2017.
    アジャイルチームが「ワーキングアグリーメント（Working Agreement）」を用いて 意思決定やコミュニケーションのルールを明文化し、チームの自律性とコラボレーションを高めるという 実践を紹介しており、第7版のチームチャーター概念の背景となっている。
  • PMI Webinar.
    “PMBOK® Guide – Seventh Edition Overview”, PMI.org, 2021.
    プロジェクト憲章やアーティファクトの形式を「組織文脈に応じてテーラリングすべき」と説明。 また、チームの自律性と価値提供を強調している。
プロジェクトマネジメント知識体系ガイド（PMBOKガイド）第7版＋プロジェクトマネジメント標準　PMI日本支部 監訳
プロジェクトマネジメント知識体系ガイド（PMBOKガイド）第7版＋プロジェクトマネジメント標準
プロジェクトマネジメントの世界的基準書。
第7版では「成果志向」から「価値志向」へ。
現場マネージャーに必携の1冊です。

コメント