コミュニケーションミスを減らしてシステムトラブルを乗り越える

お金がない！1

ITに携わっているとシステムトラブルを避けて通ることはできません。システムトラブルと一言で言ってもハードウェア障害からオペミス、自分が作り出したバグまでその種類は多岐にわたります。障害が発生すると関係者はダウンタイムを極力抑えるために躍起になって対応するわけですが、トラブル対応で最も怖いのはその混乱の中で生み出される二次災害です。二次災害は三次災害を呼び、なんでもなかった小さな障害がユーザサービスに影響する大きな障害に発展してしまうこともあります。

二次災害を生み出してしまう原因も色々ありますが、個人的な経験上コミュニケーションミスは上位にランクインし、かつ防ぎようのあるものと感じています。しかし、コミュニケーションというものは複雑で、いざトラブルが発生してから「コミュニケーションミスを起こさないぞ！」と思ったとしてもそれはなかなか難しい。災害対策と同じで日頃からトラブルを想定して訓練し、また情報を収集・整理しておく必要があります。

コミュニケーションミスを減らしてシステムトラブルを乗り越えるためには、どんなヒューマンスキルを鍛える必要があり、どのように使っていけばいいか、個人的な経験から考えてみたいと思います。

日頃から養っておくもの

実際にシステムトラブルが発生したら

思い込みを排除し事実を伝える技術

例えば、前の処理でDBにデータ登録して後続処理でそのデータを使用するシステムにおいて、後続処理で「Record not found」というエラーが出ていたとします。あなたはそのデータ前の処理で登録されるべきデータであることを知っています。この時どのように報告しますか？

報告を受けた人はきっと前処理のログを調査し、前処理のプログラムを確認し、デバッグを行うでしょう。でもちょっと待ってください。本当に前処理に問題があったんでしょうか？後続処理のエラーメッセージは適切だという前提があったとしても、そこにある事実は「後続処理実行時にレコードが存在しなかった」というものだけです。前処理以外にも原因は考えられるんじゃないでしょうか。例えば…

本当に前処理に問題がなかったとすると、前述の報告ではこれらの可能性を潰してしまい、原因の特定を困難になってしまうでしょう。

そのようなことにならないよう、あなたは「後続処理実行時に前処理が登録するはずのレコードが存在しなかった。そのためにエラーが発生している。」のように、只々事実を伝えるべきなのです。その上で9割方前処理が悪いと思っているなら「まずは前処理のデータ登録に問題がなかったか調査しましょう。」と付け加えればいいんです。

ですが、いざトラブルが発生した時に「思い込みを排除して考えるぞ！」なんて都合のいいことはできないので、常日頃からバイアスを排除した会話を心がけて癖を付ける必要があります。

※こういうのを「認知バイアス」って言うんですかね？

相手が理解できるように伝える技術

じゃあ、もっとバイアスのかかっていない「プログラムAのn行目で『Record not found』エラーが発生しています！」でも良いんじゃないですかね？同じ仕事に従事している仲間ならこっちのほうが確実かもしれません。

「部長！！プログラムAのn行目で『Record not found』エラーが発生しています！」はどうでしょうか？「あー！お客様！！プログラムAのn行目で『Record not found』エラーが発生しています！」なら？

前処理が別ベンダーが保守するシステムだったらどうします？「別ベンダーさん！プログラムAのn行目で『Record not found』エラーが発生しています！調査してください！」って言いますか？

どれも通じないでしょう。相手や相手の立場によって業務知識量や持っているスキルが違うので、説明を抽象化したり言葉を選ばないといけません。後者の別ベンダーなら握ったインターフェース仕様をベースに会話しないと取り合ってもらえないでしょう。

そのためにはあらかじめ「この人にはこういう知識を持っている」「この立場の人にはこういう資料を使って説明する」ということを知っておく必要があります。でないと、あなたはトラブルの説明をするときに、自分のシステムの概要からトラブルの詳細に至る1から10までを説明して「この中であなたに引っかかる言葉を使って理解してください」と言わないといけないでしょう。

…実際にはそんなことにはならないですが、相手が報告内容を理解できないと逆に質問攻めにあってしまい、大幅に時間をロスしてしまいます。

ユーザサービスに影響を与えるポイントの知識

システムトラブルが発生したときに誰でも関心があるのは「サービスへの影響」です。トラブルを検知して直後の第一報であっても絶対に聞かれます。正確なところは後々調査するにしても、「たぶんある（ない）」くらいでもいいので大体のところは空で回答できるようにしたい。また、サービスへの影響有無によって次の作業が変わります。初動の遅れは後々響きますので、できるなら最短ルートを通っていきたいところ。

システムが出力するエラーの一覧とその原因を記憶しておければそれに越したことはありませんが、エラーメッセージは原因を示唆しているものが多いので、頑張って覚えることにあまり意味はないと思っています。人間の記憶力には限界がありますし。

