盲点：ハイスペックなコードが「無価値」になるとき
C#とXAMLの森で迷子になっていた私
正直に告白します。私が日本から海外へ飛び出した当初、私の頭の中は「いかに美しいコードを書くか」で9割が占められていました。
Visual Studioを開き、ReSharperのサジェストにニヤリとし、MVVM（Model-View-ViewModel）パターンを厳格に守り、依存性の注入（DI）を完璧に構成する。XAMLのデータバインディングがピタッと決まった瞬間や、非同期処理がきれいに制御できたときのエクスタシー。わかりますよね？ 我々エンジニアにとって、それはある種の芸術であり、プライドそのものです。
「C#の深い知識があれば、世界のどこでも戦える」
そう信じて疑いませんでした。技術こそが共通言語であり、きれいなコードこそが正義だと。しかし、その自信は海外の現場に放り込まれて数ヶ月で、音を立てて崩れ去ることになります。
「で、それは誰の問題を解決したんだ？」
あるプロジェクトでのことです。現地のクライアント（非エンジニア）から、「業務フローを効率化したいから、ダッシュボード機能を改善してくれ」という、よくあるざっくりとした要望が飛んできました。
日本の現場なら、ここから詳細な要件定義書が降りてくるか、あるいはSEが仕様を詰めてくれるのを待つところです。でも、海外（特に私がいる環境）では、「エンジニア＝解決策の提案者」という期待値が強烈に高い。「仕様書がないと動けません」なんて言った日には、「じゃあ君は何のためにいるの？ コーディングマシーンならオフショアに頼むよ」という冷ややかな視線が返ってきます。
私は焦りました。そして、焦ったエンジニアがやりがちなミスを犯しました。「技術でのオーバーキル」です。
私は最新のライブラリを導入し、UIをモダンにし、バックグラウンド処理を高速化し、拡張性抜群の設計でそのダッシュボードを作り直しました。「これなら文句ないだろう、パフォーマンスも200%向上だ」と意気揚々とデモを見せたんです。
しかし、クライアントの反応は渋いものでした。
「Wow, 動きは速いね。でもさ、僕たちが本当に困っていたのは『データの入力ミス』であって、『表示速度』じゃないんだよ。これじゃあ、速く間違ったデータが表示されるだけだ」
頭をハンマーで殴られたような気分でした。
私の書いたコードは、技術的には完璧でした。単体テストも通っているし、設計も美しい。でも、「ユーザーの課題」という文脈においては、完全に無価値だったのです。
その時、同僚のシニアエンジニア（彼はコードも書きますが、どこか哲学者っぽい雰囲気があります）が、落ち込む私にこう言いました。
「君のツールキットには『ハンマー』しかないね。だから全てが『釘』に見えるんだ。君に必要なのは、コードを書く前に『何を作るべきか』を発見するためのツール、つまり**Design Thinking（デザイン思考）**だよ」
デザイン思考は「デザイナー」のものじゃない
「デザイン思考」と聞いて、当時の私はこう思っていました。「ああ、UI/UXの人がやる、付箋をペタペタ貼るやつでしょ？ おしゃれな画面を作るためのセンスの話だよね」と。
これが大きな間違いでした。
特に海外のテックシーンにおいて、デザイン思考（Design Thinking）は「意匠（見た目）」の話ではありません。それは**「不確実な問題に対する、人間中心の解決アプローチ」**のことです。
私たちバックエンドや業務アプリ（WPFなど）を扱うエンジニアこそ、この思考法が必要です。なぜなら、私たちが向き合うシステムは、複雑なビジネスロジックや、目に見えないユーザーのワークフローと密接に関わっているからです。
日本で働いていた時は、「要件」は誰かが決めてくれるものでした。しかし、海外の、特に変化の激しい現場では、「何を作るか（What）」と「なぜ作るか（Why）」を定義する段階からエンジニアが関与することが求められます。「How（どう実装するか）」だけでは、もはや価値が出せないのです。
「正解のない問い」に立ち向かうための武器
C#のコンパイラは、文法エラーがあれば即座に赤線を引いて教えてくれます。それは「正解」と「不正解」がはっきりしている世界です。私たちはその心地よい論理の世界に住むのが好きです。
しかし、現実のビジネス課題にはコンパイラがありません。「この機能はユーザーを幸せにするか？」という問いに、Visual Studioは答えてくれません。
ここで「デザイン思考」が登場します。
これは、正解のないカオスな状況の中で、ユーザー（使う人）への深い共感（Empathy）からスタートし、問題を再定義（Define）し、素早くアイデアを出し（Ideate）、試作（Prototype）し、検証（Test）するというループを回すプロセスです。
これをエンジニアのワークフローに取り入れると、世界が一変します。
いきなりVisual Studioを開かなくなります。まず、ユーザーの隣に座るようになります。「なぜそのボタンを押すのが面倒なのか？」を聞くようになります。WPFで重厚な画面を作る前に、紙とペンでスケッチを描いて「こういうこと？」と確認するようになります。
これを実践し始めてから、私の評価は劇的に変わりました。「コードが書ける奴」から、「ビジネスの課題を技術で解決してくれるパートナー」へと格上げされたのです。
あなたの「明日」のツールキットをアップデートせよ
これから海外を目指すあなた、あるいは今まさに海外で壁にぶつかっているあなたへ。
英語力？ もちろん大事です。
C#やクラウドの知識？ 必須です。
でも、それらは「戦場に立つための装備」に過ぎません。戦況を読み、勝てる場所を見つけるための「作戦参謀」としての能力、それがデザイン思考です。
特にAIがコードを生成できるようになった今、私たち人間が担うべきは「コードの記述」そのものよりも、「どのコードを書くべきかを見極める力」です。
このブログシリーズでは、かつて「技術偏重」で失敗した私が、いかにしてデザイン思考を日々のエンジニアリング（特にWPF開発という少し堅い領域）に統合していったのか。その具体的な「ツールキット」の中身を公開していきます。
抽象論で終わらせるつもりはありません。明日から職場で使える具体的なアクション、つまり「Your Toolkit for Tomorrow」を手渡すのが私の目的です。
準備はいいですか？
次回からは、具体的な「承：実装編」に入ります。おしゃれなワークショップを開く必要はありません。いつものデスクで、たった5分から始められる「エンジニアのためのデザイン思考」の実践法をお話しします。
コンパイラのエラーよりも、ユーザーのため息に敏感になること。そこから、あなたのエンジニアとしての「本当の強さ」が始まります。
実装：明日から使える思考の道具箱
Visual Studioを開く前の「15分」が勝負を決める
よし、デザイン思考が大事なのはわかった。でも、私たちは忙しいエンジニアです。スプリントのタスクは山積みだし、Jira（チケット管理ツール）のステータスを「In Progress」にしないとマネージャーから突っ込まれる。いきなり「今日からデザイン思考の時間を作るので、コーディング時間を半分にします」なんて言ったら、クビになりかねません。
安心してください。私が提案するのは、日々のワークフローを根本から破壊することではなく、「コンパイルの前段階」に小さなフック（留め金）を掛けることです。
私はこれを**「Zero-Code Investigation（コードゼロの捜査）」**と呼んでいます。
アクション1：チケットの「行間」を読む（Empathyの実装）
通常、タスクはこんな感じで降ってきますよね。
- 「設定画面に『データをエクスポート』ボタンを追加してください（CSV形式）」
以前の私なら、即座にSettingsView.xamlを開き、<Button Content="Export" ... />を追加し、ViewModelにICommandを実装し、CSV出力のヘルパークラスを書いて終わりでした。所要時間2時間。完璧な仕事です。
しかし、「デザイン思考」をインストールした今の私は違います。ここで一度立ち止まります。これが最初のツール、**「The 5 Whys（なぜなぜ分析）」**の簡易版です。
私は、そのチケットを切った人（プロダクトオーナーや、もし可能ならエンドユーザー）のところへチャット、あるいは直接話に行きます。
「ボタン追加の件、了解です。ちなみに、このCSVデータって、エクスポートした後、具体的に何に使いますか？」
これを聞くだけです。すると、驚くべき答えが返ってくることがあります。
「ああ、実は毎月末に経理システムに手入力しなきゃいけないんだけど、そのシステムがCSVインポートに対応してないから、一度Excelで開いて見やすく整形して、それをプリントアウトして入力してるんだよ」
待ってください。
- CSV出力する
- Excelで整形する
- 紙に印刷する
- 別のシステムに手入力する
これは地獄です。ここで私が提案すべきは「CSV出力ボタン」ではありません。「経理システムのAPIを叩いて、ボタン一発で連携する機能」あるいは、それが無理でも「経理システムが要求するフォーマットに整形されたExcelを出力する機能」です。
もし私が言われた通りにCSVボタンを作っていたら、ユーザーは永遠に「Excelでの整形作業」という苦行から解放されませんでした。
「ユーザーが欲しい言ったもの（Want）」ではなく、「ユーザーが真に必要としているもの（Need）」を見抜く。 これがエンジニアにおけるEmpathy（共感）の実践です。
たった5分の会話で、私の実装するコードの価値は「ただのボタン」から「業務改善の魔法」に変わりました。
アクション2：紙とペンは最強のIDE（Prototypingの実装）
WPFエンジニアあるあるですが、私たちはXAMLを書くのが好きすぎて、プロトタイプもXAMLで作りがちです。Blend for Visual Studioを使えば、かっこいいUIがすぐ作れますからね。
でも、「High-Fidelity（高忠実度）なプロトタイプ」は、初期段階では害悪になります。
なぜか？ きれいに動く画面を見せると、ユーザーは「ボタンの色」や「フォントのサイズ」といったどうでもいい細かい点に気を取られてしまうからです。さらに、「もうほとんど完成してるじゃん」と勘違いされ、仕様変更を受け入れにくくなります。
そこで使うツールが**「Napkin Sketching（ナプキンスケッチ）」**です。
私はiPadやホワイトボード、あるいは裏紙に、汚い手書きで画面イメージを書きます。四角と線だけで構成された、小学生の落書きのようなレベルです。
これをユーザーに見せます。
「こんな感じで、ここにリストが出て、ここを押すと詳細が出るイメージであってる？」
手書きのスケッチは「未完成」であることが明白なので、ユーザーも安心して批判できます。
「うーん、リストはここじゃないほうがいいな。実は作業中は左手に電話を持ってるから、右側だけで操作完結したいんだよね」
このフィードバック！ これこそが宝です。
もしXAMLで左側にリストをガチガチに実装した後でこれを言われたら、Gridの定義からやり直しです。でも手書きなら、消しゴムで消して書き直すだけ。30秒です。
「コードを書く前に失敗する」。これが最も効率的な開発手法です。
C#のコード修正コストを100とすると、XAMLの修正コストは50、手書きスケッチの修正コストは1です。コスト1の段階で、徹底的に試行錯誤を繰り返すのです。
アクション3：オズの魔法使い（Testingの実装）
もう少し複雑なロジックが必要な機能の場合、どうするか。ここで使えるのが**「Wizard of Oz（オズの魔法使い）」**というテクニックです。
映画『オズの魔法使い』で、恐ろしい魔法使いの正体が、実はカーテンの裏で機械を操作しているおじいさんだった、という話をご存知ですか？ あれと同じことをやります。
例えば、「AIが自動で文書を要約してくれる機能」を作るとします。
いきなりOpenAIのAPIを繋ぎこんで、非同期処理を書いて…なんてやりません。
まずは、画面に入力欄と「要約」ボタンだけ置いたハリボテアプリを作ります。
そして、ユーザーに使ってもらいます。「ここに文章を入れて、ボタンを押してみて」
裏で私が待機していて、ユーザーがボタンを押した瞬間に、私が手動で要約したテキストをハードコードで表示させる（あるいはデータベースに直接書き込む）のです。
システムは動いていません。人間（私）が裏で動かしています。
でもユーザーにとっては「システムが動いた体験」になります。
これで何がわかるか？
「要約機能、すごいね！ でもさ、要約よりも、この文章から『アクションアイテム（やるべきこと）』だけ抜き出してくれた方が助かるかも」
もし本気で要約アルゴリズムを実装した後だったら、私は膝から崩れ落ちていたでしょう。
「動くコード」を作る前に、「動く体験」を作って検証する。 これこそが、デザイン思考を取り入れたエンジニアの真骨頂です。
毎日のルーチンにどう組み込むか？
これらを、忙しい毎日にどう組み込むか。私は以下の「3つのルール」を自分に課しています。
- 「とりあえず」を禁止する「とりあえず作ってみてよ」と言われたら、全力で拒否（または笑顔でスルー）します。「とりあえず」で作ったものは、大抵「とりあえず」では済まない負債になります。「作る前に、5分だけ画面共有してイメージ合わせしませんか？」と持ちかけます。
- モニタから目を離す時間を強制的に作る1日の中で、コードエディタを見ていない時間を意識的に作ります。同僚の雑談、ユーザーの愚痴、Slackの何気ない会話。そこに「解決すべき本当の問題」が転がっています。
- 「私は何も知らない」と唱えるエンジニア歴が長くなると、「あー、はいはい、そのパターンね」と経験則で判断しがちです（これを”Beginner’s Mind”を失った状態と言います）。毎回、「このユーザーは、私の知らない特殊な文脈で困っているかもしれない」と疑うこと。これがデザイン思考のスタートラインです。
技術力 × デザイン思考 ＝ ？？？
さて、ここまで読んで「なるほど、ユーザーと話すのが大事なのはわかった。でも、それってPM（プロジェクトマネージャー）の仕事じゃないの？ 俺は技術で評価されたいんだよ」と思った方もいるかもしれません。
いいえ、違います。
この「デザイン思考」というOSを搭載したエンジニアこそが、これからのAI時代に最も市場価値が高まる人材なのです。
AIは、仕様通りのきれいなコードを書くのは得意です。しかし、「ユーザーのふとした愚痴から、真の課題を発見し、それを技術的な解決策に翻訳する」ことは、まだ人間にしかできません。
デザイン思考を手に入れたあなたは、単なる「実装者」から、**「課題解決のアーキテクト」**へと進化します。
それは、給与レンジが変わるだけでなく、エンジニアとしての寿命を飛躍的に延ばすことにも繋がります。
次回、「転」パートでは、この「未来を生き抜くエンジニアの条件」について、もう少しマクロな視点、そして急速に進化するテック業界での立ち位置について深掘りしていきます。
「技術力があるのは当たり前。その上で、あなたは何ができるの？」
この残酷な問いに対する答えを、一緒に見つけていきましょう。
進化：未来を生き抜くエンジニアの条件
「そのコード、GitHub Copilotが3秒で書きましたよ」
ある日のコードレビューでの出来事です。
私は後輩の書いた複雑なLINQのクエリを見て感心していました。「よくこんなエレガントなロジック思いついたね」と褒めると、彼は悪びれもせず言いました。
「あ、それコメントでやりたいこと書いたらCopilotが提案してくれたんで、そのままTabキー押しただけっす」
背筋が凍りました。
私が数年かけて習得したLINQのテクニック、MVVMパターンのボイラープレート、非同期処理のベストプラクティス。これらはもはや「職人の技」ではなく、「誰でも（あるいはAIでも）一瞬で出力できるコモディティ」になっていたのです。
ここで私たちは、残酷な事実に直面します。
「How（どう実装するか）」の価値は、暴落している。
これから海外を目指す、あるいは海外で戦い続けるエンジニアにとって、これは死活問題です。なぜなら、単に「仕様書通りに動くコードを書く」だけの能力なら、AIか、あるいはもっと人件費の安い国（私のいる国から見て）のエンジニアに容易に代替可能だからです。
「C#ができる」ことの価値は、以前ほど高くありません。
では、これからの時代、何が「高い価値」を持つのでしょうか？
エンジニアの定義が変わる：「Building the Right Thing」
ここで、これまでの話を思い出してください。
AIは「答え（コード）」を出すのは天才的に速いです。しかし、AIには致命的な弱点があります。
それは、「問い（課題）」を見つけることができないということです。
AIは「このCSVをパースするコードを書いて」と言われれば書けます。
しかし、前回の例のように「そもそもCSV出力なんてやめて、API連携すべきじゃない？」と、ユーザーの潜在的な苦痛に気づき、前提を疑うことは（現時点では自律的には）できません。
ここで「デザイン思考」が、ただの便利ツールから「最強の生存戦略」へと変貌します。
未来のエンジニアの価値は、**「Building the Thing Right（ものを正しく作る＝品質、速度）」から、「Building the Right Thing（正しいものを作る＝課題発見、価値創出）」**へとシフトします。
技術力（How）は、あくまで解決策を具現化するための手段に過ぎなくなります。
その手前にある「何を作るべきか（What）」「なぜ作るのか（Why）」を定義できるエンジニアこそが、AIを「使う側」に回り、生き残ることができるのです。
「Product Engineer」への進化
海外のテック業界では、最近よく「Product Engineer（プロダクトエンジニア）」という言葉を耳にするようになりました。
これは、単にタスクを消化するだけのエンジニア（Code Monkeyと揶揄されることもあります）との対比で使われます。
プロダクトエンジニアとは、以下のような特徴を持つ人たちです。
- ビジネスのゴールを理解している（なぜこの機能が必要か？）
- ユーザーの痛みを理解している（誰がどう困っているか？）
- 技術的な実現可能性とコストを即座に判断できる（この機能ならWPFでやるよりWeb化した方が早い、等）
お気づきでしょうか？ この3つの要素を繋ぐ接着剤こそが「デザイン思考」です。
私が担当しているC# WPFの現場でも、この変化は顕著です。
昔は「デスクトップアプリの画面描画速度を0.1秒縮める」ことに命をかけていました。もちろん今も大事ですが、それ以上に「クラウド側のマイクロサービスとどう連携して、ユーザーにリアルタイムなデータインサイトを提供するか」という、アーキテクチャ全体とユーザー体験（UX）を含めた設計力が求められています。
技術スタックが、モノリシック（一枚岩）なアプリ開発から、APIやSaaSを組み合わせるコンポーザブル（構成可能）なアーキテクチャへと変わる中で、私たちエンジニアには**「部品を作る力」よりも「部品をどう組み合わせてユーザーを幸せにするかを描く力」**が求められているのです。
日本人エンジニアの「隠れた強み」
「え、そんなハイレベルなこと求められるの？ 言語の壁もあるのに無理だよ…」
そう思ったあなたに、朗報があります。
実は、デザイン思考の根底にある「共感（Empathy）」や「察する力」において、私たち日本人はとてつもないポテンシャルを秘めています。
海外（特に欧米）のエンジニアは、論理的で弁が立つ人が多いですが、一方で「ユーザーの言葉にしない空気」や「行間」を読むのが苦手な傾向があります。「仕様書に書いてないから知らないよ」と平気で言います。
ここで、日本的な**「おもてなし（Omotenashi）」**の精神が火を吹きます。
「言われてないけど、ここ使いにくそうだから直しておきました」
「ユーザーの業務フローを考えると、このボタンはこっちにあった方が自然ですよね」
この「気の利くエンジニア」というポジションは、海外ではレアキャラであり、めちゃくちゃ重宝されます。
ただし、これまではそれを「なんとなくの勘」や「サービス精神」でやっていました。それを「デザイン思考」という世界共通のフレームワークに乗せて、論理的に説明し、プロセスとして実践するのです。
「私はただ気が利くのではありません。ユーザー観察とプロトタイピングの結果、このUIが最適であると検証しました」
こう言えた瞬間、あなたは「言葉の壁がある外国人エンジニア」から、「チームになくてはならないUXアーキテクト」へと昇格します。
ソフトスキルこそが、新しいハードスキルだ
これからの10年、技術の陳腐化速度はさらに加速します。
今最新のフレームワークも、3年後にはレガシーかもしれません。WPFだっていつまであるかわかりません（長生きだとは思いますが）。
しかし、「人間の本質的な欲求を理解し、問題を定義し、解決策を創造するプロセス」（＝デザイン思考）は、10年後も、50年後も陳腐化しません。人間が人間である限り、不変のスキルです。
これまで私たちは、ソフトスキル（コミュニケーションや思考法）を「あればいいもの（Nice to have）」と捉え、ハードスキル（コーディング）を「必須なもの（Must have）」と考えてきました。
この認識を「転（ひっくり返す）」換してください。
AI時代においては、思考法こそが最も習得困難で価値の高い「ハードスキル」となり、コーディングはAIが補完してくれる「ソフト（柔軟な）スキル」になる可能性があります。
未来への不安を感じているなら、新しいプログラミング言語を覚える前に、まずは思考のOSをアップデートしましょう。
C#のバージョンアップを追うのと同じくらいの熱量で、人間理解を深めるのです。
そうすれば、どんなに技術トレンドが変わろうとも、あなたは常に「必要とされるエンジニア」であり続けることができます。
さあ、未来への準備はできましたか？
ここまで、少し大きな話をしてきました。
「概念はわかった。重要性も痛いほどわかった。でも、具体的にどんな本を読めばいいの？ どんなコミュニティに行けばいいの？ そして、明日から私のキャリアをどう設計すればいいの？」
その問いに答えるのが、次回の最終回「結」です。
私が実際に助けられた書籍、ツール、そして海外でキャリアを築くための具体的なロードマップ（リソース集）を惜しみなく公開します。
ただの「いちエンジニア」で終わるか、「未来を創るエンジニア」になるか。
その分岐点は、今、あなたの目の前にあります。
始動：成長へのリソースと最初の一歩
あなたの「道具箱」に何を入れるべきか？
ここまで読んで、「よし、デザイン思考やってやるぞ！」と熱くなっているあなた。その情熱を冷まさないために、私が実際に海外で揉まれながら読み漁り、使い倒してきた「必携リソース」を紹介します。
C#の技術書（『C# in Depth』とか）はもう本棚にありますよね？
その隣に、これらを並べてください。これらはあなたの「エンジニア脳」を「プロダクト脳」へと拡張するドライバーやレンチです。
1. 必読書：エンジニアの視界を変える3冊
- 『誰のためのデザイン？』（The Design of Everyday Things） / ドナルド・A・ノーマン
- なぜ読むべきか？: UI/UXのバイブルですが、これは「ドアノブ」や「コンロ」の話です。「なぜユーザーはこのボタンを押し間違えるのか？」それはユーザーが悪いのではなく、設計（デザイン）が悪いのだということを骨の髄まで叩き込まれます。
NullReferenceExceptionが出たらコードを直すように、ユーザーが迷ったらデザインを直す。その当たり前の感覚が身につきます。
- なぜ読むべきか？: UI/UXのバイブルですが、これは「ドアノブ」や「コンロ」の話です。「なぜユーザーはこのボタンを押し間違えるのか？」それはユーザーが悪いのではなく、設計（デザイン）が悪いのだということを骨の髄まで叩き込まれます。
- 『ユーザーストーリーマッピング』（User Story Mapping） / ジェフ・パットン
- なぜ読むべきか？: アジャイル開発の現場で、「バックログ（やることリスト）」の海に溺れそうなエンジニアへの救命浮き輪です。ユーザーの行動を時系列で並べ、全体像（Big Picture）を見失わずに開発する方法が書かれています。これを読むと、Jiraのチケット消化マシーンから脱却できます。
- 『ジョブ理論』（Competing Against Luck） / クレイトン・クリステンセン
- なぜ読むべきか？: 「顧客はドリル（機能）が欲しいのではなく、穴（解決策）が欲しい」という有名な話を深掘りした本です。機能要件定義書に書かれた「What」の裏にある、真の「Why（片付けるべきジョブ）」を見抜く透視能力が手に入ります。
2. 必須ツール：思考を可視化する武器
- Miro / Mural （オンラインホワイトボード）
- C#のクラス図を書く前に、ここで「ユーザーの感情曲線」や「業務フロー」を描いてください。リモートワークが当たり前の海外開発現場では、Zoomで顔を見るよりも、Miroのボードを共有して付箋を貼り合う時間の方が長いです。「コードで語る」前に「図で語る」スキルは、英語のハンディキャップを埋めてくれます。
- Figma（の「閲覧」モード）
- デザイナー専用ツールだと思って食わず嫌いしていませんか？ 自分でデザインできなくてもいいんです。デザイナーが作ったプロトタイプを見て、CSS（WPFならXAMLスタイル）の値を確認したり、コメント機能で「この挙動、実装コスト高いけど本当に必要？」と初期段階で議論したりする。Figmaは「デザイナーとエンジニアの共通言語」です。
- A5サイズのノートと太いペン
- iPadもいいですが、物理的な紙とペンは最強です。バッテリー切れもないし、起動時間もゼロ。カフェで、電車で、アイデアが降りてきた瞬間に書き留める。汚いスケッチこそが、偉大なプロダクトの種になります。
コミュニティ：どこに身を置くべきか？
海外に出ると、Meetupなどの勉強会が盛んです。ここで一つアドバイス。
「.NET Developers Group」だけでなく、「Product Management」や「UX Design」のミートアップに参加してください。
最初は居心地が悪いかもしれません。「君、エンジニアなのになんでここにいるの？」という顔をされるかもしれません。でも、そこが狙い目です。
「エンジニアの視点もわかるUXデザイナー」や「実装の痛みがわかるPM」はいますが、**「ビジネスとUXの言葉が喋れるバリバリのバックエンドエンジニア」**は、ユニコーン並みに希少種です。
そこで「技術的にはこうすれば、そのUXをもっと低コストで実現できるよ」と提案してみてください。あなたは一瞬でその場のヒーローになり、強烈なネットワーキングが生まれます。
自分の「タグ」を掛け合わせるのです。 [C# Expert] x [Design Thinker] 。これがあなたの市場価値を倍増させます。
アクションプラン：明日からのロードマップ
さて、最後に具体的なアクションプランを提示して、このシリーズを締めくくりたいと思います。
明日から、以下のステップで動いてみてください。
- Step 1：観察（Day 1～）
- コードを書く手を止め、ユーザー（またはPM）の隣に座る。
- 「これ、使いにくくないですか？」と聞いてみる。
- 自分のアプリが使われている現場を、ただじっと見る（ログを見るのではなく、人を肉眼で見る）。
- Step 2：疑問（Week 1～）
- 降りてきた仕様書に対して「Why?」を3回問う。
- 「言われた通りの機能」ではなく「意図を汲んだ代替案」を一つだけ提案してみる。
- 「ナプキンスケッチ」でイメージをすり合わせる習慣をつける。
- Step 3：実験（Month 1～）
- 小さな機能でいいので、プロトタイプ（動かないハリボテ）で検証してから実装に入るフローを試す。
- 同僚のエンジニアを巻き込んで、プチ・デザインワークショップをやってみる（「みんなでユーザーのペルソナ描いてみない？」と誘う）。
- Step 4：変革（Year 1～）
- あなたの肩書きは「Senior Software Engineer」のままでも、チーム内での認識は「Product Engineer」に変わっているはずです。
- AIを部下（コーディング担当）にし、あなた自身はより高度なアーキテクチャ設計と価値創造に集中する。
最後に：あなたは「何を作る人」ですか？
WPFのXAMLには、DesignHeight や DesignWidth というプロパティがありますよね。これは実行時には無視される、デザイン時のための設定値です。
私たちの仕事もこれに似ています。
ユーザーが最終的に触れるのは、コンパイルされたバイナリ（実行ファイル）だけです。
私たちが裏でどれだけユーザーのことを考え、どれだけ付箋を貼り、どれだけスケッチを描き直したか。その「デザイン時の思考プロセス」は、ユーザーの目には見えません。
でも、確かに伝わります。
「あ、このアプリ、なんだか使いやすい」
「私のやりたいこと、わかってくれてる」
そのユーザーの無意識の「心地よさ」の中に、あなたのデザイン思考は生きています。
美しいコードは、開発者を幸せにします。
しかし、美しい思考（デザイン）は、ユーザーの人生を少しだけ幸せにします。
私たちエンジニアは、魔法使いです。
キーボード一つで、世界中の誰かの面倒な作業を消し去り、新しい可能性を生み出すことができます。
その魔法の杖（技術）を、どこに向けて振るのか。それを決めるのは、あなたの「心（デザイン思考）」です。
さあ、恐れることはありません。
あなたのツールキットには、もう最強の武器が入っています。
C#とデザイン思考を携えて、世界へ飛び出しましょう。
現場でお会いできるのを、楽しみにしています。
Happy Coding, and Happy Designing!
コメント