今日もお疲れ様です。
ちょっとした現場あるあるですが、よければ軽く読んでいってください。
突然電話がかかってきて、
「トラブルが発生しました」
とだけ伝えられることがあります。
少し慌てた様子で、そのまま話が進んでいくこともあります。
気持ちはよく分かるのですが、このままだと状況の整理が難しくなってしまいます。
なので、まずは一呼吸おいて、お名前から確認するようにしています。
誰からの連絡なのかが分かるだけでも、その後の対応が進めやすくなります。
トラブル対応では、最初の情報整理でほぼ流れが決まります。
トラブル対応、まず何を確認する？
トラブル対応のときに、まず確認しておきたいもの。
それが「商品コード」や「受注番号」です。
専門用語では「一意」や「主キー」と呼ばれることもありますが、トラブル対応では対象となるデータを特定するための重要な情報です。
商品コードや受注番号が分からないと、どのデータで問題が起きているのかを絞り込むことができません。
主キーというのは、他と重複しない番号のことです。
だからこそ、「どのデータなのか」を特定するための手がかりになります。
この番号が出てこないだけで、調査が止まってしまうことも珍しくありません。
実際の現場では情報が揃っていないことも多い
とはいえ、最初から必要な情報が揃っていることはあまりありません。
むしろ、
「トラブルが発生しました」
という連絡だけが来ることの方が多かったです。
受注番号が分からない。
発注番号が分からない。
商品コードが分からない。
そんな状態から調査が始まることも珍しくありません。
そのため、まずは相手の話を聞きながら、こちらはメモを取る準備をします。
そして、
・受注番号はあるか
・発注番号はあるか
・商品コードはあるか
・いつ発生したのか
など、必要な情報を少しずつ整理していきます。
最初から情報が整理されていることを期待するのではなく、整理されていない情報を整理することもトラブル対応の仕事の一つだと思っています。
なぜコードや番号が重要なのか
原因を調べていくうえで大事なのは、
「該当するデータにいかに早くたどり着けるか」
です。
商品コードではなく商品名を教えてもらった場合、似たような名前の商品が並んでしまい、探すのに時間がかかることがあります。
その点、商品コードや受注番号であれば対象のデータにピンポイントでたどり着くことができます。
だからこそ、最初に確認する価値がある情報になります。
さらに言うと、もう一つメリットがあります。
コードや番号が分かっていれば、情報を探し回る必要がありません。
多くのシステムでは、商品コードや受注番号を入力するだけで該当の画面にそのままたどり着けることが多いです。
一発で目的の画面に行けるかどうかで、対応のスピードはかなり変わってきます。
事象整理は5W2Hで考える
事象を整理するときによく使う5W2Hですが、トラブル対応の場面でも役立ちます。
WHEN：いつ
→ トラブルが発生した時間
WHERE：どこで
→ どの受注データか、どの商品コードか
※実際のところ、商品名よりも商品コードの方が重要だったりします。
WHO：誰が
→ 誰が操作したのか、誰が確認したのか
※対象者を特定することで見えてくることもあります。
WHAT：何が起きたのか
→ エラーなのか、表示不具合なのか、処理が止まったのか
この4つが揃うだけでも、原因の切り分けはかなり進みます。
推理小説や推理ゲームに少し似ている
私が5W2Hを意識するようになったきっかけは、推理小説や推理ゲームだったと思います。
犯人を探すためには、
・いつ起きたのか
・どこで起きたのか
・誰が関係しているのか
・何が起きたのか
といった情報を整理していきます。
トラブル対応も少し似ています。
情報が揃っていない状態から必要な情報を集めて、原因を絞り込んでいく。
そう考えると、原因究明は推理に近い部分があるのかもしれません。
原因と対応はここからが本番
WHY：なぜなのか
→ 何をしたらこうなったのか
→ 集まった情報をもとに原因を探っていく部分です
HOW：どのように
→ どのように解決するか
→ ここからが私たちの役割です
HOW MUCH：どれくらい（コスト）
→ プログラムの改修や対応にどれくらいお金がかかるのか
→ 必要に応じて判断していくポイントです
実際には、
「直せるけど費用が高い」
というケースも少なくありません。
追加開発費用が大きくなる場合は、運用で回避する方法を選ぶこともあります。
技術的にできるかどうかだけではなく、費用対効果も考えながら判断していく必要があります。
まとめ
トラブル対応で大事なのは、
「とりあえず動くこと」
ではなく、
「正しく整理すること」
です。
商品コード・受注番号でデータを特定する。
5W2Hで事象を整理する。
この2つが揃うだけで、対応のスピードも精度も大きく変わってきます。
プログラムの不具合だったこともありますし、操作ミスだったこともあります。
体感としては半々くらいです。
ただ、どちらが原因だったとしても最初にやることは変わりません。
必要な情報を集めて整理することです。
原因究明というと難しく聞こえますが、実際には情報整理が8割だと思っています。
慌てて結論を出そうとするよりも、
「いつ」
「どこで」
「誰が」
「何をしたのか」
を整理した方が、結果的に早く解決できることが多いです。
ちょっとしたことですが、現場ではしっかり効いてくるポイントです。
関連記事
情報整理というと難しく聞こえるかもしれませんが、考え方としては推理小説や推理ゲームに近い部分があります。
実際に以前読んだ『薬屋のひとりごと』2巻でも、
・情報を整理する
・状況を把握する
・限られた情報から原因を探る
という流れが印象に残りました。
今回のトラブル対応の考え方にも通じる部分があるので、興味のある方はこちらもご覧ください。
👉 『薬屋のひとりごと』2巻レビュー｜情報整理と責任の線引きが印象に残った話
「もしこの記事が役に立ったと感じたら、SNSでシェアしていただけると嬉しいです！」
その際、インスタグラムやX（Twitter）で**「フォロー」や「シェア」**してもらえると、次の記事を書く大きな励みになります！
他にもSEの裏話や便利なガジェットやちょっと一息つけるようなコラムも用意していますので、ぜひご覧ください。
コメント