それよりも、エラーが発生したときにどのような挙動をするシステムなのかを把握しておきたい。例えばエラーが発生したのがデータを一括更新するバッチなら…

また、普段コードを触ってるなら、例外処理に目を向けましょう。

結局のところ、対象のシステムに興味を持とう、ということなのかもしれません。

実際にシステムトラブルが発生したら

ここからは、実際にトラブルが発生したときに気をつける点について書きます。

まず報告する

とにもかくにもまず報告しましょう。隠したり、塩漬けにしても何も良いことはありません。直属の上司が捕まらないなら誰でもいいので情報を共有しましょう。

上で述べたように、第一報の際にサービスへの影響有無も添えると余計なやりとりを省くことができますが、わからない場合は影響有無を調べるのに時間を使うのはやめて、素直にサービスへの影響はこれから調査する旨を伝えましょう。

また、トラブルを発見した時刻と報告した時刻は記録しておきましょう。（後述）

とにかく記録する

いつ、何を見て、何をしたかを記録しましょう。特に時刻。ターミナルエミュレータによっては自動ロギングする機能を有しているものがありますので、普段からそういった機能を有効にしておきましょう。（例: Teraterm）

設定を変更したり、再起動したりした時間は後々重要になることがあります。必ず作業した時刻を記録するようにしましょう。

経過を報告・共有する際は、作業内容とともに作業した時刻も報告するようにします。

タスク保持者を明確にする

自分の手の届く範囲だけで解決できればいいですが、実際には別の領域や業務部門と連携することがほとんどでしょう。相手に何かを依頼するときは会話のキャッチボールを意識して不明瞭な言い方ではなく、明確に相手のタスクとわかるように伝えましょう。特に自分に否がある場合はお願いしづらいですし、ぼやかした言い方になりがちですが、後で問題となる方がお互いダメージがでかいので、ここは覚悟を決めましょう。また、「謝ったら負け」みたいな考えは一文にもならないです。個人的な経験ですが、「謝ったんだからお前の責任だ！」と言ってくる人を見たことないです。気持ちよくタスクを受け取ってもらうためにどんどん謝っていきましょう。

また、自分が保持しているタスクも積極的に公開していきましょう。同じタスクを他の人が重複して作業してしまうリスクが減ります。それに、他の人にタスクを依頼する上で、全体像を見渡せるようにすることは礼儀だと私は考えています。

ひとりで対処しない

トラブル対応はスピードが物を言うのでパニックになります。どんなに自分では冷静だと思っていても平常時のそれとは異なります。ひとりで対処しないようにしましょう。

自分のミスを指摘できるだけの知識を持つ人とダブルチェックしながら作業するのが一番いいと思うんですが、そういう人がいない場合はリーダーや上司などの自分より権限を持っている人にお願いするのがいいでしょう。最悪責任を押し付けることができます。

そういう人もいない場合でも、とにかく誰かにダブルチェックをお願いしましょう。説明しながら作業をすることで、自分自身の確認になりますし、声に出すことで冷静になれます。

最悪声に出せばもう何でもいいので、オフィスに誰もいないときのためにあらかじめコウペンちゃんやﾌﾞﾙｽｺを配備しておくのも手です。

その他のテクニック

訂正する際は間違いを明示する

トラブル対応の混乱の中で間違った情報を伝えてしまうこともあります。訂正報を出すことになりますが、その時に正しい情報「だけ」を再送するのはやめましょう。受け取った相手は誤情報に対してプラスアルファの追加の情報と勘違いしてしまう恐れがあります。

メールなら「いつ送ったメールのここが間違っていたのでこう訂正」とか「いついつ送ったメールの情報はすべて忘れて今回のメールを正としてほしい」と誤情報を明示しましょう。

あと、「【最新】」「【最終版】」みたいなタイトルはやめましょう。「【訂正報】」がいいです。

謝りたくない、誤りを認めたくない人がやりがちなイメージがあります。

「電話で会話した件です」で牽制する

電話や1対1のチャットの会話の続きをオープンなチャットやメーリングリストでやると、横から余計なツッコミが入りがちなので「XXさんと電話で会話した件です」で他を牽制するといいです。あとで情報共有する必要はありますが、現在進行系でトラブルが発生してる状況下では余計な説明作業は入れたくないですし。

なんでこんな記事書いたの？

しらねー。別に何かの発表に使ったりするわけでもないんですよね。「俺はこんな視点を持ちつつ運用してるよ」って言いたかったのかもしれない。

  1. https://ja.wikipedia.org/wiki/%E3%81%8A%E9%87%91%E3%81%8C%E3%81%AA%E3%81%84!#%E3%82%B9%E3%82%BF%E3%83%83%E3%83%95 ↩︎