まずお断りしておくと、「エンジニア」という言葉は、「男」とか「女」とか言うのと同じくらいに主語が大きい。ここに書くのは、あくまで「とある一エンジニア」の思考のクセであり、一個人の意見として、どうか軽い気持ちで流してほしい。
なぜ「私のせいだ」と主張する友人と、「いや相手の問題だ」と分析する私は、すれ違うのか。
私たちの思考は、常にいくつかのパターンを試行するようにできている。何事も、まず選択肢として考えるクセがあるのだ。
それは多くの場合、物事を正確に進めるための「強み」だ。しかし、時として、この思考法が「面倒なこと」を引き起こす。
特に、非エンジニアから「答えは一つ」であることを期待される質問を受けた時だ。
「通知が届かない」に潜む、無数のシナリオ
先日、ある人にこんな相談を受けた。
「3日前にiPhoneを買い替えてLINEを移行したの。そしたら、特定のAさんにだけ、私からのLINEの通知が届かなくなっちゃったみたい」 「でも、AさんがLINEを開いてる時は（通知じゃなくて）普通にメッセージが来る。Aさん曰く、通知が来ないのは私からだけ、って」
そして、彼女はこう結論付けた。 「3日前に機種変したのが原因だよね？ なんで？」
この瞬間、私たちの頭の中では、瞬時に複数のシナリオが分岐し、その「切り分け」が始まる。
エンジニア（私）の思考プロセス：
- 事実確認：メッセージは「届いている」（Aさんがアプリを開けば見れる）。
- 問題の特定：問題は「メッセージの送信」ではなく、「Aさんの端末へのプッシュ通知」だけである。
- 切り分け1：「Aさんだけ」に起きている。
- → 送信側（友人）の全体的な問題である可能性は低い。
- 切り分け2：Aさんが「アプリを開いている時」は受信できる。
- → 送信側（友人）の回線やアカウントがブロックされている可能性も低い。
- 結論：これは「Aさん（受信側）の端末」で、友人（送信側）の通知だけをサイレントにする「設定」がされている問題である。
導き出される仮説（選択肢）：
- 仮説A（最有力）：Aさんが、友人のトークルームを「（うっかり）通知オフ」に設定している。
- 仮説B（次点）：AさんのiPhoneの「集中モード」が、友人からの通知だけを許可していない。
- 仮説C（可能性・低）：「3日前の機種変更」は、この問題とたまたま時期が重なっただけの「偶然」である。
「答え」が欲しい人と、「原因」を探る人
しかし、友人は専門家ではない。当然、この複雑な思考の分岐を求めてはいない。 彼女が欲しいのは、「機種変した私のせいだ」という自身の仮説への「同意」と「解決策」だ。
ここで、悲劇が起こる。
私たちが「うーん、それは多分、あなたのスマホじゃなくて、Aさん側の問題だと思うよ」と、論理的に正しい（そして最も解決に近い）分析を口にした瞬間、相手はそれを拒絶する。
「絶対私が機種変したことが原因だって！ docomoのせいだよね？ だって最近、回線の不具合って言われてるから！」
彼女の思考は、私たちの分析とはまったく違う場所にある。
- 友人のロジック：「機種変」と「不具合」が同時に起きた → だから「機種変（とdocomo）」が原因だ。
- 私たちのロジック：「メッセージ自体は届いている」 → だから「docomo（通信）」が原因である可能性はゼロに近い。
私たちが「いや、通信ができてるならdocomoは関係ないよ。Aさんに通知設定を確認してもらって」と正論を言えば言うほど、相手は「でも！」「だって！」と感情的になっていく。
エンジニアの「誠実さ」が「面倒」に変わる瞬間
これほど、納得のいかないことがあるだろうか。
私たちは「知っている」からこそ、「送信」と「通知」は別物だと切り分ける。「知っている」からこそ、問題の本当の震源地（＝Aさんの端末）を特定しようとする。
それが、相手にとっては「話をややこしくする人」「私の不安をわかってくれない人」に映ってしまう。
相手が欲しいのは「原因究明」ではなく、「そうなんだ、機種変って大変だね、docomoのせいかもね」という**「共感」と「（間違っていてもいいから）分かりやすい敵」**だったのだ。
私たちの「正確さ」や「論理的誠実さ」へのこだわりが、皮肉にもコミュニケーションの壁になる。 ああ、エンジニア思考は、本当に面倒である。
ワークアラウンド：「プロの技」と「時間経過」の現実
さらに話をややこしくするのが、「ワークアラウンド（一時しのぎ）」の存在だ。
断っておくが、**ワークアラウンドは、エンジニア’界隈’に生きるエンジニアにとって、非常に重要な「プロの技術」**である。
サービスが停止した時、ユーザーを待たせたまま根本原因を調査するのではなく、まずは「再起動」や「一時的なパッチ適用」などで迅速にサービスを復旧させる。そして、動いている裏でじっくりと根本原因を特定・解消する。これは、被害を最小限に抑えるための、最も合理的で高度な判断だ。
面倒なのは、この「ワークアラウンド」が、「根本解決」と誤解される時である。
非エンジニアが（意図せず）行った再起動などで「偶然、一時的に治ってしまった」場合、彼らにとってはそれが「解決」になってしまう。
根本原因が残っていても、彼らは「治ったからもういい」と調査を打ち切ってしまうのだ。
そして、何よりも。 この種のITトラブル、特に「通知が来ない」「同期がズレる」といった類の問題は、時間経過や、何か別のトリガーによって、自然に解消することがよくあるのだ。
- サーバ側の一時的な不具合が、いつの間にか解消された。
- 夜中の自動アップデートで、何かがリセットされた。
原因は特定できないまま、数日後には「あ、なんか治ったみたい」とケロッと言われる。 この「原因不明のままの解決」は、根本原因を突き詰めたいエンジニアにとって、ある意味、敗北だ。
だから、本当は「Aさん側の設定を見て」と言う代わりに、 「うーん、よくわからないけど、2〜3日待ったら何かの拍子に治るかもよ？」 と答えることもできる。
実際、それが一番現実的かもしれないと、心のどこかで分かっている。
でも、それを口にすることはできない。 「専門家なのに投げやりだ」と誤解されるのが目に見えているし、何より、原因を特定できないモヤモヤを抱えたままにするのは、私たちの「エンジニア思考」が許さないのだ。
正確な「原因」を追求したい自分と、「待てば治るかも」という「経験則」を知っている自分。 そして、そのどちらも受け入れられない「今すぐ答えが欲しい」相手。
ああ、やはり、エンジニア思考は面倒である。