プロジェクト憲章とは一体何か？（サンプルあり）

この記事では、プロジェクトマネジメントを進めるうえで、一番大切な「プロジェクト憲章」について、サンプルをご紹介しながら説明します。

 

PMBOKを勉強している人で「プロジェクト憲章」という言葉を知らない人はいないと思います。

でも、プロジェクトに従事しているけれど「プロジェクト憲章」を見たことが無い人や、そもそも「プロジェクト憲章」が何か全くわからない、という人も少なくないでしょう。

この記事では、PMBOKの基本概念で、プロマネが一番大事にしなければいけない文書である「プロジェクト憲章」について、架空のプロジェクトのサンプルを交えながら説明します。

 

スポンサード リンク

 

プロジェクト憲章とは何？

人から聞いた話です。とあるグローバルプロジェクトで、アメリカ人のチームメンバーが「プロジェクト憲章を作ろう」と発言したところ、日本人側のプロジェクトリーダーが「プロジェクト憲章ってなんだ？？」と質問してきました。一瞬沈黙が訪れました。

 

沈黙の理由は「この日本人はプロジェクトを率いているのに、プロジェクト憲章が何か知らないのか」という失望です。

 

PMBOK用語でプロジェクト憲章というのは、次のように定義されています。

プロジェクト憲章は、プロジェクトの存在を正式に認可する文書であり、プロジェクトのイニシエーターまたはスポンサーが発行する。プロジェクト憲章は、プロジェクト・マネージャーが母体組織の資源をプロジェクト活動のために使用する権限を与える。プロジェクト憲章を通して文書化されるものとして、ビジネス・ニーズ、前提条件、制約条件、顧客ニーズの理解範囲、ハイレベルの要求事項、新しいプロダクト、サービス、あるいは所産が満たすべき要求事項がある。 (PMBOKガイド 第5版)

 

プロジェクトの発起人(スポンサー)が作って、その内容に基づいてプロマネが仕事を遂行する、というものです。ある意味で、これが無いとプロジェクトが始まりません。もしプロマネが仕事を始めるときにプロジェクト憲章が存在していなかった場合は、まずはプロジェクト憲章を作る・作らせることから始めないといけないのです。

 

プロジェクト憲章が無いとどうなる？

プロジェクト憲章は、PMBOKによれば、プロジェクトの一番最初に作成されるべき書類なので、めちゃくちゃ大事です。

とはいえ、冒頭のグローバルプロジェクトの例で紹介した日本人のように、「私の会社にはそんな文書は存在しない」という人もたくさんいると思います。でも、そういう人のプロジェクトが100%失敗しているかというと、そんなことはありません。

プロジェクト憲章って「あったら嬉しいけど、無くても困らない」、その程度のものなんでしょうか？

 

PMBOKは、プロジェクトを成功させるために必要な知識・ノウハウが蓄積されたものです。プロジェクトを失敗させないために作り出されたプロセスが「プロジェクト憲章作成」です。

仕事(プロジェクト)をしていると、だいたいの関係者は、プロジェクトの名前や主要メンバーを知っていると思います。プロジェクトのメンバーは、なんでそのプロジェクトが大事なのか、だとか、スケジュール・予算を知っていることでしょう。

プロジェクト憲章というのは、プロジェクトを進める上で「みんなが何となく認識している大事な事を、最初に文書化する」というものなのです。

 

プロジェクト憲章には何を書けば良い？

そんなわけで、「我が社にはプロジェクト憲章なんて存在しない」といっている方も、一度プロジェクトを始める前に、プロジェクト憲章を作ってみてはいかがでしょうか？

 

とはいえ、一体どんな事を書けばいいのでしょうか？

 

PMBOKによれば、プロジェクト憲章には次のような項目が記載されているべき、と記載されています。(PMBOKの内容を抜粋・要約しています)

• プロジェクトの目的 (なんでこの仕事やるの？)
• 測定可能な目標 (何がゴール？)
• 前提条件と制約条件 (どうやってやるの？)
• マイルストーン・スケジュール (いつ頃までに終えるの？)
• 予算　(いくら使えるの？)
• リスク　(ヤバいこと途中で起こらない？)
• PMの名前、その責任範囲 (誰が責任者？)

 

会社によっては、項目が増えたり減ったりするでしょう。また、他にもいくつか大事な情報があるので、PMBOKガイドをしっかり読んでおいてください。

 

