問題のトラブルシューティング — Patter

The case

何かがおかしい。何がおかしいのかはっきりわからない、どのくらい深刻かもわからない、そして次に何をするかで、問題が解決するか1時間を無駄にするかが決まる。トラブルシューティングがうまくいかないのは、問題を解決する能力が低いからではなく、最初に何が起きているかを正確に説明するための時間を取らないからであることがほとんどです。

本能的に、すぐに何かを試し始めてしまいます。再起動する。再インストールする。症状を十分に言語化する前に検索する。運よくうまくいくこともあります。でもうまくいかないとき、すでに不明確だった状況に新たな変数を持ち込んでしまっています。

トラブルシューティングのルーティンは、一貫した入口を持つ決定木に過ぎません。問題を正確に説明し、再現を試み、何が変わったかを確認し、意図的に検索し、最善の選択肢を順番に試す。分岐ごとに前に進むか、ステップを飛ばすかを判断します。最後まで解決できなければ引き継ぐ — ただし、役に立つ情報を添えて。肩をすくめるだけではなく。

ルーティンがもたらすもうひとつのものは、終了条件です。それがなければ、トラブルシューティングは使える時間をすべて埋めるまで広がり続けます。ステップ #12 の判断ポイントが問いかけます。これはまだ自分の時間を使う価値があるか、それとも今は誰か別の人の問題か、と。

問題のトラブルシューティング

実行した手順、期待していた結果、実際に起きたことを書き出します。
リストを正確にたどって、問題を再現してみます。再現できない場合は @1 に戻ります — リストがまだ不完全です。
最近変更したことを確認します。ソフトウェアのアップデート、新しい入力、設定変更など、何でも。何も変更していない場合は @7 に進みます。
変更を元に戻します。以前の状態またはバージョンに戻します。元に戻せた場合は @2 に戻り、問題がまだ存在するか確認します。
変更を切り離します。変更した箇所だけを無効化・切断・削除してテストします。他のことをする前に、その変更が原因かどうかを確認することが目的です。解決した場合は @13 に進みます。
変更を再適用します。原因であることが確認できました。メモしておきます。@13 に進みます。
エラーメッセージや症状を正確に検索します。エラーがある場合は一字一句そのままコピーします。曖昧な検索では曖昧な結果しか得られません。
検索結果で最もよく出てくる解決策をメモします。頻度は出発点であり、証明ではありません。
試そうとしている情報の日付を確認します。 5年前の解決策はもう適用できない場合があります。
最も信頼できる解決策を試します。解決した場合は @13 に進みます。
次に信頼できる解決策を試します。解決した場合は @13 に進みます。
続けるか、引き継ぎにするかを決めます。どのくらい時間をかけましたか？どの程度重要な問題ですか？引き継ぐ場合は @14 に進みます。続ける場合は @10 に戻ります。
解決した方法を記録します。 1文で。忘れます。そして必ずまた同じ問題に当たります。
引き継ぐ人のために状況をまとめます。試したこと、除外できたこと、原因として考えられること。きれいに渡します。

自分流にアレンジ

最も重要なステップは #13 です。そして、ほとんどの人が飛ばすのもこのステップです。問題を解決することと、解決策を記録することは別の作業です — 後者があるからこそ、6ヶ月後に同じことで40分を失わずに済みます。1文で十分です。

ステップ #10 と #11 は、より長く繰り返せるループのプレースホルダーです。問題によっては、何かがうまくいくまで10回試す必要があることもあります。必要に応じてステップを追加し、#12 で続けるか引き継ぐかを判断してください。

#14 のエスカレーションは真剣に考える価値があります。試したこと、除外できたことを明確に伝えることは、引き継ぐ人にとって本当に役立ちます。「壊れています」だけでは役に立ちません。

特定の分野 — ソフトウェア、ハードウェア、機器 — でこのルーティンを使う場合は、中間のステップを普段の診断手順に合わせてカスタマイズしてください。構造はそのままで、詳細は自分で埋めていきます。