プロジェクト憲章とは何か？作り方と効果的な使い方をわかりやすく解説

2019年11月1日

プロジェクト憲章の概要

プロジェクト憲章とは

プロジェクト憲章とはプロジェクトの認知・承認を目的として、プロジェクトの立ち上げプロセスで作成される企画書のことです。
PMBOKによると、プロジェクト憲章は 「プロジェクト・マネジャーが母体組織の資源をプロジェクト活動のために使用する権限を与える」 ために「プロジェクトの存在を正式に認可する文書」と定義されています[1]PMBOK第６版、81頁。。

このプロジェクト憲章はPMBOKの手法に沿うと「プロジェクト憲章の作成」プロセスの中で作成され、プロジェクトのイニシエーターやスポンサーが発行します。

「憲章」という表現について

PMBOKを学び始めるとすぐに出会うこの「プロジェクト憲章」ですが、 「憲章」という言葉はイギリスのマグナカルタ（大憲章）や国連憲章程度しか目にする機会がなく、この非日常的な表現が内容をわかりづらくし、PMBOKを難しいものと認識させてしまう原因となっているのではないでしょうか。

プロジェクト憲章とは、内容的に言っても「企画書」であり、そのように認識したほうがプロジェクト中のコミュニケーションの上でも大過ないと考えられます（この「憲章」という表現には、プロジェクトを神聖なものにしようとするPMBOK側の意図を感じざるを得ません）。

この他、「プロジェクト方針書」や「プロジェクト目標定義書」などと言い換えても良いかもしれません[2]深沢隆司『ベースラインで成功する プロジェクトマネジメント』日本実業出版社 、2008年、150頁。。

プロジェクト憲章はなぜ必要なのか？

プロジェクト憲章のメリット

プロジェクト憲章は組織の中でプロジェクトの合意を得るために作成されます。マグナカルタ（大憲章）のように、一度プロジェクト憲章が発布されれば、王様（社長などの組織のトップ）であっても不可侵であることを宣言するようなものです。
一方でプロジェクト憲章がないプロジェクトというのは、組織の合意を得られていないプロジェクトとなってしまいます。
例えばプロジェクトの中で、「○○部の××さんの協力が必要になった」「開発のためにこのぐらいの金額が必要になった」という事態になったときに、プロジェクト憲章があれば、承認要求事項や財源などの項目と照らし合わせて実行の可否を判断できます。しかし、プロジェクト憲章がなければその調達も１つ１つ合意をとっていかなければならず、プロジェクト・マネジャーの負担となってしまいます。
組織内外の協力体制構築のために、プロジェクト憲章は不可欠であると言えましょう。

組織内部の契約書の代わりにプロジェクト憲章を使う

上述の通り、プロジェクト憲章は組織内外に協力を要請しやすくします。
例えば開発を組織外部に依頼するときなどは、契約書を取り交わし、業務の範囲を定めていきます。しかし、組織内部に協力を要請する場合は、契約などを結ばないため、協力を要請しても相手が応じてくれないという可能性もあります。
こうしたトラブルを防ぐために、プロジェクト憲章を作成し、組織内の契約書の代わりに使用することができます。

プロジェクト・マネジャーの理解のためにプロジェクト憲章を使用する

プロジェクト・マネジャーの選定はプロジェクト憲章を作成する中で行われるのが一般的です。
冒頭で述べた通り、プロジェクト憲章は企画書と同じようなものですから、企画を作成しながら、「このプロジェクトを成しえるのは誰なのか？」を考えていくというイメージです。
プロジェクト憲章を作成しながら、「このプロジェクトでプロジェクト・マネジャーになれば、何が目的となり、どのような責任があるのか？」「プロジェクトを達成するために、どのような権限が与えられるのか？」という情報をプロジェクト・マネジャーとして見当をつけているスタッフと共有することで、プロジェクト・マネジャー候補のプロジェクトへの理解を深めることができます。

プロジェクト憲章の内容

プロジェクト憲章の作成方法を話していく前に、プロジェクト憲章の内容を把握し、ゴールを見定めていきましょう。
プロジェクト憲章の中には以下の内容を盛り込むことが推奨されています[3]PMBOK第６版、81頁。。

  • プロジェクトの目的
  • 成功基準
  • ハイレベルの要求事項
  • ハイレベルのプロジェクト記述、アウトライン、および主要成果物
  • 全体のリスク
  • 要約マイルストーン・スケジュール
  • 事前承認された財源
  • ステークホルダーの一覧
  • 承認要求事項
  • 終了基準
  • プロジェクト・マネジャーとその責任と権限
  • プロジェクト憲章を認可するスポンサーあるいは他の人物の名前と地位

ここからは、これらプロジェクト憲章の内容について見ていきましょう。

プロジェクトの目的

