投稿者: cre-noa

〜「なぜか話が通じない」は、家庭内でも発生する〜

この思考は、生まれつきのものではないかもしれない。 なにせ3歳の頃からコンピュータという「論理の塊」に触れ、おまけにコーディングという「物事を順序立てて効率的に動かす遊び」に興味を持ってしまったが故に、半ば強制的に根付いてしまった思考なのだ。

だから、まずお断りしておきたい。 ここに書くのは、「エンジニア」という大きな主語の話ではなく、あくまでそんな環境で育った「とある一個人」の思考のクセであり、一個人の意見として、どうか軽い気持ちで流してほしい。

先日、ITトラブルの現場で「根本原因」を追求したいエンジニア思考が、いかに「共感」を求める相手とすれ違うか、という話を書いた。

だが、残念なお知らせがある。 あの「面倒な思考」は、仕事のPCをシャットダウンしても、私たちの頭からログアウトしてはくれない。

そう。それは日常生活、特に「夫婦生活」という、最もロジックが通用しない戦場（？）において、さらに複雑な問題を引き起こすのだ。

Case 1：買い物の「最適ルート」vs「寄り道のロマン」

スーパーでの買い物。 私たちにとって、これは「必要なリソースを最短の工数で調達するプロジェクト」だ。

• エンジニア思考：
  • （入店前に買い物リスト（＝要件定義）を確定）
  • 「まず野菜コーナー、次に肉、最後に牛乳…このルートが最短だ」
  • 「あ、特売だけどウチの在庫（冷蔵庫）と重複するな。不要」
  • ミッションコンプリート（滞在時間：7分）

しかし、パートナーは違う。

• パートナーの思考：
  • 「あ、シャインマスカット美味しそう！」（要件定義外のタスク発生）
  • 「このドレッシング、新発売だって」（仕様変更）
  • 「なんか小腹すいたからお菓子も…」
  • ミッションコンプリート（滞在時間：25分）

この「非効率な寄り道」と「衝動的な仕様変更」は、私たちをイラつかせる。 「なんでリストにないものを買うんだ？」「さっき通った通路だぞ？」 この「正論」が、相手の「買い物の楽しみ」という感情的な体験を、いかに害するかを想像せずに。

Case 2：「問題解決」で殴る夫（妻）と、「共感」が欲しい妻（夫）

これは、ITトラブル編の完全な応用編だ。

パートナー：「今日、職場でAさんにこんなこと言われて、本当にムカついた！」

さあ、エンジニアの出番だ。

• エンジニア思考：
  • （トラブル発生。状況を分析開始）
  • 「それは、君が先にBさんにそう言ったのが原因じゃないか？」（＝原因の切り分け）
  • 「Aさんの性格を考えると、今後はこう伝達すれば回避できるはずだ」（＝解決策の提示）
  • 「そもそも、その業務フローに問題がある」（＝根本原因の特定）

パートナー：「……もういい！！」

なぜ怒られるのか。 私たちは、相手が抱える「問題」を真剣に分析し、再発防止策まで提案したというのに。

答えは明白だ。 相手が求めていたのは「解決策（ソリューション）」ではなく、「大変だったね（共感）」という**無条件の「同意（承認）」**だったのだ。

私たちは「問題」を解決しようとし、相手は「感情」を共有しようとした。 家庭内での会話は、多くの場合、「報告」ではなく「感情の発散」が目的なのである。

Case 3：旅行計画と「分刻みのバッファなしスケジュール」

旅行は、私たちにとって「プロジェクトX」だ。

• エンジニア思考：
  • 9:15 新幹線到着 → 9:22 在来線乗り換え（バッファ：7分）
  • 10:00 レンタカー（予約済）→ 11:30 〇〇寺（滞在時間：45分）
  • 12:15 昼食（口コミ4.2、予約済）
  • …すべてが完璧なタイムライン。

