プロジェクト定義で意識合わせを

プロジェクトが始まった時には、まず「プロジェクト定義」なるものを作ることをお勧めする。

そのフォームは、図1のようなもので、プロジェクトがいかに大きくても、A4の1枚ものでかまわない。

図1: プロジェクト定義の例 (クリックで拡大)

プロジェクトを実施する以上、誰が、何のために、何を、いつまでにやるのか、ぐらいのことは、関わる人たちが共通に理解しておくべきことであるだろう。形式が大事なわけではないので、すでに同様の内容をカバーする「プロジェクト憲章」などがあれば、それでも十分である。

すでにプロジェクトが起こっている以上は、その承認の決裁や稟議書の中に相当する事項が記載されているだろうから、それを書き写すつもりでやれば、10分もあれば書けるはずである。にもかかわらず、始まって1ヶ月以上も経過しているプロジェクトで、これ1枚を書くのに大いに手間取り、メンバー内でずいぶんと議論になってしまったなどということもある。

あまりにもシンプルな内容なので、書くまでもないと思われるかもしれないが、人間系に流されがちなこのフェーズにあって、メンバー間でこのレベルの合意もないまま進めると、この先のプロジェクトの混迷の様は想像に難くない。

メンバーはまずこのレベルを共有して、「何のためにやるのか」といった基本的な問いかけに同じ答えができる程度にはなっていなければならない。理解が浅いこの時点での記載内容は仮留め程度の役割になってしまうが、少なくとも検討が進んでプロジェクトが再定義されるまでは、これがプロジェクトの根拠そのものであり、経営へのコミットメントである。

ここで記載する主な構成要素について少しだけ説明しておく。

「名称」を付けて混乱を防ぐ

名前のついていないプロジェクトをよく見かけるが、「名称」はとても重要だ。プロジェクトというのは、しばしば階層化していて、数年がかりのプロジェクトの中のxxフェーズをやっているとかいう状況がよくあるだろう。

例えば、「再構築プロジェクト」の中の「計画策定」がひとつのプロジェクトになっていたりする。この場合に「このプロジェクト」といったときに、全体の話をしているのか、「計画策定」に限った範囲を指しているのか混乱が生じる。プロジェクトが一意に識別できるよう、それぞれに適切なプロジェクト名をつけて、具体的な名称で呼ぶように徹底したい。

「目的」はひとまず適当な表現で

プロジェクトの「目的」は、最重要事項である。

いざ決めようとすると、表現にはそれなりに悩むかもしれないが、検討が進むにつれて、より適切な表現が固まってくるので、最初は時間をかけずに手早く設定することである。

「背景」で課題を明確に

「背景」には、プロジェクトがなぜ起こったのかを記述する。そこには、攻めか守りかはともかく、プロジェクトで解決すべき課題が盛り込まれるだろう。

ここまでの「目的」と「背景」を見れば、そのプロジェクトが対象としているテーマが大まかに読み取れる状態になるはずである。

「期間」は暫定でも良いので日付を明記

プロジェクトであるから、そもそもその「期間」は当然規定されていなければならないのだが、ぼんやりと、「半年間」とか、「いちおう、年末まで」とかで進められているケースも少なくない。

決め切れない要因は色々あるのだろうが、"仮留め"でもいいので、ちゃんとした日付で、記載しておくべきである。

変更が発生するのは普通、適切に修正を

初期の「目的」や「背景」の記述は、どちらかというと今起こっている現象をとらえた表層的な内容にとどまっていることが多く、この時点で解決策と考えていることもおそらくは直観的な仮説にすぎないだろう。

検討を進めていくうちに、理解が進み、プロジェクトが扱う課題の本質が見えてきて、最初に掲げた表現に違和感を覚えるようになるということはごく普通にある。適切なマイルストーンで、修正をかけていくことは重要である。

ただし、当然ではあるがプロジェクト内で共通の目的意識をもつためのものであるから、修正は、プロジェクト全体の合意のもとに行われ、関係者に周知徹底させなければならない。

プロジェクトの"タガ"を締めるためのツールとして

プロジェクト定義の内容のみならず、より詳細なプロジェクト計画書や、次回以降で述べるプロジェクトインストールで作る様々な成果物も最終的にはプロジェクト内で共有すべき情報となっていくのであるが、それらの成果物は多くの情報を含むため、記載内容をそのまま共有するというよりは、それを作成するプロセスを共有することで、各メンバーの頭の中に共通のモデルができるところを意図しているものが多い。

それに対して、プロジェクト定義書は、端的にプロジェクトの趣旨を明記したものであって、記載内容そのものを意識的に共有し、プロジェクトの趣旨からの逸脱を防ぐための魔除けの札のようなものである。

どこかの会社の五指標語のように、毎朝プロジェクトメンバーで唱和でもするとよいが、さすがにそこまで精神論化するのもやりすぎなので、プロジェクトの大事な節目にプロジェクトの目的やミッションを再確認する手立てぐらいに使うとよいだろう。

ともあれ、プロジェクトメーキングの大きな目的は、共通の目的意識を「名」「実」ともに作ることである。結果として、チームの中で、「あれ」と言えば「あれ」というような、少ないプロトコルでやりとりできる環境を醸成できればOKである。プロジェクト定義書は、言ってみれば、その「名」に相当する目的意識共有化のツールである。

最初の短いプロジェクトメーキングの期間でさえ、メンバーが目的を見失い、プロジェクトが瓦解する可能性がないわけではない。最初の段階で、この定義書がプロジェクトの一番外枠を固める「タガ」の役割になるのである。