初心者向けプロジェクトレポート入門

プロジェクトの約60%は、コミュニケーションの行き違いが原因で失敗します。また、プロジェクトマネージャーの75%は、ステークホルダーとの認識のずれなどもあり、プロジェクトの成功に自信を持てずにいます。正確で一貫したプロジェクトレポートは、自分のプロジェクトがこうした数字の一部にならないようにするための方法のひとつです。ただ、プロジェクトレポートは簡単ではありません。実際、多くのプロジェクトチームが次のような課題を抱えています。

• レポートの作成に時間をかけすぎてしまう。

• データが誤解されて悪い結果になることを恐れている。

• ステークホルダーがレポートを読まない。

• レポートをもとにパフォーマンスをどう改善すればよいかわからない。

経営層にとっても楽ではありません。ただし、プロジェクトレポートでは次のような別の課題に直面します。 

• プロジェクトごとにレポートの形式がばらばらである

• 早期の警告を検知できない

• 古い情報や不要な情報が含まれている

• 見るべきではない指標を追っている

ここでは、プロジェクトレポートの基本から、ベストプラクティス、読まれるレポートにするための簡略化のコツまでを詳しく解説します。さらに、時間を節約し、経営層向けにプロジェクトをまたいで一貫したレポートをつくるためのテンプレートもいくつか紹介します。 基本を身につければ、プロジェクトレポートに使える多くのツールも活用できるようになります。

効果的なプロジェクトレポートの書き方

焦点を絞る

次の点を自分に問いかけてみましょう。このレポートの目的は何か。誰かに送ることで、どんな結果を求めているのか。行動喚起（CTA）は何か。何を伝えようとしているのか。想定する読み手は誰か。ステークホルダーにレポートを読んでもらいたいなら、その人に合わせて情報を整え、その人にとって最も関係の深いプロジェクトの側面だけを盛り込む必要があります。必要なものだけを届けるには、レポートの価値を確かめるのがひとつの方法です。送っているレポートは、本当に相手の役に立っていますか。本人に聞いてみましょう。何を知りたいのか、何を知る必要があるのかを確認します。

記録を残す

担当しているプロジェクトの期間中に、病気になったり、オフィスを離れたりしたらどうなるでしょうか。不在の間、誰が引き継げるでしょうか。一貫してプロジェクトレポートをつくっていれば、プロジェクトの履歴が残り、代理のプロジェクトマネージャーにとっての入門資料になります。一貫したレポートには、もうひとつ利点があります。規模が似た今後のプロジェクトのテンプレートとして使えるので、次のプロジェクトの時間を節約できます。

レポートは大づかみにまとめる

細かい内容に入る前に、まずプロジェクト全体の目標、メリット、健全性、進捗を、概要がわかる情報のスナップショットで示しましょう。

レポートの形式をそろえる

ステークホルダーがいつ届くかわかるように、レポートは決まったタイミングで送りましょう。

情報を検証する

言うまでもないことですが、プロジェクトレポートの正確さは必ず確認してください。確認を怠ってミスをすると、社内での信頼を確実に失います。

レポートを簡略化する

レポートを簡略化すると、いくつかの点で役立ちます。

• プロジェクトの現在のステータスを把握しやすくなります。

• 問題解決を進めやすくなります。

• 潜在的な問題を見つけやすくなります。

• グループでのコラボレーションが進みます。

方法は3つあります。

• 例外（差異、課題、リスク）だけを報告する

• 現在のステータスを含める

• ビジュアルなデータを使う

プロジェクトレポートの4つの種類

1. プロジェクトステータスレポート

ステータスレポートは、ステークホルダーにプロジェクトのスナップショットを提供します。プロジェクトへの理解が深まり、追跡がしやすくなり、進捗も記録できます。

ステータスレポートに含める6つの項目

