技術偏重の罠：なぜ私たちは「使われない傑作」を作ってしまうのか？
完璧なコード、完璧な絶望
正直に告白します。僕はかつて、**「コードが美しければ、世界は救われる」**と本気で信じているタイプのエンジニアでした。
日本で働いていた頃も、そして海外に来て最初の数年も、僕の頭の中は常に「いかにエレガントに実装するか」で埋め尽くされていました。C#の最新機能を追いかけ、WPFのXAMLを芸術的に記述し、MVVMパターンを厳格に守り、依存性の注入（DI）を完璧に構成する。単体テストのカバレッジは常に100%近くをキープし、誰が見ても「美しい」と唸るような設計をすることに、無上の喜びを感じていたんです。
あるプロジェクトでのこと。
現地のプロダクトマネージャー（PM）から、「既存のデータグリッド（表形式のデータ表示）のパフォーマンスが悪いから、改善してほしい」というタスクが振られました。
僕は心の中でガッツポーズをしました。「待ってました」と。
WPFにおけるUI仮想化（Virtualization）や、非同期データのバインディング、メモリ管理は僕の得意分野です。僕はすぐに設計に入りました。
「どうせなら、将来的にどんなデータ型でも受け入れられるような、完全なジェネリック・コントロールを作ろう」
「リフレクションを使って動的にカラムを生成して、ソートもフィルタリングも全部自前で高速化しよう」
「Behaviorsを使って、XAML側で宣言的に機能追加できるようにしよう」
僕は週末も惜しんでコーディングに没頭しました。複雑なロジックを、驚くほどスッキリとしたインターフェースで包み込む。我ながら惚れ惚れするような「神クラス」が出来上がりつつありました。技術的な難易度が高ければ高いほど、脳内麻薬がドバドバ出るあの感覚、エンジニアなら分かりますよね？
2週間後、僕は自信満々でデモを行いました。
数百万行のデータをサクサクとスクロールし、瞬時にフィルタリングする僕の「傑作」を見て、チームメンバー（特に他のデベロッパー）は「Wow, nice work!」と称賛してくれました。僕は鼻高々でした。「見たか、これが日本のエンジニアの技術力だ！」と。
しかし、そのデモの最後、PMが静かにこう言ったんです。
「で、ユーザーはこれをどうやって使うの？ Excelにエクスポートボタンはどこ？」
僕は固まりました。
「え？ いや、今回の要件はパフォーマンス改善ですよね？ エクスポート機能なんてチケットに書いてありませんでしたけど……」
PMは肩をすくめて言いました。
「ユーザーがパフォーマンスに文句を言っていたのは、彼らがデータを画面上で見るためじゃなくて、全データを素早くダウンロードしてExcelで加工したかったからだよ。画面描画が速くなっても、エクスポート機能がなければ、彼らにとってこのツールは無意味だ。君のこの素晴らしいグリッドは、誰も使わないよ。」
その瞬間、頭をハンマーで殴られたような衝撃を受けました。
僕が2週間かけて磨き上げた「拡張性抜群のジェネリック・データグリッド」は、そのプロジェクトにおいて無価値だと宣告されたんです。
エンジニアが陥る「手段の目的化」
この経験は、僕にとってトラウマに近いものでしたが、同時に海外で働く上での決定的な「気づき」を与えてくれました。
僕たちエンジニア、特に技術が好きな人間ほど、「問題の解決（Outcome）」よりも「解決策の実装（Output）」に恋をしてしまう傾向があります。
C#が好き、WPFが好き、このアーキテクチャを試したい、Rustで書き直したい、マイクロサービス化したい……。
これらはすべて「How（どうやって）」の話です。しかし、ビジネスやユーザーにとって重要なのは常に「Why（なぜ）」と「What（なにを）」だけです。
日本にいた頃は、詳細な仕様書が降りてきて、それを忠実に、高品質に実装することが「正義」とされる場面が多かったように思います（もちろん現場によりますが）。「仕様通りに作ったのに使われないのは、仕様を決めた人の責任」という逃げ道が、心のどこかにありました。
しかし、海外（特に欧米のスタートアップやテック企業）では、その理屈は通用しません。エンジニアは「コーダー（コードを書く人）」ではなく、「プロブレム・ソルバー（問題を解決する人）」として雇われているからです。給料が高いのは、複雑なコードが書けるからではなく、複雑なビジネス課題を技術で解決してくれると期待されているからです。
僕が陥っていたのは、「The Engineer’s Blind Spot（エンジニアの盲点）」。
つまり、**「技術的な卓越性が、必ずしも製品の成功につながらない」**という冷徹な事実から目を背け、自分の得意な土俵（コーディング）に逃げ込んでいただけだったのです。
なぜ「コード」だけでは不十分なのか
では、なぜ今の時代、特に海外の環境において「コードだけ」では不十分なのでしょうか。ここには、大きく分けて3つの背景があります。
1. 「正解」のない時代の到来
昔のように、ウォーターフォールで要件がガチガチに固まっていて、それを半年かけて作る……というプロジェクトは激減しました。特にWebやアプリの世界では、アジャイルが当たり前。
「何が正解か分からないから、とりあえず最小限（MVP）で作って、ユーザーの反応を見よう」というスタイルが主流です。
この環境下で、僕のように「仕様書にはないけど、将来のために汎用的に作っておきました！」なんてことをやると、それは称賛されるどころか**「Over-engineering（過剰設計）」として批判の対象になります。「YAGNI（You Aren’t Gonna Need It：それ、いま必要ないよね？）」の原則に反するからです。
不確実性が高い環境では、完璧なコードを書くことよりも、「間違ったコードを書かない（無駄なものを作らない）判断力」**の方が遥かに価値が高いのです。
2. コモディティ化とAIの台頭
これは皆さんも肌で感じていることでしょう。GitHub CopilotやChatGPTの登場で、「要件さえ決まっていれば、そこそこのコード」は誰でも（あるいはAIが）一瞬で書ける時代になりました。
「WPFでDataGridのスタイルをカスタマイズするXAMLを書いて」と言えば、AIは数秒で出力してくれます。
つまり、「How（どう書くか）」の価値は相対的に下がり続けているのです。
これからのエンジニアに求められるのは、「AIに何を指示するか」「そもそも何を作るべきか」を定義する力です。
「俺はメモリ管理まで意識したC#が書ける！」という誇りは素晴らしいですが、それ”だけ”では、残念ながら市場価値を維持するのが難しくなってきています。
3. 海外特有の「成果主義」と「ジョブディスクリプション」
日本でよくある「頑張っているから評価する」という文化は、僕のいる環境にはほぼありません。
評価面談で「コードの品質を上げました」「リファクタリングで可読性を高めました」とアピールしても、
「で、それによって売上は上がったの？ ユーザーの離脱率は下がったの？ 開発速度は何％向上したの？」と数字で詰められます。
「見えない部分の品質」は、エンジニアとしての良心であり、長期的には絶対に必要なものです。しかし、それを「ビジネスの言葉」に翻訳して価値を証明できなければ、海外では「自己満足」と切り捨てられてしまうリスクがあるのです。
「優秀なエンジニア」の定義が変わった
僕はこの「盲点」に気づくまでに、多くの時間を無駄にしました。
夜遅くまで会社に残って、誰も読まないドキュメントを整備したり、誰も使わない機能の単体テストを書いたりしていました。「これがプロフェッショナルだ」と信じて。
でも、それは違いました。
本当のプロフェッショナルとは、**「コードを書かないという選択肢」**を持てるエンジニアのことです。
「その機能、本当に必要？ Excelのエクスポートがあれば解決するんじゃない？」と、コードを書く前に提案できる人こそが、真に優秀なエンジニアだったのです。
僕たちが海外で、そしてこれからのAI時代に生き残るためには、この「技術偏重の盲点」から脱出しなければなりません。
「良いコード」を書くことは前提条件（ミニマム・リクワイアメント）に過ぎず、その先にある「良いプロダクト」へのコミットメントが求められているのです。
ここまでの話を聞いて、「なんだよ、じゃあ技術を磨くのは無駄なのか？」と怒りを感じた方もいるかもしれません。
違います。技術は武器です。最強の武器です。
ただ、「武器の使い方」と「戦うべき相手」を見誤っているエンジニアがあまりにも多い、というのが僕の主張です。
僕の失敗談である「最強のデータグリッド」の話には続きがあります。
実はこの後、僕はボロボロになりながらも、ある方法論を取り入れることでチーム内での信頼を勝ち取り、最終的には「技術も分かり、ビジネスも分かるエンジニア」としてのポジションを確立することができました。
次回の【承】では、この「技術偏重の盲点」が具体的にどのようなメカニズムでプロジェクトを崩壊させるのか、そして僕たちが普段良かれと思ってやっている「ベストプラクティス」がいかにして「最悪の結果」を招くことがあるのか、さらに深掘りしていきたいと思います。
キーワードは、**「エンジニアリングの自己目的化」と「ユーザー不在の最適化」**です。
幻想の崩壊：完璧なアーキテクチャがビジネスに殺される瞬間
「MVVMポリス」になっていませんか？
前回の記事で、僕は「使われない神機能」を作ってPMに一刀両断された話をしました。あの時の恥ずかしさは今でも忘れませんが、実はその失敗の根底には、もっと根深い病巣がありました。
それが、**「アーキテクチャへの盲信」**です。
WPFをやっている人なら、MVVM（Model-View-ViewModel）パターンは親の顔より見ていると思います。「ViewとLogicを分離し、テスト容易性を高め、保守性を上げる」……教科書的には100点満点の正解です。僕も日本にいた頃は、コードレビューで他人のコードを見ながら、
「ここ、ViewModelのロジックがViewに漏れてますね。Interfaceを切ってDI（依存性の注入）してください」
なんて指摘を、鬼の首を取ったように繰り返していました。いわゆる「MVVMポリス」です。
海外に来て参加したあるスタートアップのプロジェクトで、僕はその「正義」を振りかざしました。
簡単な設定画面を作るタスクでした。入力項目が3つだけの、本当に些細な画面です。
僕はいつものようにPrismライブラリを使い、完璧な構成を目指しました。
- ViewとViewModelの完全分離
- Model層のリポジトリパターン化
- サービス層のInterface抽出とDIコンテナへの登録
- バリデーションロジックの共通化
- 全てのコマンドに対する単体テスト
たった3項目の画面を作るのに、クラスファイルが10個以上生成されました。コード行数は数百行。
「これで将来、DBが変わっても、UIがConsoleアプリになっても大丈夫だ」
僕は悦に入っていました。
しかし、翌日のスタンドアップミーティング（朝会）で、事態は急変します。
「競合他社が似た機能を出してきた。我々は仕様を変更して、今週中にリリースする。設定項目は全部変えるし、画面遷移もウィザード形式にする」
僕の作った「完璧な城」は、一瞬で瓦礫の山になりました。
厳密に分離しすぎたレイヤー、ガチガチに固めたInterface、大量のボイラープレートコード……それら全てが、仕様変更の足枷（あしかせ）になったのです。
「ここを変えるには、Interfaceを直して、Mockデータを直して、単体テストを直して……」
修正にかかる工数を見積もった時、隣にいた「雑なコードを書く」と僕が馬鹿にしていた同僚のジュニアエンジニアが言いました。
「え？ Code-behind（Viewの裏側）に直接書いちゃえば、1時間で終わるよ？」
彼はその通り、MVVMなんて無視して、クリックイベントハンドラに直接ロジックを書きなぐり、あっという間に動くものを作ってしまいました。汚いコードです。テストもありません。でも、彼はビジネスのスピードに勝ち、僕は負けたのです。
「Resume Driven Development（履歴書駆動開発）」の罪
この時、僕は強烈に思い知らされました。
「変更に強いアーキテクチャ」を目指していたはずが、いつの間にか「変更を拒む重厚長大な要塞」を作っていたのだと。
なぜ、僕たちはここまでのめり込んでしまうのでしょうか？
海外のテックブログでよく議論される言葉に、**「Resume Driven Development（履歴書駆動開発）」という皮肉があります。
これは、プロジェクトの成功のためではなく、「自分の職務経歴書（レジュメ）に書きたい技術」**を使って開発することを指します。
「Kubernetesを使いました」
「マイクロサービスアーキテクチャで設計しました」
「完全なクリーンアーキテクチャを実装しました」
これらはエンジニアとしての市場価値を高めるキーワードに見えます。僕自身、転職活動のために「最新の.NET Coreで、DDD（ドメイン駆動設計）を実践したい」という欲求が常にありました。
しかし、その欲求が暴走すると、本来シンプルなCRUD（読み書き）だけで済むアプリを、無駄に複雑なマイクロサービスに分割したりしてしまうのです。
結果どうなるか？
**「ユーザー不在の最適化」**が始まります。
まだユーザーが100人もいないのに、「100万人のアクセスに耐えるスケーラビリティ」を議論し始める。
データベースなんて最初はSQL Server 1つでいいのに、「将来NoSQLに移行するかもしれないから」と抽象化レイヤーを挟んで開発速度を落とす。
これらは全て、エンジニアのエゴです。
ビジネスサイド（経営者や投資家）から見れば、これは**「過剰品質という名の横領」**に近い行為だと、現地のCTOに言われたことがあります。
「君たちが楽しむためのサンドボックスとして会社があるんじゃない。我々は金を稼ぐためにコードを書いているんだ」と。
ぐうの音も出ませんでした。
技術的負債の「本当の意味」
ここで誤解しないでほしいのは、「汚いコードを書け」と推奨しているわけではないということです。スパゲッティコードは論外です。
しかし、海外の現場で学んだのは、「技術的負債（Technical Debt）」の捉え方が日本と少し違うという点です。
日本では「技術的負債＝悪＝即座に返済すべきもの」と考えられがちです。
しかし、金融の「負債（借金）」がそうであるように、**「時間を買うための戦略的な借金」**は、ビジネスにおいて正義な場合があります。
「今はあえて汚く書く。MVVMも崩す。その代わり、競合より1ヶ月早くリリースしてシェアを奪う。コードが汚れた分は、儲かったお金で人を雇って、後でリファクタリング（返済）する」
この判断ができるエンジニアこそが、海外では「シニアエンジニア」として重宝されます。
逆に、「いや、コードが汚れるのは許せません。リリースを1ヶ月遅らせてでもリファクタリングさせてください」と主張するエンジニアは、**「ビジネス感覚がない」**という烙印を押されてしまうのです。
僕の盲点はここにありました。
「コードの品質」と「プロダクトの価値」を混同していたのです。
コードの品質は、あくまでプロダクトの価値を持続させるための「パラメータの一つ」に過ぎません。時には「スピード」というパラメータを最大化するために、「品質」を意図的に下げる（トレードオフにする）判断が必要な場面がある。
それを「妥協」や「手抜き」と捉えてしまう潔癖症こそが、エンジニアの成長を、ひいてはプロダクトの成功を阻害していたのです。
コードは資産ではなく「負債」である
もう一つ、衝撃的だったマインドセットの転換があります。
それは、**「Code is Liability（コードは負債である）」**という考え方です。
僕たちは「コードを書くこと」で給料をもらっていると思いがちです。だから、たくさんコードを書くと「仕事をした！」という気になります。
しかし、本質的には逆です。
コードは書いた瞬間から、バグの温床になり、保守コストを発生させ、新しい人が入った時の学習コストになります。つまり、コード行数は少なければ少ないほど、会社にとっては利益率が高いのです。
「最高のコードとは、コードを書かないことである（No Code is the Best Code）」
この言葉の意味を、僕は海外に来て肌で感じました。
あるプロジェクトで、複雑な認証機能を実装しようとしていた時、同僚が言いました。
「なんで自作するの？ Auth0（外部の認証サービス）を使えば、月額数ドルで終わるよ。君が1週間かけて実装するコストより遥かに安い」
僕は「自分で書きたかった」のです。OAuth2.0のフローを自分で実装して理解したかった。でも、それは会社にとっては無駄なコストでした。
外部サービスを使えば、コードはゼロ行（設定のみ）で済みます。バグ対応もセキュリティパッチも向こうがやってくれます。
「エンジニアリング能力を使って、いかにエンジニアリングをしないか」
このパラドックス（逆説）を受け入れられた時、僕の中で「良いエンジニア」の定義がガラガラと崩れ落ち、再構築され始めました。
幻想から覚めた後に残るもの
「完璧なアーキテクチャ」という幻想が崩れ去った跡地に、何が残ったのか。
それは、**「ビジネスという荒野」**でした。
守ってくれる仕様書はありません。
「これを実装すれば正解」という技術的な安息の地もありません。
そこにあるのは、「ユーザーは何を求めているのか？」「今、一番解決すべき課題は何か？」という、答えのない問いだけです。
かつての僕は、その荒野に立つのが怖くて、「技術」という殻に閉じこもっていたのだと思います。IDE（統合開発環境）の中で、コンパイルエラーを潰している時だけが、安心できる時間でした。
でも、それでは世界を変えるようなプロダクトは作れません。
技術偏重の罠（起）に気づき、アーキテクチャの幻想（承）が崩壊した今、僕たちはどこへ向かえばいいのでしょうか？
コードを書く手を止めて、何をすればいいのでしょうか？
次回の【転】では、この絶望的な状況から這い上がり、エンジニアが真の価値を発揮するために必要な「視点の転換」についてお話しします。
キーワードは、「HowからWhyへのシフト」、そして**「ドメインへのダイブ」**です。
単なる「コーダー」から、ビジネスを動かす「パートナー」へと進化するための具体的なアクションプラン。
僕が実際に現場で実践し、評価を劇的に変えたメソッドを公開します。
視点の転換：「How」から「Why」へ、コードを書かない勇気
キーボードから手を離せ、現場へ行け
「承」で話した通り、僕は「技術的負債」と「ビジネスのスピード」の板挟みになり、エンジニアとしてのアイデンティティを見失いかけていました。
そんなある日、転機が訪れます。
当時開発していた物流管理システムのWPFアプリで、「在庫検索画面が使いにくい」というクレームが現場から上がってきました。
以前の僕なら、すぐにVisual Studioを開き、検索アルゴリズムを見直したり、UIライブラリをリッチなものに置き換えたりしていたでしょう。それが「エンジニアの仕事」だと思っていたからです。
しかし、その時の僕はもう、無駄なコードを書くことに疲れ果てていました。
「どうせ直しても、また文句を言われるんだろ？」
そんな半ば投げやりな気持ちで、僕は初めて**「開発ルームを出る」**という選択をしました。
車で数時間の倉庫へ向かい、実際にアプリを使っている現場のオペレーター（作業員）の隣に立ったのです。
そこで見た光景は、衝撃的でした。
彼らは、僕が精魂込めて作った「高機能な検索フィルター」なんて一切触っていませんでした。
バーコードリーダーを片手に持ち、画面を見る暇もなく、ただひたすらに「Enterキー」を連打していたのです。
彼らが求めていたのは、複雑な条件検索ではなく、**「スキャンした瞬間に、次の作業指示がデカい文字で表示されること」**だけでした。
「なんだ、これじゃあWPFのGridも、非同期検索もいらないじゃないか……」
僕はその場でノートPCを開き、オペレーターと話しながら、検索機能を削除しました。代わりに、画面いっぱいに「OK」「NG」と表示するだけの、極めて原始的な画面をプロトタイプしました。コードにすれば数十行。技術的な自慢ポイントはゼロです。
しかし、それを見たオペレーターは目を輝かせました。
「そうだよ！ これだよ！ これで仕事が3倍速くなるよ！」
その瞬間、僕の中で何かが弾けました。
今まで僕は、モニターの中の「コード（How）」と格闘していました。
でも、戦うべき場所はそこじゃなかった。
モニターの外側にある**「ユーザーの現実（Context）」**こそが、僕が向き合うべきドメインだったのです。
「Why」を5回繰り返すウザい奴になれ
この経験から、僕は仕事のスタイルを180度変えました。
チケット（タスク）が割り当てられた時、すぐにコーディングを始めるのをやめたのです。
代わりに、PMやステークホルダーに対して、徹底的に**「Why（なぜ）」**を問うようになりました。
「なぜこの機能が必要なんですか？」
「なぜ今なんですか？」
「なぜExcelじゃダメなんですか？」
最初は嫌がられました。「いいから言われた通りに作れよ、エンジニアだろ？」という顔をされたこともあります。
でも、諦めずに「Why」を掘り下げていくと、驚くべきことが分かります。
多くの場合、依頼者自身も**「本当の問題」を分かっていない**のです。
例えば、「売上データをリアルタイムでグラフ表示したい（WPFでチャートコントロールを使いたい）」という要望があったとします。
以前の僕なら「よし、LiveChartsを使ってカッコよく実装だ！」と飛びついていました。
しかし、「Why」を繰り返すとこうなります。
「なぜリアルタイムである必要がある？」→「異常値をすぐ検知したいから」
「異常値が出たらどうする？」→「担当者に電話してラインを止める」
「じゃあ、担当者はずっと画面を見張っているの？」→「いや、現場にいるから画面は見ない」
……分かりますよね？
この場合に必要なのは、リッチなリアルタイムグラフ描画機能ではありません。
異常値を検知した瞬間に、担当者のスマホに**「SMSを飛ばす機能」**です。これならUIすら要りません。TwilioなどのAPIを叩くだけで終わりです。
僕たちは、依頼者の「グラフが欲しい」という**「Solution（解決策案）」をそのまま受け取ってはいけません。
その裏にある「Problem（課題）」まで遡り、エンジニアの知識を使って「もっと安くて早い解決策」を再提案する。
これが、海外で評価される「Consultative Engineer（提案型エンジニア）」**の姿です。
ドメイン知識こそが最強のフレームワーク
こうして「Why」を追求し始めると、必然的に技術以外の知識が必要になります。
物流システムなら物流の専門用語やワークフロー、金融なら会計知識、医療なら法規制。いわゆる**「ドメイン知識」**です。
はっきり言います。
これから海外で生き残るために学ぶべきは、新しいJavaScriptのフレームワークでも、次世代のステート管理ライブラリでもありません。
あなたが今いる業界の**「ビジネスドメイン」**です。
C#の文法は世界中どこでも同じです。AIにも書けます。
しかし、**「この会社のビジネスにおいて、なぜこの機能が必要なのか」**という文脈（コンテキスト）を理解しているのは、世界中であなた（とチームメンバー）だけです。
僕はある時期から、技術書を読む時間を減らし、業界紙や社内の業務マニュアルを読む時間を増やしました。
すると、不思議なことに**「コードを書くスピード」が爆発的に上がった**のです。
なぜか？
「何を作ればいいか」が迷いなく分かるようになったからです。変数名やクラス名に悩むこともなくなりました。ビジネスの用語（ユビキタス言語）をそのままコードに落とし込めばいいからです。
ドメイン駆動設計（DDD）という難しい言葉がありますが、本質はシンプルです。
「ビジネスと言葉を合わせろ。ビジネスの構造とコードの構造を一致させろ」
これだけで、手戻りは劇的に減ります。
「英語」はプログラミング言語より重要か？
ここで、海外エンジニアとして避けて通れない「英語」の話を少しだけ。
「技術があれば言葉はいらない」というのは、半分正解で半分嘘です。
ただ仕様書通りに組むコーダーなら、拙い英語でもなんとかなります（Gitのコミットログで会話すればいいので）。
しかし、ここまで話してきた「Whyを問う」「提案する」エンジニアになるには、コミュニケーション能力が生命線です。
でも、安心してください。ネイティブのように流暢に喋る必要はありません。
必要なのは、**「分からないことを分からないと言い切る勇気」と「図解する力」**です。
僕は英語での議論がヒートアップしてついていけなくなった時、必ずホワイトボードの前に立ち、
「Wait, let me draw（待って、描かせてくれ）」
と言って、下手くそな図を描きます。
箱と矢印だけの図です。「ユーザーがここ。データがここ。君が言ってるのはこの矢印のこと？」
これで十分です。むしろ、言葉だけで議論するより、図がある方が全員の認識がズレません。
エンジニアにとって、コードは「コンピュータへの命令書」ですが、図やドキュメントは「人間へのAPI」です。
この**「人間へのAPI」を叩くことを恐れないでください。**
「コードを書かない」という最高の貢献
視点を転換してから、僕の評価基準は変わりました。
「どれだけ高度なコードを書いたか」ではなく、**「どれだけコードを書かずに問題を解決したか」**を誇れるようになったのです。
「あの機能要望、運用フローを変える提案をして、開発なしで解決しました」
こう報告した時、PMは最高の笑顔を見せてくれます。
「ありがとう！ おかげで開発リソースが空いたから、もっと重要な機能に集中できる！」と。
これこそが、エンジニアの盲点からの脱却です。
Code is not enough.（コードだけでは不十分だ）
Code is just a tool.（コードは単なる道具だ）
この当たり前の事実に気づき、道具箱（IDE）を閉じて、生身の人間（ユーザー）と向き合う覚悟を決めた時、あなたのエンジニアとしてのキャリアは、まったく新しいフェーズに入ります。
さて、ここまでの話で、
「技術偏重の罠（起）」
「アーキテクチャ幻想の崩壊（承）」
「ビジネス価値への視点転換（転）」
と進んできました。
次回、最終回の【結】では、これらを統合し、これからの時代、特にAIがコードを書きまくる未来において、私たち人間エンジニアがどこに立脚点を見出し、どうキャリアを築いていくべきか。
海外で働く一人のエンジニアとしての「結論」と、明日から使える「マインドセット」をまとめて締めくくりたいと思います。
次世代のエンジニア像：海を渡るための「プロダクト思考」という武器
AIがコードを書く時代の「エンジニア」とは？
ここまで、長々と「コードを書くな」「ビジネスを見ろ」と偉そうに語ってきました。
しかし、皆さんの頭の片隅には、常にこの不安があるのではないでしょうか？
「ビジネス大事なのは分かったけど、俺たちはエンジニアだろ？ コードを書かなくなったら、それはもうエンジニアじゃないんじゃないか？」
そして、そこには巨大な影が差しています。そう、AIです。
GitHub CopilotやChatGPTが、私たちが数時間かけていたボイラープレートコードを数秒で吐き出す今、単に「仕様通りにC#を書く」だけのスキルの価値は、残酷なまでに暴落しています。
では、私たちは廃業するしかないのでしょうか？
答えは、断じてNOです。
むしろ逆です。AIの台頭によって、「The Engineer’s Blind Spot（エンジニアの盲点）」を克服した人財の価値は、かつてないほど高騰しています。
AIは「How（どう書くか）」の天才ですが、「Why（なぜ書くか）」や「What（何を書くか）」を決めることはできません。
AIはユーザーの悔し涙を見ることもできないし、現場のオペレーターとコーヒーを飲みながら本音を聞き出すこともできません。
これからの時代のエンジニアの定義は、こう変わります。
旧：コードという名の「レンガ」を積む人
新：テクノロジーを使って「課題」という名の「壁」を壊す人
レンガを積む作業はAIに任せればいい。私たちは、どの壁を、どの角度から壊せば一番効率が良いかを設計する「解体業者（Problem Solver）」になるのです。
「プロダクト・エンジニア」への進化
シリコンバレーや欧州のテック業界で、今最もホットな職種（というか役割）の一つに、**「Product Engineer（プロダクト・エンジニア）」**という言葉があります。
これは、単に「プロダクトを作るエンジニア」という意味ではありません。
**「プロダクトの成功に責任を持つエンジニア」**のことです。
従来のエンジニアは、「チケットを消化した数」や「バグの少なさ」で評価されました。
しかし、プロダクト・エンジニアは違います。
「この機能を入れたことで、ユーザーの離脱率が下がったか？」「このUI変更で、作業効率が上がったか？」
という**「Outcome（成果）」**にコミットします。
僕がWPFで画面を作るとき、今はもう「MVVMが綺麗か」よりも「ユーザーがマニュアルを読まずに操作できるか」に命をかけています。
コードの美しさは、あくまで「将来の自分たちのため」の裏方の事情。
表舞台における主役は、あくまで**「ユーザー体験（UX）」**です。
「技術力」と「プロダクト思考」。この2つの車輪が揃って初めて、僕たちはAIに使われる側から、AIを使いこなして爆速で価値を生む側へと進化できるのです。
日本人エンジニアの隠された「最強の武器」
ここで、これから海外を目指す、あるいは世界レベルで活躍したい日本のエンジニアの皆さんに、どうしても伝えたいことがあります。
「英語も苦手だし、自己主張も弱い日本人が、海外で通用するのか？」
自信を持って言います。通用します。
むしろ、日本のエンジニアが持っているある特性は、海外では**「チート級の武器」**になり得ます。
それは、「Omotenashi（おもてなし）」の精神と**「細部へのこだわり」**です。
海外で働くと分かりますが、こちらのエンジニアは「動けばいいじゃん」というマインドが強いです（もちろん人によりますが）。UIが多少ズレていても、エラーメッセージが不親切でも気にしません。
そこに、私たち日本人の感覚を持ち込むとどうなるか。
「ユーザーがここで迷わないように、ツールチップを出しておきました」
「エラー時は、単にコードを出すんじゃなくて、次にどうすればいいかのガイドを表示するようにしました」
「処理待ちの間に不安にならないよう、プログレスバーのデザインを工夫しました」
これらを自然にできるのは、世界広しといえど日本人くらいです。
この「ユーザーへの細やかな配慮」は、先ほど述べた「プロダクト・エンジニア」としての資質そのものです。
かつて僕は、この「細かすぎるこだわり」は海外では邪魔になると思っていました。
でも違いました。
「技術（Logic）」に「共感（Empathy）」を載せられる。
これこそが、AIにも、雑な海外エンジニアにも真似できない、私たちだけのユニーク・セリング・プロポジション（独自の強み）なのです。
英語が下手でも構いません。
「I did this for users（ユーザーのためにこうしました）」
その一言と、実際に使いやすいプロダクトがあれば、誰もがあなたをリスペクトします。
今日からできる3つのアクション
最後に、この長いブログを読んでくれたあなたが、明日から「盲点」を脱出し、世界基準のエンジニアへと歩み出すための具体的なアクションを3つ提案させてください。
1. モニターの「裏側」を見に行く
今開発している機能が、実際に誰に、どのような状況で使われているか、自分の目で見たことがありますか？
もしなければ、明日、PMにお願いして現場見学に行くか、営業担当に同行させてもらってください。
「コードを書く時間」を削ってでも行く価値があります。そこで得た「一次情報」は、あなたの設計判断を劇的にシャープにします。
2. 「削除する」勇気を持つ
次にコードを書くとき、「これを書かずに済ませる方法はないか？」と自問してください。
ライブラリで代用できないか？ 仕様を簡略化できないか？ そもそもこの機能は不要ではないか？
「最高のコードは、書かれなかったコードである」
この言葉を胸に、引き算の提案をしてみましょう。最初は驚かれますが、長期的には必ず感謝されます。
3. 英語のドキュメントで「Why」を読む
新しい技術（ライブラリやフレームワーク）を学ぶとき、Getting Started（使い方）だけでなく、**Philosophy（設計思想）やMotivation（開発の動機）**の章を読んでください。
「なぜ作者はこのライブラリを作ったのか？ 既存の何が不満だったのか？」
技術の背景にある「Why」を理解する癖をつけると、ビジネスにおける「Why」を理解する力も同時に養われます。
おわりに：海は広い、そして自由だ
僕が日本を飛び出し、海外で働いて一番良かったと思うこと。
それは、給料が上がったことでも、英語が話せるようになったことでもありません。
**「エンジニアリングは、もっと自由でいいんだ」**と気づけたことです。
仕様書通りに作る必要なんてない。
職種にとらわれる必要なんてない。
C#エンジニアがデザインをしたっていいし、マーケティングに口を出したっていい。
目的が「ユーザーを幸せにすること」であれば、手段はなんだっていいんです。
「盲点」に気づいた今のあなたなら、もう大丈夫です。
手元のキーボードは、単なる文字入力装置ではありません。
世界を変えるための、魔法の杖です。
さあ、顔を上げて。
ディスプレイの向こう側にいる、誰かの笑顔のために。
最高の仕事（Problem Solving）をしましょう。
ここまで読んでいただき、本当にありがとうございました。
また、世界のどこかの現場でお会いしましょう！
Happy Coding & Happy Solving!
コメント