プロジェクト憲章では、プロジェクトの目的を記述していきます。プロジェクトの目的とは「なぜこのプロジェクトを始めなければならないのか」という情報です。この目的が明確であればあるほど、成功基準も明確になり、プロジェクト・チームへの共有もしやすくなります。
さらに、このプロジェクトの目的は後に見る要求事項がもととなっており、組織の要求にどのような対策を講じるかを宣言するものでもあります。

ここで気を付けることは、プロジェクト単体の目的だけでなく、組織の戦略がどのようなもので、その中でこのプロジェクトがどのような意味をもっているのかを示しておくとよいでしょう。
プロジェクトを「なぜ」始めるのか、そして「何」をするのかを明確にするのが、プロジェクト憲章の大きな役割です。

成功基準

成功基準とは、プロジェクトがどのような状態になったら成功したと言えるのかを定めていきます。
プロジェクトマネジメントでは、プロジェクトの目的が達成されることもさることながら、スケジュールが遅れていないか、予算超過を起こしていないのかも厳しくチェックする必要があります。品質・コスト・納期、いわゆるQCDに注目しながら、成功基準を決めていきます。

成功基準とは、このプロジェクトの成否をどのように判断するのかを文書化したものです。
PMBOKでは以下３つの質問に答えられるようにしなければならないとしています[4]PMBOK第６版、34頁。。

  • このプロジェクトの成功とはどのようなことか
  • 成功はどのように測定されるか
  • どのような要因が成功に影響するか

２点目の「成功はどのように測定されるか」という質問に対しては、具体的な数的根拠をもって答えられることが望ましいです。
例えば営業支援ツールであれば、投資収益率（ROI）の計測や、１月当たりの商談数などの目標を定めるとよいでしょう。

終了基準

プロジェクトの成功基準を定めた後は、プロジェクトの終了基準を定めておくとよいとされています。
つまり、「○○の開発が完了し、△△による検収が完了したら」であるとか「○○のイベントが終了したら」というものです。

失敗基準

成功基準とは逆に、失敗の基準をプロジェクトの企画を立てる際に明確にしておくと、価値のないプロジェクトをずるずると続けることがなくなります。
成功基準で用いた指標の中で、「どの水準を下回ったらこのプロジェクトを見直すか」をあらかじめ定めることで、プロジェクト見直しのタイミングを逃すことがなくなります。

ハイレベルの要求事項、プロジェクト記述、境界、主要成果物

プロジェクト憲章には、ハイレベルの要求事項や、ハイレベルのプロジェクト記述、境界、主要成果物も記述していきます。
「ハイレベル」というのはPMBOKでしばしば使われる表現ですが、「大まかな」とか「粒度の高い」という風に言い換えてもよいでしょう。
プロジェクトの中ではスコープ・マネジメントの中で要求事項の収集などが行われ、要望を細かく収集していきますが、プロジェクト憲章の段階ではそこまで細かな情報が得られていないのが常です。
そのため、プロジェクト憲章の段階では「人事管理システムを開発する」「Webサイトをリニューアルする」というような、大まかな要望や主要成果物を書いていきます。

全体リスク

全体リスクでは、プロジェクトで予期されているリスクについて記載していきます。
例えば「キャンペーンの関係から○月×日を過ぎることができない」であったり、「A社の体制により、月曜日には会議が行えない」など、プロジェクト全体に影響を及ぼすようなリスクについて記述していきます。

要約マイルストーン・スケジュール

要約マイルストーン・スケジュールの例
要約マイルストーン・スケジュールのイメージ図

プロジェクト憲章には、要約マイルストーン・スケジュールも掲載します。
要約マイルストーン・スケジュールとは、その名の通り、要約されたマイルストーン・スケジュールであり、納期などのプロジェクトの大まかなマイルストーンを示したものです。
スケジュールについても、プロジェクトの中でスケジュール・マネジメントを行い、プロジェクトにかかる時間を詳細に詰めていきますが、プロジェクト憲章作成の段階で「だいたいこのくらいの期間がかかる」というものを掲載していきます。

事前承認された財源

事前承認された財源とは、このプロジェクトの予算のことです。

主要ステークホルダー・リスト

プロジェクトにはさまざまなステークホルダーがいますが、その中でも主要なステークホルダーを記載していきます。
例えば、このプロジェクトを進める部署の部長もステークホルダーであれば、プロジェクトの結果生み出されるプロダクトを使用するユーザーもステークホルダーです。
このステークホルダーについても、ステークホルダー・マネジメントの中でステークホルダーを発見していったり、関与の仕方を考えていくのですが、プロジェクト憲章作成時点で把握されている主だったステークホルダーを掲載していきます。

プロジェクト承認要求事項

プロジェクト承認要求事項とは、プロジェクトの成否を判断するための事項であったり、その判断をする人物について記述したものです。
例えば、「○○年×月△日までに終了させ、A部部長のBと、C部部長のDが確認し、問題がないと判断されたら、受け入れる」というように記述していきます。