1. 主なハイライト 主なハイライトのセクションは、レポートのエグゼクティブサマリーだと考えてください。冒頭には、プロジェクトスポンサー、プロジェクトマネージャー、日付などの主要な情報を入れます。さらに、この1週間に起きたこと（または起きなかったこと）と、翌週に達成する予定のことをひととおり整理します。次の項目の更新情報を含めましょう。

• タスク

• 成果物

• ミーティング

• コミュニケーション

• 意思決定

• その他

2. プロジェクトのスケジュール達成率 プロジェクトはマイルストーン、つまりタスクのまとまりに分けておくと、フェーズや成果物のステータスを報告しやすくなります。プロジェクト全体の達成率と、各フェーズやマイルストーンの達成率をステークホルダーに伝えましょう。このセクションを見れば、予定どおりか遅れているかがわかります。完了したことをここにすべて並べてもよいでしょう。 3. 予算のステータス 予算は透明性を持って示しましょう。ただし、このレポートでどこまで開示すべきかは、経営陣や上司に確認してください。予算の状況がチームメンバーを不安にさせそうなら、レポートに簡単な注記を入れます。予算額に対する支出額と支出の割合をシンプルに更新するだけで十分です。遅れているのか、進んでいるのか、計画どおりなのかを明記します。 4. 今後のタスクとマイルストーン 見やすい4列の表に、今後のタスクとマイルストーンを並べます。列には、タスク／マイルストーンの名前、目標期限、担当者、コメントや詳細を入れます。 5. エスカレーション事項 すぐに対応が必要なことは何でしょうか。ここに記録し、誰が対応すべきかも書いておきます。リソースの追加でも重要な意思決定でも、支援を求める場所です。 6. 主なリスク、課題、軽減策 課題はすでに起きた問題で、リスクは起こりうる課題です。大きなものだけを挙げ、それに応じて優先順位をつけます。このセクションは、悪い知らせを伝えたり、埋もれさせたりする場所ではありません。そうした情報は、気づいた時点で直接伝えましょう。この情報も4列の表にまとめると読みやすくなります。列には、課題／リスク、深刻度、対応策、担当者を入れます。

2. リソースレポート

リソースレポートでは、誰がいつ何をしているのかがわかります。どのチームメンバーが、どの日に、どのタスクを担当しているのかを一覧にします。このレポートは、チームメンバーが複数のタスクに割り当てられている「過剰な割り当て」の発見に役立ちます。同時に2つの作業はできないので、これは明らかな問題で、プロジェクトがスケジュールどおりに進まなくなります。 リソースレポートは、複数のメンバーのスケジュール調整にも役立ちます。レポートを出せば、誰がいつ手が空くかがわかるので、そのタイミングで別のタスクを割り当てられます。また、リソースの空き状況をプロジェクトのスケジュールと照らし合わせると、より効率的に計画を立てられます。そうすれば、ある人がタスクを終えたときに、次に手の空いた人が後続のタスクを引き継げます。他の人の手が空くのを待ってプロジェクトが滞るのを防げます。

リソースレポートのヒント

• プロジェクトごとに時間を適切に割り当てる。リソースが100%プロジェクトに専念していると思い込まないでください。多くの場合、複数のプロジェクトを掛け持ちしています。そのため、各メンバーに自分のプロジェクトで割り当てられる時間数（割合に換算してもかまいません）を決めましょう。

• 対応できない時間を確保しておく。不在の日に重要な期限を割り当てないようにしましょう。休暇などの予定をスケジュールに反映してもらい、その時間をタイムライン上で押さえておきます。

• 重要なリソースのためにリスク計画を実行する。重要な人材がより優先度の高いプロジェクトに異動になることは珍しくありません。リスク計画に書いておき、事前に備えましょう。後任の経験や知識が足りず、作業に時間がかかる場合は、当初のプロジェクトの見積もりを更新する必要が出ることもあります。

• リアルタイムのタイムトラッキングを必須にする。

