エンジニアとして日々の業務に勤しんでいると、原因が全く見えない「謎のバグ」に突き当たることがあります。ログを精査し、ソースコードを何度読み返しても正体がつかめない時、私たちはつい「きっとあれが原因だろう」といった先入観（バイアス）に囚われて、問題の本質を見失ってしまうことがあります。実は、このような「思い込みとの戦い」と「データの力による解決」というドラマが、今から170年以上前のロンドンで繰り広げられました。1854年、ロンドンのソーホー地区を襲ったコレラのパンデミックから、医師ジョン・スノウは、データの可視化で人々を救ったのです。そこで今回は、ジョン・スノウの疫学調査を「世界最古のシステムデバッグ」と見立てて、ログの可視化、バイアスの排除、そして根本原因分析（RCA）といった、現代のエンジニアが複雑な不具合を解決するために不可欠な思考プロセスの重要性について考えてみたいと思います。
1. コレラ地図事件のざっくり把握
1-1. 1854年ロンドンで何が起きたのか
19世紀半ば、ロンドンは急激な都市化の真っ只中にありました。しかし、インフラ整備は追いつかず、衛生環境は極めて劣悪な状態だったといわれています。1854年8月、ロンドン中心部のソーホー地区にあるブロード・ストリート（現在のブロードウィック・ストリート）周辺で、突如としてコレラが発生しました。
コレラの流行は凄まじく、発生からわずか3日間で百数十人が死亡し、その後1週間で住民の約4分の3が地区から逃げ出すほどのパニックに陥ったようです。わずか10日間で数百人が命を落としています。地域によっては人口1000人あたり12.8人が亡くなるという、壊滅的な「破壊」でした。住民たちは、原因不明のまま次々と倒れていく人々を目の当たりにし、不可解な障害が連鎖しているような恐怖に包まれていました。
The 1854 Broad Street cholera outbreak（Sky HISTORY TV Channel）
1-2. 現代疫学の父「ジョン・スノウ」
この未曾有の危機に立ち上がったのが、医師ジョン・スノウ（スノ－とも表記）でした。彼は1813年生まれの医師で、麻酔医として確固たる地位を築いていました。ヴィクトリア女王のお産の際にクロロホルム麻酔を担当するなど、王室からも信頼される専門家であり、麻酔という当時の最先端技術の特性を数値化して扱う「データ志向の技術者」としての側面も持ち合わせていました。
スノウは以前のコレラ流行時から患者の症状を詳しく観察しており、呼吸器ではなく消化器に異常が出ている点に着目していました。そこから「原因は空気ではなく水にあるのではないか」という仮説を抱くようになっていました。スノウは机上の空論ではなく、徹底した観察と数字に基づく推論を重視し、現場の数字を積み上げることで真実を証明しようと考えたようです。このように徹底したデータ志向の姿勢こそが、後にスノウが「現代疫学の父」と呼ばれる理由の一つとなりました。
1-3. 当時の常識「空気感染説」
スノウが立ち向かわなければならなかった最大の壁は、当時の医学界や行政における支配的な考え方であった「瘴気説（Miasma Theory）」でした。これは、汚物や腐敗した有機物から発生する「悪い空気（悪臭）」を吸い込むことで病気になるという説です。
現代のエンジニアリングに例えるなら、これは「ネットワークが遅いのは、なんとなくサーバの負荷が高いからだろう」といった、根拠のない、しかし強力な「アンチパターンな前提」に近いものです。
当時は「すべての悪臭は病気（の元）である」と断言されるほどこの説が信じられていたため、行政による対策も「空気を綺麗にする」という方向に偏り、結果として水の汚染対策が後回しにされる、誤った意思決定がなされていました。スノウは、瘴気説という名の強固なバイアスを打破しなければなりませんでした。
1-4. 井戸ポンプの柄を外すまで
スノウは自身の「水伝染説」を証明するため、ブロード・ストリート周辺を一軒一軒訪ね歩くという、非常に泥臭いフィールドワーク（聞き取り調査）を開始します。牧師ヘンリー・ホワイトヘッドも独立した調査を行い、その結果はスノウの仮説を確認するものとなり、後に両者の証拠が揃うことになりました。その後、スノウはホワイトヘッド牧師の協力を得ながら、どの家で誰が亡くなり、どこの井戸水を使用していたのかを丹念に調べ上げました。
調査の結果、死亡例の多くがブロード・ストリートにある特定の公設井戸ポンプを利用していたことが判明します。スノウはこの調査結果を元に地域の委員会を説得し、委員会がそのポンプの使用を禁止するため、ポンプのハンドルを取り外しました。すると、驚くべきことにコレラの流行は急速に収束へと向かったのです。これは、データを収集して仮説を立て、具体的な修正アクションによって問題を解決するという、完璧なトラブルシューティングのプロセスでした。
2. コレラ地図は何を「可視化」したのか
2-1. 死亡地点をプロットする
スノウが作成した地図の革新性は、亡くなった人の住所を地図上に黒い棒グラフのような点としてプロットした点にあります。住所リストという表形式のデータを眺めているだけでは、それは単なる数字の羅列に過ぎません。しかし、それを地理的な空間に配置した瞬間、データは明確な意味を持ち始めます。
地図上には、ブロード・ストリートのポンプを中心に、死者の分布が密集している様子が克明に浮かび上がりました。この手法は、現代のデータサイエンスにおけるクラスタリングの先駆けといえます。特定の地点（エンドポイント）に異常が集中していることを視覚的に示すことで、スノウは「どこで何が起きているか」という分布の偏りを直感的につかみ、原因究明の出発点を得ていました。
2-2. 水ポンプとの距離と境
スノウの分析は単なるプロットに留まらず、住民が「どのポンプを利用するのが最も近いか」という境界線を考慮したものでした。地図を見ると、ブロード・ストリート・ポンプの利用圏内において、死亡例の密度が他のどのポンプ利用圏よりも圧倒的に高いことが一目で分かりました。
これは現代のシステム構成図において、トラフィックがどのロードバランサーを経由し、どのサブネットを通っているかを可視化する作業に似ています。物理的な距離だけでなく、インフラ（ポンプ）の利用圏という構造を地図上に重ね合わせることで、問題の発生源を論理的に囲い込むことに成功したのです。
2-3. 表形式だけでは気づけないパターン
スノウのケースでは、なぜ地図という形式が必要だったのでしょうか。それは、人間が表形式のデータから空間的なバイアスやパターンを見抜くのが非常に苦手だからです。リスト形式の報告書では、通りの名前は分かっても、路地の繋がりやポンプへのアクセスのしやすさといった構造的な偏りが見えてこないようです。
可視化によって、直感に訴えかけるパターンが明らかになりました。例えば、ポンプのすぐ近くにある醸造所の作業員は、水ではなくビールを飲んでいたために一人も死んでいなかったという例外も、地図上の空白地帯として際立って見えました。こうした「なぜここでは起きていないのか？」という視点は、現代のデバッグにおいても極めて重要なヒントになります。
2-4. 「地図がすべてを解決した」は神話？
ここで注意すべきなのは、地図さえ描けば魔法のように問題が解決したわけではないという点です。実は、スノウが地図を完成させたのは流行が収束し始めた後のことでした。地図は、すでに彼が持っていた確信を、行政や他の医師たちに納得させるための「説得のツール」であり、自身の思考を整理するための「フレームワーク」でもあったのです。
現代のインシデント対応でも、ダッシュボードを見て原因が即座に分かることは稀です。日頃の運用で得た「土地勘」と、丹念な調査によって導き出された仮説を、可視化によって補強し、チーム全体の共通認識にする。この「プロセス」こそが、スノウが残した真の功績なのではないでしょうか。
3. エンジニア視点で読む「コレラ地図＝デバッグ」
3-1. ログとインシデントを「地図化」する
現代の複雑化したマイクロサービスやクラウドネイティブな環境において、障害が発生した際に「どこで何が起きているか」を即座に把握することは容易ではありません。
ジョン・スノウがコレラで亡くなった人の発生地点を地図にプロットしたように、私たちエンジニアも、エラーログやインシデント情報をシステムの空間や構造の中にマッピングするような発想が求められています。
例えば、分散トレーシングツールを用いて、リクエストがどのサービスを、どのような順序で通過しているかを可視化することは、まさに「デバッグの地図」を作る作業に他なりません。単一のログファイルを眺めるのではなく、サービス間の接続構造（トポロジー）の上にエラー発生ポイントを重ね合わせることで、特定のサービスがボトルネックになっているのか、あるいは特定の通信経路でのみ問題が発生しているのかが、スノウの地図のように浮き彫りになります。
3-2. メトリクスのクラスタリング
スノウが死者の分布から密と疎を読み取った手法は、現代のオブザーバビリティ（可観測性）におけるメトリクス分析とも共通しています。システムに異常が発生した際、私たちは「どのクラスタで」「どのリージョンで」異常が集中しているかを確認しています。
もし、特定の箇所だけでエラーが急増し、他が正常であれば、それはシステム全体のバグではなく、その箇所特有の障害である可能性が高まります。スノウが「ブロード・ストリート・ポンプの周辺に死者が密集している」と気づいたように、メトリクスをクラスタとして捉えることで、障害の輪郭がクリアになっていきます。
逆に、似た条件でありながらエラーが起きていない「孤立したノード」に注目することも、調査対象を絞り込むための重要なヒントになります。異常を「集中」と「孤立」という観点で読み解くことで、ランダムなエラーと体系的なエラーを区別できるのです。
3-3. 空気感染説＝バイアスの罠
根本原因分析（RCA）を行う際、最大の敵となるのが「バイアス（思い込み）」です。1854年のロンドン市民が「悪い空気さえ綺麗にすればコレラは防げる」と思い込んでいたように、エンジニアも「昨日デプロイしたあのコードが原因に違いない」といった先入観に支配されがちです。
これを「思い込みのアーキテクチャ」と呼ぶことができます。自分たちが構築したシステム構造に対する過信や、過去の成功体験に基づいた決め打ちが、真の原因への到達を妨げます。RCAとは、目に見える症状の背後にある「単純かつ再現性のある原因構造」を特定することですが、組織の定説や「説明しやすい物語」に縛られてしまうと、本質を見失います。スノウが瘴気説という強力なバイアスと戦ったように、現代のエンジニアも事実が何を語っているかというデータに立ち返り、既存の仮説を一つずつ冷徹に棄却していく勇気が必要です。
3-4. 「水源」を疑う
スノウが突き止めた真犯人は、個々の家庭の不摂生や空気の汚れではなく、公共の「水源（井戸）」という共通インフラでした。エンジニアリングにおいて、これは共有ライブラリ、データベース、認証基盤、あるいは共通のネットワーク設定といった「全サービスが依存する基盤」に相当します。
アプリケーション層でのエラーが散発している時、それらを個別に修正しようとするのは、コレラ患者を一人ずつ治療するのと同じで、対症療法に過ぎません。もし複数の異なるサービスで同時に問題が発生しているなら、それぞれのコードを調べる前に、まずは共通の水源を最優先でチェックすべきです。根本原因分析の本質とは、表面的な症状を引き起こしている汚染された水源を見つけ出す作業に他なりません。
3-5. ポンプの柄を外す
スノウが行った「ポンプのハンドルを外す」という決断は、非常に興味深い教訓を与えてくれます。これは現代でいえば、不具合のある機能を無効化する、あるいは特定のトラフィックを遮断するといった暫定対処にあたります。
当時の行政にとって、井戸を止めることは住民の生活に支障をきたすリスクのある決定でした。しかしスノウは、完璧な証拠（水中の細菌の直接証明）が揃うのを待つのではなく、さらなる被害を防ぐためにデータに基づいた迅速なアクションを促しました。
この「被害の連鎖を断ち切るための最小限のアクション」を特定する発想は、現代のインシデント対応における平均修復時間を短縮するための極めて重要な戦略です。暫定対処で被害を食い止めた上で、落ち着いてから下水道システムの改善のような「恒久対策」に取り組むという二段階のアプローチが、システム運用においても肝要かもしれません。
4. 現場で使えるデータ可視化
4-1. まず「どの地図を作るか」を決める
デバッグを開始する際、闇雲にログを検索する前に、まずは現状把握に最適な「地図」は何かを考える必要があります。スノウが物理的な地図を選択したように、問題の種類に応じてプロットすべきキャンバスを正しく選択することが解決への第一歩となります。
システム全体を把握したいなら「サービス構成図（トポロジー図）」が有効ですし、ユーザーの体験を追いたいなら「ユーザーフロー図」の上でのエラー分布が役立ちます。ネットワーク遅延であればレイテンシのヒートマップ、メモリリークであればヒープ使用状況の時系列グラフといった具合に、どの次元でデータを可視化するかを戦略的に決めることで、パターンが浮かび上がりやすくなります。
4-2. データ収集の徹底
スノウが高い評価を受けているのは、単に地図を描いたからだけではありません。その地図を完成させるために、地元の牧師の助けを借りながら住民一軒一軒を訪ね歩いた、執念ともいる「聞き取り調査（データ収集）」があったからです。
エンジニアも同様に、自動化されたログだけでなく、必要に応じて手動でのトレース取得、詳細なメトリクスの収集、そして関係者へのヒアリングを徹底する必要があります。分散トレーシングを用いて「一つのリクエストがどのコンポーネントを経由したか」を追跡することは、スノウが個々の住民の生活動線を追ったことと同じです。「データが足りない状態で推論しない」という鉄則を守り、泥臭い調査を積み重ねることが、可視化された時の説得力を生むのです。
4-3. 可視化→仮説→検証→アクションのループ
スノウの疫学調査は、データ収集から対策までの一連のループを回すプロセスでした。これはそのまま現代のデバッグ手順（SOP）として適用できます。
1. 可視化
異常をグラフや地図にプロットし、パターンを見つける。
2. 仮説
「このコンポーネント（水源）が原因ではないか？」という仮説を立てる。
3. 検証
仮説を裏付けるために追加のデータを集めたり、実験（再現テスト）を行ったりする。
4. アクション
仮説が正しければ、修正を適用する（ポンプの柄を外す）。
重要なのは一度の分析で答えが出ると期待せず、反例を探しながら仮説を磨き、このループを高速で回し続けることです。PDCAにも似たこのサイクルをチーム文化として定着させることが、場当たり的な対処からの脱却に繋がります。
4-4. 少数の「反例」に注目する
スノウの調査で特に特筆すべきは、「ポンプの近くに住んでいるのに、なぜかコレラにかからなかった人々」のような反例に注目した点です。独自の井戸を持っていた醸造所の労働者が発症しなかったという事実は、水源が原因であるという仮説を最強の証明へと高める鍵になりました。
システムトラブルにおいても、「同じバージョンを使っているのに、なぜこの環境だけ発生しないのか？」という例外ケースの分析は極めて重要です。設定の差分や利用パターンの違いを丁寧に洗い出すことで、多数派のパターンだけでは見えてこない真の条件を特定できることが少なくありません。
4-5. 事後レビューとしての「疫学レポート」
インシデントが収束した後の事後レビューには、スノウのような地図的観点を取り入れてみてはどうでしょうか？ 単に発生した事象を時系列に並べるだけでなく、システム構成図の中でどこに障害の波及が広がっていったかを視覚的に記録に残すのです。
スノウが調査結果を詳細なレポートとしてまとめ、それが後の疫学の基礎となったように、よく書かれたインシデントレポートは組織の貴重な知識資産となります。どのように仮説を立て、どのようなデータでそれを検証したのかという思考のプロセスを可視化して共有することで、将来の同様の障害を未然に防ぐための、強靭なエンジニアリング文化が育まれます。
5. まとめ
ジョン・スノウの「コレラ地図」は、データによってバイアスを打破し、問題の核心を射抜くための普遍的な思考プロセスを提示しています。エラーを適切な地図にマッピングし、共通インフラという「水源」を疑い、仮説検証のループを回す。このスノウの手法は、現代の複雑なシステムデバッグにおいても驚くほど有効です。可視化を武器に論理的な分析を繰り返す「コレラ地図的思考」をチームに根付かせ、データに基づいた信頼性の高いトラブルシューティングを目指しましょう。
