あなたは、自分が参加しているプロジェクトの目的や目標を意識しているだろうか。また、目的と目標の違いを、きちんと理解しているだろうか―。
多くの人はこう聞かれて、明確に答えるのが難しいだろう。なぜなら、「目的」と「目標」という言葉の定義は非常にあいまいであり、プロジェクト内で共有できていないことが多いからだ。しかし、目的と目標という言葉の意味は、全く違うものである。そして、それらはともに、プロジェクト内で具体的に設定する必要がある。そうしないと、プロジェクトは混乱し、やがて頓挫する。今回は、「目的と目標を混同するな」というルールについて紹介しよう。
1W1Hを「目的」で「目標」で4W
筆者もかつて、目的と目標を混同していた1人である。それを当時の上司から指摘され、その本質に気付かされた。目的と目標は辞書を引くと、ともに「目当て」や「目指す所」と書かれている。だが、本質的には大きな違いがある。目的は的（まと）、目標は標（しるべ）なのだ。つまり、最終的に到達すべき地点が目的であり、「なぜ（Why）」と「どのように（How）」をセットで示す必要がある。
これに対して目標は、目的にたどり着くための道筋やルートを指す。達成状況の確認が可能であり、Howを具現化した「いつまでに（When）」「どこで（Where）」「誰が（Who）」「何を（What）」を示す。一般的に使う「5W1H」の中で、1W1Hを目的で示し、残り4Wを目標で表すわけだ。
中には「目標は意識しているが、目的はなくても仕事はできる」「目的は明らかにしているが、細かな目標の設定は部下に任せている」と考える人がいるかもしれない。だが、そのことで筆者は手痛い失敗をした。以下で、そんな二つの失敗例を紹介しよう。
最初の失敗例は、目標をきちんと設定したが、目的があいまいだったケースである。詳細設計フェーズ以降のプロジェクト・マネージャ（PM）を任されたときだ。現場を訪れると、上司から「基本設計は問題なく完了している。あとはリリースを間に合わせるだけだ」と告げられた。
筆者はプロジェクトの進捗に重きを置き、プロジェクトの目標に当たる実現範囲と作業分担、スケジュールを綿密に取りまとめた。途中から参加したこともあって、プロジェクトの目的にはあまり目を向けていなかった。
これが大きな問題だった。ユーザーから見ると、このプロジェクトではスケジュールよりもシステムの品質の方が大事だったのだ。「納期遅延を起こさない」と肝に銘じていた筆者は、品質保証部門への状況報告もおろそかにし、スケジュール優先でプロジェクトを進めた。その結果、リリース直前の受け入れテストでいくつかのバグが見つかり、リリースを先延ばしせざるを得なくなった。プロジェクトの目的をおざなりにし、スケジュールも品質も守れなかったのである。
もう一つは、目標を明確にしなかったことによる失敗だ。PMとして参加したあるプロジェクトのこと。筆者はプロジェクト開始前にメンバーを一堂に集め、キックオフ・ミーティングを開いた。そこで何のためのプロジェクトか、どのように実現するかという目的をはっきりさせた。だが「何をやってもらうか」という目標については説明しなかった。目的と目標の違いを整理できていなかったこともあるが、プロジェクトの細かい説明をしすぎると、現場が息苦しくなると考えたからだった。
目標示さずメンバーの士気下げる
「あとはみなさんにお任せします」。そう言ってミーティングを終え、目標なきプロジェクトが始まった。後日、各チームから出されてきたスケジュールや作業計画を見ると、とても目的に到達できるものではなかった。また、作業分担にも抜けや漏れが発生していた。あわてた筆者はメンバーを再び集め、キックオフ・ミーティングをやり直した。彼らの顔を見ると「なんだ、また集めるのか。振り回すのもいい加減にしてくれ」という表情。プロジェクトの開始はどんどん遅れ、メンバーの士気も下げてしまった。
プロジェクトでは、目的と目標が極めて大事である。その前提として、リーダーは目的と目標を混同せず、両方を具体的に示さなければならない。
