「よし、書き上げた。マージするぞ」
ベルリンのオフィス、あるいは時々カフェの片隅で、僕は今日もGitHubの『Merge pull request』ボタンをクリックする。画面には「24 files changed, +1,200 -150」という数字。かつてなら数週間かかっていたような複雑なWPFのカスタムコントロールと、それに関連するMVVMのロジックが、AIエージェントとの数時間の対話だけで完成してしまった。
この瞬間、脳内には強烈な「デプロイの快楽（Shipping Dopamine）」が駆け巡る。しかし、その快感の直後に、決まって冷や汗のような重苦しさが背中に張り付くようになった。
海外の、特に英語圏のチームでC#やWPFを使って設計・開発をしていると、日本にいた頃とは全く違う「壁」にぶち当たることがある。それは言語の壁でも技術の壁でもなく、**「圧倒的な人の入れ替わりの激しさ」**から来る、情報の断絶という壁だ。
コードは消えても「意思」は残る：海外の現場で学んだサバイバル術
海外ではエンジニアが2〜3年でジョブホップするのは当たり前だ。プロジェクトの途中でメインのアーキテクトが「来月から別のスタートアップに行くわ、じゃあね！」と爽やかに去っていく光景も珍しくない。残されたのは、巨大なWPFのモノリスと、誰も意図を説明できない複雑なMVVMのコード。
僕も今の拠点で働き始めた当初、ある基幹システムの保守を任されたが、そこはまさに「レガシーの墓場」だった。
「なぜ、ここであえてReactivePropertyを使わずに独自のイベントバスを作ったのか？」 「なぜ、このViewModelはこんなに巨大な状態管理を抱えているのか？」
コードを読めば「何をしているか（What）」はわかる。しかし、**「なぜそうしたのか（Why）」**がどこにも書いていない。同僚に聞いても「あ、それを作ったヤツはもう半年前に辞めたよ」で終わりだ。
ここで僕は痛感した。**「ソースコードだけを成果物だと思っているエンジニアは、この環境では生き残れない」**という事実に。
「今のチーム」ではなく「未来の自分」と「後継者」のために書く
日本にいた頃の僕は、どちらかというと「美しいコードを書けば、それがドキュメントになる」と信じていた。いわゆるクリーンコード至上主義だ。もちろんそれは間違いではないが、海外の荒波に揉まれるうちに、その考えは少し甘かったと思い知らされた。
コードがどれだけ美しくても、その背景にある「トレードオフの決断」までは語ってくれないからだ。
今、あなたが書いているそのコードは、1年後には別の誰かが書き換えているかもしれない。あるいは、仕様変更で跡形もなくなっているかもしれない。でも、その設計を選んだ時に検討した**「選択肢Aは却下し、Bを選んだ」という意思決定のプロセス**は、プロジェクトが続く限り価値を持ち続ける。
海外でサバイバルするエンジニアは、もっと利己的で、かつ利他的だ。「1年後、何も覚えていない自分」を助けるために、そして「自分の後に来る見知らぬ誰か」が迷子にならないために、パンくずリストを残すように設計の意図を記す。これが、結果的に自分の評価を守り、チームの崩壊を防ぐ第一歩になる。
なぜ「ドキュメント」ではなく「ADR（アーキテクチャ意思決定記録）」なのか？
「ドキュメントを書いてください」と言われて、テンションが上がるエンジニアに僕は会ったことがない。特にスピード感が命の海外現場では、「ドキュメントを書く時間があるなら、1つでも多くプルリクを投げろ」という空気感さえある。
しかし、ここで多くのエンジニアが想像する「ドキュメント」は、システムの全体像を網羅した巨大な仕様書や、最新の状態を保たなければならないWikiページだろう。それは残念ながら、**「書いた瞬間から腐り始めるゴミ」**になりがちだ。
そこで、僕が海外のシニア層から教わり、今やこれなしでは仕事ができないレベルで重宝しているのが、**ADR（Architectural Decision Records）**という手法だ。
「完成図」ではなく「航海日誌」を残す
ADRを一言でいうなら、それは設計の**「航海日誌」**だ。一般的な仕様書が「今のシステムはこういう形をしています」という「点」の記録だとしたら、ADRは「こういう理由で、この道を選んだ」という「線」の記録である。
かつて僕がリードしていたWPFのプロジェクトで、データグリッドの表示速度がどうしても上がらない問題に直面した。標準のDataGridを使うか、学習コストが高いサードパーティ製ライブラリを導入するか。チームで激論を交わし、最終的には「今のメンバーのスキルセットと納期を優先して、標準コントロールをカスタマイズする」と決定した。
半年後、新メンバーが「なんでこんな重い標準コントロールを使ってるんだ？」と言い出した時、僕は「ADR #014を読んでみて」と言うだけで済んだ。その記録には、当時検討した代替案や、なぜそれを見送ったのかという「制約条件」が明確に書いてあったからだ。
ADRが「コードコメント」より優れている理由
ADRの素晴らしいところは、技術的な理由以外の**「ビジネス上の制約」や「当時のチーム状況」**を堂々と書ける点にある。
- Context（文脈）：何が問題で、どんな状況だったか
- Decision（決定）：何を選んだか
- Status（状態）：承認済み、提案中、または廃止
- Consequences（結果）：その決定によって生じる将来のメリット・デメリット
この「Consequences（結果）」が特に重要だ。「この設計を選んだことで、将来的にUIの柔軟性は下がるが、今はデリバリー速度を優先する」と書いておく。これこそが、未来の自分への最高のギフトになる。
1年後の自分にボコボコにされないために——負債を資産に変える思考法
「誰だ、こんな設計にしたのは！」
修正依頼が舞い込んできたコードを読み返し、画面の前で頭を抱える。Git Lensで犯人を確認したら、自分自身の名前が出てきて絶望する。そんな「あるある」を回避する唯一の方法は、当時の「制約（Constraints）」を可視化することだ。
技術負債の正体は「情報の欠落」である
海外のチームでは “We’re taking some technical debt here.”（ここはあえて負債を抱えよう）という会話が日常的に行われる。負債そのものが悪ではない。本当の悪は、**「それが負債であることを忘れ、なぜその負債を選んだのかという経緯が消えること」**だ。
ADRがある場合、負債は「得体の知れないゴミ」から「計画的に返済可能なローン」に変わる。「当日は24時間以内にデモを動かす必要があり、汎用化よりスピードを優先した」という記録があれば、1年後の自分は「なるほど、確信犯だったのか」と納得し、建設的なリファクタリングに移れる。
「トレードオフ」を言語化する技術
海外でシニアエンジニアとして評価される人は、例外なくこの**「トレードオフ（Trade-offs）」**の言語化が異常に上手い。
C# / .NETの世界は、やり方の選択肢が膨大だ。非同期処理一つとっても、Task.Runで投げるのか、Parallel.ForEachを使うのか、あるいはChannelsを使ってパイプラインを組むのか。それぞれにメリットとデメリットがある。
僕が海外に来てから自分に課しているルールは、**「2つ以上の選択肢を比較検討しなかった設計は、設計ではない」**と定義することだ。そして、その比較結果をADRに1行でも残す。これが、未来の自分にボコボコにされないための最大の防御策になる。
未来のチームへの遺言——エンジニアとしての価値は「決定の質」に宿る
「あなたはプロとして、何を持って価値を証明するのか？」
海外で働いていると、この問いを常に突きつけられる。コードが書けるのは当たり前。最新のフレームワークを知っているのも当たり前。その先にある「エンジニアの格」を決めるのは、結局のところ**「決定の質」**だと僕は確信している。
「コードを書く人」から「意図を設計する人」へ
海外のプロジェクトでリードを務めるエンジニアは、エディタに向かっている時間と同じくらい、あるいはそれ以上に「なぜこの設計にするのか」という合意形成に時間を使っている。彼らにとって真の成果物は、ビジネスを前進させるための**「論理的な決断」**そのものなのだ。
ADRを書き始め、意思決定を資産として残すようになってから、周囲の目が変わるのを感じた。 「あのエンジニアは、単にタスクをこなすだけじゃない。将来のリスクを予測し、チーム全体が迷わないための『地図』を描いてくれる」
こう思われるようになると、海外での生存確率は一気に跳ね上がる。言語の壁があっても、論理的な決定記録があなたの代わりに雄弁に語ってくれるからだ。
生き残るために「書く」
僕たちが去った後も、システムは生き続ける。そこには、数え切れないほどの「トレードオフ」が積み重なっている。「あの時、あえて複雑なReactiveUIを導入したのは、リアルタイム通知の要件が見えていたからだ」といった意図が残されていること。それこそが、僕たちがチームに遺せる最高の**「レガシー（遺産）」**だ。
エンジニアの仕事はキーボードを叩くことだが、その文字が if や class だけで終わってはいけない。
「なぜ（Why）」を刻んでください。
海外の現場では、技術は常に移り変わる。今日使っている.NET 8も、10年後には古くなっているかもしれない。しかし、あなたが複雑な状況下で下した「決定のプロセス」と、それを残す「誠実な姿勢」は、どんな技術スタックに変わっても通用する普遍的なスキルになる。
「ソースコードは嘘をつくが、決定は嘘をつかない」
この言葉を胸に、今日も最高の設計を、そして最高の「意思決定の記録」を遺していこう。それが、僕たちがエンジニアという過酷な職業の中で生き残るための、唯一にして最強のサバイバル術なのだから。
コメント