サイトの表示がおかしい。「たぶんCSSだな」と当たりをつけて直す。変わらない。「じゃあJavaScriptか」と直す。変わらない。気づけば2時間、あちこち触った結果、最初よりおかしくなっている・・・。
推測で当てにいくと、たいていこうなります。この講のゴールは、当てにいくのをやめて、原因を"挟み撃ち"で追い詰める手順を身につけることです。地味ですが、第3部でいちばん時給の高い技術です。
ブレーカーにたとえます。
家中の電気が突然消えたとき、電気に詳しくない人でも対処できるのはなぜでしょう。分電盤を開けて、落ちているブレーカーを探し、部屋ごとのスイッチを1つずつ上げてみる。台所のスイッチを上げた瞬間にまた全部落ちたら、犯人は台所の何かです。電気の知識はゼロでも、範囲を半分ずつ削っていけば、原因の住所は特定できる。
不具合の切り分けも、これと同じ発想でやります。コツは、原因を当てにいかないこと。代わりに、「どちら側か」を確かめる質問を繰り返して、範囲を狭めます。
第1講の地図を思い出してください。画面の向こうには、客席（自分のブラウザ）・ホール（通信）・厨房（サーバー側）がいました。おかしいとき、まず知りたいのは犯人の名前ではなく、犯人がどの区画にいるかです。
どの一手も、原因を1ミリも推理していないことに注目してください。それでも3手で、容疑者の住む区画はかなり絞れます。絞れてから初めて、その区画の中を調べる。推理は、範囲が狭くなってからやるものです。
壊れていない今日のうちに、3手の"素振り"をしておきます。自分の一枚（またはサイト）で。
ばかばかしいほど簡単ですが、これで「いざというとき、この3手が打てる」状態になりました。3手目のために、触る前にコピーを取る癖（第10講の演習でやったやり方）も、ここで正式に習慣にしてください。本格的な"戻せる仕組み"は次の第13講でやります。今日は手動のコピーで十分です。
そのまま貼って使えます。
1つ目の「確認しやすい順に」は、第1講でも出てきた言い回しです。可能性の高い順ではなく、確認しやすい順。安い検査から受けるのが、切り分けの鉄則です。
複数の箇所を、同時に直すこと。
急いでいるときほどやりがちです。「CSSも怪しいし、この行も怪しいから、両方直して読み込み直そう」。それで直った場合、どちらが効いたのか分かりません。直らなかった場合はもっと悪くて、2つの変更が絡み合い、症状そのものが変わってしまう。ブレーカーを3つ同時に上げたら、どの部屋が犯人か永遠に分からないのと同じです。
ルールは第10講と同じです。1回に1箇所。直したら確認。効かなければ戻してから次。切り分けの速さは、手数の多さではなく、1手ごとの答え合わせの確かさで決まります。