プロジェクト憲章の分量はどのくらい？

プロジェクト憲章の分量は、会社の文化やプロジェクトの規模によって異なると思います。A4で1ページで良い会社もあれば、10ページ以上の文書が必要な会社もあるでしょう。この記事の最後に、A4で1ページのプロジェクト憲章のサンプルをご紹介します。

ただ、絶対に頭に入れておいてほしいことは、プロジェクト憲章には「立ち上げ時点でわかっていることだけを記載する」ということです。日本的な考え方だと、プロジェクトを始める前に、全てのリスクを洗い出して、完璧な見積もりを作って、それでようやく開始、という風にやりがちです。

でも、PMBOKの考え方は、プロジェクトは段階的に詳細がわかる性質なので、プロジェクト憲章を作る時点では、あくまでザックリとした情報を記載するにとどめて、詳細なリスクだとか予算だとかは、すべてプロジェクトメンバーがその後の工程（計画フェーズ）で決めていく、というものです。

ここの位置付けがあっていないと、いつまでたってもプロジェクトを始めることができません。

 

私の勤務先ではプロジェクト憲章が承認されたあとで、プロジェクトマネージャーがメンバーを招集して、プロジェクト憲章をもとにプロジェクトの概要を説明する、キック・オフ(プロジェクト立ち上げ)会議が開催されます。プロジェクト・マネージャーは、素早く必要最低限の情報を集めて、迅速に次のフェーズに移行することが求められています。

 

プロジェクト憲章のサンプル

最後に、プロジェクト憲章のサンプルをご紹介します。私の会社で使っているテンプレートを公開するわけにはいけないので、PMBOKに記載されている項目をヒントに作ってみました。

フォーマットはWordを想定しました。私の会社は同じような情報をパワポ1枚にまとめています。

ここでは、「PMサイト」という架空のウェブサイトを更新する、という比較的小規模なプロジェクトを想定しました。

画像が見づらいかもしれないので、補足します。

こんな項目を含めました。

1. プロジェクトの目的
2. プロジェクトの目標 (測定可能な成功条件)
3. プロジェクトの対象範囲 (更新後のウェブサイトの対象機器)
4. 前提・制約条件
5. スケジュール
6. 予算 (概算)
7. リスク
8. プロジェクトメンバーおよびプロジェクト・マネージャー

もちろんこれが正解というわけではありません。項目はそのままで、もっと詳しく書かないといけないかもしれません。

項目別に補足します。

1. プロジェクトの目的

読んで字のごとく、何をするプロジェクトなのか、ということです。仕事を進めていくと「そもそもなんでこのプロジェクトやってるんだっけ？」という素朴にして致命的な疑問が浮かんだときに、このプロジェクト憲章を突きつければ、みんな納得できるような記載を心がけましょう。

ここで取り上げたのは、HTML全盛期に作って、今や古くなってスマホで見ればレイアウトが崩れるような古いウェブサイトを最新のサイトに更新する、という案件です。訪問ユーザ数を増やしたいとか、ウェブ技術者の会社なのにサイトがしょぼいからイメージアップのためとか、「なぜこのプロジェクトをやるのか」を書いておくとより良いでしょう。

 

2. プロジェクトの目標

先に述べた目的を達成するにあたり、どうすれば成功（失敗）なのか、という状態を定義しました。アタリマエかもしれませんが、このプロジェクトでは指定された日付までに完了させることを目標としました。

定量的な目標の例として、他には予算内の達成、所定の売り上げ達成、x%の導入、などがあります。

 

3. プロジェクトの対象範囲

いわゆるスコープ定義というものです。詳しくは計画フェーズのスコープ定義でやることになるけれど、偉い人たちと一緒に、先にどのくらいまでやるかを合意しておく、というものです。

