株式会社コパイロツト COPILOT Inc. のブログ

Good Team Building & Project Management を掲げプロジェクトファシリテーションを行う会社です。ちなみに株式会社コパイロツト(ツが大きい)とかいてコパイロットと読みます。

結局どうやってつくればいいの?プロジェクト憲章について真剣に考えてみた

 

最近、プロジェクトをスタートするときに必要とされる文書「プロジェクト憲章」について社内でディスカッションしたので、その結果をシェアしたいと思います。「プロジェクト憲章って大事っぽいけど、どうやってつくったらいいのかわからーん!」という悩みをお持ちの迷えるプロジェクトマネージャの皆さま、ぜひお読み下さいませ。

1.プロジェクト憲章とは?定義と作成のメリット

さて、まずはプロジェクト憲章の定義を確認しておきましょう。

プロジェクト憲章とは、プロジェクトを立ち上げる際に策定される、プロジェクトの目的や条件、内容などを明確に定義した文書。(IT用語辞典E-Wordsより引用)

つまり、プロジェクトを始める際に、プロジェクトメンバー間で「このプロジェクトの目指すところ(目的)はこれで、スケジュールはこのくらいで、かけられるコストはこれで…」とあらかじめ決めておく大原則・根本ルール(=憲章)のことですね。

プロジェクトが迷子になったとき、「目的に照らすとこのプロモーション企画はやるべき」とか、「スケジュールとコストはこのくらいで考えているから今回はこの機能の実装は諦めよう」とかいう話がプロジェクトメンバー間でできるようになるという、スーパー文書なのです。

2.プロジェクト憲章失敗例

とはいえ、このプロジェクト憲章、なかなか作成するのが難しいんです。過去たかつが実際に経験した数々の失敗例を紹介しましょう。


ケース1 つくったプロジェクト憲章を読んですらもらえない

たかつ「ボス、今度社内で始める新しいプロジェクトのプロジェクト憲章を作りました。チェック頼みます」

ボス「項目多っ。読む気にならんわ!」

たかつ「なるほど」

Google画像検索で、「プロジェクト憲章」と検索してもらうと分かるのですが、プロジェクト憲章に記載する項目数はフルに書こうとすると相当なものになります。がっつり気合が入っているときは全部埋めようとがんばりますが、読む方からしたらけっこうな手間。そもそもプロジェクトの大原則を決めるものなのに、ガチガチに詰めたってしょうがないんですよね。。


ケース2 読んでもらっても強烈なダメ出しを受ける

たかつ「ボス、がんばって項目しぼりました。読んでもらってもいいですか?」

ボス「え、目的とかこういう認識だったの?あなたも書いてるけど、そもそもこのくらいしかコストかけないんだからこんな目的達成できるわけないじゃん。」

たかつ「なるほど」

プロジェクト憲章を読んでもらった結果、ダメ出し→大量の修正、ということはままあります。まあ、そもそもこの認識のすり合わせ自体がプロジェクト憲章を作成する理由の1つではあるのですが、とはいえあまりにも大きい手戻りは避けたいところです。


ケース3 相手のテンションを下げる

たかつ「ボス、チェックありがとうございます。じゃあ次はこっちのプロジェクト憲章をチェックしてもらってもいいですか?」

ボス「え、まだあるの…これ読むのつまらないし疲れるんだよね…」

たかつ「なるほど」

そう、決まったテンプレートはないにもかかわらず、なぜかプロジェクト憲章は多くの場合表組みで作成され、結果、文字ばかりの読みやすいとは言えない資料として完成します。プロジェクトの進行中、何回も立ち戻って読むべきプロジェクト憲章のユーザビリティが悪く、参照されないものになってしまう可能性があるのというのは非常に問題です。

3.カギは「見せ方」と「作成の順番」

さて、上記の会話から、以下の課題が浮かび上がります。

  1. ・項目が多くて読む気にならない
  2. プロジェクト憲章に記載する内容の認識にメンバー間で大幅なズレがある
  3. 読む気にならない

これらを解決するため、弊社メンバーが考えたのが、プロジェクトの諸条件を、1つの項目につき一枚のスライド形式でまとめるという手法です。そもそもプロジェクト憲章が表組み形式だから読む気にならないんです。スライド形式なら図形や絵、なんならホワイトボードの写真だって載せながら認識合わせをすることも可能です。これで、読むのがつまらないという問題は大幅に改善する(はず)です。

このとき、「目的」の項目のスライドは最後に作成します。なぜなら、プロジェクトの目的は、現実問題として立ちはだかる他の諸条件(スケジュールとかコストとかメンバーの数とか)を暗黙の前提としてつくられていることが多いからです。この目的という項目はプロジェクトの中でも超重要項目であるがゆえに、表組みにした場合冒頭に掲げられている場合が多いのですが、実は先に外堀(他の諸条件)を埋めてからのほうが認識ズレを防げるのではないでしょうか。

ここまで書くとお気づきの方もいるかと思うのですが、上記の「スライドでプロジェクト憲章をつくる」という考え方は、ソフトウェア開発におけるインセプションデッキというドキュメントから発想したものです。項目数は、インセプションデッキを参考に、開発特有の項目をより汎用的なプロジェクトマネジメント的な項目に置き換えることで必要な十分な数に抑えることができそうです。

4.もはやプロジェクト憲章ではない?プロジェクトデッキ開発へ

長々と考察してきましたが、もはや、「われわれがつくろうとしているのはプロジェクト憲章なのか?」という疑問が湧いてきました。

多くの方が「プロジェクト憲章=表組みないし文字だけの一枚ドキュメント」とイメージするなか、何枚かにわたってつくられるであろう、まだ見ぬスライド資料…そう、これを、プロジェクトデッキと名づけよう!

というわけで、コパイロツトでは現在プロジェクトデッキの作成に鋭意取り組んでおります。もう同じようなのつくってるぜ!という方は、ぜひコパイロツトまでご一報を!情報交換しましょう。

それでは皆さん良い一日を!