プロジェクト憲章とは、これから始めるプロジェクトの企画書にあたる資料です。
企画書が無いと、これから先に何を実施すればよいかわからないですよね。プロジェクト憲章はそれほど大事な資料です。
しかし、具体的にどのような内容を記載すれば良いかと問われるとすぐに回答できる人は少ないと思います。
PMに任命されて最初にやることとして「プロジェクト憲章の作成」が大切ということは理解しているが、具体的にどういった内容を記載すれば良いのかまではわからない。
そういった方に向けて、当記事ではプロジェクト憲章の大切さの再確認およびプロジェクト憲章に記載すべき内容と資料を作成した後にすべきことについて解説します。
プロジェクト憲章とは
プロジェクト憲章とは、プロジェクトを始めるにあたり何をゴールにするか、どのようなステークホルダーがかかわっているか、いつまでに完了させる必要があるのかなどを記載するプロジェクトの企画書に当たる書類です。
会社によってはプロジェクト定義書と呼ぶ場合もあります。
プロジェクト憲章の重要性
プロジェクト憲章を作成することでステークホルダー間で共通認識を持つことができ、チーム一丸となってプロジェクトが達成すべき目標に向かって仕事をすることができるようになります。
また、初めにやるべきことを文書化することによって、言った言わない論争を未然に防ぐことができ、作業の手戻り防止になります。
認識齟齬を発生させないために意識すること
プロジェクト憲章を作成する目的は、ステークホルダー間で共通認識を持つことです。
そのために有効なツールとして6W2Hがあります。
世間一般的に聞く5W1HにWhom(誰に)、How muchの2つを加えたものが6W2Hです。
| What(何を) | 顧客が保有している旅行業予約管理システムを刷新する。 |
|---|---|
| Why(なぜ) | 前回の改修から7年が経過したため老朽取り換えを実施する。刷新に当たり、顧客リストの作成業務を効率化させる。 |
| When(いつ) | 2022年1月～2024年12月まで。 |
| Who(誰が) | 本プロジェクトは流通事業部の部長主体の元、パートナー会社3社の協力を得て実施する。 |
| Whom(誰に) | 発注元であるA社向けにシステムを納品する。 |
| Where(どこで) | 東京本社と大阪支店の2拠点で開発を実施する。 |
| How(どのように) | アジャイル開発を適用し、複数回のプロトタイプを作成する。 |
| How Much(いくらで) | 予算はインフラ購入費含めて1億円とする。 |
6W2Hを使うことで認識齟齬が発生しづらいプロジェクト憲章を作成することができます。
また、プロジェクト憲章には決まったフォーマットは存在しませんが、記載すべき内容には指標があります。
プロジェクト憲章に定義すべき内容
プロジェクト憲章にはどのような内容を記載すれば良いかを解説します。
PMBOK Guideには大きく分けて次の4点を記載すべきだと有ります。
- ステークホルダー
- 目標
- 制約条件
- その他
もう少しわかりやすく、かつ詳細化すると以下の内容になります。
- プロジェクトを実施する背景
- プロジェクトの目的(ゴール)
- プロジェクトの概要
- 前提条件
- 各種方針
- スコープ
- スケジュール
- 成果物一覧
- 組織・要員計画
- 実施場所
- 会議体
- リスク
- 予算
- その他
プロジェクトを実施する背景
このプロジェクトを実施するに至った背景を記載します。
背景を記載することにより現状の困り事が明確になります。
例：
前回の改修から7年が経過したため老朽取り換えを実施する。
システム刷新に当たり、これまで旅行者が記載した要望欄の内容を手作業で顧客リストに転記しており、非常に非効率となっている。
プロジェクトの目的(ゴール)
プロジェクトの目的を明確にすることで、顧客が期待している成果物と当該プロジェクトで作成する成果物を一致させることができます。
ゴールは数値を用いてより具体的に記載することが望ましいです。
例：
老朽化に伴い最新のインフラを導入することで処理速度を現状の1.2倍にする。
次期システムからは旅行者が記載した要望欄の内容を自動で顧客リストに印字し、1日あたりの業務時間を2時間業務を効率化させる。
プロジェクトの概要
現状どのような状態で、プロジェクト実施後にどういった状態になるかを簡単に記載します。
そうすることで、プロジェクト途中から参画したメンバーにも何を実施しているプロジェクトなのかが伝わるようになります。
例：
現在10,000人の旅行者が当該システムを利用している。
同時アクセス数はピーク時に1,000人/秒であり、Web/APサーバ3台で負荷分散を行っている。
また、旅行者の要望を手作業で顧客リストに転記している。
次期では、高性能のサーバを導入することで、Web/APサーバ2台でありながら処理速度をこれまでの1.2倍に押し上げる。
旅行者の要望を自動で顧客リストに出力できるようにする。
前提条件
プロジェクトを実施するための前提条件を記載します。
前提条件が達成されないと、予算超過や目標が未達に終わることになります。
例：
Web/APサーバは〇〇社のXX型を導入すること。
もしくはそれと同等の機種を導入すること。
プロジェクト開始から1か月後の〇〇日までに顧客リストの帳票レイアウトを提示いただく。
各種方針
マネジメント方針や設計、ドキュメントの方針などプロジェクトをどのように進めようと考えているのかを記載します。
方針を記載すること、サービスレベルが明確になり、どの程度の品質を目指しているかを共有することができます。
マネジメント方針
マネジメント関連のスコープや、スケジュール、コミュニケーション、課題、リスクなどの管理方針を定義します。
例えば以下のように定義します。
| スコープ管理 | 定義したスコープからはみ出す要件は後出しせずにタイムリーに共有する。設計完了時点を起点とし、以降のフェーズで設計書の修正を伴う要望は変更管理とする。 |
|---|---|
| スケジュール管理 | 当該プロジェクトはテストを入念に実施する方針とする。そのため、2022年X月までに設計承認をいただくスケジュールとする。
工期/工数にはバッファを設け遅延に備える。 |
| コミュニケーション管理 | メールだけでなく、電話やWeb会議を用いて積極的に意見のすり合わせを実施する。
会議参加メンバーを事前に連絡し、無駄を削減する。 |
| 課題管理 | 顧客からの指摘事項だけでなく、プロジェクト内で積極的に課題を抽出するための活動を実施する。 |
| リスク管理 | プロジェクト開始時にリスク管理表を作成し、各フェーズ開始時にその内容を見直す。 |
設計、ドキュメント方針
設計書やソースコードを新たに作り直すのか、それとも現行の資産を流用するのかなどの方針を記載します。
設計書を再利用する前提で作業を進めていたのに後から「システム刷新に合わせて設計書もきれいにしたかった」と言われることを防ぐ役割があります。
また、現行のドキュメントが冗長だったり構成が不適切であるのであれば、次期では設計内容を最大限流用するが、章の構成を見直して冗長な記載を排除するといった方針を立てることもできます。
設計フェーズでは対応工数が大きくなるかもしれませんが、結果として設計書ボリュームが小さくなり、詳細設計や保守では工数を削減できるようになるといった恩恵もあります。
スコープ
システムの利用者の範囲や業務の対象範囲、機能の対象範囲、作業内容を定義します。
対象範囲を明確にすることにより、プロジェクトでやるべきことが限定され後から「これもやって」と言われることを防ぎます。
例：
システム利用者は一般旅行者だけでなく、メンテナンスを行うためにシステム管理者を対象とする。
業務として、旅行の予約、旅行者情報の帳票出力、マスタ情報のメンテナンスを範囲とする。
機能は予約機能、帳票出力機能、マスタメンテナンス機能を対象とする。外部システムへの連携は実施しない。
設計フェーズの初めに各種基準書を作成する。製造時には共通APIを作成する。
スケジュール
プロジェクトの開始から終わりまでの全体スケジュールを定義します。
スケジュールには自分たちの作業だけではなく顧客の作業も含めて記載します。
必ず達成しないといけない作業をマイルストンとして合わせて記載することによりいつまでに誰が何をしないといけないのかを把握することができます。
例：
成果物一覧
各フェーズ毎に作成する成果物を一覧で定義します。
契約上必要な成果物が漏れていないかステークホルダー間で確認し、作業の漏れが発生しないようにします。
例：
基本設計フェーズ：機能一覧、帳票一覧、メッセージ一覧、設計書
詳細設計フェーズ：詳細設計書
製造フェーズ：ソースコード、単体テスト計画書、単体テスト仕様書、単体テスト実施結果報告書
結合試験フェーズ：結合テスト計画書、結合テスト仕様書、エビデンス、結合テスト実施結果報告書
組織・要員計画
顧客体制やプロジェクト体制を図示します。
小さなプロジェクトであればステークホルダー全員を明記しますが、大きなプロジェクトになるとプロジェクトマネージャー、PMO、各チームリーダまでを記載しチームの構成メンバーは「アプリTM10名」「インフラTM5名」など人数のみを記載します。
また、体制と合わせて役割毎にどのような項目を管理するのかがわかる分担表も記載することをお勧めします。
分担表を記載することで役割が明確になり、責任の所在が明らかになります。
例：
実施場所
プロジェクトをどこで実施するかを記載します。
プロジェクト実施者全員がプロジェクトルームに集まって作業をするのか、在宅勤務をするのか、遠く離れた遠隔地で作業をするのかを分かるようにします。
顧客によっては秘密情報を扱うので1プロジェクト毎に1プロジェクトルームを用意するようにと言われる場合があります。
例：
PMおよびアプリTMは東京の自社オフィスに集まって作業をする。
インフラTMは千葉支社にプロジェクトルームを構える。
会議体
プロジェクト実施中にどのような会議を実施するのかを定義します。
出席者も明記することで無駄のない会議が設定できます。
例：
- ステアリングコミッティ：最高意思決定を行う。各社PMが参加する。
- 進捗会議：進捗を確認する。PMおよび各リーダが参加する。
- アプリ会議：アプリ開発の懸案事項、仕様を確認する。PMおよびアプリリーダが参加する。
- インフラ会議：インフラの懸案事項、、仕様を確認する。PMおよびインフラリーダが参加する。
リスク
プロジェクトのリスクをステークホルダー間で共有し、万が一の事態が発生した際の行動方針を確認します。
スケジュールやコストに影響を与えるような事象について予めどのような対処を行うかを決めておくことで、その事象が発生した場合の影響を最小化することができます。
例：
貴社責により設計書の承認が1か月遅れると、納期までに試験の完了が困難になりテスターの増員が必要になります。
その場合は別途追加費用が発生します。
予算
何にいくら掛けて開発を行うかをステークホルダー間で認識を合わせておきます。
プロジェクト憲章はパートナーも参照するため、別資料で主要メンバーにだけ共有する場合もあります。
例：
アプリ開発には8,000万円、インフラ購入費には2,000万円かかります。
※ただし、プロジェクトルーム費用含まない。
その他
その他共有しておきたい事項を記載します。
例：
品質向上施策として、市販のドキュメントチェックツールを導入します。
単体テストを自動化させるためにJUnitを利用します。
プロジェクト憲章を作成した後にすべきこと
プロジェクト憲章を作成したら、必ず顧客責任者や上司など重要なステークホルダーに承認をもらうようにしてください。
承認されて初めて、言った言わない論争の予防資料として効力を発揮します。
また、プロジェクト憲章はプロジェクト開始時にステークホルダーに説明し、新規メンバー参画時やフェーズの変わり目でも繰り返し説明するようにしてください。
プロジェクトの目標や進め方は全員が正しく理解する必要があり、プロジェクト憲章はその元となります。
まとめ
今回は、プロジェクト憲章とはどういった役割の資料で、何を定義すれば良いかを解説しました。
◆プロジェクト憲章とはプロジェクトの企画書であり6W2Hを用いることで齟齬の発生を防ぐことができる。
◆プロジェクト憲章には下記を定義する。
- プロジェクトを実施する背景
- プロジェクトの目的(ゴール)
- プロジェクトの概要
- 前提条件
- 各種方針
- スコープ
- スケジュール
- 成果物一覧
- 組織・要員計画
- 実施場所
- 会議体
- リスク
- 予算
- その他
◆プロジェクト憲章作成後は必ず承認をもらい、関係者に繰り返し説明する。
では、今回はここまで。
最後まで読んでいただきありがとうございました。
