ITプロジェクトの価値を伝えるのに有効なものは

　何年も前に、ある大きなIT企業でマネージャー全員が参加して開かれたミーティングのことを、私はいまでも憶えている。IT企業が提供しているサービスの、ビジネス面での価値を明らかに伝えられないことに対する歯がゆさを、あるバイスプレジデント（VP）が口にした。

　彼は、あるチームの例を挙げた。そのチームは海外のプラントに新しい製造業用ソフトウェアをインストールしたばかりだった。チームのメンバーは、ビジネス側がすぐに必要としていた拡張機能を、長い時間働いて、実装しなくてはならなかった。メンバーの1人はまた、重大なハードウェアの障害が発生した際に、わざわざ現地に出向き、3日間にわたってソフトウェアを再構築するのを手伝った。しかし、月例のステータスレポートを提出することになったとき、このチームのリーダーは、ただ「通常のサポートを必要とする課題を解決した」と記しただけだったという。

　そのミーティングに参加した人々は、この冗談めいた話を耳にして、いったい笑っていいものかどうか、自信が持てなかった。おかしい話に聞こえたが、しかしそれを口にしたVP自身が笑っていなかったからだ。

　私たちITプロジェクトに係わる人間の多くが、顧客のニーズを満たすために週70時間働くことも厭わないのに、いっぽうではステータスレポートひとつ満足に書けないというのは、いったいどうしたことだろうか。この理由について、私は２つの大きな問題があると信じている。1つは、文章でものごとを上手に伝えるスキルがなく、また文章を書くことを苦手に感じている人がいるということだ。

　しかし、コミュニケーションの問題は、スキルの欠如ではなく、ただフォーカスを欠いていることが原因の場合が多い。プロジェクトマネージャーの多くは、積極的なコミュニケーションの価値をわかっていない。そして、自ら何かを伝える時には、短くて、わけのわからない文章になりがちで、まるでできるだけ手間をかけずに済ませたいと思われてしまいそうなレポートが出来上がってしまう。

読み手の立場になって書く

　コミュニケーションの鍵は、自分ではなく、相手の立場に立って話をまとめることだ。相手が何を必要としており、どんな情報が相手に最も役立つかを考えてみよう。ステータスレポートを書いているときには、読み手がプロジェクトの実情を理解するために必要とする全ての情報をレポートのなかに盛り込もう。これまでに達成した事柄、課題、リスク、スコープ変更箇所、その他すべてをだ。

　多くの組織では、プロジェクトマネージャーはいろいろな立場の相手にレポートを送る必要がある。その際には、相手によってレポートの書き方を変えるといい。典型的なマネージャー向けのレポートと、役員レベルのマネージャーに出すレポートでは、中味を変える必要があるかもしれない。たとえば直接の上司や主要なクライアントには、プロジェクトのステータスと予算面の状況を1ページにまとめたものを送るとして、この同じ情報を役員に伝える場合には、半分に要約するか、あるいは一行に圧縮してもいいかもしれない。

ステータスレポートには役に立つ情報だけを盛り込む

　ステータスレポートは簡潔にまとめ、意思決定に役立つ情報だけを盛り込むようにしよう。自分の書いたレポートのなかにある情報が、本当に何か価値のある事柄を伝えているのか、それとも単にスペースを埋めているだけなのかについて、チームのメンバーに意見を求め、また自分でも反省してみること。さて、この点を念頭において考えると、どんなタイプの情報を盛り込むべきだろうか。

　プロジェクト名、プロジェクトマネージャー氏名、プロジェクトの期間、その概略説明など。こうした基本的な情報は、どのレポートにも入れておく必要がある。そうしておけば、どのプロジェクトについてのレポートであるかが、読み手にすぐわかる。

• 全体の進捗状況を示すもの

　よく目にするのは、プロジェクト全体の進捗状況を表わすのに、ごく簡単な表示を使っている例。たとえば、予定通りに進んでいるものは緑、注意が必要なものは黄色、問題が発生しているものには赤というふうに、この表示を使い分ける。

• 大局的なステータスサマリー

　レポートの上部には、プロジェクト全体に関するサマリー情報を載せるべきだ。予定通りに進んでいるプロジェクトでは、どの項目にもすべて「Yes」か「No」で答えられるような書き方で質問を記すこと。これらの質問は現在または将来にフォーカスを置くようにすること。過去の状況に対する質問ではない。たとえば：

• 本プロジェクトは予定通りに完了しそうか？
• 本プロジェクトのコストは予算内に収まりそうか？
• 本プロジェクトの成果物は、質の面で許容範囲に収まるものとなるか？
• スコープ変更の要請はうまく管理できているか？
• プロジェクトの課題はうまく解決されているか？
• プロジェクトにまつわるリスクはうまく緩和されているか？
• クライアントの抱いた懸念はすべてうまく解決されているか？

• コメント

　上記の質問事項のなかで、答えが「No」だったものについては、もっと詳しい情報を記すこと。

• 今期に達成した重要な実績

　前回のレポート提出以降に達成した主要な実績をリストアップする。もし予定していた実績が今期に完了していなければ、プロジェクトマネージャーはその理由について、コメントを付すべきだ。

• 来期に予定している達成事項

　次のレポート提出時点までに完了予定の主な事項をリストアップする。

• 追加のコメントもしくはハイライト

　読み手が知っておくべきであり、レポート内のこれまでの部分で書ききれなかったその他のコメントは、どんなものでもここに盛り込む。

• 添付書類

　読み手によっては興味を持ちそうなプロジェクトマネジメントに関するレポートが、この他にも数多くある。だが、ここでも相手のことを忘れてはいけない。たとえば、プロジェクトの作業計画に関心を抱く読み手がいるかもしれないが、おそらく関係者全員がこれを受け取っても手に余るだけだろう。同様に、予算関連情報のサマリーなら読み手は興味を示すだろうが、但し詳細なものはいらないと言うだろう。その他にも、課題解決記録、スコープ変更記録、プロジェクト・マトリクス／統計、そしてあなたの勤め先が求めているその他のレポートなどが、ステータスレポートに添付される書類となり得る。

• 未来にフォーカスする

　あなたがユーザーサポートチームに所属している場合には、ステータスレポートは、前回の報告から現時点までに起こった過去の出来事にフォーカスしたものとなるだろう。サポート業務は通常受身の仕事であり、先々どんなことが起こるかを知るのが困難だからだ。しかし、プロジェクトのステータスレポートは、現在および将来にフォーカスしたものをまとめるべきだ。これまでにあげた成果に興味がある読み手もいるかもしれない。だが、彼らもプロジェクトを完了するのに、この先何が必要なのかを、もっと知りたいはずだ。

　よく書けた、効果的で、かつ客観的なステータスレポートを仕上げるには、プロジェクトマネージャーが集中して、努力し続ける必要がある。ステータスレポートの目的はプロジェクトの実状を伝えることであり、プロジェクトマネージャーがどうなってほしいかを知らせることではない。もし課題やリスクがあれば、それも漏らさず伝えるべきだ。ステータスレポートが短すぎたり、あるいは大局的に過ぎると、読み手の側ではプロジェクトの現状を充分に理解しなくなり、後から質問しなくてはならないといったことも起こり得る。レポートの読み手がプロジェクトについて理解し、その進捗具合がわかるように、効果的な伝え方を心がけることだ。