「障害報告がわかりにくい!!」と言われたら取り入れたいストーリーのフレームワーク

障害報告で遭遇する残念な状況

何いっているか、わからないんだけど・・・

で、どんな影響があるの?

で、この先結局どうなるの?

 障害報告の場で、残念ながらかなりの確率で遭遇する言葉です。障害報告する側は、問題の暫定対処とともに恒久対処を考えながら、ITのことがわからない人たち向けに報告書を作成しなければならないという難易度の高いタスクを並行でこなさなければなりません。

 やっと作った報告書をこんな形で一蹴されると、モチベーションが下がりますよね。多くのケースは睡眠不足というフィジカル的に辛い状態で報告しているため、元気・やる気・勇気がだいぶ削られます。

わかりにくいと言われてしまう原因はシンプル

 心無い言葉を浴びせる人のせいにしたところで解決はしません。他責にしたところで、何も改善には向かわないのです。何より、構図的には障害を起こした側が説明責任を果たさなければならない。ここはぐっとこらえ、何が問題なのか原因を探っていきます。

 「わかりにくい!」と言われるほとんど全ての障害報告は自分視点になっていることが原因です。報告を受ける側の知りたいことが書かれていないんですね。仮に書かれていたとして、作成した人はわかるが、読み手には非常にわかりにくい構成になっているのが原因です。

 よくある自分視点の障害報告の例はこんな感じです。

A. 発生経緯が、順を追って長々と(丁寧に)記載されている
B. システム側の内容ばかりで、業務影響が書いていない
C. これまでのことだけ記載されている

A. 発生経緯が、順を追って長々と(丁寧に)記載されている

 一番よくあるケース。「何言っているか、わからないんだけど」に高確率で遭遇できます。気持ちはわかります。ログを取得して解析し、仮説を立てて一つ一つ検証していたりするので、頭の中は障害解析だらけになってしまっています。

 そんな状態で障害報告を書くと、どうしてもこれまでやってきたことばかりを書いてしまう。さらにはその報告書は、ITの専門用語だらけ。これが「何いっているかわからないんだけど・・・」の原因。

 残念ながら、障害報告を受ける側は、その頑張りは実は興味がない。冷たいようですが、まずはこれを理解する必要があります。そう、世の中は冷たいのです。

 ものすごく大変なことをやっているので書きたくなる気持ちはわかります。がんばってやってきたことを丁寧に書きたくなる気持ちはわかります。その「丁寧」が実は自己満足であることを理解しましょう。

B. システム側の内容ばかりで、業務影響が書いていない

 情シスならではの考慮点。結局、システム部門以外の部署は、システムに興味ないのです。システムの先にあるエンドユーザーにどういった影響があるのかをみんな知りたいのです。業務部門から、信頼を勝ち取れるかどうかは、業務影響があるのか。ある場合はどんな影響なのか。ここまで踏み込んで説明ができるかどうかにかかっています。

<情シスおさえどころ>

 実際に、業務影響まで踏み込んでいる情シス部門は少ないです。我々の仕事はここまでと線引きする情シスは本当に多い。でも、やっぱりもう一歩踏み込みたい。業務部門と早い段階で連携の体制構築ができるかどうかが、「無能な情シス」と言われるかどうかの分岐点です。

 障害での悪手の典型が、悪い情報をなかなか関係各所に伝達せずに、結果サプライズになること。どうせ色々と言われるのです。早い段階で情報を共有し、そして障害対策チームに業務部門を巻き込んでおく。おすすめです。

C. これまでのことだけ記載されている

 役職者に報告する時に、絶対忘れてはならない点。ある程度の役職の人たちは「意思決定」をするのが役割です。つまりこの先どうするべきかを判断する。その際に、今後どうなるかといった「見込み」が報告書にないと、ほとんど多くの人はイライラします。「で、この先結局どうなるの?」につながる。

 過激なことを言えば、究極的にはここだけの報告でも十分だったりします。「来週解決します」「まだ調査中で原因不明です、明日の17時に報告をします」などなど。とにかく未来にフォーカスをする。

 過去は変えられないですが、未来はある程度コントロールすることができます。それを責任をもって行うのが役職者。役職者が味方になってくれるのかは、実はあなたの報告次第だったりするのです。

意外に思うかもしれないが、障害報告はストーリーなのだ!!

ストーリーのフレームワーク

 障害報告はストーリーだ・・・と言われてもピンとくる人は少ないかも知れません。でも、ストーリーなんです。なぜか?理解してもらう相手側のことを考えた時、ストーリーでの説明だと頭に入りやすいんです。

 なんでもそうですが、何かを理解するには順番があります。その順番をストーリーというフレームワークにしておくということですね。報告書を書く側も、この枠にそって書けば旅行記にならず、余計なストレスから解放されます。

<おすすめしたいストーリーのフレームワーク>

  1. どんなことが起きているの?
  2. 増えているの?減っているの?
  3. 業務影響は?
  4. いま何をしているの?
  5. 今後の見通しは?

ストーリーにしたときの読み手の思考回路

 障害報告を受ける側は前提知識がありません。詳細はわからないが、「何か問題が起きている」と言うことだけはわかる。そして、解決しなければならないというプレッシャーにさらされます。

 ❶〜❸で基礎情報・事実をインプットし、❹で現在の状況、❺で未来を伝えるのが大枠の流れです。

