トラブルシューティングに悩む人たち
それなりの経験を積んでいるはずなのに、なぜかトラブルシューティングが苦手、という人が周りにいませんか。
トラブルの原因を見つけられない。あるいは場当たり的な対処をしてしまう。開発はできるけど運用ができない。手戻りが多い。
そんな人。
今回は、そんな人たちの行動を探ってみましょう。
1.作業は速い
無能なわけではありません。むしろ作業は速いです。
速いけれども、対処方法そのものが間違っているため手戻りが発生することが多いです。
そして、手戻りで本人が意気消沈。悪循環です。
2.事実誤認
本人から聞いた話と、われわれが認識している話とで、食い違いが発生することが多いです。
クライアントからは「そんなこと言ってない!」と言われ、同僚からは「その話ほんとう?」と疑念を持たれ、本人が大混乱。
そして、本人に自覚がない場合が多いです。やっかいです。
3.再現性がない
事実を誤認しているのであたりまえのことですが、再現性がありません。
再現性がないため、問題が複雑化…しているように本人には見えます。
4.どうしてこうなった
なにが問題でしょうか。
事実誤認が問題なのは明らかですが、なぜ事実を誤認してしまうのか。
それは、事実は情報というパーツ(断片)の集合体、というのが起因しています。
事実には、クライアントから見えている情報、クライアントからしか見えない情報、エンジニアにしか見えない情報、いろいろあり、すべてを見渡せる人はいません。
それらを集めてようやく事実として組み上がります。
トラブルシューティングが特に苦手な人は、部分的にしか情報を集めない(一方的な情報しか集めない)傾向があり、ここで事実誤認が起きます。
そしてさらに、本人は情報をすべて集めたと自信を持っていることです。
なぜでしょうか。
こういった人の多くは、自分で推測した情報をパーツとして事実を組み上げてしまうからです。
確たる情報と、推測したあいまいな情報が混ざり合った、信頼性の低い事実。それをもとに対処するため、ポイントがブレたり、手戻りが発生してしまいます。
クライアントからは「解決して欲しいのはそこじゃないんだけど!」と言われたり、同僚からは「現状認識が甘い人」と評価を下げてしまうことでしょう。
5.どうしたらいいか
5-1.推測かどうかみきわめる
メモをとるときに、それが推測かどうか、という情報を添えるといいでしょう。簡単なマーク(シンボル)でもつけるといいかもしれません。
具体的には、集めた情報なのか、まだ集めていない情報なのかかどうか、です。
確たる情報=収集済みの情報
推測=まだ集めてない情報
推測ということは、まだ情報が足りていない、パーツが不足しているわけです。収集済みかどうかさえわかれば、情報収集だけを誰か他の人に頼むこともできます。
5-2. 誰から見た情報か
クライアントから見える範囲の情報なのか、エンジニアから見える範囲の情報なのか。あるいはベンダーに依頼しないとわからない情報なのか。あるいはソフトウェアのログか。
人によって見える景色(情報)が違うため、どこから仕入れた情報なのかは重要になります。
例えば、Webサイトがエラーで閲覧ができなくなったとします。
クライアントからはエラーかどうかしか見えません。
インフラエンジニアからもサーバ負荷が上昇していることしか見えません。同時接続数を調整してもさほど効果がありません。
ここで、開発エンジニアが新バージョンのバッチプログラムを試験投入したという情報があれば、そのプログラムを停止するだけで済んでしまうわけです。
誰から見た情報かを把握していれば、一方的な事実かどうか判別しやすいと思います。
5-3.ログ
ログ(記録)はとても重要な、確たる情報です。システムから見た情報、といってもいいでしょう。ログからアタリをつけて、関係者に必要最小限のことをヒアリングする人もいるほどです。
ログがない、ということも、ときに重要になります。
なにかしらの問題を見つけるのではなく、あるはずのものを見つける、というアプローチも時間短縮にひと役買うこともあるでしょう。
5-3.時系列
付せんにメモをすれば、貼ったり剥がしたりが簡単です。
また、推測だけ違う色の付せんにするのもいいでしょう。
誰から見た情報か、情報を書き込んだ付せんを時系列に並べます。
おそらく最初は、部分的にごっそりスペースが空いていたり、部分的に推測が多いでしょう。が、それでも問題ありません。
どんな情報が足りていないかをはっきりさせることが目的です。
そうやって、じょじょに推測付せんを減らしていけば、自然と解決策が見つかるはずです。
6.メモの例
収集した日時 2020年◯月☓日 xx:xx
誰からの情報か ◯☓さん
情報源の立場 Webユーザー
どう見えたか Webブラウザでxxxエラーが表示された
7.まとめ
トラブルシューティングは地道です。地味です。難しそうです。
ですが、事実を積み重ねるだけで解決策が見えてくるので、意外にシンプルです。
参考になれば幸いです。
技術とともにあらんことを。