• ボトルネックを見つけ、すばやく調整する。

3. リスク評価マトリクス

70%のプロジェクトが失敗し、平均の超過率は27%でした。さらに、6件に1件のプロジェクトでは、コストが平均で200%超過し、スケジュールも70%近く超過しました。こうした数字を減らし、プロジェクトの失敗を防ぐのに役立つプロジェクトレポートがあります。それがリスク評価レポートです。リスク評価マトリクスは、起こりうるすべての問題を挙げ、その影響の大きさを検討することで、プロジェクトのリスクをすばやく算出します。これにより課題の優先順位をつけやすくなり、対処しなければプロジェクトに最も大きな影響を与えるものに集中できます。

リスク評価マトリクスのつくり方

ステップ1：リスク登録簿をつくる。リスク登録簿とは、プロジェクトで起こりうるあらゆる問題を並べた一覧です。影響を受ける領域、深刻度、発生の可能性、リスクの影響度、推奨される対応策を記載します。アイデア出しの参考に、よくあるリスクを挙げます。

• リソース：病気、死亡、けが、別のプロジェクトへの異動によるチームメンバーの喪失

• 運用：供給や業務の中断、必要な資産へのアクセス喪失、配送の失敗

• 評判：顧客や従業員の信頼の喪失、ブランドの評判の低下

• 手続き：説明責任、社内システム、統制の不備

• プロジェクト：予算超過、期限の未達、品質基準の未達

• 財務：事業の失敗、株式市場の変動、金利の変化、資金調達の不可

• 技術：技術の進歩、または技術的な不具合

• 自然：天候、自然災害、病気

• 政治：税制、世論、政府の政策、外国の影響の変化

• 構造：危険な化学物質、不十分な照明、落下する箱など、スタッフ、製品、技術が損害を受けうるあらゆる状況

ほかにも、次のようなアイデア出しの方法があります。

• システム、プロセス、体制を見直してリスクを分析する。弱点は見つかりませんか。

• 違う視点を持つ人に聞く。チームメンバーに尋ねたり、似たプロジェクトを管理した経験のある人に相談したりします。

ステップ2：深刻度、発生の可能性、影響度を決める。 深刻度 最悪の場合、何が起こるでしょうか。深刻度のラベルは、自分が使いやすいように決めてください。私たちのテンプレートでは、次のようにしました。

• 許容できる：このリスクが起きても、問題はありません。

• 耐えられる：痛手にはなりますが、プロジェクトは必ず立ち直れます。

• 深刻：これ以上悪い事態はありません。

発生の可能性 当然ながら、ほかより起こりやすいリスクがあり、そうしたものにはより早く対処したいものです。発生の可能性を評価するために、次の3つのラベルを選びました。

• 起こりにくい：豚が空を飛ぶようなことでもなければ起こりません。

• 起こりうる：起こらないという望みは、まだあります。

• 起こりそう：起こる方に賭けるでしょう。

リスクの影響度 これは、起こる可能性と結果の深刻さをもとにした、リスクの全体的なレベルです。リスクの優先順位づけや、危険信号の特定に使います。私たちのラベルは次のとおりです。

• 低：起こる可能性が低く、深刻な脅威にはなりません。

• 中：プロジェクトを遅らせる障害になります。

• 高：軽減策がなければ、プロジェクトが大きく軌道を外れると考えてください。軽減のために、すぐに対応が必要です。

4. プロジェクト振り返りレポート

プロジェクトが成功でも失敗でも、終了時には振り返りのミーティングを開くのが最善の方法です。振り返りミーティングとは、チームで集まってプロジェクトの成功と失敗を検証し、今後に生かす教訓を見つける場です。次のことを確認する機会になります。

• プロジェクトでうまくいったことのうち、今後も繰り返すべきことは何か。

• プロジェクトでうまくいかなかったことのうち、今後避けるべきことは何か。

• 次回は何を変えるべきか。

