【PMノウハウ】トラブル報告

本番稼動しているシステムにトラブルが発生した時。
また、システム開発プロジェクトで、進捗が大きく遅延した時。
プロジェクトにはトラブル報告がつきもの。　（って、無いに越したことはないけど）

トラブル報告のしかたも、実はPMのノウハウとして非常に重要。
というのも、報告の内容や報告の仕方によって、問題が大きくなったりするからだ。

たとえば、本番システムの夜間バッチ処理にトラブルが発生したとする。

①『夜間バッチでトラブルが発生しました。』

報告内容がこれで終わりだと、報告を受けた側は、？？　となる。
はっきりいって、”こいつ大丈夫か？”と疑われる。


②『夜間バッチのXXX処理でトラブルが発生し、XXXXデータの更新ができていません。』

①よりは、情報量が増え、何が起きたかがはっきりしてる。
【具体的な事実の報告】が重要、だが、事実だけを報告しても、聞く側は納得しない。
なぜなら、本当に知りたいことは、起きたことではなく、いつ復旧するか、どういう影響があるか？
という内容だからだ。
原因も、今後の見通しもない、事実だけの報告は、報告を受ける側からすると不安が強まるだけになる。また、報告を受けても何も判断ができない。”だから、どうしろ？”と思われる。

③『現在、XXXを対象に原因と影響範囲を調査中、XXXXには調査結果を報告します』

さらに追加して、現在の実施作業を報告する。これも必要、だがこれだけでもだめ。
”じゃあ、その間、どうなるの？”　

④『影響拡大を防止するため、XXXを実施。これにより影響は拡大せず（一時対応）、本格対応としてXXXXに着手、XXXXｘに対応完了予定』

現在実施している作業（というか着手すべき作業）として
・原因調査
・影響範囲調査
・被害拡大防止の一時対応内容、完了時期
・本格対応の内容と完了時期
・既に発生した影響の解消

これぐらいを報告するのが必要。

要は、何が起きているか、はもちろん報告するが、それ以上に、いつまでに解消するのか、起きた影響は解消されるのか？　といった点が、システムの利用者＝報告先にとって知りたい事であるはず。

要は、自分がわかっていることだけを報告するのではなく、報告を受ける側が知りたいこと、報告の後に意思決定が可能、または意思決定をしてほしい事に関する情報を報告するのである。

報告する内容が不足すると、逆に不安を抱かせることになる。
不安はさらに不安を呼び、問題を大きくする。
 適切な報告を行う事が、信頼を得ることにもなる。信頼されることで、周りの理解・協力も得やすく、問題終結が早まることにもつながる。

トラブル報告そのものも、トラブル対応の一環であり、重要なコミュニケーションである。
ただ言えばいい、というものではなく、よく考え、戦略的に実施すべき。