様々な情報を見える化や数値化すると、予定と実績の対比が可能になり、客観的な状況の把握が容易になります。しかし、進捗の予実を見て予定を下回っていた時に、頭ごなしに「ダメじゃないか」と怒っていないでしょうか。それでは、見える化の本来の目的を達成するのは難しいです。あなたのプロジェクトで、こんな会話を耳にしたことはないですか。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
プロジェクトマネジャー（PM）：Aチームの進捗状況はどうなっていますか。
チームリーダー：予定では15タスク終わっているべきところですが、進捗が思わしくなく、現在13タスクしか終わっていません。
PM：あれ、遅れているんですか？ 先週聞いた時は、今週までに終わると言っていたじゃないですか。
チームリーダー：はい。先週時点ではそうだったのですが。（PMからの無言のプレッシャーに負けて）でも、今週末までに必ずリカバリーします（できるか分かりませんけど）。
PM：分かりました。それでは来週また報告してください。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
この会話は極端な例に見えるかもしれません。ですが、意外に身近なところで同じようなやり取りがされているのではないでしょうか。
この会話の後、チームリーダーは期日に間に合わせるために頑張るでしょう。そして優秀なリーダーであれば、期日を守り、事なきを得るかもしれません。ですが、状況によっては頑張ることが解決策にならない場合もあります。もし終わらなかった場合にどう対応するのか、この会話のなかでは議論の余地がありません。
少なくとも、こんなやり取りを繰り返せば、チームリーダーはプロジェクトマネジャーに対して、悪い話は報告しなくなってしまいます。
同じ話でも、こんなやり取りをすると、先ほどとは全く違った結果が出てきます。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
PM：Aチームの進捗状況はどうなっていますか。
チームリーダー：予定では15タスク終わっているべきところですが、進捗が思わしくなく、現在13タスクしか終わっていません。
PM：そうですか。遅延の原因は明確になっていますか。
チームリーダー：はい。XX機能の開発が予想以上に難しく、時間がかかっています。
PM：対応の見込みは立っていますか。他チームの協力は必要ないですか。
チームリーダー：XX機能の問題はチーム内で有識者を集めて今週末には対応できますが、後続のYY機能の開発に影響が出るかもしれません。
PM：分かりました。遅延の可能性があることを早めに関係チームに伝えておきましょう。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
プロジェクトマネジャーの話し方次第で、チームリーダーもプロジェクトマネジャーに状況を報告しやすくなるのです。
それでは、このプロジェクトマネジャーと先ほどのプロジェクトマネジャーの違いは何でしょう。大きく違っているのは、「何のために進捗を数値で管理するのか」という点に関する認識です。
前者は守るべき予定を数値化し、それを守らせることが管理だと考えています。そのため、進捗を守れていればよし、守れていなければダメという判断を下そうとします。後者は、予定と比べて遅れているという状況について、原因と対策、その先のリスクを早期にキャッチする情報として数値を活用しています。
このように比較してみれば、後者のように判断する必要があると理解できますが、前者のように数値を組織や個人の評価に使うという考え方は、実は多くの現場に根強く残っています。そして、プロジェクトマネジャー、チームリーダー、メンバーの全ての層に、その誤解は広がっています。
上記は、管理の枠組みはできているにもかかわらず、うまく運用できなかった例です。このチームの中核メンバーには、「人数が少ないから把握できる」という文化が根付いていました。メンバーを増やしてやや規模が大きくなっても、同様の管理レベルで対応しようとして、苦しんでいたのです。そこで、前任者はしっかりとした計画書を作成し、チームをコントロールしようとしたわけですが、定着するどころか、かえって混乱を招きました。
この管理方法は、10人に満たないプロジェクトメンバーからすると、なぜここまで必要なのか理解できないものだったと言えるでしょう。もちろん、説明が足りないことも大きな原因の1つです。加えて、取得したい情報や管理したい内容が、規模に対して過剰だったのです。
どんなプロジェクトでも同じですが、過去の経験やPMBOKなどの知識にあまり捉われずに、本当に必要な情報だけを収集する仕組みを考える必要があります。
プロジェクトではEVM（アーンド・バリュー・マネジメント）の手法を取り入れたり、経営の見える化においてはKPIを取り入れたりするなど、色々な場面で様々な数値化に取り組み、改善につなげようとしています。
しかし、表面化した数値だけを見て良しあしを判断しようとすると、報告者が内容についてネガティブな印象を持ってしまい、悪い状況が顕在化するまで報告されなくなるような弊害を引き起こします。また、現場の理解と協力が特に重要となるKPIの導入においては、運用そのものの定着が非常に困難になってしまいます。
見える化が組織や個人の評価を目的としているのではなく、対策の検討やリスクの抽出を目的としていることを、しっかりと理解してもらう必要があるのです。この点に理解を得るのは、非常に難しいことです。組織に根付いている文化や意識を変えていく必要があるのですから、プロジェクトを通じて本来の目的を伝え続けることはもちろんですが、言葉で伝えていくだけでなく、プロジェクトマネジャーやPMOがブレのない態度で徹底的に示していくことが重要になっていきます。
数値化して客観的な情報を得ることの目的は、その数字を見て良しあしを判断することではありません。数値の傾向を見て、早期に対策を検討し、潜在的なリスクを抽出することが真の目的なのです。この目的をプロジェクトの共通認識にすることが、プロジェクトマネジメントを円滑に行うための大きな一手となります。