不具合を直す順番を決めたら、原因に辿り着くのが速くなった

• 手当たり次第だと、同じ場所を何度も見る
• 範囲を半分ずつ狭める
• 変更を1つずつ戻すのが、最も確実

表示が崩れたとき、思いついた場所から直していた。順番を決めてから、原因に辿り着く時間が短くなった。

手当たり次第の問題

以前のやり方は、こうだった。

• 怪しそうな場所を直す
• 直らなければ、別の場所を直す
• 何を試したか分からなくなる

3つ目が最悪だ。同じ場所を何度も見ることになる。

最初にやること

いまは、必ずこの2つから始める。

• いつから起きているか確認する
• 直前に何を変えたか思い出す

2つ目で解決することが多い。原因は、たいてい直前の変更にある。

範囲を狭める

原因が分からないときは、半分ずつ絞る。

• 変更した箇所を、半分だけ戻す
• 直れば、戻した側に原因がある
• 直らなければ、残した側にある
• これを繰り返す

この方法なら、10個の変更でも、3〜4回で特定できる。

1つずつ戻す

変更が少ないときは、1つずつ戻している。

• 最後の変更を戻す
• 直らなければ、その前を戻す
• 直った時点の変更が原因

確実だが、数が多いと時間がかかる。5個以下なら、この方法が速い。

記録しながら進める

何を試したか、書きながら進めている。

• 試した内容と、結果を1行ずつ
• 戻した変更を記録する
• 途中で中断しても、再開できる

3つ目が重要だ。翌日に再開すると、何を試したか忘れている。

切り分けに使う道具

手で戻す以外にも、切り分けを速くする方法がある。

• 開発者ツールで、指定を一時的に無効にする
• ファイルを変更せずに、効果を確かめられる
• 当たりが付いてから、ファイルを直す

2つ目が効率的だ。ファイルを直して読み込み直す往復が無くなる。画面上で切り替えて、即座に結果を見るほうが、試す回数を増やせる。当たりが出てから、その1行だけファイルに反映する。調整にかかる時間が数分で済むようになった。

環境を切り分ける

自分の環境だけの問題か、確認している。

• 別のブラウザで見る
• 別の端末で見る
• キャッシュを消して見る

3つ目で解決することがある。直っているのに、古い状態が表示されている。

頼むときの形

自分で切り分けてから、頼んでいる。

次の不具合を調べています。

【症状】（何が起きているか）
【いつから】（直前の変更）
【切り分け】
- Aを戻すと直る
- Bを戻しても直らない
【環境】（版、ブラウザ）

原因として考えられるものを挙げてください。

切り分けの結果を渡すと、推測の範囲が狭まる。

再現できるか確認する

直す前に、確実に再現できる手順を作っている。

• どういう操作をすると起きるか、手順にする
• 何度やっても同じ結果になるか確認する
• 再現しないなら、条件が他にある

3つ目で何度か助かった。たまにしか起きない不具合は、別の条件が絡んでいる。再現手順が作れない状態で直しても、直ったか判断できない。確実に起こせるようになって初めて、直したことを確認できる。

直す前に理解する

原因が分かっても、すぐ直さないようにしている。

• なぜそれが原因か、説明できるか確認する
• 説明できないなら、別の原因かもしれない
• 偶然直っただけ、ということがある

3つ目が怖い。理解せずに直すと、同じ問題がまた起きる。

他の人が触っている場合

自分以外も触る環境では、切り分けが難しくなる。

• いつ、誰が、何を変えたか分からない
• 変更の記録が無いと、追えない
• 記録を残す仕組みが要る

3つ目を整えてから、調べる時間が大幅に減った。変更の履歴があれば、不具合が出た時刻の前後を見るだけで候補が絞れる。記録が無い環境では、推測で探すしかなくなる。切り分けの前提として、記録が要る。

直した後

直った後の作業も決めている。

• なぜ起きたか、記録に残す
• 同じことが起きないよう、手順を見直す
• 関連する箇所も確認する

2つ目が再発を防ぐ。直すだけだと、同じ失敗を繰り返す。

まとめ

• 最初に「いつから」と「直前の変更」を確認する
• 範囲を半分ずつ絞ると、少ない回数で特定できる
• 試した内容を書きながら進める
• 切り分けの結果を渡すと、推測の範囲が狭まる
• なぜ原因なのか説明できないなら、直ったとみなさない