海外でC# / WPFを武器に設計・開発をしている僕が、現場で体験した「冷や汗」の記録をシェアするこのブログ。今回は、エンジニアなら誰もが恐れる「バグ」の中でも、特にたちの悪い**「ロジックボム（論理爆弾）」**についてお話しします。
それも、悪意のあるウイルスではなく、自分たちの「完璧なはずの設計」と「厳格すぎるマニュアル」が作り出してしまった、静かなる爆弾の話です。
悲鳴を上げない「完璧な」監視システム —— 静かなるバグの胎動
ヨーロッパの風に吹かれながら、今日もMVVMパターンと格闘しているC#エンジニアです。皆さんは「ロジックボム」と聞いて何を想像しますか？ 映画に出てくるような、カウントダウンと共にデータが消去される物々しいコードでしょうか。僕が今回直面したのは、もっと地味で、もっと残酷なものでした。それは**「すべてが正常に見えるのに、中身だけが死んでいる」**という、エンジニアにとって最悪の悪夢です。
鉄壁のフェイルオーバーが仇になる時
舞台は、僕が担当していた「エネルギーインフラの監視システム」の刷新プロジェクト。C#で書かれたバックエンドが、膨大な数のパワーコンディショナからデータを吸い上げ、WPFで構築されたダッシュボードにリアルタイムで表示するという、極めて高い可用性が求められるシステムでした。
海外の、それも社会インフラに関わるような現場では「何が起きても止まらないこと」が絶対条件です。そのため、システムは二重、三重のフェイルオーバー構造を持っていました。メインの処理が止まればサブが即座に立ち上がる。heartbeat（心拍）確認用のパケットが途絶えれば、アラートが鳴り響く。
「これで安心だ」と、誰もが思っていました。そう、あの「静かなる爆弾」が爆発するまでは。
異常なしの「異常」
ある火曜日の午後でした。ダッシュボードに並ぶWPFのグラフは、どれも美しい曲線を描いていました。ステータスランプはすべて「緑」。ログを確認しても、エラーを示す赤文字（Fatal）は一行もありません。
でも、僕は自分の感覚に違和感を覚えました。データの更新頻度が、微妙に遅い。特定のデータソースだけが「5分前の値」で止まっているように見えたのです。しかし、システム全体の監視モニターは「正常稼働中」を誇らしげに表示し続けていました。
調査の結果、判明したのは**「親切すぎるエラーハンドリング」による無限リトライ**でした。バックエンドのデータ取得タスク（C#の Task.Run で回していた無限ループ）の中で、特定の条件下で例外が発生した際、用意されていたレジリエンス・ロジックがその例外をキャッチし、無限にリトライを繰り返していたのです。
ロジックボムの解剖（Anatomy）
- サイレント・エラー: 例外はキャッチされるものの、ログレベルが「Warning」だったため監視チームの目に止まらなかった。
- フェイルオーバーの無効化: 生存確認スレッドが別だったため、処理系が死んでいても外部からは「生存」に見えた。
- 自動化の脆弱性: プロセスが生きてリトライを続けている限り、自動再起動は作動しなかった。
階層（ヒエラルキー）の壁 —— 現場の直感を阻む「上意下達」のジレンマ
システムは「正常」だと主張しているけれど、僕の目には「死」が見えている。この状況で、僕は現場責任者のピエール（仮名）に詰め寄りました。
「これ、今すぐデバッガを当ててスレッドの状態を確認すべきです。データが完全にスタックしています」
しかし、欧米の伝統的な企業において、エンジニアリングは日本以上に**「厳格な職務分掌（ジョブ・ディスクリプション）」**の上に成り立っています。
「君の仕事はUIの設計だ」
ピエールは肩をすくめてこう言いました。「落ち着けよ。君の担当はWPFのUIロジックだろう？ データの受信側の挙動については、インシデント・マネージャーが異常を検知してから、専門チームが動くことになっているんだ」
日本的な「誰かが火を見つけたら全員でバケツを持って走る」文化とは対照的に、ここでは役割（Role）と責任（Responsibility）がシビアに分離されています。「上の人間（またはマニュアル）がOKと言っているものに、下の人間が異を唱える」には、単なる推測以上の圧倒的な証拠が必要とされるのです。
僕は孤独なトラブルシューティングを開始しました。権限がないなら、UI側から証明するしかない。WPFの DispatcherPriority を制御し、バックエンドからのデータ流入が途絶えていることを視覚化する「自作の診断ツール」を構築し始めたのです。
標準作業手順書（SOP）という名の目隠し —— なぜマニュアルが原因を隠したのか
深夜、自作のツールが暴き出したデータは、想像以上にグロテスクな真実を物語っていました。データ受信タスクは死んでいるわけでも、ブロックされているわけでもなく、**「秒間数千回というレベルで意味のないリトライを繰り返していた」**のです。
マニュアルという名の「真犯人」
僕はプロジェクトの「標準作業手順書（SOP: Standard Operating Procedure）」を読み返しました。そこには、今回のようなインフラ系システムにおける「エラーハンドリングの鉄則」が書かれていました。
SOP項目 8.4: 可用性の維持（Maintenance of High Availability） 「予期せぬ例外が発生した場合、システムを停止させてはならない。即座にリトライを試み、最小限のダウンタイムで復旧を図ること。すべての例外はグローバルハンドラでキャッチし、ログに記録した上で継続せよ。」
これこそが、ロジックボムを爆発させた火種でした。開発者たちはこのSOPに忠実に従い、どんなエラーが起きても「とりあえずキャッチしてリトライ」という堅牢（に見える）コードを書いたのです。
しかし、今回起きたのは「リトライしても絶対に解決しない、データ形式の不整合」でした。マニュアル通りに動けば動くほど、システムは無限ループの深みにハマり、正常なデータを処理する隙間を失っていく。**「マニュアルを完璧に守った結果、システムが死ぬ」**という、皮肉な逆転現象が起きていたのです。
ピエールにこのデータを突きつけたとき、チームに戦慄が走りました。彼らが「聖書」のように守ってきた手順書が、実は根本原因を覆い隠すための「目隠し」になっていたことを認めた瞬間、ヒエラルキーの壁は崩れ去りました。
チェックリストを超えて —— グローバルな現場で「直感」を武器にする方法
あの事件を経て、僕たちはコードだけでなく、プロジェクト全体の「例外に対する考え方」を再定義しました。あえてシステムを不完全に、脆く（Fail-Fast）見せることこそが、真の堅牢性を手に入れる近道だったのです。
海外で生き残るエンジニアとして、僕が学んだ「得する人生術」をまとめます。
1. 「Fail-Fast」をコードと組織にデプロイせよ
エンジニアとして、あらゆる Exception をキャッチしたくなる誘惑に打ち勝ってください。致命的な不整合には Environment.FailFast() を使う覚悟を持つこと。「エラーが出ることは悪ではなく、エラーが隠されることが最大の悪である」という文化を、データを持って示し続けることが重要です。
2. 「Green」を疑い、独自のメトリクスを持て
監視システムが「正常」と言っているから安心……。その思考停止が、海外では命取りになります。彼らのツールは「想定内の異常」しか検知できません。「自分ならこのシステムのどこを疑うか？」という独自の視点で、生データを覗き見る手段（独自のダッシュボードや診断ツール）を常に隠し持っておいてください。
3. 「波風を立てないこと」は最大の裏切りである
海外のプロフェッショナルは、あなたが空気を読んで黙っていることを評価しません。むしろ、「なぜあの時、もっと強く言わなかったんだ？」と後で責められることすらあります。自分の技術的な直感が「NO」と言っているなら、それを言語化し、証拠を揃え、テーブルの上に叩きつける。それが、結果としてプロジェクトを救い、あなた自身の評価を不動のものにします。
まとめ：あなたの「違和感」には価値がある
海外というアウェイな環境にいると、自分の違和感を「英語力のせい」や「文化の違い」として飲み込んでしまいがちです。しかし、その違和感こそが、日本で培ってきた繊細な感覚と技術的バックグラウンドが発する「警告アラート」です。
マニュアルを信じるな、とは言いません。しかし、マニュアルを「完成品」だとも思わないでください。常に自分のツールで裏を取り、おかしいと思ったら声を上げる。その積み重ねが、あなたを「ただの作業員」から「プロジェクトの守護神」へと変えてくれるはずです。
コメント