Zenn
🔥

プロジェクト立ち上げ時に「プロジェクト憲章」はなぜ必要か？（記載例あり）

2022/02/18に公開
プロジェクト管理
idea

「プロジェクト憲章」はなぜ必要か？

これまで、様々なプロジェクトを経験する中で、実感したことがプロジェクト憲章の必要性です。

これまでの経験上、トラブルが多発するプロジェクトや進捗があがらないプロジェクトのほとんどは、このプロジェクト憲章がイケてない場合がほとんどです。

この記事では、プロジェクトの成功確率をあげるプロジェクト憲章の作り方について記載します。

そもそも、プロジェクト憲章とは？

プロジェクト憲章とは、プロジェクトの目的、やること、やらないこと、誰がやるかなどなどが記載された文書のことです。これとスケジュールがあれば、基本的にプロジェクトとして成り立ちます。

作成するタイミングは、プロジェクト開始時です。
この内容が決まってない（何が決まってないかも見えていない）段階で、スケジュールの作成から実行に移ると確実に後から困ります。

ざっくりまとめると、プロジェクト憲章とは、「なにをするためのプロジェクトで、誰がどのようにやるか？」 が記載されている文書です。

プロジェクト憲章に記載するべき内容は？

主要な項目を以下に記載しました。
この内容が決まっていて各項目ごとに内容を記載して、チームや関係者と同意が取れれば、それだけでプロジェクトの成功確率が爆上がりします。

前提として、最初の段階で全ての内容が完璧に埋まることは、あまりないかと思います。
ただ、暫定的にでもいいのですべて記載することが重要です。

この内容をもとにプロジェクトの進捗に合わせてブラッシュアップしていきましょう。

もし、あなたが外部から依頼を受けたプロジェクト管理者（PM/PMO）であれば、この内容をもとに1項目を1スライドでパワポにでもまとめて、クライアントと内容を詰めればプロジェクトに対する理解も深まるので一石二鳥です。

記載項目と内容例

  • プロジェクトの目的は？

    • 例：
    • データドリブンな経営を実現するために、DWHを導入する

  • ハイレベルな要件は？

    • 例：
    • デイリーで連携されたデータの確認が可能
    • ダッシュボード上で▲▲のデータが確認ができる

  • プロジェクトの制約事項は？

    • 例：
    • 予算を5,000万円までに抑える必要があるため、コスト管理を最優先する

  • プロジェクトのゴールは？

    • 例：
    • 導入が完了し、〇〇領域のデータとXX領域のデータを連携して、分析が可能になる

  • プロジェクトのスコープ(やること/やらないこと)は？

    • 例：
    • 対象範囲
      • A,B領域のデータの取り込み
    • 対象外
      • C~E領域のデータの取り込み

  • プロジェクトの期間は？

    • 例:2022年4月 ~ 2023年6月

  • プロジェクトのコストは？

    • 例：
    • システムベンダー 3,000万円
    • コンサルタント 1,500万円
    • システムのライセンス費用 500万円

  • プロジェクトのマイルストーンは？

    • 例:
    • 2022年6月 Kick-off
    • 2022年10月 設計完了
    • 2023年3月 開発/テスト完了
    • 2023年6月 リリース

  • プロジェクト体制は？

    • 例：
    • 最高責任者（スポンサー）　ゆきこ
    • 現場責任者（プロジェクトリーダー）　たかし
    • A領域リーダー　イザベル　メンバーXX,・・
    • B領域リーダー アジャイ　メンバーXX, ・・・

  • ステークホルダーと責任範囲（RACI）は？

    • 例：
    • A領域
      • 説明責任者(A)　イザベル
      • 実施責任者(R)　ゆうじろう
      • アドバイザー(C)　ピーター
      • 報告先(I) たかし、ゆきこ、アリサ・・・

  • プロジェクトの主なリスクは？

    • 例：
    • A領域の実施者のリソースが、メンバーの退職により足りなくなる可能性がある
    • データ連携についてのナレッジが不足している

補足

  • スコープを記載する際には、スコープ内/外は必ず記載することが重要です。
    スコープ内だけ記載するとプロジェクトの対象範囲が広がり続けてしまい、終わらない炎上プロジェクトになりがちなので、必ずスコープ外(やらないこと) は記載しましょう。

  • プロジェクト憲章は、プロジェクトが進み、より明確になるにつれて更新していくドキュメントだと私は考えています。 ただ、更新履歴の管理はしっかりと行いましょう。
    プロジェクト開始時からどのように変更されたかトラックできるようにしておきましょう。

  • スコープの変更については特に注意してください。スケジュール、コスト、人員など全ての範囲に影響します。

  • 責任範囲を決めるときは各領域ごとに説明責任者は必ず一人にしてください。複数人いると意思決定が遅れます。さらに、責任範囲が不明確になり、炎上リスクが爆上がりします。

まとめ

プロジェクト形式での仕事は非常に楽しいですが、炎上してしまいプレッシャーに追われてしまうこともあると思います。

この記事が少しでも、皆のプロジェクトライフを良くすることができれば嬉しいです！

Discussion