本記事は日経コンピュータの連載をほぼそのまま再掲したものです。初出から数年が経過しており現在とは状況が異なりますが、この記事で焦点を当てたプロジェクトマネジメントの本質は今でも変わりません。

プロジェクトに取り組むにあたって,最初にすべきことは,「プロジェクトの定義」である。その目的は,プロジェクトの存在を示すことと最終ゴールを明確にすることである。プロジェクトを定義するときには,「プロジェクトチャータ」と呼ぶ文書を作成する。ここには,プロジェクトの背景や目的,最終成果物,予算と期間,プロジェクトの終了条件,プロジェクトマネジャの権限と責任,組織,コミュニケーションの取り方について記述する。

伊藤 健太郎
アイシンク 代表取締役

 「今やっているプロジェクトの内容はなんだか分かりにくいよね」。「確かにそうだけれど,言われた通りやっていれば,そのうち分かるようになるんじゃない」。プロジェクトの初期段階に,こんな会話がプロジェクト・メンバーの間で交わされることがある。はなはだしい場合,プロジェクトの中盤になっても,まだメンバーたちが首をひねっているケースもある。

 しかし,こんな状態ではそのプロジェクト・メンバーはプロジェクトを効率的に実行できないであろうし,プロジェクト全体からみて非効率である。プロジェクトの内容がよく分からないのでは,メンバー本人もプロジェクトの関係者でありながら,本当の意味でプロジェクトに関与していると実感できないのではないだろうか。「始めよければ,終わりよし」ということわざがある。プロジェクトでも同じである。なんといっても最初が肝心である。

 プロジェクトの内容があいまいのまま,スタートするのと,できる限りプロジェクトの内容を明確にしてから遂行するのでは,プロジェクトの効率は当然異なるものになる。プロジェクト・メンバーも自分たちが関係するプロジェクトがどのようなものであるかを知っておかないと効果的に業務を遂行できない。

 したがって,今からとりかかるプロジェクトがどのようなものであるのかを明確にするプロセスが欠かせない。このプロセスを,「プロジェクトの定義」と呼ぶ。プロジェクト定義の目的は大きく二つある。第1は,プロジェクトの存在を示すこと。第2は,プロジェクトの最終ゴールを明確にすることである。

定義をして初めて存在する

 プロジェクトの存在を示すとは,「プロジェクトの定義」が完了した時点で,プロジェクトが存在するという意味である。プロジェクトの定義がされていなければ,なんらかの作業をしていたとしても,プロジェクトは存在していない。

 ここで読者の方々はちょっと考えていただきたい。質問は,「いったいどの時点からプロジェクトが存在している,と言えるのか」である。「プロジェクトルームにメンバーを集め,作業指示が出たとき」であろうか。「顧客の○○さんから今度のプロジェクトを頼まれたときから,プロジェクトは存在する」という人もあろう。あるいは,「社長からこのプロジェクトをやるんだ,と言われた時点から,プロジェクトは存在する」と考えるかもしれない。

 しかし,本当にそうであろうか。例えば,顧客の○○さんからプロジェクトを遂行するように依頼されても,当然ながらプロジェクトをすぐには遂行できないであろう。つまり,ただ話があった状態ではプロジェクトは存在しているとは言えない。また,なし崩しにメンバーを集めて開発作業を始めるようなケースも,プロジェクトが存在するとは明言しにくい。

 つまり,どの時点からプロジェクトがスタートしたのかを明確にすることが必要になる。プロジェクトの存在を明確にし,必要な関係者に公表する。それによって,プロジェクトの関係者はプロジェクトが存在することを知って,行動しやすくなる。

最終ゴールを明確にする

 プロジェクト定義のもう一つの目的は,「プロジェクトの最終ゴールを明確にすること」である。すなわち,何のためにプロジェクトを遂行するのか,何を成し遂げるためのプロジェクトであるのか,といった点をプロジェクトの開始時点で明らかにする。

 そうしないと本来の目的と異なった方向にプロジェクトが進んでいきかねない。プロジェクトの初期にプロジェクトの方向性が決まっていないと,何が優先事項であるのか,何を最初にしたらいいのか,何のためにプロジェクトを実施しているのかが分からず,ただ目の前にある業務をこなしているだけの状態になりかねない。

 プロジェクトは目的志向の時間限定の活動である。目的があいまいなまま遂行すると,後戻りできない失敗をしてしまうことにつながる。つまり,無駄なコストが発生してしまうわけだ。

 ここでいう「最終ゴール」とは,プロジェクトでの最終成果物だけではなく,プロジェクトを遂行するに至った背景も含んでいる。最終成果物,すなわち,プロジェクトで最終的に生み出すものはプロジェクトの目的とは異なる。この差異を明確に理解しておかないと,せっかく成果物が出来上がっても役に立たないものになってしまう。

 例えばテスト段階で,開発中の情報システムがバグが少なく,性能も要求通りのものが出たとする。それでも,実際に利用してみると顧客が考えていた目的を達成することができず,システムの修整を要求されることがある。修整費用が大きいと,顧客とITベンダーとの契約内容に基づいてどちらに落ち度があるのかを裁判で争うことにもつながりかねない。

 こうした事態を避けるためには,いかにしてコミュニケーションの間違いを防ぐかにかかっている。顧客もITベンダーもどちらも,意図的にシステム開発プロジェクトを誤った方向に誘導しているわけではない。むしろ,お互い精一杯,努力していることが多い。ITベンダーのメンバーは一生懸命夜遅くまで仕事をしている。その結果できたシステムが顧客に喜んでもらえて初めて,彼らの努力が報われる。

目的の明確化はマネジャの責任

 そのためにプロジェクトマネジャは,プロジェクトの開始前にプロジェクトが必要になった背景と目的を必ず明確にする必要がある。

 この点については読者の方々は総論としては賛成していただけると思う。しかし,現実に実施しているかというと,そうでない場合が多い。「そんな理想を言っても,この業界では難しいものです」,「そもそも客先が明確にしてくれないんですよ」,「それは社長が決めるものでしょう」などと,多くの言い訳が存在する。

 ここで,どのように対応するのかが,プロジェクトを成功できるかどうかの最初の分かれ道である。周囲の状況のなすがままでプロジェクトを担当しても,プロジェクトを的確にコントロールできない。プロジェクトマネジャは客先やトップマネジメントがプロジェクトの目的を明確にできない場合には,自ら明確な目的をまとめ上げ,顧客から必要な承認を取りつけ,その目的を公式のものとして公表しなければならない。