見えない「スパーク」と、数字という名の巨大な壁
こんにちは、あるいはこんばんは。
日本から数千キロ離れた異国の地で、今日も今日とてVisual Studioと睨めっこしている一介のC#エンジニアです。
普段はWPF（Windows Presentation Foundation）を使って、デスクトップアプリケーションの設計や開発をゴリゴリやっています。XAMLの記述量が増えるたびに、「ああ、今日も生きてるな」と謎の実感を得る、そんな毎日です。
さて、これから海外で働きたいと思っているエンジニアの皆さん、あるいは今まさに海を渡ろうと準備している皆さんに、一つだけどうしても伝えておきたい「不都合な真実」があります。それは技術力の話でも、語学力の話でもありません。
それは、**「あなたの最高の仕事は、既存のモノサシでは測れないかもしれない」**という現実です。
今日は、そんなエンジニアなら誰しもが一度はぶつかる、けれど誰も教えてくれない「評価と創造性のジレンマ」について、僕の実体験を交えてガッツリ話していこうと思います。長くなりますが、コーヒーでも飲みながら付き合ってください。
1. 異国のオフィスで直面した「数字の亡霊」
海外のテック企業、特に僕がいるような開発現場では、一見すると非常に合理的でクリアな評価制度が整っているように見えます。
「Job Description（職務記述書）」が明確で、「KPI（重要業績評価指標）」が設定され、アジャイル開発における「ベロシティ（開発速度）」が常にモニタリングされています。
日本のような「なんとなく頑張っているからOK」という空気感はありません。それはとてもフェアな世界に見えました。最初は僕もそう思っていました。「コードを書けば書くほど、チケットを消化すればするほど、俺の価値は証明されるんだ」と。
しかし、働き始めてしばらく経ったある日、僕は強烈な違和感を覚えることになります。
きっかけは、ある複雑なUIコンポーネントの改修タスクでした。
WPFを触ったことがある人なら分かると思いますが、データバインディングとUIの描画スレッド、そしてバックグラウンド処理の連携は、時にスパゲッティのように絡み合います。既存のコードは、無理やり継ぎ接ぎされたイベントハンドラだらけで、メモリリークの温床になっていました。
僕に割り当てられたタスクは「機能追加」でしたが、コードを見た瞬間に直感が働きました。
「これは、機能を追加している場合じゃない。土台から腐っている」
そこで僕は、マネージャーに頼まれた機能追加の実装を一晩寝かせ、構造自体をMVVM（Model-View-ViewModel）パターンに則って美しくリファクタリングすることに時間を割きました。
複雑怪奇なコードを削ぎ落とし、ObservableCollectionの扱いを見直し、非同期処理をTaskとasync/awaitできれいに整理しました。
結果どうなったか。
コード行数は半分以下になり、動作は劇的に軽くなり、将来的なバグの温床も一掃されました。
僕の中では「会心の一撃」でした。脳内でドーパミンがドバドバ出る、あの瞬間です。これぞエンジニアリングだ、と。
しかし、翌週のスプリントレビューで僕を待っていたのは、称賛ではなく冷ややかな数字でした。
「今回のスプリント、君のストーリーポイント消化率は平均以下だね」
「Lines of Code（LOC：コード行数）の貢献度もマイナスになっているけど、何か問題があったのか？」
その時、僕は悟りました。
「ああ、彼らは『何を解決したか』ではなく、『どれだけ積み上げたか』しか見ていないんだ」 と。
2. The Elusive Spark：捉えどころのない「閃き」
ここで、今回のテーマである「The Elusive Spark（捉えどころのない閃き）」という概念について触れておきましょう。
エンジニアリングの本質は、キーボードを叩く指の運動量ではありません。モニターの前で腕を組み、天井を見上げ、コーヒーを啜りながら「どうすればもっとシンプルになるか？」「どうすればこの問題を根本から解決できるか？」と思考を巡らせる、その静かな時間にあります。
そして、解決策が降りてくる瞬間――それが「スパーク（閃き）」です。
このスパークによって生み出される解決策は、往々にして「コードを書かないこと」や「既存のコードを捨てること」、あるいは「全く別のアプローチを採用すること」だったりします。
しかし、現在の主流なソフトウェア開発指標の多くは、この「スパーク」を評価する術を持っていません。
- Lines of Code (LOC):コード行数で生産性を測るなんてナンセンスだと誰もが言いますが、それでも無意識のうちに「たくさん書いた人」が「たくさん仕事をした人」に見えてしまうバイアスは強力です。リファクタリングでコードを削除してシステムを健全化したエンジニアは、この指標では「何もしていない」、最悪の場合は「資産を減らした」と見なされかねません。
- Story Points (ストーリーポイント):アジャイル開発でよく使われるこの指標もまた、曲者です。「機能を作ること」にポイントが振られるため、「機能を作らずに問題を解決する（例：既存ライブラリの活用や、仕様自体の見直し）」という高度な判断は、ポイントに反映されにくいのです。
- Velocity (ベロシティ):チームの速度を測る指標ですが、これはあくまで「予測可能性」のためのものです。しかし、独創的なアイデアや抜本的な改善というのは、得てして予測不可能です。定型的なタスクを淡々とこなす方がベロシティは安定し、逆にクリエイティブな挑戦をするほどベロシティは乱れます。
つまり、「創造性を発揮すればするほど、既存のメトリクス上では『非効率』なエンジニアに見えてしまう」 という恐ろしいパラドックスが、現代の開発現場には潜んでいるのです。
3. “How” を無視した “What” の量産
冒頭のフックにもありましたが、従来の指標は「何を作ったか（What）」を教えてくれますが、「どれだけ工夫して、どれだけ独創的に作ったか（How）」については沈黙します。
海外のエージェンシーや多国籍チームで働いていると、日本以上に「Innovation（イノベーション）」という言葉を耳にします。
「我々はイノベーティブでなければならない」「常に新しい価値を創造しろ」
経営陣やマネージャーは口を揃えてそう言います。
しかし、現場の実態はどうでしょう。
彼らが求めている「イノベーション」とは、往々にして「目に見える、分かりやすい新機能」のことです。
画面上に新しいボタンが増えること、新しいレポートが出力されること、AIが何かをサジェストしてくれること。そういった「派手なWhat」は評価されます。
一方で、
「WPFの依存関係プロパティの継承ロジックを見直して、レンダリングパフォーマンスを20%向上させました」
「ジェネリクスを活用して、似たようなクラスを共通化し、将来の修正コストを劇的に下げました」
「非同期処理のデッドロック回避のために、ConfigureAwait(false)の適用ルールをチーム全体に整備しました」
こういった、システムの寿命を延ばし、開発者の精神衛生を守り、長期的な利益を生み出すための「How」の工夫は、ビジネスサイドの人間の目には映りません。彼らのダッシュボードには表示されないからです。
これをこのまま放置しておくと、どうなるか？
エンジニアは賢い生き物です。「工夫しても評価されないなら、言われた通りに動くものを作ればいいんでしょ？」と学習します。
創造性は枯渇し、コードはコピペの継ぎ接ぎになり、技術的負債は雪だるま式に膨れ上がり、最終的には誰も触りたくない「レガシーシステム」が完成します。
これこそが、「創造性を測定基準から無視することが招く、最適ではない解決策の蔓延」です。
4. これから海を渡る君へ：恐怖する必要はない、知っていれば戦える
ここまで読んで、「海外で働くのってやっぱり大変そうだな…」「評価されないなら行きたくないな」と不安に思った方もいるかもしれません。
でも、待ってください。僕がこのブログを書いているのは、皆さんを脅すためではありません。
むしろ逆です。
この「構造的な欠陥」を理解しているエンジニアこそが、海外市場で最も重宝され、最強のポジションを築ける ということを伝えたいのです。
なぜなら、多くのエンジニア（現地の人も含めて）が、この矛盾に苦しみながらも、どう戦えばいいか分からずに疲弊しているからです。
「俺はこんなに凄いコードを書いたのに！」と不満を垂れ流すだけのエンジニアになるか。
それとも、「見えない価値」を可視化し、ビジネスサイドにも分かる言葉で自分の「スパーク」を売り込めるエンジニアになるか。
C#やWPFといった技術スタックは、あくまでツールです。
しかし、「創造性のジレンマ」を乗り越えるためのマインドセットと処世術は、どの国に行っても、どの言語を使っても通用する最強の武器になります。
僕が日本で培った「察する文化」や「細部へのこだわり」、そして海外で学んだ「主張する技術」。これらを掛け合わせた時、初めてこの「数字の壁」を突破するルートが見えてきました。
次回の章では、具体的にWPF開発の現場で僕が直面した「効率化の罠」について、もう少し技術的な話を交えながら掘り下げていきます。
なぜ、良かれと思ってやったリファクタリングが、時にチームの足を引っ張ると見なされてしまうのか。そのメカニズムを解明し、僕らが陥りやすい思考の落とし穴を明らかにしていきましょう。
準備はいいですか？
効率化のパラドックス：なぜ革新的なコードほど評価されにくいのか
前回は、僕たちが直面している「見えないスパーク」と、それを無視する「数字の壁」という現状についてお話ししました。今回は、その闇の奥底へ、もう少し深く潜ってみようと思います。
なぜ、企業はこれほどまでに数値に固執するのか。そして、なぜ僕らエンジニアが良かれと思って発揮した「工夫」が、時として「無駄」と断罪されてしまうのか。
そこには、ソフトウェア開発特有の「効率化のパラドックス」が潜んでいます。
1. 「予測可能性」という名の麻薬
海外のテック企業で働いていると、マネジメント層が口を酸っぱくして言う言葉があります。
それは「Predictability（予測可能性）」です。
ビジネスサイドからすれば、これは当然の要求です。「いつ、何ができるのか」が分からなければ、マーケティングもセールスも動けないからです。
彼らにとって、ソフトウェア開発は「工場」であるべきなのです。材料（要件）を投入すれば、一定の時間（スプリント）で、製品（機能）が出てくる。このラインが安定して動くことを彼らは望んでいます。
しかし、ここで思い出してください。僕たちエンジニアが発揮する「創造性（スパーク）」とは何でしたか？
それは、**「非線形な飛躍」**です。
例えば、ある機能を実装するのに、従来の方法なら5日かかるとします。
ここで創造的なエンジニアは考えます。「待てよ、このロジックを汎用化してライブラリにすれば、今回は7日かかるかもしれないけど、来月からの似たようなタスクは全部1日で終わるぞ」と。
これは素晴らしい「投資」です。しかし、工場のライン長（マネージャーやスクラムマスター）の視点で見るとどうでしょう？
「なぜ、5日で終わるタスクに7日かけているんだ？ ベロシティが落ちているじゃないか！」
これが**「予測可能性の罠」**です。
創造的な解決策は、往々にして「短期的には予測を裏切り（遅れを生じさせ）、長期的には爆発的な利益をもたらす」という性質を持っています。
しかし、2週間単位のスプリントという短いタイムスパンで区切られた世界では、この「長期的な利益」は視界に入りません。目の前のスプリントゴールを達成したか、バーンダウンチャートが綺麗に下がっているか、それだけが正義になりがちです。
僕らは、イノベーションを起こそうとすればするほど、マネジメントが愛してやまない「予測可能な安定」を乱す「ノイズ」として扱われてしまうのです。
2. WPFの現場で起きる悲劇：コピー＆ペースト vs 抽象化
もう少し技術的な話をしましょう。僕の専門であるC#とWPFの現場で実際にあった話です。
ある時、プロジェクトで「複雑なデータグリッドを表示し、各行で特定の条件に応じたグラフを描画する」という要件が降ってきました。
チームには、とにかく手が早くて有名なエンジニア（仮にボブとしましょう）がいました。彼はLOC（コード行数）の王者で、チケット消化率もトップクラスです。
ボブのアプローチはこうでした。
DataGridのテンプレートの中に、大量のGridとRectangleをXAMLでベタ書きし、Code-behind（コードビハインド）でガリガリとイベントハンドラを記述しました。
「動けばいいんだよ、動けば」という精神です。彼は3日で実装を終え、マネージャーから「さすがボブ、早いね！」と称賛されました。
一方、僕はそのコードを見て目眩がしました。
XAMLは数千行に膨れ上がり、ViewModelとの結合度はガチガチ。将来、グラフの種類が増えたら？ デザイン変更があったら？ 全て書き直しになるのは明白でした。
もし僕がここで「創造性」を発揮しようとしたら、どうしたでしょうか。
おそらく、グラフ描画ロジックをカプセル化した「カスタムコントロール」を作成するか、あるいはBehaviorを使ってロジックを分離し、再利用可能なコンポーネントとして設計したでしょう。データテンプレートセレクターを使って、条件分岐もスマートに処理するはずです。
しかし、それをやるには設計に時間がかかります。依存関係プロパティ（Dependency Property）の定義や、ジェネリックなデータ構造の設計など、脳のリソースを大量に使います。実装には5日、あるいは1週間かかるかもしれません。
ここで残酷な比較が生まれます。
- ボブ（コピー＆ペースト）： 3日で完了。コード行数多い（働いた感がある）。すぐに動くものが見える。 → 評価：S
- 僕（抽象化と設計）： 7日で完了。コード行数少ない（サボってる？）。動くものは後半まで見えない。 → 評価：B（あるいは「遅い」と叱責）
従来のメトリクスは、「将来の修正コストを削減したこと」や「コードの可読性を高めたこと」を計測できません。
その結果、皮肉なことに、**「技術的負債を大量生産しながら、見かけ上の機能を素早くリリースするエンジニア」**が最も優秀だと評価されるシステムが出来上がってしまうのです。
これこそが、エンジニアを蝕む最大のストレス源です。
まともな神経をしたエンジニアなら、汚いコードを書くことに苦痛を感じます。しかし、組織の力学が「汚くてもいいから早く出せ（そして数字を稼げ）」と圧力をかけてくる。この板挟みが、多くの優秀なエンジニアをバーンアウト（燃え尽き症候群）に追い込んでいます。
3. 「火消し」ばかりが英雄になる世界
もう一つ、忘れてはならないパラドックスがあります。それは「トラブル対応の評価」です。
システム開発では、バグや障害は付き物です。
深夜に発生したクリティカルなバグを、徹夜で修正してサービスを復旧させたエンジニア。彼は翌朝、チームの英雄として称えられます。「よくやった！ 君がいなければプロジェクトは終わっていた！」と。
しかし、ちょっと待ってください。
もし、別のエンジニアが、設計段階でそのバグが起きないような堅牢なアーキテクチャを組んでいたとしたら？
あるいは、静的解析ツールを導入したり、単体テストを徹底して、そのバグを未然に防いでいたとしたら？
そのエンジニアは、誰からも称賛されません。なぜなら、**「何も起きなかった」**からです。
平和な日常を守った功績は、ドラマチックな「火消し」の物語の前では霞んでしまいます。
メトリクスも同様です。「修正したバグの数」はカウントされますが、「未然に防いだバグの数」をカウントする方法はありません。
結果として、雑なコードを書いてバグを生み出し、それを自分で修正して回る「マッチポンプ」のようなエンジニアが、活動量が多く、貢献度が高いと誤認されるケースが後を絶ちません。
僕らのような、設計や品質にこだわりを持つエンジニアにとって、これほど虚しいことはありません。
「静かなるプロフェッショナル」であることは、現代の騒々しい開発現場においては「存在しない」ことと同義になりかねないのです。
4. コンフォートゾーンという名の沼
ここまで読んで、「じゃあ、どうすればいいんだ？ 諦めてボブのようになればいいのか？」と思った方もいるでしょう。
正直に言います。海外で生き残るためだけなら、ボブになるのは一つの有効な戦略です。
言われた通りのチケットを消化し、小難しい設計論は捨てて、コピペで量産する。定時で帰り、給料をもらう。それも一つの人生です。
しかし、この記事を読んでいるあなたは、きっとそれでは満足できないはずです。
なぜなら、あなたは「エンジニア」だからです。
より良いものを作りたい、美しく解決したい、という欲求（スパーク）を魂に刻まれているからです。
それに、ボブの戦略には致命的な弱点があります。それは、技術の進化に取り残されることです。
コピペと力技で凌いでいる間に、AIコーディングアシスタントが台頭してきました。単純なコード記述なら、もはやAIの方が早くて正確です。
「What（何を作るか）」だけの作業は、いずれ自動化されます。その時、最後に残る価値は「How（どう作るか）」、つまり僕らが信じてきた「創造性」と「設計力」なのです。
だからこそ、僕たちはこのパラドックスに飲み込まれてはいけません。
現状のメトリクスが腐っていることを理解した上で、それでもなお、自分の創造性を守り抜く必要があります。
しかし、ただ黙々と良いコードを書いているだけでは、評価されないまま終わってしまいます。
日本人の美徳である「陰徳善事（人知れず良いことをする）」は、残念ながら海外のビジネスシーンでは通用しません。見えないものは、ないものと同じです。
では、どうやってこの「見えないスパーク」を可視化し、ビジネスサイドに認めさせ、正当な評価を勝ち取るのか？
システムをハックする側である僕たちが、この「評価システム」自体をハックすることはできないのか？
次回の「転」では、いよいよその具体的な戦略についてお話しします。
エンジニアリングの言葉ではなく、ビジネスの言葉を使って、創造性を「利益」に翻訳する技術。
評価されないなら、評価されるストーリーを自分で作ればいい。
そのための「逆転の発想」を、僕の実践例と共に公開します。
ハック・ザ・システム：「創造性」をビジネスの言葉に翻訳する技術
前回、僕は「コピペエンジニアのボブ」と「設計にこだわる僕」の対比を通じて、効率化のパラドックスについて語りました。
正直、あの頃の僕は腐っていました。「なんでわかってくれないんだ」「こんな会社、レベルが低い」と、居酒屋で管を巻く（海外なのでパブでビールですが）日々でした。
しかし、ある時ふと気づいたのです。
WPFで「Adapterパターン」を使う時、互換性のないインターフェース同士をどう繋ぎますか？
ラッパーを噛ませて、相手が理解できる形にデータを変換して渡しますよね。
僕とマネージャー（ビジネスサイド）の間には、インターフェースの不一致があるだけではないか？
彼らが悪いわけでも、僕が悪いわけでもない。単に、僕が**「技術語（Tech Speak）」を喋り、彼らが「ビジネス語（Business Speak）」**を喋っている。その間に「翻訳機（Adapter）」がないことがバグの正体ではないか、と。
そこで僕は決意しました。
「待っていても誰も翻訳してくれない。なら、僕自身がそのAdapterになろう」と。
ここからの逆転劇は、コードを書く技術ではなく、**「価値を定義する技術」**へのシフトチェンジから始まりました。
1. 「リファクタリング」は禁句だと思え
まず最初に変えたのは、言葉の選び方です。
エンジニアがつい口にしてしまう「リファクタリング」「技術的負債の返済」「コードのクリーンアップ」。
これらは、エンジニアにとっては神聖な行為ですが、ビジネスサイドにとっては**「金にならない趣味の時間」または「動いているものを壊すリスクのある行為」**にしか聞こえません。
僕は、これらの言葉を「ビジネス語」に翻訳する辞書を脳内に作りました。
- ×「リファクタリングします」
- ○「将来の機能追加にかかる時間を40%削減するための、基盤整備を行います（Time to Marketの短縮）」
- ×「このコードは汚いので書き直したいです」
- ○「現在の構造ではバグ発生率が高く、サポートコストが圧迫されています。これを解消し、運用コストを下げます（Risk & Cost Reduction）」
- ×「新しいライブラリ（PrismやReactiveProperty）を導入したいです」
- ○「開発標準を統一し、新しいメンバーのオンボーディング（戦力化）にかかる期間を2週間から3日に短縮します（Scalability）」
例えば、以前話した「MVVMへの書き換え」の件。
もし僕が今やり直すなら、こう言います。
「現在、UIの変更があるたびにロジックの修正が必要で、テストに3日かかっています。アーキテクチャを変更することで、UI変更の影響をロジックから切り離し、変更コストを半減させます。これにより、次の四半期のリリースサイクルを加速できます」
中身は同じリファクタリングです。でも、アウトプットの定義が「きれいなコード」から「コスト削減とスピードアップ」に変わっています。
彼らのKPI（金、時間、リスク）に紐づけて提案する。これが「翻訳」の基本です。
2. 見えない価値を「勝手に」可視化する（Shadow Metrics）
既存のメトリクス（LOCやベロシティ）がクソなら、どうするか。
文句を言うのではなく、**「自分に都合の良いメトリクス」**を勝手に作って、それをレポートにねじ込むのです。
僕はこれを「Shadow Metrics（影の指標）」と呼んでハックに使いました。
あるプロジェクトで、WPFのレンダリングパフォーマンスを改善した時です。
上司は「機能は増えてないよね？」という顔をしていました。
そこで僕は、Jiraのチケットに勝手にこんなグラフを添付しました。
- Before: 画面起動時間 3.5秒 / メモリ使用量 400MB
- After: 画面起動時間 0.8秒 / メモリ使用量 150MB
- Impact: ユーザーの待ち時間を1日あたり累計10分削減。これは従業員100人で換算すると、年間◯◯ドルの生産性向上に相当。
数字は強いです。特に「お金（ドル）」や「時間」に換算された数字は、マネージャーがさらに上の上司に報告する時の「武器」になります。
「僕が頑張った」ではなく、「僕の仕事によって、あなたのチームはこれだけの成果を出したことになりますよ」と材料を渡してあげるのです。
これを繰り返すと、面白いことが起きます。
マネージャーが、LOCではなく、僕が提出する「改善レポート」の方を楽しみにし始めるのです。
「次はどこを速くできる？」「どこを削減できる？」と聞いてくるようになります。
こうなればこっちのものです。僕は堂々と「創造的な仕事（スパーク）」に時間を割き、それを成果として認めさせることができるようになりました。
3. 「火消し」ではなく「防火設備」を売り込む
「承」で触れた、「バグを出さないエンジニアは評価されない問題」。
これを解決するために、僕は**「Pre-Mortem（事前検死）」**という手法を取り入れました。
通常、プロジェクトが終わった後に「Post-Mortem（反省会）」をやりますよね？
そうではなく、設計段階や実装中に、「もしこの工夫をしなかったら、どんな地獄が待っていたか」をドキュメント化しておくのです。
例えば、並行処理でデッドロックが起きそうな箇所を、SemaphoreSlimを使って回避したとします。
コードレビューや日報で、こう書きます。
「ここで従来の方法を使うと、高負荷時に1%の確率でデッドロックが発生し、アプリがフリーズする可能性がありました（過去の類似事例へのリンク）。今回はこのパターンを適用することで、そのリスクを完全に排除しました」
つまり、「起きなかった災害」をシミュレーションし、「私がそれを未然に防いだ」という事実をストーリーとして残すのです。
これをやることで、「何も起きなかった」のではなく、「平穏無事という成果を勝ち取った」という認識に変えることができます。
「保険」と同じです。事故が起きなくても保険料を払う価値があるように、僕の設計力は「プロジェクトの保険」であると認識させるのです。
4. Brag Document（自慢ドキュメント）をつける
海外のエンジニア界隈で最近よく言われるのが、**「Brag Document（自慢ドキュメント）」**の重要性です。
謙虚さは美徳ですが、評価面談では敵です。
半年も前の「ちょっとした工夫」なんて、自分も忘れているし、上司が覚えているわけがありません。
僕は、Google Docsに自分専用の「成果メモ」を作っています。
そこには、「何を作ったか（What）」だけでなく、「どんな工夫をしたか（How）」「誰を助けたか（Who）」「何を防いだか（Risk）」を箇条書きでメモり続けました。
- 10/5: 〇〇機能の実装で、WPFのコンバーターを汎用化。他のメンバーも使えるようにNugetパッケージ化して共有。→ チーム全体の工数削減に貢献。
- 11/12: 新人のコードレビューで、メモリリークの可能性を指摘し修正。→ クラッシュ率低下に貢献。
- 12/1: デザイナーと折衝して、実装コストが高いアニメーションを、効果が同じで軽い実装に代替案提示。→ 開発期間を2日短縮。
評価面談の時、このドキュメントをそのままマネージャーに見せます。
「君、今期は何をした？」と聞かれたら、「これを読んでください」で終わりです。
そこには、LOCやチケット数には表れない「質的な貢献」が、具体的なエピソードと共に羅列されています。
これを突きつけられて、低い評価をつけることができるマネージャーはいません。
なぜなら、もし低い評価をつけて僕が辞めたら、これだけの「見えない貢献」が全て失われることが可視化されているからです。
5. マネージャーを「教育」する（Managing Up）
最後に、一番ハードルが高いですが、最も効果的なハックを。
それは、**「上司を教育する（Managing Up）」**ことです。
マネージャーの多くは、悪意があってLOCを見ているわけではありません。
「それ以外に見るべき指標を知らない」だけなのです。
だから、1on1のミーティングで、僕は少しずつ彼らに「エンジニアリングの勘所」を教え込みました。
「コードの行数は、少なければ少ないほどバグが減るんですよ」
「早く作ることより、変更しやすく作ることの方が、半年後の開発スピードを上げるんですよ」
これを、実際の事例（僕が翻訳した成果）を見せながら、粘り強く伝え続けました。
すると、彼らの意識も少しずつ変わっていきます。
「今回はLOCが少ないけど、かなり構造を整理してくれたんだね？」と、向こうから聞いてくれるようになる。
ここまで来れば、システムハックは完了です。
あなたは、既存の腐ったメトリクスの上で踊らされる「リソース」ではなく、ビジネスパートナーとして対等に話ができる「エンジニア」としての地位を確立できます。
こうして僕は、海外の荒波の中で溺れかけていた状態から、自分の価値を証明し、自由な裁量権（＝創造性を発揮できる環境）を勝ち取っていきました。
「郷に入っては郷に従え」と言いますが、もしその郷のルールが間違っていたら？
従うふりをして、ルールの方を書き換えてしまえばいいのです。
だって、僕らはシステムを作るエンジニアなんですから。
さて、これで僕の「生存戦略」の種明かしはほぼ終わりました。
しかし、最後に一つだけ。
これらのテクニックを駆使して「評価」を得た先に、僕らエンジニアは何を目指すべきなのか？
単に給料が上がればそれでいいのか？
次回の最終章「結」では、これからの時代（AI時代も含めて）に求められる、真のエンジニア像について。
そして、数字や評価を超えた先にある、僕らが本当に大切にすべき「プライド」について語り、このシリーズを締めくくりたいと思います。
エンジニアの真価は、何を書いたかではなく、**「何を減らしたか」**で決まる。
その本当の意味を、最後にお伝えします。
エンジニアの真価は「何を減らしたか」で決まる
長い旅の終着点へようこそ。
C#とWPFを愛する一人のエンジニアとして、そして海外という荒野でサバイバルしてきた先輩として、最後にあなたに贈りたい言葉があります。
それは、「足し算のエンジニアになるな、引き算のエンジニアになれ」 ということです。
1. 「生産性」の定義を書き換える
これまでの章で、従来のメトリクス（LOCやチケット数）がいかに「量」を賛美し、「質」を軽視してきたかを語りました。
多くのエンジニア、特に若手の頃は、この圧力に負けて「何かを足すこと」で自分の存在証明をしようとします。
- 新しい機能を追加する。
- 新しいライブラリを導入する。
- 複雑なデザインパターンを適用する。
- コードの行数を増やす。
これらは全て「足し算」です。足し算は気持ちいいのです。「仕事をした！」という実感が湧きやすいからです。
しかし、熟練したエンジニア――僕が海外で出会った、本当に「魔法使い（Wizard）」と呼ばれていたトップティアのエンジニアたち――は、全く逆のことをしていました。
彼らの仕事は、常に**「引き算」**でした。
- 不要な機能を仕様から削ぎ落とす。
- 過剰な抽象化を取り除き、シンプルにする。
- 重複したコードを削除し、共通化する。
- 会議を減らし、プロセスを簡略化する。
彼らがプルリクエストを出すと、追加された行数（緑）よりも、削除された行数（赤）の方が圧倒的に多いことがよくありました。
WPFのXAMLで言えば、初心者がStackPanelとGridを何重にもネストして書いた100行のレイアウトを、魔法使いはたった1つのGridと適切なStyle定義で20行に書き直してしまうようなものです。
真の生産性とは、「どれだけ作ったか」ではなく、「どれだけ不要なものを作らずに済ませたか」で測られるべきです。
なぜなら、ソフトウェア開発において「コード」とは資産であると同時に、最大の「負債（Liability）」だからです。
コードが存在する限り、そこにはバグが潜む可能性があり、メンテナンスのコストがかかり、読むための認知負荷がかかります。
最高のコードとは、極論を言えば「書かれなかったコード」です。
問題を解決しつつ、コードを一行も書かずに済むなら、それが最高のエンジニアリングです（例えば、既存ツールの設定変更だけで済ませるとか）。
「スパーク（閃き）」とは、まさにこの**「書かずに解決する道」や「劇的にシンプルにする道」**を見つけ出すために必要なのです。
2. AI時代のエンジニアの役割：生成者から「選定者」へ
今、GitHub CopilotやChatGPTのようなAIツールが、開発現場を席巻しています。
これからの数年で、この流れは決定的になるでしょう。
「ボブ（量産型エンジニア）」の仕事は、AIに奪われます。
「この要件でクラスを作って」と言えば、AIはボブよりも速く、ボブよりも正確な文法で、大量のコードを吐き出してくれるからです。
もしあなたが「コードを書くスピード」や「量の多さ」だけで勝負しようとしているなら、残念ながら未来は暗いです。
しかし、だからこそ「The Elusive Spark（捉えどころのない閃き）」を持つエンジニアの価値は、かつてないほど高騰します。
AIは「足し算」が得意です。放っておけば、無限にコードを生成し、無限に複雑さを増大させることもできます。
そんな時代において、人間である僕たちに求められる役割は、**「剪定（せんてい）者」**になることです。
- AIが提案した10通りの実装の中から、プロジェクトの長期的なビジョンに合致する、最もシンプルで堅牢な「1つ」を選び取る審美眼。
- AIが生成した冗長なボイラープレートを、勇気を持って削除する判断力。
- 「そもそも、その機能はユーザーにとって本当に必要なのか？」と問い直し、開発自体を止める（＝負債を作らせない）勇気。
これらは、コンテキスト（文脈）を深く理解し、美意識を持った人間にしかできません。
「The Spark」とは、混沌とした情報の海の中から、きらりと光る「本質」を見つけ出し、それ以外を捨て去る力のことなのです。
3. 日本人エンジニアの武器：「禅」のマインドセット
ここで少し、僕ら日本人のアイデンティティの話をしましょう。
海外に出て働くと痛感しますが、日本人が文化的に持っている感覚は、エンジニアリングにおいて強力な武器になります。
それは「引き算の美学」です。
「Less is More（少ないことは、より豊かである）」
「Wabi-Sabi（不完全さや簡素さの中に美を見る）」
ゴチャゴチャと機能満載のアプリよりも、研ぎ澄まされた単機能のアプリを美しいと感じる感性。
行間を読み、余白（Ma）を大切にする姿勢。
これらは、複雑怪奇になりがちな現代のソフトウェア開発において、最強の解毒剤になります。
海外の同僚が「もっと機能を追加しようぜ！」「もっと複雑なアーキテクチャにしようぜ！」と盛り上がっている時、僕は会議で静かに手を挙げてこう言います。
「シンプルにいこう（Keep it Simple）。今の実装はOver-engineering（やりすぎ）だ。将来の自分たちがメンテナンスしやすいように、今は愚直なまでに単純な実装にしておこう」
この一言が言えるエンジニアは、めちゃくちゃ信頼されます。
なぜなら、誰もが心の奥底では「複雑なのは嫌だ、怖い」と思っているからです。
その不安を解消し、クリアな道筋を示してくれる「引き算の提案」は、チームに安心感を与えます。
あなたが海外に出る時、英語が完璧である必要はありません。
でも、この**「複雑さを憎み、単純さを愛する心」**だけは持って行ってください。
それが、あなたのエンジニアとしてのブランドになります。
4. 最後に：見えない価値を信じて、海を渡れ
長くなりましたが、これが僕からの「海外エンジニア生存戦略」の全てです。
- 現実は厳しい： 既存の評価指標は、あなたの創造性を無視するかもしれない。（起）
- 構造を知れ： 効率化のパラドックスにより、良い仕事ほど「遅く」見えてしまう。（承）
- 言葉を変えろ： 技術をビジネス価値に翻訳し、自分のルールで評価させる。（転）
- 本質を貫け： 足し算ではなく引き算で貢献し、複雑さと戦う守護者になれ。（結）
これから海を渡ろうとしているあなたへ。
不安はあると思います。「自分の技術は通用するのか」「評価されずに埋もれてしまうのではないか」。
でも、大丈夫です。
あなたがモニターの前で悩み、苦しみ、そして「ハッ」と閃いたその瞬間の価値は、国境を越えます。
その「スパーク」が、ユーザーの体験を良くし、チームの負担を減らし、ビジネスを救うことを、僕は知っています。
もし、評価指標があなたを正当に評価してくれないなら、堂々とハックしてください。
Brag Documentを書き、Shadow Metricsを提示し、上司を教育してください。
それは「ズル」ではありません。あなたの正しい価値を伝えるための、プロフェッショナルな義務です。
そしていつか、どこかの国のオフィスで、あるいはリモート会議の画面越しに、
「おっ、いい引き算のコード書くね！」
と、あなたと乾杯できる日を楽しみにしています。
コード行数よりも、あなたの人生の「物語（ストーリー）」の方が、ずっと価値があるのですから。
それでは、また。
Happy Coding & Keep Sparking!
コメント