しかし、現地では予測不能な「障害（インシデント）」が多発する。 「道が混んでる」「あのお土産屋、寄りたい」「なんか疲れたからカフェ入ろう」

この「仕様変更」に対応できず、私たちはフリーズする。 「スケジュールが押している！」「ここでカフェに入ると、次の〇〇に行けなくなるぞ！」

パートナーは「旅行（体験）」を楽しみたいのに、私たちは「スケジュール（計画）」を遂行することに必死になってしまう。 「楽しむ」という目的が、「計画通りに進める」という手段にすry（すり）替わってしまうのだ。

私たちは「非効率」を愛せるか

この「面倒なエンジニア思考」は、私たちの強みでもある。 家計を最適化し、家のネットワークを安定させ、物事を効率的に進めることで、生活の基盤を支えている自負もある。

しかし、日常生活や夫婦生活とは、「効率」や「ロジック」の外側にある「無駄」や「感情」を楽しむものでもあるらしい。

「非効率な寄り道」を、「新しい発見」と捉えられるか。 「ロジックゼロの愚痴」を、「ただの放電」として受け流せるか。

私たちの「エンジニア思考」が試される、本当の戦場は、どうやら家庭（プライベート）にあるようだ。

…ああ、やっぱり、面倒である。

まずお断りしておくと、「エンジニア」という言葉は、「男」とか「女」とか言うのと同じくらいに主語が大きい。ここに書くのは、あくまで「とある一エンジニア」の思考のクセであり、一個人の意見として、どうか軽い気持ちで流してほしい。

なぜ「私のせいだ」と主張する友人と、「いや相手の問題だ」と分析する私は、すれ違うのか。

私たちの思考は、常にいくつかのパターンを試行するようにできている。何事も、まず選択肢として考えるクセがあるのだ。

それは多くの場合、物事を正確に進めるための「強み」だ。しかし、時として、この思考法が「面倒なこと」を引き起こす。

特に、非エンジニアから「答えは一つ」であることを期待される質問を受けた時だ。

「通知が届かない」に潜む、無数のシナリオ

先日、ある人にこんな相談を受けた。

「3日前にiPhoneを買い替えてLINEを移行したの。そしたら、特定のAさんにだけ、私からのLINEの通知が届かなくなっちゃったみたい」 「でも、AさんがLINEを開いてる時は（通知じゃなくて）普通にメッセージが来る。Aさん曰く、通知が来ないのは私からだけ、って」

そして、彼女はこう結論付けた。 「3日前に機種変したのが原因だよね？ なんで？」

この瞬間、私たちの頭の中では、瞬時に複数のシナリオが分岐し、その「切り分け」が始まる。

エンジニア（私）の思考プロセス：

1. 事実確認：メッセージは「届いている」（Aさんがアプリを開けば見れる）。
2. 問題の特定：問題は「メッセージの送信」ではなく、「Aさんの端末へのプッシュ通知」だけである。
3. 切り分け1：「Aさんだけ」に起きている。
   • → 送信側（友人）の全体的な問題である可能性は低い。
4. 切り分け2：Aさんが「アプリを開いている時」は受信できる。
   • → 送信側（友人）の回線やアカウントがブロックされている可能性も低い。
5. 結論：これは「Aさん（受信側）の端末」で、友人（送信側）の通知だけをサイレントにする「設定」がされている問題である。

導き出される仮説（選択肢）：

• 仮説A（最有力）：Aさんが、友人のトークルームを「（うっかり）通知オフ」に設定している。
• 仮説B（次点）：AさんのiPhoneの「集中モード」が、友人からの通知だけを許可していない。
• 仮説C（可能性・低）：「3日前の機種変更」は、この問題とたまたま時期が重なっただけの「偶然」である。

「答え」が欲しい人と、「原因」を探る人

しかし、友人は専門家ではない。当然、この複雑な思考の分岐を求めてはいない。 彼女が欲しいのは、「機種変した私のせいだ」という自身の仮説への「同意」と「解決策」だ。

