報告は簡潔に | A Day In The Boy's Life

A Day In The Boy's Life

とあるエンジニアのとある1日のつぶやき。

かれこれ3ヶ月ぐらい悩まされたトラブルがやっと本日解決し、その報告を上長に報告しました。

メールでの報告を行ったのですが、この内容に四苦八苦。


報告を行う際に、対象が誰かによって、どのレベルの事実を報告すべきかが異なってきます。例えばトラブル時の報告として


・ 結果(現状、問題が解決したのか否か)

・ 原因

・ 対応(経緯)

・ 懸案事項(出た結果において、今後問題等があるのか)


項目としては、こういったことですがその内容が対象によって異なってきます。

例えば「原因」では上長やプロジェクトマネージャー(PM)に対し「Aというシステムに問題がありました」と報告し、現場の作業者、プロジェクトリーダー(PL)などには「Aシステムのエラー制御の一部に欠陥があり、○という問題が発生しました」という報告をします。

後者の説明をPMにしても、「で?」と言われる場合があります。


PMなど責任者は、「問題があったのかどうか?」「結果としてどのような影響が誰にあったのか」という大きな視点での情報を望みます。

エラー制御に問題があろうがなかろうが、その問題が顕著化し誰にどれ位の問題があったのかを知りたいわけです。


一方、現場レベルの人としては影響度はさほど気にしません。

その対応を行うかどうかの判断は、(影響度の大きさにもよりますが)その責任者が行えばよくその決定に従って、動くわけです。

現場は動く際に、問題の詳細を知る必要があります。

ですので、細かな内容が必要になるわけです。

報告する際の対象が知りたい情報を見誤ると、非常に判りづらい説明になってしまいます。

この辺の判断が難しいわけですね。


報告は簡潔に。

単純に文章量を減らすと言うわけではありません。

報告する対象がほしい情報を、分かりやすく説明する事です。

簡潔な内容ほど書くのが難しいと改めて感じた日でもありました。


※ 私自身が説明を行うために非常に参考にしたのが、「説明術 」でも紹介した「分かりやすい説明の技術」と言う

  本です。

  相手が納得するための説明として、何故そのような事が必要なのか理解できながら身につけることができると

  思います。



「分かりやすい説明」の技術 最強のプレゼンテーション15のルール ブルーバックス/藤沢 晃治
¥840
Amazon.co.jp