【プロジェクトマネジメント】プロジェクトを立ち上げる際に整理すべき観点としてのプロジェクト憲章
プロジェクトを立ち上げてますか？
プロジェクトと、仰々しい名前で呼ばずとも、日々の業務の中で何か新しい仕事や、新しいタスクが発生して取り組むことは多々あるとあります。
もちろん、すぐに終わるような短期間のタスクや定例タスクは、すぐにやって終わりで良いですが、誰かを説得して動いてもらう、ある程度の期間を必要とするような場合には、最初にいくつかのポイントを整理すべきです。
プロジェクトの立ち上げも、新しい仕事に取り組む際も、プロジェクト憲章に従って必要な観点を整理していきましょう！
今回の記事ではプロジェクトを立ち上げる際に整理すべき観点をプロジェクト憲章に基づいて説明していきます。
プロジェクト憲章とは？
プロジェクト憲章とは、プロジェクトの立ち上げ時に最初に作成する成果物です。
PMBOKの定義上、プロジェクト憲章はプロジェクトを正式にスポンサー（あるいは、イニシエータ）に認可してもらうための文書と定義されています。
すなわち、これからこんなプロジェクトを始めると宣言するための文書であり、その内容を判断いただき、問題が無ければ予算をつけてもらいます。
そのため、承認者、つまり、誰が読んでも分かる言葉でプロジェクトの全体感が分かるような文書にしなければいけません。
プロジェクト憲章を作る意味
プロジェクト憲章を作る意味は大きく２つあります。
- スポンサーの承認をいただく
前章で説明した通り、予算を出す権限を持っている方々に「プロジェクトの内容」を理解いただき、「このプロジェクトを進めて良い」と承認をいただくためにプロジェクト憲章を使います。つまり、予算承認者の意向からずれていないことを確認して、必要な予算を出してもらいます。 - プロジェクトの参加者が全員同じ方向を向く
プロジェクトに参加しているメンバーがプロジェクトの目的、ゴールを共有して、同じ方向を向いて意思決定をしていくための重要な指針として使います。
プロジェクトを進めている内に目的を見失うことは多々あります。
Gerd AltmannによるPixabayからの画像
例えば、全体最適のためのアーキテクチャ改善のプロジェクトのはずが、特定の制約のために、一部個別最適を作ってしまい、それが全体に悪影響を及ぼすことはよく見かけます。
例えば、事務コスト削減のためのシステム更改のはずが、既存機能を残さないと業務が回らないから、あれもこれもそのまま残して欲しい！と言う意見がまかり通ってしまい、結果的にシステムは変わったが、業務フロー改善もなされず事務コストも減らないなんてこともあります。
もちろん、各メンバーに悪気は無いです。各メンバーは各課、各部署の最適を求めています。しかし、それがプロジェクトとしては最適ではないことが多々あります。
プロジェクト憲章を作っておくと、このような本来達成したかった目標から逸脱することを防ぐことができます。プロジェクトを進める上での意思決定、判断するための指標を作成しておくことができます。
逆に言うと、プロジェクト憲章に記載されていることがプロジェクト立ち上げ時に整理されていないと、プロジェクトはブレていきます。結果、後から振り返ると失敗プロジェクトになります。
プロジェクト憲章に記載すべき内容
プロジェクト憲章に記載すべき内容、すなわち、プロジェクト憲章の目次は以下のとおりです。
- プロジェクトの目的
- 計測可能なゴール
- 大枠のスコープ
- 前提条件、制約条件
- コスト
- スケジュール
- リスク
- 体制
プロジェクトの目的
プロジェクトの目的を最初に記載します。
ここで大事なのは、どんな課題が存在するか？、なぜそれを解決する必要があるか？（ここまでが背景）
だから、何をしなければいけないのか？（目的）までが表現されていることです。
以前、別記事でも記載しましたが、目的だけでは人を動かすことはできません。そこにストーリーが必要です。「なぜ、そんな目的が生まれたのか？」に対する答えとして背景が必要です。
よくありがちなのが、WhatとHowを混同してしまうことです。
「帳票を電子化しよう 」
目的に見えなくなも無いですが、実際には目的では無いです。
その後ろに本来やりたいwhatが隠れていています。
それを見極めるには、以下を問います。
「それは何のためにやるのでしょう？？」
「帳票を電子化しよう 」
→「コスト削減、すなわち、紙を伴う事務コストの削減や、プリンタ等の設備費、紙の保管コストをそれぞれ〇〇円削減するために、帳票を電子化します。」
→「来年、事務センターを設立するので、センターと支店間のコミュニケーションコストが上がることを避けるために、今のうちに電子化してワークフロー上でやり取りできるようにするために、帳票を電子化します。」
目的（=What)があり、そのためにこう言った方策(=How)を打ちます！
ということが言えない限りは目的が見えていないプロジェクトです。
残念ながら、目的がクリアになっていない限りこのプロジェクトはうまくいきません。
このプロジェクトが実現したら、何が得られるのか？という質問が経営から来た際に答えられ無いため、そもそも予算がつきません。
（※ 実際にはそんなプロジェクトはゴロゴロ転がっており、プロジェクトを止められないところまで来ていることも良くあります。その際には、まず目的を立てて、立て直すことが重要です。）
この目的が無いと、何かおきた際の判断がブレます。
プロジェクトでは必ず、想定外のことが発生します。その際に、立ち返る基準としてプロジェクトの目的は必須です。
プロジェクトの目的に照らして、想定外の事象に対する方針や方向性が正しいかを判断することができます。あるいは、目的に向けてあるタスクが最短距離になっているかを精査することができます。
逆に言うと、目的が明確になっていないと、念のために、あれもやって、これもやってと、スコープが大きくなっていきます。
計測可能なゴール
次に必要なのは、ゴールです。
どのような状態になっていれば、前述の目的を達成したと言えるのかを整理します。
そして、その状態が計測可能であることが重要です。
過去記事の「プロジェクトの成功の定義」で記載したとおり、計測可能でなければいけません。
ここの定義が曖昧だと、プロジェクト内で混乱を生みやすいです。
そのため、プロジェクトの大きなゴールと、それを分解して、個別のチーム単位や、システム単位のゴールを作成することで、できるだけプロジェクト参加者の思いがブレないようにします。
大枠のスコープ
次に、その目的やゴールに向けて何をするかを定義していきます。
どのようなタスクを想定しているか、作業範囲がどこまでかをここでは記載していきます。
後半に出てくる体制と絡めてどんなタスクを想定して誰がやるかを定義しておくことで、関係者を巻き込みやすい状況を使っておくとプロジェクト運営しやすいです。
前提条件、制約条件
このプロジェクトを進める上での前提条件を提示します。
特にプロジェクトで不足しがちな人、モノ、金についてプロジェクトを進める上で必要になる場合には、承認者に提示しておくことが重要です。
あるいは、プロジェクトの性質上、他のプロジェクトの成功を前提としていることもあると思います。そこを可視化して承認者に事前に理解いただくことも重要です。
承認者にはどんなリスクが発生しそうかを事前に伝えることが重要です。そのため、他のプロジェクトの成否が、今回のプロジェクトの成否に関わる場合には必ず伝えなければなりません。
コスト
ここは会社毎に違いが出てくる部分と思います。
概算を伝える。
予算の出元を伝える。
予算の最大値を伝える。
それぞれの会社のルールに応じて提示するコストを変えていきます。
とはいえ、「このプロジェクトでかかる予算」の規模感を理解いただく必要があります。
実施しようとしているプロジェクトがリスクを加味して、これだけのコストをかけてやるかやらないかを判断いただくためにはコスト規模感は必須です。
ちなみに、予算の最大値をここで提示しておくことは、スコープ拡大の抑制に繋がります。
ただし、立ち上げ時点ではスコープも未確定なため、段階的にコストを詰めていく等の宣言も重要です。
スケジュール
プロジェクト規模が大きい場合、スケジュールもコストと同様、大枠しか決められないことが多いと思います。
どのようなフェーズをどのような順番で実施するかを提示する。
フェーズ定義をプロジェクト立ち上げ後に決める場合には、マイルストーンを提示することが重要になります。
特に、プロジェクトの継続要否を判断できるような場が今後どのタイミングで来るかを承認者にご理解いただきましょう。
プロジェクトはリスクにさらされており、時には止める決断も重要です。そのためにも、どういったタイミングで、情報をお耳に入れられるかは提示しておくべきです。
リスク
プロジェクトにリスクがつきものなのは、過去の記事の通りです。
リスクの内部要因、外部要因をそれぞれ提示しておきましょう。立ち上げの段階でリスクが整理できていると対策の検討に時間が取れるため、プロジェクト成功の一助になります。
できるだけ立ち上げ時に整理しておくべきです。
体制
プロジェクトのステークホルダーを可視化します。
ある意味、前提条件にもなりますが、ここで記載したステークホルダーがプロジェクト参画できない場合、プロジェクトはうまくいきません。
それぞれのプロジェクト参加者の役割と責任を可視化しておき、承認者の力も借りて、関係者をプロジェクトに巻き込むことが重要です。
この際、組織の壁を超えなければいけないことが多々あります。承認者（えらい人）の力を存分に使いましょう。
担当間ではらちがあかない場面もあると思います。えらい人を有効活用するためにも、ここの体制は確り練りましょう。
プロジェクト憲章を活用できる場面
プロジェクトの立ち上げ時に作成するものですが、プロジェクトと同じ性質を持つ仕事やタスクを実行する場合には、プロジェクト憲章の観点が役に立つと思います。
ここで言う同じ性質とは、独自性、有期性、変化、機能横断、リスクを指しています。
詳しくは過去記事参照。
また、プロジェクトを進める上で何か課題が発生した際には、プロジェクト憲章に立ち返り目的からずれていないかを確認すべきです。
立ち上げ時に作る資料ですが、活用は、プロジェクトを通してできます。
ただし、プロジェクト計画書等に、その内容を取り込んでプロジェクト憲章を破棄することもあるので、状況に応じてご活用ください。
まとめ
今回の記事では、プロジェクトを立ち上げる際に整理すべき観点を、プロジェクト憲章を用いて説明しました。
プロジェクト立ち上げの際に参考にしてください。
立ち上げ時に多くの観点が整理できていれば、それだけプロジェクトを成功に導ける確率が上がります！
皆様のプロジェクト成功をお祈りしております！
では。
