問題が起きると、できるだけ早く原因を見つけたくなります。直前に変えたことや目についた出来事があると、「きっとこれが原因だ」と考え、その前提で対処を始めることもあります。
ただ、最初に思いついた説明が正しいとは限りません。原因を決めつけたまま複数の対策をすると、本当に確認すべき場所が見えにくくなります。
そんなときは、確認できた事実と、自分がそこから考えた推測をいったん分けます。そのうえで、推測を確かめるための確認を1つだけ行います。
正解を急いで出すより、「今わかっていること」と「まだ確かめていないこと」を分けることが、原因を絞る出発点です。
確認できた事実を書く
見たこと、起きた時刻、実際の結果など、確かめられる情報だけを先に並べます。
推測を別に置く
「おそらく」「きっと」と考えている原因候補を、事実とは別のものとして扱います。
1つだけ確かめる
原因候補を強める、または外せる確認を1つ選び、結果を見て次へ進みます。
この記事のタグ
最初に思いついた原因をいったん保留にします
問題が起きた直後は、直前の変更や目立つ出来事を原因と結びつけやすくなります。しかし「その前に何かが変わった」ことと、「それが原因だった」ことは同じではありません。
- いつ、どこで問題が起きたか
- 実際に何ができなかったか
- 問題が起きる前と後で何が変わったか
- 同じ条件で毎回起きるのか、時々なのか
最初の段階では原因を当てるより、確認できる材料を増やすことを優先します。
たとえば「設定を変えたあと動かなくなった」は確認できる経過ですが、「設定変更が原因で壊れた」はまだ推測を含みます。
確認できたことと推測していることを分けます
手元の情報を「確認済み」と「推測」に分けます。自分で見た、記録がある、同じ条件で再現したものは確認済みへ置きます。
確認できた事実
記録、時刻、操作、結果など、その場で確かめられる内容です。
自分の推測
「たぶん原因はこれ」という、まだ未確認の説明です。
不足している確認
推測が合っているか判断するために、まだ足りない情報です。
推測を消す必要はありません。仮の原因候補として残し、確認対象へ変えます。
原因候補を確かめる確認を1つだけ決めます
推測が複数あると、あれもこれも同時に変えたくなります。しかし複数の条件を一度に動かすと、直ったとしても何が影響したのかわかりにくくなります。
「新しい手順に変えたから遅くなった」と考えても、まずは変更前の条件へ一部だけ戻して比較します。戻しても遅いなら、別の原因候補を調べます。
一度に道具、担当、手順を全部変えないことで、何が結果に影響したかを追いやすくなります。
確認は原因を証明するためだけでなく、「この候補ではなさそう」と外すためにも役立ちます。候補を1つ減らせれば、それも前進です。
結果を見て事実の欄だけ更新します
確認を1つ行ったら、その結果を新しい事実として追加します。予想と違っていても、元の推測へ合わせて解釈し直さないことが大切です。
- 確認前に決めた条件だけを変えましたか？
- 結果は再現できましたか？
- 最初の原因候補は強まりましたか、弱まりましたか？
- 新しく確認すべき事実が見つかりましたか？
- 次の確認を1つに絞れますか？
結果がはっきりしない場合は、対策を増やすのではなく、比較できる条件をそろえます。
困っている問題を1つ選び事実を3つだけ書きます
大きな問題を完全に分析する必要はありません。今気になっている問題を1つ選び、原因を書く前に、確認できた事実を3つだけ並べます。
今日のポイント
- 実際に起きたことを3つ書く
- 「たぶん原因はこれ」を別に1つ書く
- 事実と推測が混ざっていないか見る
- 推測を確かめる確認を1つ決める
- 確認後の結果だけを新しい事実として追加する
原因を急いで決めるより、間違った候補を1つずつ外せる方が、結果として解決へ近づきやすくなります。
原因を当てるより確認できる材料を増やします
最初の仮説を持つこと自体は悪いことではありません。注意したいのは、その仮説を確認前から事実として扱うことです。
確認済みの事実と推測を分け、推測を確かめる行動を1つだけ選びます。結果を新しい事実として積み重ねれば、原因候補は少しずつ絞られていきます。
原因を判断する前の最終チェック
- 確認できた事実を先に書きましたか？
- 推測を事実と分けて扱っていますか？
- 一度に複数の条件を変えていませんか？
- 次に確かめることを1つ決めましたか？
- 確認結果を新しい事実として残しましたか？
