さぁ、プロジェクトをはじめよう<第6回> 〜プロジェクト憲章とプロジェクト計画書〜

武漢ウィルスの影響により東京都で外出自粛を要請されている中、家のパソコンでちょうどこの記事を書いている。4月ももうすぐで桜も散りかけというのに外は曇天、そして雪。春の訪れを気持ちよく迎えたいところだがそうもいかないようである。

さて、「プロジェクトをはじめよう」と銘打つ割に、まだ具体的なプロジェクトの進め方に関しては入れていない。PMBOKも軽い紹介で済ませたいところだったが、どうしても細かいところまで言及せざるを得ない部分もあり、経営者が知るべき範囲かどうかは微妙な感じでもあった。

今回ようやくプロジェクトの進め方に一歩踏み込む。

「何故」、「何を」、「どのように」

第一回で述べたとおり、このブログではプロジェクトを「期間と目的を限定し、適切な人材を集めて目的志向的に課題の解決を図る組織的な枠組み、または、取り組み」と定義させてもらった。プロジェクトは、常設の組織ではなく、臨時の組織体である。「臨時」とは何かしらの理由があって集められるということだ。
よって、プロジェクトを立ち上げるときには「何故、立ち上げるのか？」(=Why)、「そこで何を為すのか？」(=What)とまた、「どのように」(=How)それを進めていくのかを利害関係者(ステークホルダー)に明示しなければいけない。

この「何故、立ち上げるのか？」(=Why)、「そこで何をするのか？」(=What)をまとめたものが「プロジェクト憲章」で、「どのように」(=How)それを進めていくのかを表したものが「プロジェクト計画書」となる。

PMBOKでは、「プロジェクト憲章」でプロジェクトマネージャを任命し、PMが「プロジェクト(マネジメント)計画書」を作ってキックオフを行うという流れを説明している。
ここら辺は様々な現場によってドキュメントの名称も進め方も異なる場合が多い。プロジェクトオーナー(=予算を割り当てる人)がまずプロジェクトマネージャを任命して、プロジェクト憲章を作らせる場合もあるし、プロジェクト定義書という名前でプロジェクト計画の内容まで記載している場合もある。

重要なのは名称や進め方ではなく、プロジェクトの立ち上げ期には「何故」、「何を」、「どのように」がしっかりとドキュメントの形で落とし込まれていることだ。
この３点は、プロジェクトの土台であり、ここがしっかりしていないと大抵プロジェクトは失敗することになる。特に、プロジェクトの進行自体はうまく行っていたとしても、出来上がりがプロジェクトオーナー（＝スポンサー）が求めていたものと全く違っている結果にもなりかねないし、それに途中で気がついてプロジェクトが炎上することもよく聞く話である。

では、具体的にどんな事が記載されている必要があるのだろうか？

プロジェクト憲章

システム構築におけるプロジェクト憲章（※プロジェクト定義書と呼ぶ場合もある）を例に見てみよう。

定義項目	内容	補足
コアコンセプト	このプロジェクトを実現することでどんなサービスを提供したいのか？
システム化の狙い	システム化することによって得られる効果。このタイミングでこの案件を実施することの意味、優先度付けの理由	基本ボトムアップはない。様々な意見の中間点が正解にはなり得ない
システム化の範囲	今ある、あるいはこれから作る業務のどこからどこまで作りこむか。「新規構築」「改修(or見送り)」「外部サービス導入」するのか	全てをシステム化することが正解ではない。
システム化の方針	要件の出し方・捨て方の軸。判断軸を方針として言語化。する事と同時にしない事を定義	複数の選択肢の中から最適なものを正しく判断できるよう軸を定める
投資対効果	開発費が膨らむとトータルでマイナスになる場合もある。終了条件の定義。	開発費が膨らみ、効果がマイナスになった場合の対応も記載したい。

 

「システム化の」とついてはいるが、狙い＝目的・理由(Why)と、範囲＝何を作るのか(=What)をここで定義している。また、ここには載せていないが、プロジェクトで作るプロダクトやサービスの「概念設計」「業務設計」「システム要件」などを掲載する場合もある。
プロジェクトを立ち上げる上での「投資対効果」まで定義し、上位概念となる事業上の位置付けまで明確化する。

プロジェクト憲章(プロジェクト定義書)は言ってみれば、憲法のようなものであり、プロジェクトの枠組みを規定するような役割を持っている。再三述べているとおり、特にプロジェクトとは「期間と目的を限定して」組織横断的に「適切な人材」を集めて立ち上げる暫定的な組織体であるため、プロジェクト憲章は人々を繋げる根拠に他ならない。この根拠が弱ければ、そこに携わる関係者の関与（エンゲージメント）も弱くならざるを得ず、プロジェクトの成否にも大きく影響を及ぼすのである。

プロジェクト計画書

次にプロジェクト計画書（※PMBOKでは「プロジェクトマネージメント計画書」）に記載すべき内容を見てみよう。

定義項目	説明	補足
前提条件 (与件)	プロジェクトを実施する上で、変えられないもの。	経緯、予算、期限、制約 等
マネジメントスコープ	マネジメントの範囲。「誰が、何を、どこまでやるか」を定義する。	「ユーザ企業が要件定義まで」「ベンダーが開発〜リリースまで」など
マネジメント方針	推進方針：プロジェクトの進め方の方針 QCD方針：トレードオフが発生した場合、何を優先するか。品質なのか、コストなのか、納期なのか？	段階リリースをする。ステコミを月一で解散し、仕変判断を行うなど。 D→Q→C順：間に合わなければコストを追加してでも対応する。
大日程	関係者に全体の日程感を共有する。	パワーポイントのスライド1枚で表示できるレベル。矢羽根で提示。
体制図	関係者の役割とその位置付け、また誰が任命されているかなどを共有	パワーポイントのスライド1枚で表示できるレベル。階層図で提示。
役割分担	役割名、行うべき仕事や権限などを定義	役割名、行うべき仕事・権限、担当名(byName)で表化
会議体	ステークホルダーが集まる会議体とその位置付け、開催頻度、対象者を定義	会議体、説明、開催頻度、対象者をマトリクス形式でまとめる
コミュニケーション方針	ステークホルダーがどのように情報を交換し合うか、その方法や方針を定義	会議や事務連絡はメーリングリスト、仕様の調整はSLACKを仕様…など

プロジェクト計画書に記載する必要があるのは前述のとおり、「どのように」（＝How）の部分である。どこまでをマネジメントの範囲かを定めた上で、どのように進めていくかの方針を定義。後は、利害関係者に対して、いつまでに、誰を使って、どのように役割分担しながら、プロジェクトを進めていくかを具体化していくのである。

プロジェクト憲章とプロジェクト計画書の位置づけを分かっていただけただろうか？
プロジェクトを旅行に例えると「ルーブル美術館に生のモナリザを見にいこう」が「プロジェクト憲章」であり、「いつ、誰と、どのように行くか」・・・目的を実現するためにその方法を定義するのが「プロジェクト計画書」の役割なのである。

繰り返しになるが、名称などや順番が多少違っていてもそんなには問題ではない。
「何故」、「何を」、「どのように」がしっかりと決まっている事が重要なのである。