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

ガイドの視点

 今回のテーマはコミュニケーションについて。話し言葉によるコミュニケーションの重要性はこれまでも取り上げられていたが、今回は書き言葉、文章を書く能力に着目している。話し言葉同様、書き言葉によるコミュニケーションを苦手とする人も多いだろう。しかし、Mochal氏は、それはスキルの欠如ではなくフォーカスを欠いているだけだと指摘する。

 しっかりとフォーカスが合った報告書とはどのようなものだろうか。読み手の立場になって記述する、読み手に不要な事柄は書かない、適切な分量と詳細度で記述する。この3点を押さえておけば良いとされる。

 むかし、大きなプロジェクトで、各チームが会議の度に報告書の厚みを競っているのを見たことがある。クライアント側の担当者は、毎回、分厚いファイル1冊分にもなろうという報告書を受け取る。それから12時間以上にわたって、大局的なことから極めて細かい詳細設計上の問題を話し合うのだ。報告書の厚みが足りないといって、無用でもいいから詳細設計ドキュメントを添付するように指示されたことすらある。

 このときのクライアント側担当者は、山のようなドキュメントに目を通し、不毛な議論につきあわされ、どれが最重要課題なのか理解できなかったようだ。はたで見ていると、膨大な資料で本質を隠し、故意に煙に巻いてやろうとしているようにも見えた。会議の運営方法にも問題があったのだが、読み手の立場を考えない、不適切な分量・不適切な詳細度の報告書がもたらす害の極端な例だ。

 さて、本稿ではステータスレポートの項目、質問形式でのステータスサマリーの書き方も紹介している。「本プロジェクトは予定通りに完了しそうか?」「本プロジェクトのコストは予算内に収まりそうか?」等、はっきりとYes または Noで答えられるいくつかの要点が列挙されている。とかくステータスレポートのサマリーは玉虫色になりがちなので、このようにハッキリと白黒つけるような潔い記述ができるように心がけたいものだ。読み手に誤解を与えない明確な記述は、まさに読み手の立場に立った記述といえよう。

監訳者(若田部)
このコーナーでは米国TechRepublicから日本企業のITマネジメントに役立つ情報を日本人ガイドが厳選してご紹介しています。

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

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

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

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

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

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

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

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

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

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

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

  • 全体の進捗状況を示すもの
 よく目にするのは、プロジェクト全体の進捗状況を表わすのに、ごく簡単な表示を使っている例。たとえば、予定通りに進んでいるものは緑、注意が必要なものは黄色、問題が発生しているものには赤というふうに、この表示を使い分ける。
  • 大局的なステータスサマリー
 レポートの上部には、プロジェクト全体に関するサマリー情報を載せるべきだ。予定通りに進んでいるプロジェクトでは、どの項目にもすべて「Yes」か「No」で答えられるような書き方で質問を記すこと。これらの質問は現在または将来にフォーカスを置くようにすること。過去の状況に対する質問ではない。たとえば:
  • 本プロジェクトは予定通りに完了しそうか?
  • 本プロジェクトのコストは予算内に収まりそうか?
  • 本プロジェクトの成果物は、質の面で許容範囲に収まるものとなるか?
  • スコープ変更の要請はうまく管理できているか?
  • プロジェクトの課題はうまく解決されているか?
  • プロジェクトにまつわるリスクはうまく緩和されているか?
  • クライアントの抱いた懸念はすべてうまく解決されているか?
  • コメント
 上記の質問事項のなかで、答えが「No」だったものについては、もっと詳しい情報を記すこと。
  • 今期に達成した重要な実績
 前回のレポート提出以降に達成した主要な実績をリストアップする。もし予定していた実績が今期に完了していなければ、プロジェクトマネージャーはその理由について、コメントを付すべきだ。
  • 来期に予定している達成事項
 次のレポート提出時点までに完了予定の主な事項をリストアップする。
  • 追加のコメントもしくはハイライト
 読み手が知っておくべきであり、レポート内のこれまでの部分で書ききれなかったその他のコメントは、どんなものでもここに盛り込む。
  • 添付書類
 読み手によっては興味を持ちそうなプロジェクトマネジメントに関するレポートが、この他にも数多くある。だが、ここでも相手のことを忘れてはいけない。たとえば、プロジェクトの作業計画に関心を抱く読み手がいるかもしれないが、おそらく関係者全員がこれを受け取っても手に余るだけだろう。同様に、予算関連情報のサマリーなら読み手は興味を示すだろうが、但し詳細なものはいらないと言うだろう。その他にも、課題解決記録、スコープ変更記録、プロジェクト・マトリクス/統計、そしてあなたの勤め先が求めているその他のレポートなどが、ステータスレポートに添付される書類となり得る。
  • 未来にフォーカスする
 あなたがユーザーサポートチームに所属している場合には、ステータスレポートは、前回の報告から現時点までに起こった過去の出来事にフォーカスしたものとなるだろう。サポート業務は通常受身の仕事であり、先々どんなことが起こるかを知るのが困難だからだ。しかし、プロジェクトのステータスレポートは、現在および将来にフォーカスしたものをまとめるべきだ。これまでにあげた成果に興味がある読み手もいるかもしれない。だが、彼らもプロジェクトを完了するのに、この先何が必要なのかを、もっと知りたいはずだ。

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

CNET Japanの記事を毎朝メールでまとめ読み(無料)

-PR-企画特集

このサイトでは、利用状況の把握や広告配信などのために、Cookieなどを使用してアクセスデータを取得・利用しています。 これ以降ページを遷移した場合、Cookieなどの設定や使用に同意したことになります。
Cookieなどの設定や使用の詳細、オプトアウトについては詳細をご覧ください。
[ 閉じる ]