進捗報告のフォーマットを変えただけで、クライアントの満足度が上がった話

きっかけは、定例ミーティングでクライアントの担当者がこう言ったことだった。

「すみません、ここ……今日の話のどこに書いてありますか？」

僕がその週、夜なべして書いたA4で2枚の進捗レポートを指でめくりながらの質問だった。書いてある。ちゃんと2ページ目の真ん中に書いてある。でも見つけられていない。そのとき初めて、「このレポート、もしかして読まれてないのでは」という疑いが頭をよぎった。

恥ずかしながら、当時の僕は「情報量が多いレポート = 丁寧な仕事」だと思い込んでいた。その思い込みが崩れた日から、報告フォーマットを作り直すまでの話を書いておきたい。同じように「頑張って書いてるのに伝わらない」と感じている人に、何か残ればと思う。

毎週2枚のレポートが、実は冒頭しか読まれていなかった

入社2年目で、初めて自分が窓口の案件を持たせてもらった。週次の進捗報告も僕の担当だった。

張り切った僕は、とにかく全部書いた。今週やったタスク、来週やるタスク、消化した工数、残課題、依頼中の確認事項、細かい技術メモ……見出しを並べて、漏れがないように埋めていく。A4で2枚はいつもの分量だった。「ここまで書いておけば後で揉めない」という防衛本能もあったと思う。

【Before：当時の週次レポート構成】

1. 今週の作業実績（タスク7件・箇条書き）
2. 来週の作業予定（タスク6件・箇条書き）
3. 工数実績（計画 vs 実績の表）
4. 課題・懸念事項（5〜6項目）
5. 確認依頼事項（3項目）
6. 補足メモ（技術的な細かい話）

→ A4 約2枚。とにかく「全部入り」

冒頭のあの質問のあと、勇気を出して先輩に相談した。「レポート、ちゃんと読まれてる感じがしないんです」と。先輩はしばらく僕のレポートを眺めて、こう言った。

「これさ、お客さんが一番知りたいことが、どこにある？」

言葉に詰まった。全部大事だと思って書いていたから、「一番」がどこかなんて、自分でも決めていなかった。先輩いわく、忙しい担当者がレポートを開いて読むのはせいぜい最初の数行で、そこで「で、順調なの? ヤバいの?」が分からないと、あとはもう斜め読みになる、とのことだった。

正直なところ、ショックだった。2枚びっしり書く労力の大半が、読まれずに流されていたことになる。

「結論 → 根拠 → 次のアクション」の3段に削った

先輩に教わったのは、拍子抜けするくらいシンプルな型だった。「結論を先に、根拠を次に、最後に次のアクション」。それだけ。

最初は半信半疑だった。こんなに削って大丈夫なのか、情報が足りないと怒られるんじゃないか、と。でも試しに翌週から構成をまるごと入れ替えてみた。

実際に書き直すと、こんな見た目になった。

【After：3段構成にしたレポート（冒頭）】

■ 結論
　今週は予定通り。リリース判定に影響する遅れはありません。

■ 根拠
　・管理画面の一覧/検索を実装完了（予定どおり）
　・帳票出力の仕様で1点未確定あり（後述）
　・工数は計画比 -0.5人日（前倒し気味）

■ 次のアクション
　・来週：帳票テンプレートの実装に着手
　・お願い：帳票の項目順、5/2(金)までにご確認ください

詳細なタスク一覧や工数表を消したわけではない。それは下の方に「補足」として残して、読みたい人だけ読めるようにした。順番を変えて、「結論を一番上に置いた」だけ。やったことはほぼそれだけなのに、定例での反応が明らかに変わった。担当者が冒頭の3行を見て「あ、順調ね。じゃあ帳票の件だけ確認しますね」と、こちらが一番話したかった論点にすぐ入ってくれるようになった。

数字より「リスクの見える化」のほうが刺さった

3段構成にして、もう一つ気づいたことがある。最初、僕は「根拠」のところに工数の数字をたくさん入れていた。計画比マイナス何人日、進捗率何パーセント、みたいに。エンジニアとしては、数字で示すのが誠実だと思っていた。

でも、クライアントの担当者が前のめりになる瞬間は、数字を出したときじゃなかった。「来週、帳票の仕様確認が遅れると、テストの開始が1週間ずれます」と書いたときだった。

今思えば当たり前なのだけど、進捗率90%と言われても、相手にとっては「で、何かまずいの?」が分からない。一方で「ここが詰まると、あなたの予定にこう響きます」と書くと、自分ごととして反応してくれる。数字は状態の説明で、リスクは相手への影響の説明なんだと、このとき腹落ちした。

そこから「リスク」を一行で添えるようにした。書き方はこんな感じに落ち着いている。

【リスクの一行表記（テンプレ）】

[懸念] 帳票の項目順が未確定
  影響 → 確定が来週にずれると、結合テスト開始が約1週間遅延
  対策 → 今週中に仮の項目順で実装を先行、確定後に差し替え

ただ、白状すると、このリスクの「重大度」をどう見極めるかは、正直まだ感覚に頼っている。本当は発生確率と影響度でスコアリングして優先度を決められるとよくて、先輩からも「そろそろリスク管理表を軽量でいいから持っておくといいよ」と言われている。ここは明確に改善の余地があると思っていて、今まさに自分の宿題になっている。

「最近のレポート、分かりやすい」と言われて分かったこと

フォーマットを変えて1か月くらい経った頃、定例の雑談で担当者がぽろっとこう言った。

「最近のレポート、分かりやすくて助かってます」

地味なひと言なんだけど、僕にとってはけっこう大きかった。あんなに時間をかけて2枚書いていたときには一度も言われなかった言葉が、削って3段にしたら出てきた。情報を足したからではなく、減らしたから伝わった、というのがなんとも皮肉で、でも腑に落ちる出来事だった。

このとき分かったのは、進捗報告は「自分がどれだけやったかの証明」じゃなくて、「相手が次の判断をするための材料」なんだ、ということ。主語が自分ではなく相手だった。当時の僕のレポートは、今振り返ると完全に「僕が頑張った記録」になっていた。読み手が何を知りたいかではなく、自分が何を書き残したいかで作っていた。

先輩に「お客さんが一番知りたいことはどこ?」と聞かれて詰まったのは、要するに主語が入れ替わっていたからだったんだと思う。

振り返って

たかがレポートのフォーマット、されどフォーマットだった。中身の作業は何も変えていないのに、伝え方の順番を変えただけで、クライアントとの会話の質がここまで変わるとは思っていなかった。

正直、今でも油断すると情報を盛りたくなる。不安だと、つい「あれも書いておこう」と手が動く。でもそのたびに、あの「どこに書いてありますか?」の質問を思い出して、一番上の3行に何を置くかをまず考えるようにしている。

次にやりたいのは、さっき書いたリスクのスコアリングをちゃんと型にすることと、この3段フォーマットを案件をまたいで使えるテンプレとして社内に置いておくことだ。僕が異動しても次の担当が同じ品質で報告できるようにしておきたい。属人化させないところまでやって、ようやくこの学びが仕事として完成する気がしている。