（2）問題の原因と影響範囲を特定する

　バグを直そうとするとき、「この現象が出ているなら、問題の箇所はあそこかな」と当たりがつけばそれに越したことはない。その箇所を調査して修正すればよい。だが中には、バグの原因がなかなか特定できないこともある。

　そんなときは「問題の切り分け」を行う。

　具体的には、「この箇所は犯人ではない」という箇所を除外していき、最終的な原因を探り当てていく。やり方はこうだ。ソフトウェア全体をまず2つに分け、調査を始める。一方に原因がないとわかったら、犯人は残りの一方にいることになる。

　次に、犯人がいるほうをさらに2つに分け、同じことを繰り返していく。すると問題がある箇所が絞り込まれていき、最終的には原因を特定できる。

　経験の浅いエンジニアは「とにかくサーバーが頻繁に落ちるんです！　大問題です！」と言ってとり乱す（設定を1ヵ所間違えているだけだったり、バグを1つ直せば済む話だったりすることが多い）。

　あるいは「おかしいな、動かないはずないんです。昨日までは動いていて、その後何も変えていないはずなのに！」と言って途方にくれる（「昨日から何も変えていない」は、大体の場合何かしらの変更が入っている）。

細かく切り分けて考える

　現実世界の問題についても、プログラムのバグ修正と同じことが言える。例えば、「ＥＣアプリを作ったが、あまりユーザーに利用してもらえなかった」ときのことを考えてみよう。

　商品詳細ページまでは行ったが、そこから「買い物かごに入れる」人が大幅に少なかったのであれば、「商品の見せ方に問題がある」、もしくは「商品そのものが来てくれた人の求めているものではなかった」と考えられる。

「買い物かごに入れる」人は多かったが「購入する」ところで一気に離脱してしまったのであれば、決済画面の設計に問題があったのかもしれない。

　例えば、そこでログインを求められて面倒になった、あるいは読み込みに時間がかかって閉じてしまった。こうした問題があるのかもしれない。

「どこまで何人くらいの人が行ったのか」「どこで何パーセントの人が離脱したのか」

　これらを分析し、離脱率の高いポイントを絞り込んで直していけばいい。もちろん、何もかもがこんなに簡単かつ綺麗に解決するわけではない。しかし問題が起きると、人間は問題の原因と関係ないことまで含めて、事態を大きくとらえてしまう傾向がある。

　だからトラブルが起きたらプログラミングの例のように、とにかく問題を切り分けて、原因を特定していくと意外と簡単に解決する。

　最後に申し添えておくと、私がデータベースを消してしまった事例は、バックアップをとってくれていた人がいて、大ごとにはならずに済んだのだった。