ベルリンの冬、冷え切った空気の中で叩くエンターキーは、不思議なほど重い。
画面にはGitHubの『Merge pull request』ボタン。かつてなら数週間を要したであろう複雑なWPFのカスタムコントロールと、それに関連するMVVMのロジックが、AIエージェントとの数時間の対話だけで完成してしまった。
しかし、この「デプロイの快楽」の裏側で、僕は言いようのない不安に襲われることがある。僕たちが「結果」として生み出しているこの美しいコードは、実は恐ろしく脆い砂上の楼閣ではないか、という不安だ。
今日は、僕が海外のシビアな現場で揉まれる中で辿り着いた、2026年というAI時代を生き抜くための「生存戦略」についてお話ししたい。キーワードは、**「The Fragility of the How（やり方の脆弱性）」**だ。
見えているのは氷山の一角。コードという「結果」の脆さについて
海外でC# / WPFエンジニアとして、日々デスクトップアプリの設計や開発に明け暮れている僕が確信していることがある。それは、「コードがすべてだ」と思っているエンジニアほど、グローバルな現場では早期に価値を失うということだ。
「エンジニアなんだから、動くコードが正義じゃないのか？」
そう思う気持ちは痛いほど分かる。かつての僕も、完璧な依存注入（DI）で制御され、クリーンアーキテクチャに基づいたC#のコードさえ書ければ、それがプロとしての「正解」だと信じていた。しかし、文化も時差もバラバラなチームで、数年、十数年とメンテナンスされる巨大なプロダクトに関わるうちに、その考えはガラガラと崩れ去った。
コードは「敗者の死体」の上に立つ、たった一つの生存者である
GitHubを開けば、そこには洗練されたViewModelがあり、美しくバインドされたXAMLが並んでいる。しかし、これらはあくまで**「最終的に生き残った解決策」**でしかない。
一つの「正しいコード」に辿り着くまでに、僕たちは何十もの「ボツ案」を捨てているはずだ。
- 「最初はReactiveUIを検討したが、今回の要件ではメモリリークの管理コストがメリットを上回ると判断した」
- 「このカスタムコントロール、最初は汎用的に設計したが、特定のWindowsアップデートでレンダリングが崩れることが判明したため、あえて固有の実装に倒した」
こうした**「検討したけれど採用しなかった選択肢（Discarded Alternatives）」**。これこそが、実はプロジェクトの生命線だ。ところが、完成したコードは結果しか語らない。この「文脈の欠如」こそが、コードを脆い存在に変えてしまう。
「How」だけを知っているエンジニアが詰む理由
例えば、僕が数年前に担当した、WPFの複雑なチャート描画機能での出来事だ。 前任者が書いたコードに、一見すると非常に非効率に見えるループ処理があった。僕は「LINQを使って書き直せばスッキリするし、可読性も上がる」と考え、リファクタリングしてマージした。ユニットテストもパスし、完璧だと思った。
しかし数日後、特定の高リフレッシュレート（144Hz以上）のディスプレイを使っているユーザーから「アプリがカクつく」というクレームが入った。
調査の結果、その「非効率なコード」は、GPUレンダリングのタイミングと同期させるために、あえてガチガチに制御された泥臭い実装だったことが判明した。LINQの遅延評価によるわずかなオーバーヘッドが、その絶妙なバランスを壊してしまったのだ。
コードに「なぜあえて非効率に書いているのか」が一行も書いていなかった。そして僕も、「書かれているコードが答えだ」と思い込んでしまった。もしそこに、**「捨てた案とその理由」**が記されていれば、この地雷を踏むことはなかったはずだ。
時差と国境を越える「暗黙知」の恐怖：ドキュメントなき開発の末路
グローバルな多拠点開発において、コードの脆さは「爆弾」に変わる。その最大の要因は、物理的な**「時差」**だ。
12時間の断絶と、消えない通知
僕のチームは、ヨーロッパ、アメリカ、アジアにメンバーが分散している。太陽を追いかける「Follow the Sun」モデルだ。 一見効率的だが、現実は残酷だ。僕が寝ている間に地球の裏側で誰かがコードを書き、僕が起きたらその成果をレビューする。このサイクルの中で最も恐ろしいのは、「誰かに聞けばわかる」という選択肢が物理的に存在しない時間帯があることだ。
朝、Slackを開くとアメリカの同僚から「至急教えてくれ！」というメッセージが届いている。だが、送り主はすでにベッドの中だ。もし僕のコードが「How（どう書いたか）」しか語っていなかったら、彼は僕が起きるまでの12時間を推測（博打）で進めるか、作業をストップさせるしかない。
これが**「部族知（Tribal Knowledge）」**の弊害だ。
「Dispatcher」の一行に隠された呪い
かつて、WPFの Dispatcher.BeginInvoke の優先順位（Priority）を、あえて一段階下げた Background に設定している箇所があった。
C#
// なぜかBackground優先度で実行されている
Application.Current.Dispatcher.BeginInvoke(new Action(() => { ... }), DispatcherPriority.Background);
新しく入ったメンバーは「UIの反応を良くすべきだ」と、良かれと思ってこれを Normal に戻した。結果、低スペック端末の拠点でUIが完全にフリーズした。 実はそれは、描画スレッドが過負荷になった際に入力イベントを優先して受け付けるための、血の滲むような回避策だった。しかし、その「Why」は僕の頭の中にしかない暗黙知だったのだ。
低コンテキスト文化での「伝える努力」
日本は「言わなくてもわかる」ハイコンテキスト文化だが、海外の多国籍チームは超「ローコンテキスト」だ。言葉にされていないことは、この世に存在しないのと同じだ。
「コードを見ればわかるだろ」という態度は、海外では「プロフェッショナリズムの欠如」と見なされることがある。テックリードから言われた言葉が今も胸に刺さっている。 「コードを見れば『何』が変わったかはわかる。だが僕たちが知りたいのは、なぜこのリスクを取ってまでその変更が必要だったのかだ。それが書けないなら、そのコードはただのノイズだ」
AIがコードを書く時代、僕たちが語るべきは「なぜそれを選ばなかったか」
2026年、GitHub CopilotやClaudeといったLLMの台頭により、エンジニアの立ち位置は劇的に変わった。定型的なコードの実装において、AIの正確さはもはや人間を超えている。
しかし、僕は確信している。AI時代こそ、「人間によるWhy」の価値がかつてないほど高まっているのだ。
AIには「ボツ案」を語ることができない
AIに「パフォーマンスの高いWPFリストビューを作って」と頼めば、数秒で最適化されたコードが返ってくる。しかし、そのコードはあなたのチームの「過去の失敗」を知らない。
- 「来月予定されているバックエンドの仕様変更と競合しないか？」
- 「顧客が頑なに使い続けている古いライブラリとの相性は？」
AIは「一般解」を出すのは得意だが、**「あえて非効率なB案を選ぶべき、泥臭い現実」**を汲み取ることはできない。
これからのエンジニアは、コードの書き手から**「意思決定のキュレーター」**へと進化しなければならない。「AIが出してきた3つの案のうち、なぜ我が社にはB案が最適なのか」を論理的に説明できる能力。それが、2026年のエンジニアの市場価値を決定づける。
「意図力」は英語力を凌駕する
よく「海外で働くには高い英語力が必要か」と聞かれる。もちろん重要だが、現場で本当に信頼されるのは流暢な発音ではない。 「拙い英語でも、なぜこの設計にしたのか、そのロジックを逃げずに説明しきれる力」 これこそが最強の武器だ。言葉が不自由だからこそ、図解を使い、ドキュメントに「意図」を込める。その執念が、時差を越えてチームメイトの信頼を勝ち取る。
エンジニアの価値は「意図」に宿る。世界で生き残るための「思考のログ」術
最後に、僕がベルリンの現場でサバイブするために毎日実践している、具体的で今日から真似できる**「思考のログ（Thought Logging）」**術を共有したい。
1. プルリクエストに「やらなかったこと」を添える
PR（プルリクエスト）の概要欄に、実装したことのリストだけでなく、**「検討したが採用しなかった案（Discarded Options）」**という項目を追加してみてほしい。
| 項目 | 内容 |
|---|---|
| 検討した案 | Prismの標準的なNavigationServiceの使用 |
| 不採用理由 | 今回の要件（モーダル内での子ウィンドウ制御）でメモリリークのリスクが高いため |
| 最終的な決定 | 独自のメッセージング方式を採用 |
Google スプレッドシートにエクスポート
これがあるだけで、レビュワーはあなたの思考プロセスを追体験でき、12時間の時差を超えて「信頼」が構築される。
2. 「3時のおやつ」の代わりに「ADR」を1行書く
ADR（Architecture Decision Records）を難しく考える必要はない。リポジトリに docs/adr/ というディレクトリを作り、その日に下した重要な決断を1枚のMarkdownに残すだけだ。 「2026/04/08：ライブラリXの採用を見送り。理由は.NET 10との互換性問題」 この1行が、1年後にバグをデバッグしている未来のあなた、あるいはあなたの後任を救う聖書になる。
3. コメントには「ビジネス上の背景」を優先する
クリーンコードの原則では「コメントは最小限に」と言われるが、「Why（なぜ）」に関するコメントは例外だ。
C#
// 悪い例：リストをソートする（読めばわかる）
var sortedItems = items.OrderBy(x => x.Date);
// 良い例：顧客の法務要件により、1970年以前のデータは表示順に関わらず最下部に隔離する必要がある
var displayItems = items.CustomSortByCompliance();
コードを読んでも絶対に分からない「大人の事情」や「歴史的経緯」こそ、コメントに残すべき真の資産だ。
4. AIを「代筆者」ではなく「壁打ち相手」にする
AIにいきなりコードを書かせるのではなく、「A案とB案で迷っている。WPFのメモリ管理の観点からデメリットを比較して」と相談しよう。 AIが出した回答を元に、最終的に自分が「どの根拠で選んだのか」を言語化する。その言語化のプロセス自体が、あなたのエンジニアとしての筋肉になる。
結び：世界で通用する「知的誠実さ」を磨け
海外でエンジニアとして働き始めて、一番の驚きだったこと。それは、世界中のどんなに優秀なエンジニアも、みんな等しく「自分のコードが数年後にどうなっているか」を不安に思っている、ということだった。
だからこそ、**「意図を繋ごうとする姿勢」**は、言語や文化の壁をあっさりと飛び越える。
最新のフレームワークを使いこなすことよりも、誰よりも速くコードを書くことよりも、「自分の後にこのコードを読む誰か」を思いやり、なぜその一歩を踏み出したのかを記録に残す。 その**「知的誠実さ」**こそが、あなたを世界のどこへ行っても歓迎されるエンジニアにする。
「やり方の脆弱性」に怯えるのはもう終わりだ。 あなたが残す「意図」という強固な資産とともに、自信を持ってグローバルな舞台へ踏み出してほしい。僕も、ベルリンの空の下で、いつかあなたと一緒に働ける日を楽しみにしている。
Viel Glück!（幸運を！）
コメント