ウェブサイトを作るプロジェクトなので、スマホ・パソコン・タブレットという端末を対象にしました。手間がかかる割に使っている人が少ないであろう、フィーチャーフォン(ガラケー）や、古いブラウザ(Internet Explorer)はやらないよ、と決めちゃいました。

もっと突き詰めると、「iOSのこれ以前のバージョンは技術的に対応が難しいよね」とか「このブラウザは互換性がないね」とか細かい話がでてくるでしょう。でも、経営陣とかとやるべき粒度でないと感じた場合は、後工程のスコープ定義でやりましょう。

 

4. 前提・制約条件

プロジェクトを進めるにあたって、前提とすることがあるでしょう。そういったことを書いておきます。例えば、この事例の場合、「今のサイトの情報は完璧だ。でもデザインがダサい」という前提だったら、文章の書き直しはしなくていいことになります。

ベンダー側が作る場合だと、「5-6月の間、顧客側担当者が毎日レビューをしてくれること。そ(そうじゃないと手戻りが発生してとても納期に間に合わない）」なんて前提条件もありうるでしょう。

完璧なサイトを作ったけど、このベンダーさんに毎月うん百万円払わないと記事の更新すらできない、という事態を防ぐために、「社内の人が更新できること」という前提をつけてみました。そうすると、あとあと要件を詰めていくときに拠り所ができます。

 

5. スケジュール

プロジェクト憲章に載せるスケジュールはあくまで概算です。詳細は後工程のスケジュール作成で作ります。この時点では、9月稼働だったら、8月の時点でテスト終わってないとな、とか、要件定義は2ヶ月くらいかかるよな、とか、大日程レベルで良いのです。

終了までにある、必要なマイルストーンを列挙する程度で良いでしょう。「xxを承認するのは7月末しか無い」という制約があるならば、それを書いておきましょう。後でスケジュールを作るときに、その制約日程に間に合わせるように前の工程を終わらせないといけないな、とか今から考えることができます。

 

6. 予算 (概算）

ここでは概算として、「詳しくは後で見積もる、でも上限額はxx円」と決めました。ただ、プロジェクトを承認するにあたって決める予算のレベルは組織によって違うと思います。

概算・上限だけザックリ決める会社もあれば、完全な見積もりがでていないとプロジェクトを開始することすら許されない会社もあるでしょう。もっとも、見積もりを作るのだって工数が必要なので、できればプロジェクトの作業に組み込んでおきたいものです。

 

7. リスク

遅延が発生したら、稼働日後に予定されているイベントに影響が出る、というリスクを想定しました。そうならないように、リスクを「軽減」されるべく、スコープを一旦縮小して納期に間に合わせる、という対策を立てました。これはあくまで大方針レベルの対策です。

「プロジェクトを始めたのだけど、不測の事態で中止になった」なんて事態は避けたいものです。開始時点で考えうるリスクを列挙して、対応策を考えましょう。

まだ全てのリスクに解決策を立てる必要はありません。日本企業は「そうはいってもセキュリティが心配だ」「情報漏洩したらどうするんだ」と最悪の事態を洗い出すのが得意な人が多いように思います。でも、この時点で対策を立てていたらいつまでも前に進めません。プロジェクト立ち上げの段階ではみんなでリスクがあることを認識して、必要な対策は後でじっくり考えよう（リスク対応計画）というのがPMBOKの考えです。

始めから「全てのリスクは潰したから絶対失敗しない！」と言い切れるプロジェクトなんてどこにも無いのです。

 

8. プロジェクトメンバーおよびプロジェクト・マネージャー

誰がプロジェクトを実行するのか、誰が責任者なのか、といった具合に必要な人の名前を記載しておきましょう。ステークホルダー特定が終わっていれば、ここで活かします。プロジェクトの組織図をかければ理想です。

プロジェクトの中盤になって、「お、この案件、データセンター部門と連携しないといけなかった」なんてことが無いように、関係がありそうな人は一通り含めるように心がけましょう。

 

 

おわりに：プロジェクト憲章に正解はない

PMBOKには「プロジェクト憲章はこういう風に書くべし」と説明はありますが「このテンプレートにしたがって書かなくてはならない」とは書いてありません。全ての組織・プロジェクトは違うので、一律にルールを適用できないからです。つまり、プロジェクト憲章はあなたの組織によって異なります。

 

ここで紹介したのは、あくまで架空の案件をもとに私がササっと作り出したサンプルです。もっと項目を増やしたり、記載を充実させる必要があるかもしれません。とはいえ、このサンプルを30ページに膨らますような努力は必要ないはずです。きっと、計画フェーズでやるべき仕事をしちゃっています。プロジェクト憲章は、対象となる読者(ステークホルダー)をしっかり頭に描いた上で、必要な粒度で作成するようにしてくださいね。

このサンプルが参考になれば幸いです。