ここで、悲劇が起こる。

私たちが「うーん、それは多分、あなたのスマホじゃなくて、Aさん側の問題だと思うよ」と、論理的に正しい（そして最も解決に近い）分析を口にした瞬間、相手はそれを拒絶する。

「絶対私が機種変したことが原因だって！ docomoのせいだよね？ だって最近、回線の不具合って言われてるから！」

彼女の思考は、私たちの分析とはまったく違う場所にある。

• 友人のロジック：「機種変」と「不具合」が同時に起きた → だから「機種変（とdocomo）」が原因だ。
• 私たちのロジック：「メッセージ自体は届いている」 → だから「docomo（通信）」が原因である可能性はゼロに近い。

私たちが「いや、通信ができてるならdocomoは関係ないよ。Aさんに通知設定を確認してもらって」と正論を言えば言うほど、相手は「でも！」「だって！」と感情的になっていく。

エンジニアの「誠実さ」が「面倒」に変わる瞬間

これほど、納得のいかないことがあるだろうか。

私たちは「知っている」からこそ、「送信」と「通知」は別物だと切り分ける。「知っている」からこそ、問題の本当の震源地（＝Aさんの端末）を特定しようとする。

それが、相手にとっては「話をややこしくする人」「私の不安をわかってくれない人」に映ってしまう。

相手が欲しいのは「原因究明」ではなく、「そうなんだ、機種変って大変だね、docomoのせいかもね」という**「共感」と「（間違っていてもいいから）分かりやすい敵」**だったのだ。

私たちの「正確さ」や「論理的誠実さ」へのこだわりが、皮肉にもコミュニケーションの壁になる。 ああ、エンジニア思考は、本当に面倒である。

ワークアラウンド：「プロの技」と「時間経過」の現実

さらに話をややこしくするのが、「ワークアラウンド（一時しのぎ）」の存在だ。

断っておくが、**ワークアラウンドは、エンジニア’界隈’に生きるエンジニアにとって、非常に重要な「プロの技術」**である。

サービスが停止した時、ユーザーを待たせたまま根本原因を調査するのではなく、まずは「再起動」や「一時的なパッチ適用」などで迅速にサービスを復旧させる。そして、動いている裏でじっくりと根本原因を特定・解消する。これは、被害を最小限に抑えるための、最も合理的で高度な判断だ。

面倒なのは、この「ワークアラウンド」が、「根本解決」と誤解される時である。

非エンジニアが（意図せず）行った再起動などで「偶然、一時的に治ってしまった」場合、彼らにとってはそれが「解決」になってしまう。

根本原因が残っていても、彼らは「治ったからもういい」と調査を打ち切ってしまうのだ。

そして、何よりも。 この種のITトラブル、特に「通知が来ない」「同期がズレる」といった類の問題は、時間経過や、何か別のトリガーによって、自然に解消することがよくあるのだ。

• サーバ側の一時的な不具合が、いつの間にか解消された。
• 夜中の自動アップデートで、何かがリセットされた。

原因は特定できないまま、数日後には「あ、なんか治ったみたい」とケロッと言われる。 この「原因不明のままの解決」は、根本原因を突き詰めたいエンジニアにとって、ある意味、敗北だ。

だから、本当は「Aさん側の設定を見て」と言う代わりに、 「うーん、よくわからないけど、2〜3日待ったら何かの拍子に治るかもよ？」 と答えることもできる。

実際、それが一番現実的かもしれないと、心のどこかで分かっている。

でも、それを口にすることはできない。 「専門家なのに投げやりだ」と誤解されるのが目に見えているし、何より、原因を特定できないモヤモヤを抱えたままにするのは、私たちの「エンジニア思考」が許さないのだ。

正確な「原因」を追求したい自分と、「待てば治るかも」という「経験則」を知っている自分。 そして、そのどちらも受け入れられない「今すぐ答えが欲しい」相手。

ああ、やはり、エンジニア思考は面倒である。