「完璧なコード」が「役立たず」と切り捨てられる瞬間 ～技術偏重の罠と、海外現場での敗北体験～
こんにちは！海外のとある都市で、日々C#とWPF（Windows Presentation Foundation）を駆使してデスクトップアプリの設計開発をしているエンジニアです。
今日はちょっと、技術的なコードの話から離れて、もっと根源的な、「僕たちエンジニアの生存戦略」について話をさせてください。
突然ですが、みなさんは「完璧なコード」ってなんだと思いますか？
バグがないこと？
処理速度が爆速なこと？
MVVMパターンが美しく適用され、結合度が極限まで低いこと？
あるいは、最新の.NETの機能をフル活用していること？
日本で働いていた頃の僕は、間違いなくこう答えていました。「仕様通りに動き、保守性が高く、パフォーマンスが良いコードこそが正義だ」と。
でも、海外に出てきて、その価値観は見事に粉砕されました。
今日は、僕がこっちに来て最初に味わった「挫折」と、そこから見つけた「デザイン思考」という武器について、実体験を交えながらお話しします。これは、これから海外を目指す人、あるいは今の現場で閉塞感を感じている人にとって、間違いなく「明日の自分を助けるツール」になるはずです。
海を渡って直面した「Why?」の洗礼
僕が今の現地企業に入社して間もない頃の話です。
ある業務支援ツールの改修プロジェクトを任されました。WPFを使った、社内のオペレーターが使うデータ管理画面のリニューアルです。
僕は張り切りました。「よーし、日本のエンジニアの品質の高さを見せつけてやるぞ」と。
既存のスパゲッティコードを解析し、Prismライブラリを使って綺麗に疎結合化し、ReactivePropertyを使ってリアクティブなUIを実装しました。単体テストのカバレッジも100%近く。技術的には「完璧」な仕事をしたつもりでした。
そして迎えたレビューの日。
プロジェクトマネージャー（PM）と、実際にツールを使う現場のリーダー（UX担当も兼ねているような人）に対して、僕は自信満々でデモを行いました。
「見てください、このグリッドの描画速度。以前の10倍は早いです。しかも、アーキテクチャを一新したので、今後の機能追加も容易ですよ」
僕は賞賛の言葉を期待していました。しかし、返ってきたのは冷ややかな沈黙と、現場リーダーの一言でした。
“Okay, but why did you build it this way? This doesn’t solve my headache.”
（わかった。でも、なんでこんな風に作ったの？ これじゃ私の頭痛の種は解決しないわ。）
僕は耳を疑いました。「え？ 仕様書にはグリッドの高速化と、検索機能の強化って書いてありましたよね？」
彼女は首を横に振って言いました。
「仕様書はあくまで『解決策の仮説』に過ぎないわ。私たちが本当に困っているのは、データのロード時間じゃなくて、エラーデータを見つけた後の修正フローが複雑すぎることなの。この新しいUI、ロードは速いけど、修正画面に行くのに3回もクリックが必要じゃない。前より悪化してるわよ」
そして、PMが追い打ちをかけます。
「君のコードが美しいのはわかる。でも、ユーザーの課題（Pain Point）を解決していないなら、それは**Waste（無駄）**だ。君は『何を作るか（What）』ばかり見ていて、『なぜ作るか（Why）』を見ていないね」
ガーン、と頭を殴られたような衝撃でした。
日本にいた時は、「仕様書通りに作ること」がエンジニアの仕事でした。仕様が間違っていたら、それは仕様を決めたSEやプランナーの責任。僕は「指示通り、高品質に」作ればそれで評価されたんです。
でも、こっち（海外、特にアジャイルが浸透している現場）では違いました。
「エンジニアもプロダクトの価値にコミットしろ」
「コードは手段であって、目的じゃない」
これが、暗黙の、しかし絶対的なルールだったんです。
「機能」ではなく「体験」を作るということ
その日の夜、僕は悔しさで眠れませんでした。「C#の腕なら誰にも負けないのに」「WPFのXAMLなんて手書きで全部書けるのに」。そんなプライドが邪魔をして、素直に反省できなかったんです。
でも、冷静になって翌日、現場リーダーの席に行ってみました。「実際にどうやって作業しているのか、見せてもらえませんか？」と。
これが、僕の転機になりました。
彼女の横に座って、1時間ほど作業を観察しました。
彼女は、ロード時間なんて気にしていませんでした。それよりも、電話を受けながら片手でキーボードを叩き、画面上の小さなアイコンをクリックするのに苦戦していました。エラーデータを見つけると、ため息をつきながら別のウィンドウを開き、IDをコピペして検索し直していました。
「ああ、これか……」
僕が作った「高速化されたグリッド」は、彼女のこの「行ったり来たりするストレス」を何一つ解決していなかったのです。むしろ、画面遷移をリッチにしたせいで、彼女の作業フローを分断していました。
僕が必要だったのは、高度な非同期処理のコードではありませんでした。
「彼女がどんな状況で、どんな感情でそのツールを使っているか」を知ること。
そして、その課題を解決するためのシンプルなUIの工夫だったのです。
これが、僕が**「デザイン思考（Design Thinking）」**という概念の重要性を骨の髄まで理解した瞬間でした。
デザイン思考は「デザイナーのもの」ではない
ここで誤解しないでほしいのが、「デザイン思考」という言葉の響きです。
「デザイン」とついているので、「あ、それUIデザイナーの仕事でしょ？」「僕はバックエンド寄りだから関係ないし」「絵心ないから無理」と敬遠してしまうエンジニアが非常に多い。
断言します。デザイン思考こそ、現代のエンジニア、特に海外で活躍したいエンジニアにとって必須の「サバイバルスキル」です。
デザイン思考とは、簡単に言えば**「ユーザーの課題を人間中心で解決するためのアプローチ」**です。
おしゃれな画面を作ることではありません。「ユーザーが何を求めているか（共感）」からスタートし、「問題を定義」し、「アイデアを出し」、「プロトタイプを作り」、「テストする」。このサイクルを回すことです。
なぜこれがエンジニアに必要なのか？
- AIにはできない「共感」が価値になるからGitHub CopilotやChatGPTの登場で、綺麗なコードを書くことの価値は相対的に下がっています。仕様さえ与えれば、AIは僕たちよりも速くコードを書きます。しかし、「現場のリーダーが電話を受けながら片手で操作しているから、ボタンは大きく、右下に配置すべきだ」という判断は、現場で共感（Empathize）した人間にしかできません。AIはまだ、ユーザーの「痛み」を感じ取ることができないからです。
- 海外（特に欧米）のジョブディスクリプションの変化海外の求人を見ていると、Senior Software Engineerの要件に「Product Mindset」や「Ability to solve ambiguous problems（曖昧な問題を解決する能力）」と書かれていることが増えています。ただのコーダー（Coder）ではなく、プロブレムソルバー（Problem Solver）が求められているのです。デザイン思考は、この「曖昧な問題」を具体化するための最強のツールキットになります。
- 手戻りの劇的な削減僕の失敗談のように、完成間近で「これじゃない」と言われるのが、開発において最もコストが高い失敗です。デザイン思考を取り入れ、早い段階でプロトタイプ（簡単なモック）を見せてフィードバックをもらっていれば、数週間の開発期間を無駄にせずに済みました。「急がば回れ」ではないですが、「作る前に考える（Feel before Build）」ことが、結果として最短ルートになるのです。
この記事で手に入れる「未来へのツールキット」
さて、前置きが長くなりましたが、このブログシリーズでは、僕が失敗から学び、現在進行系で実践している「エンジニアのためのデザイン思考」について、徹底的に実用的な視点で解説していきます。
教科書的な「デザイン思考の5段階プロセス」をなぞるつもりはありません。そんな情報はググればいくらでも出てきます。
そうではなく、**「じゃあ、明日の朝会（Daily Standup）からどう動けばいいの？」「C#のコードを書く前に何をすればいいの？」**という、泥臭い現場レベルのアクションプランを提供したいと思っています。
この「起」のパートを読んでくれたあなたに、まず伝えたいこと。
それは、**「自分はコードを書く機械ではない」**というマインドセットへの切り替えです。
あなたは、C#という言葉を話せるだけの通訳ではありません。
テクノロジーという魔法を使って、誰かの「困った」を「良かった」に変える魔法使いです。
その魔法の杖を振るう方向を決めるのが、デザイン思考なんです。
「でも、具体的にどうやるの？ 忙しい開発フローの中で、いちいちユーザーインタビューなんてできないよ」
そう思うかもしれません。大丈夫です。僕も最初はそうでした。
次回の【承】パートでは、**「Your Toolkit for Tomorrow（明日のためのツールキット）」**と題して、多忙なエンジニアでも実践できる「小さなデザイン思考」の取り入れ方を紹介します。
例えば、WPFエンジニアなら馴染み深い「XAML」を使った爆速プロトタイピング術や、コードの中に「ユーザーのストーリー」をコメントとして残す技術、そしてGitHubのIssueの書き方一つでチームの意識を変える方法など。
今日から使える「武器」を配ります。
これから始まる話は、単なるスキルの話ではありません。
あなたがエンジニアとして、この先10年、20年と第一線で必要とされ続けるための、キャリアの防波堤を築く話です。
準備はいいですか？
それでは、かつての僕のように「Why?」の壁にぶつかって砕けないための、転ばぬ先の杖。
いや、未来を切り拓くための強力なツールキットを、一緒に紐解いていきましょう。
エンジニアのためのデザイン思考「実践」入門 ～今日からワークフローを変える具体的なファーストステップ～
「デザイン思考」と聞くと、ポストイットを何百枚も壁に貼って、何日もかけて行うワークショップを想像していませんか？
もちろん、そういった大規模なセッションも重要です。でも、日々の開発に追われる僕たちエンジニアにとって、本当に必要なのは**「マイクロ・デザイン思考」**とも呼べる、日常的な習慣です。
IDE（統合開発環境）を開く前に、あるいはGitにコミットする前に、ほんの数分、思考のスイッチを切り替えるだけ。それだけで、あなたの書くコードの「意味」が劇的に変わります。
ここでは、僕が実践している3つのステップ（ツールキット）を紹介します。
Step 1. 「How」の前に「Who」を定義する ～コードの中にペルソナを住まわせる～
海外の現場でよく耳にするのが、”User Story” という言葉です。
日本でもアジャイル開発でおなじみですが、こちらのエンジニアはこれを徹底的に意識しています。
僕がまだ新人だった頃、機能実装のチケット（タスク）には、単に「CSVエクスポート機能を実装する」としか書いていませんでした。これだと、僕は「CSVヘルパーライブラリを入れて、効率的に出力するコード」を書くことだけに集中してしまいます。
しかし、デザイン思考を取り入れてからは、コードを書く前に必ず**「誰が（Who）、どんな状況で（Context）、なぜ（Why）これを使うのか」**を明確にするようにしました。
具体的には、ソースコードのコメントやプルリクエスト（PR）の記述を変えるのです。
Before（以前の僕）:
C#
// データをCSV形式でエクスポートする
public void ExportCsv(List<Data> data) { ... }
After（今の僕）:
C#
// [Persona: 会計担当のサラ]
// 月末の締め処理でExcelに取り込むために使用する。
// 彼女は技術に詳しくないので、文字化けを防ぐBOM付きUTF-8が必須。
// また、5万件以上のデータでもUIがフリーズしないよう非同期で実行する。
public async Task ExportCsvAsync(List<Data> data) { ... }
違いがわかりますか？
「会計担当のサラ」という具体的なユーザー像（ペルソナ）をコードの文脈に持ち込むことで、**「BOM付きであるべき」「UIフリーズは許されない」**という、仕様書には明記されていないかもしれないけれど、ユーザー体験にとって致命的な要件が見えてきます。
「サラなら、ここでプログレスバーが出ないと不安になるだろうな」
「サラは古いExcelを使っているかもしれないから、CSVの区切り文字は設定可能にした方がいいかな」
こうやって、モニターの向こう側にいる生身の人間を想像しながらコーディングすること。
これが、エンジニアができる最初にして最大のデザイン思考の実践です。
Step 2. 「動くもの」より「伝わるもの」 ～ペーパープロトタイピングの魔術～
エンジニアの悪い癖は、すぐに作り始めてしまうことです。「とりあえずWPFで画面作ってみますね」と言って、Visual Studioを立ち上げ、XAMLを書き始めてしまう。
でも、海外の優秀なエンジニアは、**「コードを書くのをギリギリまで我慢」**します。
なぜか？ コードを書いた瞬間に、「変更コスト」が発生するからです。
僕がおすすめするのは、**「ペーパープロトタイピング」**です。
文字通り、紙とペンです。iPadとApple Pencilでも構いません。
ある時、複雑な検索フィルターの実装を依頼されました。僕は裏紙を取り出し、汚い手書きで「ここにドロップダウンがあって、これを選ぶと、下のリストが変わって……」と書き殴りました。所要時間は5分です。
それをスマホで撮って、チャットでPMとデザイナーに送りました。
「イメージしてるのはこんな感じ？」
すぐに返信が来ました。
「No, No! ドロップダウンはダメだ。ユーザーは一目で全選択肢を見たいんだ。チェックボックスを並べてくれ」
もし僕が、いきなりWPFでComboBoxコントロールを実装し、ViewModelにバインディング処理を書いてから見せていたらどうなっていたでしょう？
「書き直し」です。ViewModelの構造から変える必要があったかもしれません。数時間のロスです。
紙に描いた落書きなら、ゴミ箱に捨てて書き直すのに10秒もかかりません。
“Fail fast, learn faster.”（早く失敗して、もっと早く学べ）
シリコンバレー界隈でよく言われる言葉ですが、これを実現する最強のツールが「手書き」なのです。
WPFエンジニアなら、次の段階として**「Design Data（デザイン時データ）」**の活用も強力な武器になります。
ロジックは一切書かず、View（XAML）と、画面確認用のダミーデータ（Mock ViewModel）だけを作る。
「ロジックはまだ空っぽですが、画面の動きと見た目はこうなります」と見せる。
これなら、ロジックの実装工数をかける前に、ユーザーからのフィードバック（「ボタンが小さい」「この情報は要らない」など）をもらえます。
「完成品」を見せるのではなく、「未完成の可能性」を見せて、相手を巻き込む。
これも、立派なエンジニアリングスキルです。
Step 3. 要件定義は「御用聞き」ではない ～「Why」を5回繰り返す～
日本のSIer時代、僕は「要件定義」とは「お客様の言ったことを漏らさずメモすること」だと思っていました。
しかし、海外に来て、それは「御用聞き（Order taker）」であって「エンジニア（Engineer）」の仕事ではないと教わりました。
ヘンリー・フォード（自動車の生みの親）の有名な言葉があります。
「もし私が人々に何が欲しいかと聞いていたら、彼らは『もっと速い馬が欲しい』と答えただろう」
ユーザーは、自分の本当の課題解決策（車）を知りません。彼らが知っているのは、今の不満（馬が遅い）だけです。
だから、エンジニアがユーザーの言葉をそのまま鵜呑みにして実装すると、たいてい失敗します。
ここで使うツールが**「5 Whys（なぜなぜ分析）」**です。
例えば、ユーザーから「この一覧画面に『印刷』ボタンをつけてほしい」と言われたとします。
ダメなエンジニアは、すぐに PrintDocument クラスを調べ始めます。
デザイン思考を持つエンジニアは、こう聞きます。
- Why? 「なぜ印刷したいんですか？」→ 「会議で上司に報告するためだよ」
- Why? 「なぜ紙で報告する必要があるんですか？」→ 「上司はPC画面の細かい数字を見るのが苦手で、重要な数字だけ赤ペンでチェックしたいんだ」
- Why? 「重要な数字とは具体的にどこですか？」→ 「この『利益率』と『前年比』のところだね」
ここで気づきます。
彼らが必要なのは「紙への印刷機能」ではなく、**「利益率と前年比を強調表示した、上司が見やすいダッシュボード画面（あるいはPDFレポート）」**かもしれない、と。
もしかしたら、印刷機能を実装するよりも、画面の文字を大きくして、重要な数字を赤太字にするだけで、iPadで見せられるようになり、ペーパーレス化まで実現できるかもしれません。
「印刷ボタンが欲しい」というリクエスト（What）の裏にある、本当の願い（Why）を掘り当てることができれば、実装コストを下げながら、顧客満足度を上げるという魔法のようなことが起こります。
今日から始める「小さな革命」
ここまで読んで、「なんだ、当たり前のことじゃないか」と思った方もいるかもしれません。
そうです。デザイン思考は魔法でも何でもなく、**「当たり前の人間中心の視点」**を取り戻すことです。
しかし、この「当たり前」を、納期に追われる開発現場で徹底できているエンジニアは、実は驚くほど少ないのです。だからこそ、これをやるだけで、あなたはチームの中で「頭一つ抜けた存在」になれます。
- コードに「ペルソナ」への思いやりをコメントする。
- コードを書く前に、汚い手書きの絵で合意を取る。
- 「機能」の注文に対して、「背景（Why）」を問い返す。
これらは、特別なツールも新しいライブラリも必要ありません。今日から、今のプロジェクトで始められます。
「でも、そんな勝手なことをして、プロジェクトが遅れたらどうするんだ？」
「失敗したら評価が下がるんじゃないか？」
そんな不安を感じるあなたの背中を押すために、次回の【転】パートでは、**「なぜ失敗が賞賛されるのか？」**という、海外テックシーンの核心に触れたいと思います。
失敗を恐れるマインドセットこそが、実は最大のリスクである理由。そして、あなたのキャリアを「Future-proof（未来に通用するもの）」にするための学習リソースについてお話しします。
あなたの書く1行のコードが、誰かの人生を少しだけ良くするために。
次回も、この場所でお会いしましょう。
なぜ「失敗」が賞賛されるのか？ ～イノベーションを生むためのマインドセットと成長のリソース～
「君は、今週何回失敗した？」
これは、僕が今の会社に入って最初の1on1ミーティングで、マネージャーから聞かれた言葉です。
日本で働いていた頃の感覚で、僕はこう答えました。
「いえ、単体テストもしっかり書いたので、バグは一つも出していません。順調です！」
褒められると思いました。しかし、マネージャーは眉をひそめてこう言ったのです。
“That’s not good. If you’re not failing, you’re not trying hard enough.”
（それは良くないな。もし失敗していないなら、君は十分に挑戦していない証拠だ。）
衝撃でした。
日本では「失敗＝悪」「バグ＝謝罪案件」でした。しかし、ここ（イノベーションを重視する海外テックシーン）では、**「失敗＝学習の証（Learning Milestone）」**だったのです。
デザイン思考の本質は、実はここにあります。
「カッコいいUIを作ること」ではありません。「いかに早く、安く、賢く失敗するか」。これが裏テーマです。
1. 「Fail Fast（早く失敗しろ）」の本当の経済的価値
なぜ彼らは失敗を歓迎するのか？ 精神論ではありません。極めて合理的な経済的理由です。
WPFの開発で例えてみましょう。
完全に作り込んだ後に、ユーザーから「この機能、使いにくいから要らない」と言われたらどうなりますか？
ViewModelの設計、XAMLのバインディング、単体テスト、それらに費やした2週間分の給料がすべて「ゴミ（Waste）」になります。
しかし、紙に書いたペーパープロトタイプ（所要時間10分）の段階で「これじゃない」と言われたら？
失うのは紙切れ一枚と10分だけです。
早く失敗すればするほど、修正コストは安い。
この当たり前の事実に気づくと、エンジニアとしての行動が変わります。
以前の僕は、完璧なコードを書くまでプルリクエスト（PR）を出せませんでした。
今の僕は、動かなくてもいいから「設計方針のメモ」だけでPRを出します。「この方向で実装しようと思うけど、どう思う？」と。
そこで「そのライブラリは非推奨だよ」と指摘されれば、実装する前に対処できます。これが「賢い失敗」です。
海外のエンジニアは、自分の未熟さを晒すことを恐れません。なぜなら、**「隠して後で爆発するより、今晒して修正する方が、チーム全体にとって得だ」**と全員が理解しているからです。
この**「心理的安全性（Psychological Safety）」**を自ら作り出し、率先して「小さな失敗」を積み重ねられる人だけが、デザイン思考を本当の意味で使いこなせるのです。
2. バグを憎んで人を憎まず ～Blameless Culture～
デザイン思考を実践するには、環境選びも重要です。
もしあなたが今、「なぜ間違えたんだ！」「誰の責任だ！」と犯人探しをするような現場にいるなら、残念ながらデザイン思考を実践するのは難しいでしょう。
僕が働くチームには**「Blameless Post-Mortem（非難なき事後検証）」**という文化があります。
ある時、僕がデプロイ設定をミスして、テスト環境を半日ダウンさせてしまったことがありました。真っ青になって謝りました。
でも、チームの反応はこうでした。
「謝る必要はない。君という優秀なエンジニアがミスをするということは、システムやプロセスに欠陥があるということだ。一緒に再発防止の仕組み（仕組みのデザイン）を考えよう」
ここでは、失敗は個人の能力不足ではなく、**「プロセスのバグ」**として扱われます。
だからこそ、安心して新しいアイデア（例えば、斬新なUI操作や、新しいアーキテクチャ）を提案できる。
「もしダメなら戻せばいい（Git Revertすればいい）」という感覚。
このマインドセットを手に入れた時、僕は初めて「エンジニア」として解放された気がしました。
仕様書通りに動くマシーンではなく、より良い未来を探索する「探検家」になれたのです。
3. 成長のためのリソース ～「共感力」と「設計力」を鍛えるツールキット～
マインドセットが変わったら、次はスキルのアップデートです。
C#の公式ドキュメントやStack Overflowを見るだけでは、デザイン思考力は養われません。
僕が実際に使い倒し、血肉にしてきた「エンジニアのための成長リソース」を紹介します。
【Books: エンジニアの脳みそを書き換える本】
- “The Lean Startup” (Eric Ries)
- なぜ読むべきか: 「MVP（Minimum Viable Product）」という概念のバイブルです。エンジニアはつい「高機能」を目指しますが、この本を読むと「必要最小限の実装で、最大の学習を得る」ことの重要性が痛いほどわかります。無駄なコードを書きたくない全エンジニア必読。
- “Don’t Make Me Think” (Steve Krug)
- なぜ読むべきか: Webユーザビリティの本ですが、WPFやデスクトップアプリにも通じます。「ユーザーに考えさせるな」。この一言に尽きます。直感的な設計とは何かが、ロジカルに解説されています。
【Tools: デザインの世界をハックする武器】
- Figma (Dev Mode)
- 解説: 「デザイナーのツールでしょ？」と思っていませんか？ 違います。今やFigmaはエンジニアとデザイナーの「共通言語」です。
- 使い方: 自分でデザインする必要はありません。デザイナーが作った画面を見て、余白（Padding）の数値や色コードを見るだけでなく、**「プロトタイピング機能」**を使って画面遷移を動かしてみてください。「この遷移、エンジニア視点だと実装コスト高いけど、ユーザーにとって本当に必要？」といった議論がここから生まれます。
- Miro / FigJam
- 解説: オンラインホワイトボードです。
- 使い方: アーキテクチャ図を書くだけでなく、ユーザーの**「カスタマージャーニーマップ」**を描くのに使います。「ユーザーがアプリを開く→エラーが出る→サポートに電話する」という一連の流れを可視化すると、システムログには残らない「ユーザーの感情の起伏」が見えてきます。
【Community: 失敗談を共有できる場所】
- Local Meetups & Hackathons
- https://www.google.com/search?q=%E6%B5%B7%E5%A4%96%E3%81%A7%E3%81%AFMeetup.comが非常に活発です。特におすすめなのが「Hackathon（ハッカソン）」への参加です。
- ハッカソンは、デザイン思考の実験場です。限られた時間（24時間や48時間）で何かを作るには、完璧なコードなんて書いていられません。「何を作るか」「誰が使うか」を極限まで突き詰め、汚くても動くものを作る。この経験は、業務での開発スピードと判断力を劇的に向上させます。
- もし現地にいなくても、オンラインハッカソンなら日本からでも参加できます。「Devpost」などのサイトをチェックしてみてください。
技術力 × デザイン思考 ＝ ？？？
失敗を恐れず、ツールを駆使して「ユーザーの課題」に肉薄する。
そうやって仕事をしていると、ある日、周りからの評価が変わっていることに気づきます。
「あいつはC#が書けるだけじゃない」
「あいつに相談すれば、技術的な実現可能性と、ユーザー体験のバランスをとった提案が出てくる」
これが、次回【結】でお話しする**「Future-Proof Engineer（未来に生き残るエンジニア）」**の正体です。
AIがコードを書く時代、単なる「コーダー」の価値は暴落します。
しかし、「何を作るべきか」を定義し、技術的な裏付けを持ってそれを実現し、さらに失敗から学んで改善し続けられるエンジニア。この価値は、AIには決して代替できません。
次回、最終回。
この「デザイン思考」という武器を携えて、激動のテック業界をどう泳ぎ切るか。
そして、日本から世界へ飛び出そうとするあなたへの最後のエールを送ります。
AI時代に生き残る「Future-Proof」なエンジニアへ ～技術と共感のハイブリッドが切り拓く未来～
「GitHub Copilotが出てきて、もう僕たちの仕事はなくなるんじゃないか？」
最近、そんな不安を口にするエンジニアが増えました。
確かに、定型的なコードを書くスピードで人間はAIに勝てません。仕様書を渡せば、数秒でC#のクラス定義が出力される時代です。
でも、僕は全く悲観していません。むしろ、デザイン思考を持つエンジニアにとっては、かつてないチャンスの時代が到来したと確信しています。
なぜか？
AIは「How（どう書くか）」の天才ですが、「Why（なぜ作るか）」と「What（何を作るか）」に関しては、まだまだ赤ちゃんだからです。
1. AIには見えない「行間」を読む力
前回の話に出た「会計担当のサラさん」を思い出してください。
AIに「CSV出力機能を作って」と頼めば、完璧なCSV出力コードを書いてくれます。
しかし、AIは気づけません。
「サラさんが使っているPCは画面が小さくて、右側のボタンが見切れるかもしれない」ことや、
「月末の彼女はイライラしていて、待たされるとマウスを連打する癖がある」ことには。
「共感（Empathy）」。
これこそが、AIに対する人間の最後の、そして最強の砦です。
ユーザーの痛み、焦り、喜び。そういった感情の機微を読み取り、それを「UIの挙動」や「システムのエラーメッセージの文言」一つ一つに落とし込む。
これは、現場の空気を吸い、人と対話できる人間にしかできません。
これからのエンジニアの仕事は、「コードを書くこと」から**「AIという超優秀な部下を使って、ユーザーの課題を解決すること」**にシフトします。
その時、AIに的確な指示（プロンプト）を出すために必要なのが、「ユーザーは何を求めているか」という深い洞察、つまりデザイン思考なのです。
2. 「技術」と「共感」の二刀流（Hybrid）になれ
海外のテック業界で評価されるエンジニア像が変わってきています。
かつては、一つの技術を極めた「I型人材（スペシャリスト）」が重宝されました。
しかし今は、技術力という軸に加え、ビジネスやデザイン（ユーザー理解）というもう一つの軸を持つ**「π（パイ）型人材」**が求められています。
僕自身、C#とWPFの技術力には自信があります。
でも、今の現場で僕が信頼されているのは、「WPFのレンダリングパイプラインに詳しいから」だけではありません。
「あいつは、デザイナーともマーケターとも会話ができるエンジニアだ」と認識されているからです。
デザイン思考を身につけると、**「共通言語」**が手に入ります。
デザイナーには「ユーザー体験」の言葉で、ビジネスサイドには「課題解決とコスト」の言葉で、そしてエンジニアには「技術的実現性」の言葉で語ることができる。
この**「翻訳者（Translator）」としてのポジション**こそが、これからの時代、最も替えが効かない（Unreplaceable）立ち位置です。
技術がわかるからこそ、無茶なデザインに「No」と言えるし、逆に技術的に簡単な方法でデザインの意図を実現する対案が出せる。
この「ハイブリッドな強さ」は、どんなにAIが進化しても色褪せません。
3. 英語が苦手な日本人エンジニアへのメッセージ
最後に、これから海外を目指す、あるいは海外で戦おうとしているあなたへ。
「英語が完璧じゃないから、議論で負けるのが怖い」
わかります。僕もそうでした。流暢なネイティブの議論には、今でもついていくのがやっとです。
だからこそ、デザイン思考を使ってください。
言葉で勝てないなら、**「モノ」**で語るのです。
会議で言葉に詰まったら、ホワイトボードに行って図を描いてください（カスタマージャーニーマップ）。
複雑な仕様を説明する英語が出てこないなら、簡単なプロトタイプ（動く画面）を作って見せてください。
“A picture is worth a thousand words.”（百聞は一見にしかず）
動くもの、目に見えるものは、言語の壁を軽々と超えます。
「これ、どう思う？」とプロトタイプを見せれば、相手は「Oh! これだよこれ！」と反応してくれます。
そこで「Why?」と聞き返すだけで、深い議論が成立します。
僕たち日本人のエンジニアは、繊細な「気遣い」ができる民族です。
「おもてなし」の心は、実は極めて高度なユーザー中心設計（User Centered Design）の精神に通じます。
その細やかな感性を、デザイン思考というフレームワークに乗せてアウトプットすれば、言葉のハンデなんて吹き飛ばせるくらいの価値を、海外のチームに提供できます。
結び：Your Toolkit for Tomorrow is Ready.
長いブログにお付き合いいただき、ありがとうございました。
【起】 技術偏重の落とし穴に気づき、
【承】 小さな実践（ペルソナ、プロトタイプ、Why）を始め、
【転】 失敗を恐れず学習の糧とし、
【結】 テクノロジーと共感の力で未来を切り拓く。
これが、僕があなたに渡したかった「ツールキット」の全てです。
このツールキットは、ダウンロードする必要も、インストールする必要もありません。
あなたの頭の中に、もうインストールされています。
あとは、「使う」と決めるだけです。
明日の朝、エディタを開く前に、一瞬だけ手を止めて想像してみてください。
あなたの書くそのコードの向こう側で、誰かが笑っている姿を。
あるいは、誰かの仕事が少しだけ楽になっている姿を。
その想像力さえあれば、あなたはもう、ただのコーダーではありません。
未来を作る、真のエンジニアです。
さあ、恐れることはありません。
Toolkitを持って、明日の現場（世界）へ飛び出していきましょう！
Good luck on your journey!
コメント