振り返りは、大規模なプロジェクトだけのものではありません。小規模なプロジェクトや継続中のプロジェクトにも同じように役立ちます。また、大きなプロジェクトが終わるのを待たなくても、チームの振り返りから価値を引き出せます。プロジェクトの開始時にスケジュールを組むときに、大きなマイルストーンの終わりごとに小さな振り返りを入れておきましょう。そうすれば、プロジェクトの進み具合がチームに伝わり、問題が大きくなる前に見つけやすくなります。また、チーム全員が成功するプロジェクトの運営に必要なスキルを身につけられるよう、書籍や講座をすすめるのにも最適なタイミングです。

プロジェクトの振り返りの進め方

ステップ1：ミーティング前にアンケートを送る。振り返りは通常1時間ほどのミーティングなので、チーム全員が発言できるよう、事前にアンケートを送ります。メンバーが事前にミーティングに備え、考えを整理する機会にもなります。ミーティングのアジェンダは、アンケートの回答をもとに、影響が最も大きかった項目を中心に組み立てます。振り返りアンケートのテンプレートに質問のリストを用意していますので、こちらからダウンロードできます。 ステップ2：ミーティングを準備する。振り返りは、時間を最大限に生かすため、普段のミーティングよりも体系的で正式なものにします。この段階で、中立的な司会者を選び、議論を進行して全員が礼儀を守りアジェンダに沿うようにします。基本ルールを決めておくのも効果的です。参考になる例を紹介します。

• 建設的に話し、批判のための批判はしない。問題を述べ、解決策に焦点を当てます。

• 個人攻撃をしない。責任を追及したり、犯人探しをしたりする場ではありません。課題を話し合い、今後の解決策を見つける場です。

• チームメンバー全員に意見を述べる機会を与える。

• お互いの意見を尊重する。

• 漏れなく取り上げる。プロジェクトが簡単だった理由、難しかった理由、楽しかった理由、つらかった理由を明らかにします。

• プロセスがうまく機能している点と、行き詰まる点を見つける。

• 成功を祝い、欠点を直す。

ステップ3：ミーティングのアジェンダを決める。事前にアジェンダをつくっておけば、チームが大きく脱線するのを防げます。アジェンダの例です。 プロジェクトの振り返り（15分） 当初のプロジェクトへの期待と成果物を簡単に確認します。これを見直すことで、成功と失敗を測る基準が定まります。 結果の振り返り（15分） 想定していた結果に照らして、うまくいったことと、そうでなかったことを明らかにします。 ステークホルダーの意見（30分） プロジェクトがそのように進んだ理由について、チームとクライアントに意見を述べてもらいます。 ステップ4：記録に残す。書記を決め、ミーティング中の主なハイライトをメモしてもらい、終了後にチーム全員へ送ります。一言一句を書く必要はありません。主なハイライトだけで十分です。

• プロジェクトのすべての課題

• プロジェクトのすべての成功

• 次のステップやアクション項目

ステップ5：メモから得られた知見を取り出す。振り返りで得た知見をもとにプロセスを変えないのであれば、ミーティングで全員の時間を使う意味がありません。実際に変えるために、ミーティング直後に時間をとってメモを見直し、大まかな結論をアクションプランに落とし込みましょう。メモを見直しながら、共通するパターンとその根本原因を見つけます。改善点がいくつか見つかったら、このプロジェクトで犯したミスを避けるために、次のプロジェクトで実施できる手順の変更をいくつか考えます。この作業のきっかけになる質問をいくつか紹介します。

• 絶対にやるべきことは何か。問題と、それがプロジェクトに与える影響を特定します。

• 今できることは何か。今後数か月で実施できる施策を考えます。

• 将来的に何をすべきか。今後3か月より先に実行できる施策を考えます。

最終的なアクションプランをチームに送り、フィードバックと賛同を得たうえで、最後に実行しましょう。