❶どんなことが起きているの?

 報告を受ける側がまっさきに知りたいこと。それが、「どんなことが起きているのか」です。いちばんの基礎情報とも言えます。多くの報告書が経緯ばかりを説明してしまうのですが、経緯なんかは究極的には後回しでよい。

 自身が聞く立場になったら理解できるはずです。皆さんの家族が「救急車で運ばれました」と言われたら、まずは何が起きているか知りたいはず。にもかかわらず、「2日前にこんなことがありました、その次にあれやこれら。で、こんなことをして・・・」と経緯を長々と聞かされたら、「いや、そんなことより何が起きているか教えてよ」と言ってしまうはず。

❷増えてるの?減ってるの?

 発生した障害が増加傾向にあるか・減少傾向にあるかを把握することは、意思決定者が障害対応の優先度を決める上で重要な要素です。優先度を決める時は「発生確率 x 影響度」の掛け算。もし、発生はするがなぜか減少傾向にあり、実は半年に一回しか起きな内容であれば、そんなに急がなくても良いと言う判断になるかも知れません。

 新しいシステムを導入したときなどは、障害が複数発生します。対応するリソースは限られます。その際に、この情報をしっかりと押さえておくのは、障害をうまくコントロールする上での重要な要素となります。

❸業務影響は?

 事業会社の情シスならではの要素。システムのことばかり伝えても、聞いている側はかなりの確率で理解できないでしょう。

 経営層であれば、売上にどう影響があるのか?バックオフィス部門であれば、業務にどんな影響があるのか?何が発生したかが理解できたら、次に知りたいのはそれぞれが管掌する領域にどんな影響があるかなのです。

 ここまで踏み込んで報告する情シスは案外少ないかもしれません。ただ、これが情シスの価値。ベンダーは出来ない領域。ぜひ、業務影響にまで踏み込んで報告をしたい。

 なにより、優先度を考える上での要素は「発生確率 x 影響度」です。この2つは報告を受ける側は必ず知りたい情報ですのでセットで報告がおすすめです。

❹いま何をしているの?

 さて、ここまで相手が理解できたら、次に知りたいことは、「いま、なにしているの?」です。おそらくここは多くの方が得意なはず。細かくなりそうなのであれば、結論や要点だけを書き、詳細は別紙や添付を活用しましょう。

❺今後の見通しは?

 多くの報告書で記載がなく、かならず突っ込まれる重要な項目。多くの人が、「まだわからないから」で記載すらしないことが多い。

 分からないのであれば、「TBD」でよいのです。重要なのはわからなくても、この項目自体は必ず入れておくということ。できるのなら、見通しの報告ができそうなタイミングはいつになるのかを仮で記載しておけばよりGoodです。

 障害報告を受ける側が一番知りたいのは「いつなおるの?」です。記載がない場合は、必ずこの質問が飛んできます。さて、何が起こるか?

 あの手この手で説明がはじまるのですが、多くの場合はその場の思いつき。結果、全部言い訳に聞こえてしまう。わからないのであれば「確認中」で十分です。言い訳より、全然良い。正面突破が基本。

実際の障害報告でのフレームワークの使い方

 さて、ここで多くの障害報告を書いてきた方は、「原因」「暫定対処」「恒久対処」といったこれまで障害報告で書いていた内容はどこに入るのか、疑問を持たれるかと思います。答えは簡単、それらをこの❶〜❺の小項目の中に入れてやればいいのです。

例えば❶〜❺のタイトルを障害報告向けに変えて

❶全体概要
  ・事象
  ・経緯
  ・原因

❷障害発生の推移

❸影響
  ・業務影響
  ・システム影響

❹対応・対策状況
  ・暫定対処
  ・恒久対処

❺今後の見通し

 みたいにしてやると、ストーリーの中に必要項目が入ります。他にもみなさんが普段報告で使われている項目があるはずです。基本的にはどこかに入るはずですので、ぜひ使ってみてください。

組み合わせたい、その他の合わせ技

 そのほか、障害報告での小技を。品質がグッと上がりますよ。

「添付 or 別紙」を活用しよう

 多くの人が甘く考えている。そして、本来添付や別紙でいい内容を、障害報告のメインに持ってきてしまって、旅行記が始まるのです。特に注意したいのが経緯を書く時。何時何分に・・・みたいな細かい情報は必ずあった方がいい。ただ、本編にはサマリで十分。細かいのは、添付資料か別紙にするとすっきりします。

悪いことほど手段を選ばず先に報告

 情報が揃ってからでないと報告してはならないと勘違いしている人がいますが、悪い情報ほど手段を選ばず関係者に報告。これ、鉄則。

 「いろいろと聞かれたら答えられないから」。よく聞く言葉ですが、「その点は現在調査中です」で、問題ないです。だって、わからないものはわからない。

 コツがあるとすれば、先に「速報で原因等は調査中ですが、影響が大きくなりそうなので報告です」とそえて報告すれば良い。それで文句言う上司の場合は、その上司に問題ありです。

グラフを活用

 ぜひ、グラフを活用しよう。よく使うのは3つ。それぞれ使い分けをちゃんと理解したい。

棒グラフ:データの大きさを比較したい時
折れ線グラフ:棒グラフとごっちゃになる人が多いが、時系列での変化を見る時がこちら
円グラフ:全体に占める割合をみたい時

この3つを理解しているだけでも、随分と報告書の品質が上がります。