終わらない「機能追加」の波と、静かに崩れゆく信頼
やあ、みんな。元気にしてる？
こっちは相変わらずだよ。朝、オフィスのドアを開けると、強烈なエスプレッソの香りと共に、デイリースクラム（朝会）前のあの独特な「ざわめき」が聞こえてくる。僕がいま働いているこの国では、エンジニアの朝は早い。そして、議論の熱量も半端じゃない。
僕はここで、C#とWPF（Windows Presentation Foundation）を使って、主に産業機器向けの制御アプリケーションの設計と開発をしている。日本にいた頃からWPFは触っていたけど、こっちに来てからというもの、求められるスピード感がまるで違うことに最初は戸惑ったものだ。
「Hey, Is that feature ready?（あの機能、もうできた？）」
「Can we release it by Friday?（金曜までにリリースできる？）」
プロダクトオーナー（PO）やビジネスサイドの連中は、まるで呼吸をするように新機能を求めてくる。彼らの目には、僕らエンジニアが魔法使いに見えているらしい。キーボードを叩けば、無限に価値が生み出されると思っている。
確かに、WPFは強力だ。XAMLによる柔軟なUI構築、強力なデータバインディング、MVVMパターンによるロジックの分離。これらを駆使すれば、デスクトップアプリとは思えないほどリッチなUXを素早く構築できる。C#のモダンな機能（LINQやAsync/Await）も相まって、開発体験は最高だ。
でもね、ここには落とし穴があるんだ。
今日は、そんな「速度（Velocity）」という甘い蜜の裏側に潜む、僕らが直面している**「見えない敵」**の話をしようと思う。これは、単にコードが汚いとかそういう話じゃない。もっと根本的な、エンジニアとしての「生き様」と「信頼」に関わる話だ。
「とりあえず動く」の代償
僕のチームが抱えているプロジェクト、通称「Legacy Monster（レガシー・モンスター）」について話そう。
数年前に立ち上がったこのWPFプロジェクトは、最初は素晴らしかったらしい。Prismを使った綺麗なモジュール構成、完璧なMVVM、テストカバレッジも80%超え。誰もが誇れるコードベースだった。
しかし、ビジネスが成功し始めると、状況は一変した。
「顧客Aのためにこのボタンを追加してくれ」
「顧客Bの環境だとレンダリングが遅いから、とりあえずCode Behind（コードビハインド）で直接UIを操作して直してくれ」
「リファクタリング？ それでお金は稼げるの？」
わかるだろ？ この感覚。日本でも経験があるかもしれないけど、海外のスタートアップやテック企業の「Grow Fast（急成長）」のプレッシャーは、もっと露骨で直接的だ。
WPFをやっている人なら共感してくれると思うけど、WPFは「行儀よく」作らないとすぐに破綻するフレームワークだ。ViewModelを経由せずにViewを直接いじり始めたり、DependencyPropertyの依存関係がスパゲッティになったり、ResourceDictionaryが肥大化してアプリの起動時間が数秒遅れたり……。
ある日、POのマイケル（仮名）が僕のデスクにやってきてこう言った。
「今度の展示会用に、メイン画面にリアルタイムの3Dグラフを表示したいんだ。ライブラリはある。来週までに頼むよ」
僕はコードを見た。メイン画面のViewModelはすでに3000行を超えている。INotifyPropertyChangedの発火イベントが複雑に絡み合い、どこを触っても予期せぬ場所でバグが起きる状態だった。「ジェンガ」の最後の1本を抜くような作業だ。
正直に言えば、技術的には「可能」だ。汚いコードの上に、さらに汚いコードを継ぎ足せば、来週には動くものができる。マイケルは喜ぶだろう。展示会も成功するかもしれない。
でも、僕はその時、強烈な違和感を覚えたんだ。
「これをやったら、僕はこのコードを二度と愛せなくなる」と。
なぜ私たちは「No」と言えないのか？
海外で働いていると、「Assertive（自己主張）」であることが非常に重要視される。でも、それは単に「ワガママを言う」ことじゃない。プロフェッショナルとしての意見を戦わせることだ。
しかし、多くのエンジニア（特に渡航したての日本人エンジニア）が陥る罠がある。それは、「技術力で認められたい」という焦りだ。
「No」と言うことで、「あいつは能力が低い」と思われるのが怖い。
「リファクタリングが必要です」と言うことで、「プロなら速く書けよ」と言われるのが怖い。
だから、僕たちはつい「Yes」と言ってしまう。「頑張ればなんとかなる（残業すればいい）」と思ってしまう。
そして、その「Yes」が積み重なって、巨大な「技術的負債（Technical Debt）」という利子が膨れ上がっていく。
ここで重要なのは、「技術的負債」という言葉の重みが、エンジニアと非エンジニアの間で決定的に違うということだ。
僕らにとっての負債は、「将来の開発速度を落とす足かせ」であり、「バグの温床」であり、「モチベーションを下げるヘドロ」だ。
しかし、ビジネスサイドにとってはどうだろう？ 彼らにとっては、それは「見えない」のだ。画面上でボタンがクリックできて、データが保存されれば、それで「完了」なのだ。
この認識のギャップこそが、悲劇の始まりだ。
信頼のパラドックス
話を「Legacy Monster」に戻そう。
もし僕がマイケルの要求通り、無理やり3Dグラフを突っ込んだとしよう。展示会は成功する。マイケルは僕を「仕事が速い優秀なエンジニア」として評価するだろう。一見、Win-Winに見える。
だが、その1ヶ月後、別の機能追加の依頼が来たときに何が起こるか？
以前なら3日で終わっていた作業が、あの無理な実装のせいで1週間かかるようになる。
さらにその次は2週間。そして、謎のクラッシュが頻発し始める。
マイケルは言うだろう。
「なんで最近、そんなに遅いの？ 前はもっと速かったじゃないか」
これが**「信頼のパラドックス」**だ。
短期的な要望に応えれば応えるほど、長期的には「開発が遅い」「品質が悪い」というレッテルを貼られ、結果として信頼を失っていく。
「No」を言わずに積み上げた「Yes」が、皮肉にも自分の首を絞めることになるんだ。
特に海外の現場では、パフォーマンス（成果）が全てだ。
「頑張ったから」なんて言い訳は通用しない。「なぜ遅れたのか？」「なぜ品質が落ちたのか？」を論理的に説明できなければ、評価は容赦なく下がる。
僕は、その時デスクでコーヒーを飲みながら、画面上のスパゲッティコード（巨大なXAMLとViewModelの癒着）を見つめ、冷や汗をかいていた。
このまま進めば、このプロジェクトは半年以内に「死ぬ」。メンテナンス不能になり、誰も触りたくない「レガシー」として、チーム全員の士気を削ぐ呪いのアイテムになる。
転機：コードの向こう側を見る
そこで僕は気づいたんだ。
僕が向き合うべき相手は、Visual Studioのエディタでも、C#のコンパイラでもない。
目の前にいる「マイケル（ステークホルダー）」の認識そのものだと。
僕たちが真にプロフェッショナルであるならば、コードを書くだけでは不十分だ。
「技術的負債」という概念を、ビジネスのリスクとして翻訳し、彼らに「教育」しなければならない。
そして、メンテナンス性やスケーラビリティへの投資が、実は「新機能開発」と同じくらい、いや、それ以上にビジネスにとって価値があることだと証明しなければならない。
これは、日本流の「阿吽の呼吸」や「察してちゃん」では絶対に伝わらない。
ロジックと、情熱と、そして少しの「政治力」が必要な戦いだ。
「Beyond the Code（コードを超えて）」というタイトルの意味はそこにある。
C#やWPFの技術力はもちろん大事だ。Dependency Injection（依存性の注入）も、Reactive Extensions（Rx）も使いこなせた方がいい。
でも、それらの技術を**「使い続けることができる環境」を守る力**こそが、シニアエンジニアやリードエンジニア、そして海外で生き残るエンジニアに求められる本当のスキルなんだ。
僕はマイケルの方を向き直り、深呼吸をして口を開いた。
「マイケル、その3Dグラフの件だけど、今のまま実装するのは危険だ。でも、もっと良い方法がある。少し話せるか？」
ここから、僕の（そしてチームの）本当の戦いが始まった。
次回は、この「技術的負債」をどうやってビジネスサイドに理解させ、リファクタリングの時間を勝ち取り、それを「チームの文化」に変えていったのか。その具体的な交渉術とマインドセットについて話そうと思う。
キーワードは、**「技術的負債を『機能』として売る」**だ。
「技術的負債」を「機能」として売り込むマインドセット
マイケルに「話がある」と切り出したあの日、僕は会議室でホワイトボードの前に立っていた。
手には黒のマーカー。背中には冷や汗。
正直に言おう。僕たちエンジニアにとって、コードを書くことは呼吸するより簡単だ。C#の非同期処理（async/await）のデッドロックを回避する方法なら3時間は語れる。でも、ビジネスサイドの人間（POやマネージャー）に、「なぜコードを綺麗にする必要があるのか」を説明するのは、異国の言葉で詩を書くくらい難しい。
日本にいた頃の僕は、これを**「わかってもらう」**ための努力だと思っていた。「技術的な正しさ」を熱弁すれば、相手もいつか理解してくれると信じていたんだ。
でも、海外に来て気づいた。それは間違いだ。
彼らに僕らの言語（技術）を学ばせるんじゃない。僕らが彼らの言語（ビジネス）を話さなければならないんだ。
これが、「Beyond the Code」の第一歩。「翻訳者」としてのエンジニアへの進化だ。
1. 辞書を書き換えろ：「技術用語」を「ビジネス用語」へ
会議室で僕は、マイケルに対して「ViewModelの結合度が…」とか「XAMLの構造が…」といった言葉を一切封印した。なぜなら、その瞬間に彼の目は死に、スマホの通知を気にし始めるからだ。
僕が実践したのは、徹底的な**「語彙の置換」**だ。
海外の現場で戦うなら、以下の「翻訳辞書」を脳内にインストールしておくといい。これが僕の武器だ。
| エンジニアの言葉（NG） | ビジネスへの翻訳（OK） | 殺し文句（英語フレーズ） |
| リファクタリングしたい | 将来の開発速度を買う（投資する） | “We are buying future velocity.” |
| コードが汚い / 負債がある | 市場投入までの時間が遅れるリスクがある | “This creates a ‘Time-to-Market’ risk.” |
| バグが出るかもしれない | ユーザーの信頼とブランドを損なう | “It impacts user trust and brand reputation.” |
| テストコード書きたい | 品質保証のコストを自動化で下げる | “Automating QA cost to focus on features.” |
| WPFのアーキテクチャを守る | 拡張性と変更への柔軟性を確保する | “Ensuring scalability for upcoming requests.” |
僕はマイケルにこう言った。
「マイケル、3Dグラフの追加は可能だ。でも今の土台のままそれを乗せると、**『機能的破綻のリスク（Risk of functional collapse）』**が極めて高くなる。これは君が最も恐れている『展示会でのデモ中のクラッシュ』に直結する」
「クラッシュ」という言葉が出た瞬間、彼が身を乗り出したのがわかった。
「そこで提案だ。今回の実装には、**『スケーラビリティのための準備工数』**を含ませてほしい。これをやることで、今回の3Dグラフだけでなく、次の四半期に予定しているダッシュボード機能の追加も、今の半分の期間でできるようになる。これは『修理』じゃなくて、開発スピードを上げるための『機能』なんだ。」
僕は、「リファクタリング」という言葉を一度も使わずに、リファクタリングの時間を勝ち取った。
彼にとってそれは「掃除」ではなく、「次の機能を早く出すための投資（Deal）」になったからだ。
2. 「見えない負債」を可視化する：レストランの厨房メタファー
それでも、どうしても納得しない強敵もいる。「投資なんていいから、今すぐ出せ」というタイプだ。
そういう時に僕が海外でよく使うのが、「レストランの厨房」のメタファーだ。これは万国共通で通じる最強の武器だ。
「いいかい、僕らは今、ランチタイムのピークを迎えている人気レストランのシェフだ。
オーダー（機能要望）は次々と入ってくる。とにかく皿を出せと言われて、汚れたフライパンを洗わずに次の料理を作り続けている状態だ。
最初の数皿はなんとかなる。でも、やがて作業台は汚れ、食材は混ざり、どこに何があるかわからなくなる。
結果どうなる？ 料理が出るのが遅くなるだけじゃない。客（ユーザー）の料理にゴキブリ（バグ）が混入するんだ。
君が僕に求めている『とりあえず動くコードでいいから出せ』というのは、『皿を洗わずに床に落ちた食材で料理を作れ』と言っているのと同じだ。
僕はプロのシェフ（エンジニア）として、それを客に出すことはできない。なぜなら、食中毒を出して店（会社）が潰れたら、君も困るだろう？」
この話をした時、マイケルは苦笑いしながら言ったよ。
「OK、わかったよ、ゴードン・ラムゼイ（有名な鬼シェフ）。で、掃除にはどれくらいかかるんだ？」
ここで重要なのは、**「プロフェッショナルとしての倫理観」**を盾にすることだ。
「技術的にできない」のではなく、「プロとして、その品質のものは出せない」と主張する。欧米の文化では、この「Professionalism（プロ意識）」へのリスペクトが非常に強い。ここを刺激するんだ。
3. 「20%ルール」の隠蔽と、見積もりのハッキング
さて、ここからは少しグレーだが、実戦的な話をしよう。
毎回毎回、マイケルのようなPOを説得するのは疲れるし、時間もかかる。
だから僕は、ある時期から**「交渉しない」**という選択肢も持つようになった。
それが**「20%の品質税（Quality Tax）」**だ。
機能実装の見積もりを求められた時、僕は心の中でこう計算する。
「純粋な実装に3日。リファクタリングとテスト追加に1日。合計4日」
そして、見積もりとして「4日」を提示する。
ここで「内訳は？ 3日でできるんじゃないの？」と聞かれたら、こう答える。
「これは、『完了の定義（Definition of Done）』を満たすための最短の時間だ」と。
「完了の定義」には、当然ながら以下が含まれる。
- コードがSOLID原則に従っていること。
- ViewModelにロジックが漏れ出していないこと（WPF特有の事情だ）。
- ユニットテストがパスしていること。
これを「オプション」にしてはいけない。
外科医が「手を洗う時間は手術時間に含まれますか？」と患者に聞くだろうか？ 聞かない。それは手術の一部だからだ。
同じように、リファクタリングやテストは「機能開発の一部」であり、わざわざ許可を求めるものではない。そう自分自身を洗脳するんだ。
もし、「もっと早く」と言われたら？
その時は機能を削る（Scope Cut）。品質（Quality）は絶対に削らない。
**「品質は変数ではない。定数だ」**という姿勢を崩してはいけない。一度でも妥協して「汚いコード」を納品すると、それが前例となり、次からはそれがスタンダードになってしまうからだ。
4. 信頼の貯金を崩さないために
結局、あの時の3Dグラフ機能はどうなったか？
僕はマイケルと握手し、当初の予定より2日長いスケジュールをもらった。
その2日間で、僕は3000行あったViewModelを分割し、Behaviorを使ってコードビハインドの処理をXAML側に綺麗に分離した。
結果、3Dグラフはスムーズに動き、展示会は大成功だった。
さらに嬉しかったのは、その翌月だ。
「グラフの色を動的に変えたい」という変更要望が来た時、僕はそれを半日で実装してリリースした。以前のコードなら3日はかかっていただろう。
マイケルは驚いていた。「Wow, that was fast!（え、もうできたの？）」
僕はニヤリと笑って答えた。
「Remember the investment we made last month? It paid off.（先月の投資を覚えてる？ その配当が出たんだよ）」
この瞬間、「技術的負債の解消」という行為が、彼の中で「成功体験」に変わった。
これが最大の成果だ。
一度この信頼（Trust）を勝ち取れば、次はもっと楽になる。
「彼が時間をくれと言うなら、それには意味があるんだ」と信じてもらえるようになるからだ。
これが、技術的負債を「機能」として売り込むマインドセットだ。
必要なのは、高度なプログラミングスキルじゃない。
相手の利益に寄り添い、共通の言語で話し、プロとしての矜持（プライド）を見せることだ。
でも、安心してはいけない。
信頼を勝ち取っても、技術の世界は秒単位で進化していく。WPFも、.NETのバージョンアップと共に変わっていく。
そこで立ち止まれば、今の「綺麗なコード」も、明日には「レガシー」になる。
次回は、この変化し続ける環境の中で、どうやって自分自身とコードベースを進化させ続けるか。
**「転：変化を恐れない：コードベースと共に自分自身もリファクタリングする」**について語ろう。
単なる技術の習得だけじゃない、エンジニアとしての「生存本能」の話になるはずだ。
変化を恐れない：コードベースと共に自分自身もリファクタリングする
マイケルとの交渉に勝ち、プロジェクトにテストコードとリファクタリングの文化が根付いてから半年。
チームは順調だった。バグ報告は減り、リリースのサイクルも安定した。「Legacy Monster」は手懐けられ、僕たちは「平和」を謳歌していた。
だが、海外のテック業界において「平和」とは、「停滞」の同義語だ。そして「停滞」は、エンジニアとしての「死」を意味する。
ある日のランチタイム。同僚のフロントエンドエンジニア（彼はReactとTypeScriptの使い手だ）が、サンドイッチを頬張りながら無邪気にこう言った。
「ねえ、なんで君たちはまだWPFを使ってるの？ MicrosoftはMAUIやBlazorに注力してるし、デスクトップアプリなんてオワコン（Legacy）じゃない？」
僕は喉にコーヒーを詰まらせそうになった。
反論しようとした。「WPFは安定している！」「産業用には最強だ！」と。
でも、言葉が出なかった。なぜなら、僕自身も薄々気づいていたからだ。
僕たちが一生懸命磨き上げているこの「WPFの剣」は、もしかしたら時代の戦場にはもう合っていないのではないか？
この瞬間、僕の敵は「社内の無理解」から、**「自分自身の陳腐化」**へと変わった。
「ぬるま湯」という名の恐怖
海外で働いていると、日本以上に「市場価値（Market Value）」を意識させられる。
LinkedInの通知は正直だ。自分のスキルセットが市場の需要とマッチしている時はスカウトが鳴り止まないが、少しでもトレンドから外れると、潮が引くように静かになる。
WPFは素晴らしい技術だ。XAMLの表現力は今でも色褪せない。しかし、僕たちは「WPFしかできないエンジニア」になってはいけない。
当時の僕は、.NET Framework 4.8 のぬるま湯に浸かっていた。長年使い古したライブラリ、コピペで使い回せる ViewModelBase、暗記しているXAMLのお作法。
これらは「生産性」を生んでいたが、同時に僕の「学習能力」を錆びつかせていたのだ。
「このままでは、このプロジェクトと共に沈む」
そう直感した僕は、ある決断をした。
「コードベースを最新の .NET (Core) へ移行し、アーキテクチャをモダン化する」
そして同時に、**「僕自身の脳みそもアップデートする」**と。
これは、マイケルを説得するよりも遥かに過酷な、自分自身との戦いだった。
アンラーニング（学習棄却）の痛み
「移行なんて簡単だろ？ ツールを使えばいい」
そう思っていた時期が僕にもあった。しかし、蓋を開けてみると地獄が待っていた。
古いWPFプロジェクトは、OSの機能（Win32 API）や、古いサードパーティ製ライブラリにガチガチに依存している。それらが新しい .NET では動かない。
しかし、もっと深刻だったのはコードそのものではなく、**僕たちの「古い考え方」**だった。
例えば、Dependency Injection (DI) だ。
モダンな .NET (.NET 5/6以降) では、DI（Microsoft.Extensions.DependencyInjection）は空気のように当たり前の存在だ。Webだろうがコンソールだろうが、DIコンテナを前提に設計する。
しかし、僕らのWPFコードは違った。
シングルトンパターンの乱用、ServiceLocator という名の「何でも屋」への依存、そして new ViewModel() を平気で書くコードビハインド。
これらをモダンな設計に書き換えようとした時、僕は自分の手が止まるのを感じた。
「えっ、ここで new しちゃダメなの？」
「コンストラクタインジェクション？ 全部のViewModelを書き直すのか？」
長年染み付いた「手癖」を捨てるのは、新しいことを覚えるより100倍苦しい。
これを**「アンラーニング（Unlearning）」**と呼ぶらしいが、まさに身を削る思いだった。自分が「シニアエンジニア」だと思っていたプライドが、「モダンな作法を知らない初心者」へと叩き落とされる感覚だ。
でも、海外の現場で生き残るやつらは、この「痛みを伴う変化」を楽しんでいる。
「Hey, look at this! Source Generators are amazing!（見ろよ、ソースジェネレーターってすげえぞ！）」
チームの若手が目を輝かせて新しい技術を導入してくる。それに負けてはいられない。僕は必死に食らいついた。
RDD（履歴書駆動開発）の誘惑と、真のプラグマティズム
ここで一つの罠について話そう。
**「Resume Driven Development（履歴書駆動開発）」**だ。
技術的負債を返し、モダン化を進める中で、エンジニアはつい「流行りの技術」を使いたくなる。
「Prismをやめて、流行りの CommunityToolkit.Mvvm に全部書き換えよう！」
「Rx (Reactive Extensions) を全部に入れて、リアクティブにしよう！」
これらは、自分の履歴書を飾るには良いかもしれない。でも、ビジネスにとってはどうだ？
動いているコードを、単に「カッコいいから」という理由で書き換えるのは、新たな負債を生む行為だ。
僕はここで、マイケルとの交渉で培った視点を思い出した。
「なぜ、それをやるのか？（Why?）」
僕たちは .NET のバージョンアップを「パフォーマンス向上（起動時間の短縮）」と「デプロイの簡素化（Single File Publish）」という、ビジネスメリットに直結する理由で行うことにした。
ライブラリの置き換えは、それが「メンテナンス不能」になった時だけに行うと決めた。
「最新」を追いかけるのが正解じゃない。
「最適」を選び取れる目利き力こそが、シニアの証だ。
結果として、僕たちはWPFという「枯れたUI」を使いながらも、その中身（バックエンドロジック、通信周り、DI構成）は最新の .NET 技術で武装したハイブリッドなモンスターを作り上げた。
見た目は変わらない。でも、中身は別物だ。ビルドは爆速になり、単体テストは書きやすくなり、何より開発している僕たちの目が再び輝き出した。
アーキテクチャは「建築物」ではなく「庭」である
この一連の騒動（マイグレーション地獄）を通じて、僕は一つ、決定的な真理にたどり着いた。
日本にいた頃、僕は「アーキテクチャ」を**「建築物（Architecture）」**だと思っていた。
最初に完璧な設計図を引き、頑丈な柱を立て、完成したらそこで終わり。あとはメンテナンスするだけ。
でも、それは違う。
ソフトウェア、特に変化の激しいビジネス環境におけるコードベースは、**「庭（Garden）」**なんだ。
雑草（負債）は放っておけば生えてくる。これは自然の摂理だ。
新しい植物（技術）を植えることもあるし、枯れた木（古いライブラリ）を伐採することもある。
「完成」なんてない。あるのは、日々の「手入れ（Gardening）」だけだ。
僕が .NET Framework から .NET 6+ へと移行した経験は、庭の土壌を完全に入れ替えるような大工事だった。
大変だったかって？ ああ、死ぬほど大変だった。
でも、そのおかげで僕たちの庭には、再び新しい花が咲くようになった。
もしあなたが今、「WPFは古いから」とか「今の現場はレガシーだから」と嘆いているなら、伝えておきたい。
レガシーなのは技術じゃない。そこで思考停止している「あなた自身」かもしれない。
古い技術を使っていたって、アプローチは進化させられる。
CI/CDパイプラインを最新にする、静的解析ツールを導入する、ドメイン駆動設計（DDD）を取り入れてみる。
WPFの INotifyPropertyChanged を書くのが面倒なら、Roslyn Source Generators を使って自動生成させればいい。
環境のせいにするな。
海外の荒波で生き残るエンジニアは、与えられた手札（技術スタック）の中で、常に最強のコンボを探し続けている。
こうして僕たちは、技術的負債を返済し、さらに最新の環境へと適応することに成功した。
コードは綺麗になり、チームは自信を取り戻した。
だが、物語はここでは終わらない。
どれだけ良いコードを書いても、どれだけ最新の技術を使っても、それを支えるのは結局のところ**「人」**だ。
一人のスーパーエンジニアが頑張るだけでは、限界がある。
次回、最終章の**「結」では、この変化を個人の努力で終わらせず、どうやって「チーム全体の文化」**として定着させ、みんなで勝利を祝う場所（Happy Place）を作ったかについて話そう。
地味な改修作業を、どうやって「称賛されるべきヒーローの仕事」に変えるか。
それが、”Sustaining Trust”（信頼を持続させる）ための最後のピースだ。
小さな勝利を祝おう：品質が評価される文化をハックする
「平和ボケ」という言葉があるけれど、エンジニアリングの世界において、これほど危険な言葉はない。
マイケルとの信頼関係を築き、最新の .NET 環境を手に入れた僕たち。しかし、半年も経てば、人間というのは忘れる生き物だ。
「ちょっとだけなら、コードビハインドにロジック書いてもいいよね？」
「急いでるから、単体テストは後回しで……」
こうした「悪魔の囁き」は、なくならない。
綺麗になった庭（コードベース）も、手入れをサボれば一瞬で雑草だらけになる。これを防ぐために必要なのは、優秀な庭師を雇うことじゃない。
**「雑草を抜くことが、最高にクールで称賛される行為だ」**という文化を作ることだ。
今回は、僕が海外のチームで実践した、「地味な作業をヒーローインタビューに変える」ための文化ハックを紹介しよう。
1. 「火消し」よりも「防火」を称える仕組み
ソフトウェア開発には、困ったパラドックスがある。
本番環境で障害が起きた時、徹夜で修正して復旧させたエンジニアは「ヒーロー」として称賛される。
一方で、その障害が起きないように、地味にリファクタリングやテスト追加をしていたエンジニアは、誰にも気づかれない。
「火消し（Firefighting）」ばかりが評価される組織は、無意識のうちに「放火魔」を育てているのと同じだ。
僕はチームリーダーとして、この評価軸をひっくり返すことにした。
導入したのは、**「The Scout Award（ボーイスカウト賞）」**だ。
毎週のレトロスペクティブ（ふりかえり）で、「誰が一番、コードを綺麗にしたか？」を投票するようにしたんだ。
- 「Aさんが、あの複雑な
Convertersを整理してくれたおかげで、XAMLが読めるようになった！」 - 「Bさんが、CIのビルド時間を30秒短縮してくれた！」
- 「Cさんが、出力ウィンドウに出続けていた謎のBindingエラーを撲滅してくれた！」（WPFエンジニアなら、これがどれだけ快感かわかるはずだ）
そして、勝者にはスタバのギフトカード（少額でいい）と、Slackの専用チャンネル #wall-of-fame でのド派手な称賛を送った。
効果はてきめんだった。
今まで「誰かがやるだろう」と放置されていた警告（Warning）や、小さなコードの匂いが、競うように掃除され始めたのだ。
みんな、「褒められたい」のだ。大人だって、地味な努力を見ていてほしいのだ。
2. 「完了の定義」に「祝杯」を含める
海外のエンジニアは、パーティが好きだ（偏見かもしれないけど、僕の周りはそうだ）。
だから僕は、リファクタリングという苦行にも「パーティ」の要素を取り入れた。
大きな技術的負債（例えば、古いライブラリの完全撤去や、.NETのメジャーバージョンアップ）を完遂した時は、ただチケットを「Done」にするだけじゃ終わらせない。
**「Funeral for the Legacy（レガシーの葬儀）」**と称して、実際にケーキを買ってきて、チーム全員で祝うイベントにした。
「さようなら、System.Windows.Interactivity。君のおかげでここまで来れたよ。でも、これからは Microsoft.Xaml.Behaviors の時代だ」
冗談みたいだけど、こういう儀式（Ritual）はものすごく大事だ。
これにより、**「コードを削除すること」**が、機能を追加することと同じくらい価値のあるマイルストーンとして記憶に刻まれる。
マイケル（PO）もケーキにつられてやってくる。そこで彼にも改めて伝えることができる。
「見てくれ、このコードが消えたおかげで、次の機能開発はもっと速くなるぞ」と。
こうして、ビジネスサイドも巻き込んで「品質向上を祝う文化」を作っていくんだ。
3. 失敗の共有を「知見」に変える
文化作りでもう一つ重要なのが、**「心理的安全性（Psychological Safety）」**だ。
WPFのような歴史あるフレームワークを使っていると、思わぬ「地雷」を踏むことがある。
例えば、ObservableCollection を別スレッドから操作してアプリをクラッシュさせたり、WPFのメモリリーク（イベントハンドラの解除忘れ）でアプリが重くなったり。
以前のチームでは、こういうミスをしたエンジニアは「すみません」と縮こまっていた。
でも、僕はそれを変えたかった。
「ミスをした奴が悪いんじゃない。ミスをさせる仕組み（API設計）が悪いんだ」
誰かがバグを出した時、僕はこう言うようにした。
「Great catch!（よく見つけた！）」
「君がその地雷を踏んでくれたおかげで、他の全員が助かった。どうすれば二度と踏まないようにできるか、みんなで考えよう」
そして、その対策（例えば、Roslynアナライザーで警告を出すようにするなど）を実装した人を、また全力で褒める。
こうすることで、失敗は「恥」ではなく、チームの資産（Assets）になる。
若手エンジニアも「恐れずにコードを触れる」ようになり、結果として開発速度（Velocity）は落ちるどころか加速していった。
4. あなたのキャリアにとっての意味
最後に、これを読んでいるあなた自身のキャリアについて話そう。
「技術的負債の返済」や「環境の整備」なんて、職務経歴書（Resume）に書いてもアピールにならないと思っていないだろうか？
「○○機能を開発しました」の方がカッコいいと思っていないだろうか？
はっきり言おう。それは逆だ。
海外のシニアエンジニアの採用面接において、最も高く評価されるのは、
「ゼロから何かを作れる人」よりも、
**「泥臭いカオスな状況を整理し、チーム全体の生産性を底上げできる人」**だ。
なぜなら、世の中のプロジェクトの99%は「既存のコード（Brownfield）」であり、どこもかしこも負債だらけだからだ。
「綺麗なコードしか書きたくありません」というお姫様エンジニアよりも、「汚いコードを前にしても怯まず、戦略的に綺麗にしていける」野戦病院の外科医のようなエンジニアの方が、圧倒的に市場価値が高い。
僕がやってきたこと――
ステークホルダーを説得し（承）、
自分自身と技術をアップデートし（転）、
チームの文化を変えた（結）。
これらは全て、単なる「C#コーディング」の枠を超えたスキルだ。
これこそが、タイトルにある “Beyond the Code” の意味だ。
旅の終わりに：次なる冒険者へ
日本から海外へ出て、言葉の壁や文化の壁にぶつかりながら、WPFという少しニッチな武器で戦ってきた僕の物語は、ひとまずここで区切りだ。
もしあなたが今、目の前のスパゲッティコードに絶望しているなら、思い出してほしい。
そのコードは、誰かが必死にビジネスを成功させようとした痕跡だ。
そして、それを「次のステージ」へ進化させられるのは、今そのコードを見ているあなたしかいない。
コードを書こう。
でも、コードだけを見るのはやめよう。
その向こう側にいる「人」を見よう。信頼を築こう。そして、小さな勝利を祝おう。
そうすれば、きっとどこに行っても、どんな技術を使っても、あなたは必要とされるエンジニアになれるはずだ。
さあ、エディタを開こう。まずは小さなリファクタリングから、今日を始めようか。
Good luck, and happy coding!
コメント