プロジェクト終了基準

プロジェクト終了基準はプロジェクト承認要求事項と同様に、「どのような状態になったらプロジェクトを終了させるか」という基準ですが、プロジェクトを無事完了させたときの基準だけでなく、途中で中止する場合の基準も設けています。

任命されたプロジェクト・マネジャーとその責任と権限レベル

プロジェクト憲章では、任命されるプロジェクト・マネジャーについても言及していきます。
プロジェクト・マネジャーはプロジェクト憲章の作成途中で相談を受け、任命されるのが望ましいとされています。この任命されたプロジェクト・マネジャーがどのような責任を負い、権限をもっているかを記述していきます。

プロジェクト・マネジャーの仕事のしやすさはこの記述に拠ることも多いでしょう。
例えば、「○○万円以内であれば、プロジェクト・マネジャーが自由に判断し、調達活動を行うことができる。」とされているプロジェクトと「どのような場合でも予算を使用する場合は、常に会議にかけ、その可否を判断する。」という場合では、プロジェクト・マネジャーが持っている自由度が異なってきます。
そのため、プロジェクト・マネジャーへの任命を受けそうな場合は、極力この権限の相談をしながら、プロジェクトを動かしやすい権限を得られるようにするとよいでしょう。

プロジェクト憲章を認可するスポンサーあるいは他の人物の名前と地位

プロジェクト憲章の最後には、このプロジェクト憲章を認可した人物の名前と地位を明記します。
この承認者は多くの場合、お金を出すスポンサーが該当しますが、それ以外の人物が名を連ねることもあります。

プロジェクト憲章の承認者というのは、最終的なプロジェクトの責任者です。
プロジェクトが失敗した場合、プロジェクト・マネジャーの責任が問われるのは当然ですが、そもそもそのプロジェクト・マネジャーを任命しようとしたプロジェクト憲章を認めた人物の責任でもあります。

プロジェクト憲章を承認するというのは、ある意味プロジェクトの保証人になるようなものであり、プロジェクト・マネジャーと同等か、それ以上の責任があることを忘れてはいけません。
そのため、プロジェクト憲章の承認は慎重に行う必要があります。

プロジェクト憲章のインプット

プロジェクト憲章を作成する上で、材料となる情報（インプット）は以下のようなものです[5]PMBOK第６版、77～79頁。。

プロジェクト憲章はプロジェクトの開始前に作成するものなので、多くの資料が使えるわけではありません。
もとから組織が有している情報や、後述するツールと技法で必要な情報を取得していく必要があります。

ビジネス文書

ビジネス文書とは、その名の通り、ビジネスに関わる文書のことを指します。
その中でビジネス・ケースというのは、候補に挙がっているプロジェクト案の内容が経済的に実現可能かどうかを調査した文書です。言い換えれば、議題に挙がっているプロジェクトに投資をする価値があるのかどうかを示したものがビジネス・ケースです。

他方、ベネフィット・マネジメント計画書もプロジェクトに投資をする価値があるのかどうかを示したものではありますが、ビジネス・ケースがプロジェクトを行う意味を明らかにしているのに対し、ベネフィット・マネジメント計画書はより利益が創出されるプロセスに注目して記述されています。

ビジネス・ケース、ベネフィット・マネジメント計画書およびこれらの文書の違いについては、以下の記事もご参照ください。

プロジェクト憲章のツールと技法

プロジェクト憲章で使われるツールと技法は以下の通りです[6]PMBOK第６版、79～80頁。。

プロジェクト憲章は、企画書と同じようなものであるため、使われるツールと技法もブレインストーミングやフォーカス・グループ、インタビューというアイデアを出すものが主になります。
そして、そのアイデアをステークホルダーなどの協力者からうまく引き出すため、データ収集の際や会議の場で使えるコンフリクト・マネジメントやファシリテーション、会話のマネジメントという人間関係とチームに関するスキルが求められます。

プロジェクト憲章の作成の際に求められる専門家の知識としては、以下のようなものが挙げられます[7]PMBOK第６版、79頁。。

  • 組織戦略
  • ベネフィット・マネジメント
  • 業界の技術知識とプロジェクトの注力点
  • 所要期間と予算の見積り
  • リスクの特定

このように、プロジェクト憲章の作成の際に招かれる専門家は、経営全体を見ることができ、これから進めようとするプロジェクトの業界での基準を知っているような人物です。

注

注
↑1,↑3PMBOK第６版、81頁。
↑2深沢隆司『ベースラインで成功する プロジェクトマネジメント』日本実業出版社 、2008年、150頁。
↑4PMBOK第６版、34頁。
↑5PMBOK第６版、77～79頁。
↑6PMBOK第６版、79～80頁。
↑7PMBOK第６版、79頁。

文書・資料PMBOK,文書・資料

Posted by promapedia