ここでは、「JIS Q21500：2018 (ISO 21500：2012) プロジェクトマネジメントの手引」（以下、「プロジェクトマネジメントの手引」と呼びます。）に書かれている「プロジェクト憲章」について説明します。
「プロジェクト憲章」というと難しそうなイメージを受けますが、実はプロジェクト目標達成に必要な項目についてまとめた合意文書といったものと考えています。
なお、この記事を作成するに当たり、「プロジェクトマネジメントの手引き」の他にPMBOKも参考にしていますが、私の理解している内容になりますので、両者の正確な内容を知りたい場合には、それぞれの原文を参照してください。
JIS規格「JIS Q 21500：2018 (ISO 21500：2012) プロジェクトマネジメントの手引」はネットで見ることができます。
JISについては、以下のページをご参照ください。
「プロジェクト憲章」とは何か
憲章とは、重要かつ根本的なことを定めたもので、基本方針や実行計画をまとめた文書のことです。
プロジェクト憲章は、プロジェクトを正式に認可する文書であり、プロジェクトのオーナーやスポンサーが発行します。
プロジェクトのオーナーやスポンサーとは、プロジェクトの予算を握るいわゆる偉い人です。
このプロジェクト憲章の中で、プロジェクト・マネージャーが任命されて、資源（プロジェクト予算やメンバー）を使用する権限が与えられえます。
実際にプロジェクト憲章に含まれる内容には、
- プロジェクトの目的・前提・制約
- 顧客を含めた様々なニーズ
- 新商品やサービスに求められる要求事項
などがあります。
これらの内容についてプロジェクト憲章で明確にし、プロジェクトの利害関係者（ステークホルダ）と合意することにより、プロジェクトが正式に立ち上がります。
プロジェクト憲章に含めること
プロジェクト憲章に書く項目の内、主要なものを以下に列挙します。
- プロジェクトの目的（何のためにこのプロジェクトをするのか）
- （測定可能な）目標（何をもって目標達成とするのか）
- プロジェクトについての前提条件と制約条件
- 計画（主なマイルストーン、何をいつ頃までに完了するのか）
- 予算
- リスク
- プロジェクトの責任者（プロジェクト・マネージャーは誰であるかとその責任範囲）
プロジェクトにより、上記の項目以外の項目が増えることも、減ることもありますが、プロジェクトを成功させるための特別なことが含まれている訳ではありません。
プロジェクト憲章のボリューム（ページ数）
プロジェクト憲章の分量は、プロジェクトの種類や規模により様々です。
極端な話、Ａ４用紙１枚で済ませる場合もあれば、冊子のような場合もあります。
プロジェクト憲章の作り方にも関係しますが、プロジェクト憲章には、プロジェクトを立ち上げ時点で分かっていることだけを書きます。
「プロジェクトを立ち上げ時点で分かっていることだけを書く」ことについて、もう少し説明を加えます。
プロジェクトを始める前に、全てのリスクを洗い出し、完璧な計画を作ってから、プロジェクトを開始するという考えはムダに時間が過ぎていくことになり、間違いと言ってよいと考えています。
現在は社内外の環境が絶えず変化している時代です。仮にすべてのリスクを洗い出し、完璧な計画を作っても、プロジェクトを始めると予想外のこと、計画外のことが日常的に発生するからです。
プロジェクトには、詳細は進めていくうちに段階的に分かってくるという性質があります。プロジェクトを始めて進めないと分からないことがあるということです。
そこで、プロジェクト憲章を作る段階では、プロジェクト全体のおおまかな情報を記載するにとどめ、詳細なリスクや予算などは、プロジェクト・メンバーがその後の工程（計画フェーズ）で決めていきます。
プロジェクトで取り組もうと考える場合には、プロジェクトを素早く立ち上げ速く成果を得ることが要求されていることが多いかと思います。
このため、プロジェクト憲章でプロジェクトの目的と目標を明確にし、任命したプロジェクト・マネージャーがメンバーを集めて、プロジェクト憲章を使いメンバーにプロジェクトの概要を説明し、プロジェクトを進めていくことが求められています。
プロジェクト憲章の例
ここでは、「新商品Ａ」という商品開発を例に、主要メンバーが数名のプロジェクトを想定したプロジェクト憲章をつくってみました。
1.プロジェクトの目的
何のためのプロジェクトなのかということです。
プロジェクトの進捗管理をする、プロジェクト・マネージャー（責任者）は、プロジェクトの目的、目標、手段については、繰り返し周知し、徹底させることが必要です。
プロジェクトを進めていくと、問題があれば必ず、問題がなくても些細なことがきっかけとなり、
「このプロジェクトって何のためにやっているのですか？」
という、シンプルにして致命的な質問が唐突にやってきます。
プロジェクト憲章にプロジェクトの目的、目標などが具体的に書いてあれば、プロジェクトの迷走を防ぐことができます。
少なくとも、プロジェクト・メンバー間で共有できる分かりやすい言葉で表現することがポイントです。
ここでは、次のような新商品開発を例に説明します。
- 新商品開発が必要な理由
- 振動や騒音の計測器がパソコンと計測ユニットを組み合わせたものが主力商品となっているが、陳腐化が進んでいる。（現在の状況）
- 主に現場での計測をするユーザーから「現場で使う一体型の計測器が欲しい」との声がある。（顧客ニーズ）
- 社内では一体型計測器の開発の必要性は認知されているが開発リソースがない。（社内状況）
- プロジェクトの目的
- 一体型計測器をリリースする。
2.プロジェクトの目標
プロジェクトの目的を明確にし、どうすればプロジェクトが成功したことになるかを明確にしました。
目標は、定量的であることが望ましいので、ここでは決められた期限までに完了させることを目標とします。
- プロジェクトの目標
- プロジェクト開始から１年後の4月に新商品をリリースする。
目標としては、予算をオーバーしない、売り上げ、販売台数などがあります。
3.プロジェクトの対象範囲
プロジェクト・マネジメントでスコープ定義と呼ばれるものです。
プロジェクトの対象範囲について、詳細はプロジェクトの計画フェーズでスコープを定義しますが、プロジェクト開始に当たりどの程度までやるかを決めて、プロジェクト・スポンサー（予算を決める、いわゆる偉い人）と合意しておくことです。
ここでは、新商品を開発するプロジェクトなので、次のようなことを決めました。
- 計測用ソフトウェアは、既存製品を利用する。
- パソコンは、業務用のモニタ（画面）一体型のタッチパネル搭載パソコンを利用する。
- 社内の開発リソース（技術者）最小限（筐体設計のみ）とする。
4.前提・制約条件
プロジェクトを進めるに当たり前提や制約となることを明確にします。
ここでは、次のようなことを決めました。
- 業務用のパソコンを利用するが、その大きさについてはパソコンの選定時に詳細を検討する。
- 業務用PCの選定の際は、現場使用のためキーボードとマウスを使わずに操作できるものとする。
この例では、一体型と言ってもその大きさは、いわゆるモバイルPCから、受付や案内などで使われる比較的大型のものまであります。
ここでは、一体型の計測器を期限までにリリースすることを優先し、大きさについては市場の反応をみて改めて商品化を検討することとし、プロジェクト開始後に一体型PCの大きさを決めることにしました。
5.スケジュール
プロジェクト憲章を作る段階でのスケジュールは、あくまでも概算です。
ここでは、新商品リリース時期を4月としているため、以下のマイルストーン設定しました。（期間のみ記載していますが、実際には何年何月まで明確にします。）
- 一体型PCの選定（小さいもの、大きいもの）
- 選定から入手まで2か月
- 操作性の確認と使用するPCの決定
- 操作性確認に１か月
- 計測器と組み合わせた場合に必要な改修
- ソフトウェア（ラインセンス管理を想定）
- ハードウェア（電源周り）
- 筐体の設計、試作に３か月
- 試作品の評価に１か月
6.予算（概算）
予算は、結構悩ましい問題です。
- 予算を決定する側は、総額と予算超過（特に外注費など外に出る費用）が気になります。
- プロジェクト実行側は、少しでも余裕のある予算を確保したい。
妥協点としては、プロジェクト開始時点では上限金額は決めるが、総予算は概算金額として、詳細はプロジェクト開始後に報告するのが現実的かと思います。
ここでは、予算を次のように決めました。
- 一体型PC購入費：50万円
- ソフトウェア改修（ライセンス管理）：テスト含め１人/日
- 筐体設計
- 10人/日
- 型は使わない。詳細は、プロジェクト開始後、承認を得る
会社によっては、概算の総予算と上限だけ決めるのではプロジェクトを開始できず、詳細で完全な見積もりがないとプロジェクトを開始できない場合もあるようです。
後者の場合、予算を作るためプロジェクトを立ち上げ、詳細予算を作っているそうです。こと予算については会社にとって考え方が様々なのでやむを得ないとは思いすが、プロジェクトの良さを自ら打ち消してしまっていると考えています。
7.リスク
予算同様、リスクもすべて洗い出し、対策をとることは現実的ではありません。
プロジェクトのリスクが、事前にすべて分かり、対策をとれるのならば、航空機の開発遅延や自動車のリコールがゼロになってもよさそうなものです。
ここでは、次のリスクを想定しました。
- 新商品リリースが遅れると、新商品発表を予定している大規模イベントに間に合わず、販売計画に大きな影響が出る。
このリスクの対策は、次の通りです。
- 大規模イベント時に新商品販売開始予定を発表できない場合には、新商品開発について中止または延期する。
なお、考えられる、思いつくリスクを全て洗い出しますが、リスク対策をすべてのリスクについて作る必要はありません。
リスク対策は、プロジェクトの中（リスク対応計画）で考えます。
プロジェクト・マネジメントでは、プロジェクト立ち上げ時にはリスクがあることをプロジェクト関係者全員で認識することがポイントです。
新商品開発に限らず、「絶対成功しますと保証はできないけれど、何とかできそうだからプロジェクトで何とかしよう。」と取り組んでいるのに、ただ「心配だ」とつぶやく偉い人がいたりします。
この「心配だ」が、プロジェクト成功のための最大のリスク要因だったという笑い話もあります。
全てのリスクをつぶすことは現実的ではありませんし、仮にすべてのリスクをつぶせたとしても失敗しないことを保証してくれるわけではありません。
「リスクはあるけれど、プロジェクトの目的を達成するために、プロジェクト・メンバー全員で取り組むのだ。」という姿勢を示し続けてくれるプロジェクト・スポンサーがいると、プロジェクトをマネジメントする人が、プロジェクトの目標達成に集中できるのです。
プロジェクト成功の大きな要因の１つは、人選です。
8.プロジェクトメンバーおよびプロジェクト・マネージャー
プロジェクトのメンバー表（組織図）です。
プロジェクトの責任者やプロジェクトに関係のある人が誰かが分かるものです。
ステークホルダーが明確になっていれば、これを反映します（利用するといった方が適切かもしれません）。
責任者とプロジェクトをマネジメントする人、プロジェクトに必要な様々な役割を誰が担当するのかを明確にすることがポイントです。
ここでは、次の役割について誰が担当するのか決めました。
- プロジェクト責任者
- プロジェクト・マネージャー
- 商品企画担当
- ハードウェア設計責任者
- ソフトウェア設計責任者
- 販売促進担当（営業対応）
参考：プロジェクト憲章とプロジェクト計画書
以下、参考までに、「JIS Q21500：2018 (ISO 21500：2012) プロジェクトマネジメントの手引」に書かれている、
4.3.2 プロジェクト憲章の作成
4.3.3 プロジェクト全体計画の作成
を引用しながら説明します。
言わんとしていることは分かりますが、このまま理解するのは正直なところ難しいです。
4.3.2 プロジェクト憲章の作成
プロジェクト憲章を作成する目的には、以下の３つがあります。
- プロジェクト又は新規のプロジェクトフェーズを正式に許可する。
- プロジェクトマネージャを特定し、適切な責任と権限を明確にする。
- ビジネスニーズ、プロジェクトの目標、期待する成果物及びプロジェクトの経済面を文書化する。
簡単に言うと、
- 勝手にプロジェクトを進めてはだめですよ。
- プロジェクトをマネジメントする人を指名して、責任と権限を明確にしなさい。
- プロジェクトの必要性、目標、成果物、予算などを明確にして文書に残しなさい。
ということです。
プロジェクト憲章は、プロジェクトを組織の目的に関連付けるものであり、あらゆる適切な委任事項、義務、前提及び制約を明らかにすることが望ましい。
望ましいとはありますが、プロジェクトに関し関係者を含め合意内容を文書化し明確にしなさいということです。
プロジェクト憲章の作成プロセスの主要なインプット
プロジェクト憲章の作成プロセスの主なインプットには、以下の３つがあります。
- プロジェクト作業規定書
- 契約
- ビジネスケース又は以前のフェーズの文書
4.3.3 プロジェクト全体計画の作成
プロジェクト全体計画の作成の目的は、次の事項を文書化することである。
プロジェクトを実行できる具体的な文書です。分からないことや決められないことは、いつ分かる見込みかやいつ決めるのかを明確にします。リスク管理の対象にもなります。
- なぜプロジェクトを実施するのか。
- 誰が何を提供するのか。
- どのように提供するのか。
- コストはどれほどか。
- どのようにしてプロジェクトを実行し、管理し、終結するのか。
ここは、書いてあること読んだ通りで、具体的にしておくことがポイントになります。
プロジェクト全体計画は、一般にプロジェクト計画及びプロジェクトマネジメント計画からなります。これらの計画は、独立した文書でもよいし、一つの文書にまとめてもよいが、プロジェクト全体計画は、スコープ、時間、コスト、その他の対象を適宜、統合したものを反映することが望ましい。
以下、プロジェクト全体計画についての注意点、ポイントが列挙されています。
実際には、プロジェクトメンバー、期間、予算などから、優先度を加味して決めていく項目になります。
プロジェクトマネジメント計画
- プロジェクトマネジメント計画は、どのようにプロジェクトを実施し、監視し、管理するのかを定義した一つ又は複数の文書の集合である。
- プロジェクトマネジメント計画は、プロジェクト全体に適用しても、リスクマネジメント計画、品質マネジメント計画などの下位の計画によってプロジェクトの一部に適用してもよい。
- 典型的には、プロジェクトマネジメント計画は、リスク、課題、変更管理、スケジュール、コスト、コミュニケーション、構成管理、品質、健康、環境、安全並びにその他の対象に関するマネジメントの役割、責任、組織及び手順を必要に応じて定義する。
プロジェクト計画
- プロジェクト計画には、プロジェクトを実施するためのベースライン、例えばスコープ、品質、スケジュール、コスト、資源及びリスクを含む。
- プロジェクト計画の全ての部分は整合性をもち、完全に統合することが望ましい。
- プロジェクト計画は、関連する全てのプロジェクト計画のプロセスびプロジェクトの実行、管理及び終結に関する全ての適切な作業を定義し、統合し、調整するために必要な処置を含むことが望ましい。
- プロジェクト計画の内容は、適用分野及びプロジェクトの複雑さによって異なる。
- 遂行組織の裁量において、適切なステークホルダと調整した上で、プロジェクト計画は、詳細な文書としてもよいし、スコープ計画及びスケジュールなど適切な下位の計画を参照する概要レベルの文書にしてもよい。
- 概要レベルのプロジェクト計画を使用する場合は、個々の下位の計画のマネジメント方式を統合、及び、調整することを規定することが望ましい。
- プロジェクト期間を通じて、プロジェクト計画は必要に応じて更新し、適切なステークホルダに伝達することが望ましい。ただし、プロジェクト計画は上位の計画として始めてもよい。
- このプロセスでは、スコープ、予算、資源、スケジュール及びその他の項目である当初の配分を、より詳細で緻密に配分した作業のまとまりになるよう段階的に改訂する。これらの作業のまとまりには、プロジェクトリスクを受け入れるに足る洞察及び管理のマネジメントに必要なレベルを明記する。
プロジェクト全体計画の主要なインプット
- プロジェクト憲章
- 補足計画
- 以前のプロジェクトから得た教訓
- ビジネスケース
- 承認された変更
プロジェクト全体計画の主要なアウトプット
- プロジェクト計画
- プロジェクトマネジメント計画
まとめ
プロジェクトの成功には、プロジェクトの基本方針・目的や実行計画を明記したプロジェクト憲章の合意が必要です。
ここでは、プロジェクト憲章の例を使い「JIS Q21500：2018プロジェクトマネジメントの手引」について以下の項目で説明しています。
- 「プロジェクト憲章」とは何か
- プロジェクト憲章に含めること
- プロジェクト憲章のボリューム（ページ数）
- プロジェクト憲章の例
- 1.プロジェクトの目的
- 2.プロジェクトの目標
- 3.プロジェクトの対象範囲
- 4.前提・制約条件
- 5.スケジュール
- 6.予算（概算）
- 7.リスク
- 8.プロジェクトメンバーおよびプロジェクト・マネージャー
- 参考：プロジェクト憲章とプロジェクト計画書
