報告って難しいですよね。
みなさんは、次のようなことを言われた経験がありますか？
- 何が言いたいのか分からない
- 長くて読む気にならない
- で？
思い出すだけで腹が立ってきました。
でも、自分の報告に問題があるのかもしれません。
良い報告と悪い報告の違いはどこにあるのでしょうか？
私はこんな風に考えています。
- 良い報告は、読み手の知りたいことを教えてくれる。
- 悪い報告は、書き手の言いたいことしかない。
少し言い換えると、「書き手の言いたいことが読み手に伝わるようにするため、読み手の役割や状況を考え、何を報告すれば良いか考えられている」ことが良い報告になります。
では、読み手の知りたいことを整理してみましょう。
- 問題の有無
- そのように判断した根拠
- 次のアクション．
- 定量的データ（日付、問題数など）
早速、これらの情報を入れて報告してみます。
◼️報告書(6/29)
6/24にAさんがX機能を作成中に、Bさんと認識が違うことが分かり、その日の内にメールで連絡をもらいました。
Aさんはこのように言っており、Bさんはこう言っているとのことでした。
私としてはBさんの方が正しいと思いましたが、6/27に3人で話をしました。
そうすると、実はAさんの方が正しいことが分かりました。
この結果、２日の遅れが出たため、6/28からスケジュールの見直しを行っています。
見直し作業は、6/30には完了する見込みです。
今後このような認識違いが起きないようにこういう事を行なっていきます。うーん。確かに知りたいことは含まれているけど、、
どこが悪いのでしょうか？
伝える順番が悪いのと余計な情報が多いと感じますね。
つまり、時間的に正しい順番は、知りたい情報ではないということです。
そして、必要がない情報を削って、要約する力が求められます。
よく言われることですが、最初に結論を伝え、その後に細かい話をしていきます。
では、先程の報告を見直してみましょう。
◼️報告(6/29)
報告開発者間で認識の齟齬があり、2日の遅れが出ています。
問題は解決済みですが、スケジュールの調整が必要になりそうです。
6/30 15:00までに見直し後のスケジュールを提示します。
認識のズレが起きた原因は、次の通りです。
開発プロセスを変更し、本日6/29から適用しています。
・原因1
・原因2いかがでしょうか？
少し分かりやすくなりましたか？
自分の伝えたいことが、必ずしも相手の知りたいことではありません。
その点を理解し、相手のことを常に考えて報告しましょう。
