---

デザイン思考との出会い — 「技術だけじゃ、解けない問題がある」

サブタイトル：エンジニア人生を揺らした、あの日の違和感

海外で働き始めてしばらく経った頃、僕は大きな壁にぶつかりました。
「コードは書ける。仕様も理解している。なのに、なぜかチームが求めている“本質”からズレる。」
そんなモヤモヤを毎日のように感じていたんです。

特に、C# WPFで新しいUIフローを設計していたある日、プロダクトマネージャーに言われたひと言が今も忘れられません。

“You solved the requirement, but not the problem.”
（要求には応えたけど、問題は解けていないよ。）

最初は意味がわかりませんでした。
仕様書通りに作って、動きも完璧。バグもなし。
なのに「問題は解けてない」と言われる。

「え？どういうこっちゃ？」と心の中で日本語で突っ込みながらも、僕はその言葉の意味を理解できていませんでした。

---

■ “正しく作る”と“正しいものを作る”は全く別物

エンジニアとして成長していくと、無意識のうちに
**「正しく作る（build the thing right）」**ことばかり意識してしまうものです。

設計通りに動く
バグがない
パフォーマンスが安定している
テストが通る

これはもちろん大切。
だけど、海外の開発現場ではもう一つ、もっと強調される言葉があります。

それが 「正しいものを作る（build the right thing）」。

僕はこの違いを理解していませんでした。
いや、頭では理解していたけど “体感” が伴っていなかったんでしょうね。

このギャップを埋めるきっかけになったのが デザイン思考（Design Thinking） でした。

---

■ デザイン思考は「デザイナー専用の魔法」ではない

デザイン思考という言葉を初めて聞いた時、
「いやいや、俺エンジニアなんだけど。 UIとかデザインの専門家じゃないし。」
と正直思いました。

でもこれは完全な誤解。

海外の現場では、デザイン思考はエンジニアにも当たり前のように求められるスキルなんですよ。

なぜか？

理由は簡単。
エンジニアほど“技術に引っ張られやすい”職種はないから。

できること
実現可能性
ライブラリの制約
アーキテクチャ
既存コードとの相性

こういう技術の“枠”で考え始めると、すぐに本質の問題を見失う。

だからこそ、技術を一旦置いて
「そもそも何の課題を解こうとしているのか？」
に立ち戻る思考が必要だったんです。

---

■ 海外エンジニアにこそ効く“5つのフェーズ”

デザイン思考には「Empathize（共感）」「Define（定義）」「Ideate（発想）」「Prototype（試作）」「Test（検証）」という5つのフェーズがあります。

でも、理解してほしいのは
全部やらなくていい。ひとつでもやれば世界が変わる。
ということ。

たとえば Empathize（共感）。
これを1時間やるだけで、
「そもそもこの機能いらないんじゃ？」
と気づくことだって普通にあります。

実際、僕自身が経験しました。
半年かけて設計しようとしていた新しい画面が、ユーザーインタビューをたった2回やっただけで “不要” になったんです。

正直 shock でしたが、同時に
「これがデザイン思考か……」
と衝撃でした。

---

■ 僕が“技術者”から“プロダクトを作る人”に変わった瞬間

海外の現場では、
「ただコードを書く人」は評価されません。

求められるのは
“プロダクト全体を理解し、価値を生み出すエンジニア”。

そのスタート地点に立てたのは、まさにデザイン思考のおかげでした。

ユーザーの感情を想像する
課題を見極める
柔らかい発想を生む
小さく試す
早く失敗する
すぐ学ぶ

これらはどれも、技術書では学べない「現場のスキル」です。

そして驚いたことに、
デザイン思考は“技術を超えた問題解決術”だった。

この気づきが、僕のエンジニア人生の大きな転換点になりました。

5つのフェーズを“エンジニア視点で読み解く”

サブタイトル：今日から使える「技術に縛られない思考術」

前回、「デザイン思考はデザイナーの道具じゃない」と書きましたが、
じゃあエンジニアがどう使えばいいの？
という疑問があると思います。

今回は、デザイン思考の5つのフェーズ
Empathize → Define → Ideate → Prototype → Test
を、海外エンジニアとして現場でどう使ってきたか、僕自身の失敗談も交えながら“実務レベル”で解説します。

---

■ Empathize（共感）— 技術を一旦捨てる勇気

デザイン思考で一番大切なのは、いきなり技術の話をしないこと。
C#のMVVMがどうだ、WPFのDataBindingがどうだ、パフォーマンスがこうだ…
そういう議論は普通は大好物だけど（笑）、最初のフェーズでは封印します。

● なぜ最初に“共感”なのか？

理由はシンプルで、
「そもそも何のために作るの？」がわからない状態で技術を語っても意味がないから。

海外のPMやUXデザイナーと仕事して驚いたのは、
「じゃあユーザーは何に困ってるの？」
「どんな状況でその問題に直面してるの？」
と“人の行動や感情”から話が始まることでした。

特にエンジニアは技術に逃げがち。
でもこのフェーズでは “技術は一旦忘れる” のが最強の姿勢です。

---

● 僕が体験した「勘違いプロジェクト」

あるプロジェクトで、ユーザーの作業時間を短縮するツールを作ることになりました。
僕は張り切って、

• 高速化
• 自動化
• UIの最適化
• ホットキーの追加
  など“機能”の話ばかりしていました。

ところが、UXデザイナーがあるユーザーに話を聞いて、こう言ったんです。

“They don’t need speed. They need confidence.”
（彼らが欲しいのは速度じゃなくて安心感よ）

僕は衝撃を受けました。
実際のユーザーは作業時間より「ミスしたくない」が最優先。
だから
「スピードより、手順を可視化するUI」
が正解だったんです。

機能をゴリゴリ作る前に、たった10分ユーザーと話すだけで答えが変わる。
それがEmpathizeの力です。

---

■ Define（定義）— 解くべき問題は実はいつも“最初の理解と違う”

共感フェーズで得た情報を整理して、
「問題は結局何なの？」
を一言で表すのがDefine。

● 問題定義がズレると、全部ズレる

海外で何度も目にしたのは、

• 仕様通り作ったのに評価されない
• MVPがユーザーに刺さらない
• 開発が複雑化する
  という失敗。

たいていの原因は、
問題を間違えて定義していた
これです。

---

● エンジニアにありがちな“悪い問題定義”

× 「UIを改善すること」
× 「処理を高速化すること」
× 「WPFで再実装すること」

いや、それは“手段”なんですよね。

---

● 良い問題定義はたった1行で言える

正しいDefineは、
ユーザーの感情や状況が入っているものが多いです。

例：

“ユーザーが業務中にミスを恐れず、安心して作業できるようにしたい。”

例：

“初心者でも迷わずに目的の情報へたどり着けるようにしたい。”

この1行を作ると、チーム内の議論の質が劇的に変わります。
エンジニア側の設計もブレなくなる。

僕もDefineがちゃんと決まっているプロジェクトは、本当にストレスが少なかったです。

---

■ Ideate（発想）— 技術を混ぜていいのはここから

ここがエンジニアの腕の見せどころ。
他のフェーズでは抑えていた“技術トーク”を解禁できます。

ただし注意点がひとつ。
最初から正解を作ろうとしないこと。

● 「とりあえず出せるだけ出す」発想法

海外の現場ではブレスト中に
「それ無理じゃない？」
と言うのはタブー扱いされます。

理由は簡単。

最初に「無理」と言った瞬間、発想が止まるから。

僕が最初に海外の現場でブレストしたときも、
「こんなアイデア出していいの？」
と躊躇していましたが、PMに言われた言葉がこちら。

“It doesn’t have to be good. It just has to be said.”
（正しい必要はない。ただ出せばいい）

これを聞いて、発想って技術より“勇気”なんだなと思いました。

---

● エンジニアのアイデアは“実現性”で価値がある

アイデアを出す中で、エンジニアが特に強いのは
そのアイデアをどう実現できるかを説明できること。

たとえば

• ユーザーの行動をログで検出できる
• 負荷を下げるアルゴリズムに置き換えられる
• UIを段階的に出すことでミスを減らす
  など、アイデアと実装の橋渡しができる。

デザイン思考の発想フェーズは、エンジニアの技術力が“価値”として最も輝く瞬間なんです。

---

■ Prototype（試作）— 作り込み禁止！雑でいい！

ここで多くのエンジニアがやってしまうのが、
最初から高品質なものを作ってしまうこと。

僕も昔はWPFで綺麗な画面を作って、
「ほら、どう？」
と出していたんですが…

99%の確率で言われるんですよ。

“Can we try something simpler?”
（もっとシンプルでいいんだけど？）

● プロトタイプは“雑だから強い”

• 紙
• ホワイトボード
• 手書きUI
• Figmaの線だけUI
• C#で最低限動くだけの仮実装

これで十分。

理由は明確で、
雑なものほど、チームが手を加えやすいから。

ガチガチに作り込んだプロトタイプは、
「壊したら悪い」
「変更しづらい」
という空気になってしまい、本当の議論ができません。

海外の現場では
“プロトタイプは10分で作って、10回捨てるもの”
という感覚でした。

---

■ Test（検証）— 「正しかったか？」を最速で確かめる

プロトタイプができたら、すぐにユーザーへ見せに行きます。
海外では「恥ずかしいレベル」のものでも普通に見せます。

● ここでエンジニアが得られる最大のメリット

それは
「自分の設計がズレてないかを早期に確認できる」
という点。

正直、これがあるだけで後々のストレスが全然違います。

---

● 僕が一番驚いたテストの結果

ある画面設計で
「このボタンは右下でしょ」
と思って配置していたんですが、テスト中にユーザーが一言。

“Why is this button hiding from me?”
（なんでボタンが隠れてるの？）

え…隠れてたの？
と思ったんですが、ユーザーにとっては
「押したいと思った瞬間に視界にない」＝隠れている
だったんですよ。

この気づき、いくら机上で議論しても得られません。

---

■ 5つのフェーズを使えるエンジニアは「作る人」から「価値を届ける人」に変わる

Empathize
Define
Ideate
Prototype
Test

この流れをしっかり回すと、エンジニアは
“コードを書く職人”から “価値の創造者”
へと本当に変わっていきます。

海外の現場で評価されるエンジニアは例外なく
“問題を正しく理解し、正しいものを作れる人”。

そのベースになっているのが、まさに デザイン思考 でした。

デザイン思考が現場を変えた瞬間

サブタイトル：失敗が学びに変わり、学びが成長に変わるプロセス

「起」でデザイン思考の本質を知り、
「承」で5つのフェーズの使い方を理解し、
ここからは “現場での実装と変化” を語っていきます。

正直に言うと、最初からうまくいったわけではありません。
むしろ、失敗だらけ。
だけど、そこから得た学びが今の僕のエンジニア人生を作っています。

---

■ 1. 「話の通じない会議」が変わった日

——理解されない技術説明の地獄から抜け出す

海外の開発現場に入ったばかりの頃、
会議はいつも 「意思疎通のズレ」と「議論の迷子」 でカオスでした。

僕が技術的にベストと思う案を説明しても、
PMやデザイナーからはこう返ってくる。

“But does it solve the problem?”
（で、それって問題を解決してるの？）

“Why do we need that complexity?”
（なんでそんな複雑に？）

内心「いや、ちゃんと説明してるよ？」と思っていたけど、
実は僕は “技術の話しかしてなかった”。

---

● デザイン思考を取り入れた会議に起きた変化

その後、EmpathizeとDefineのまとめを冒頭で必ず共有するようにした。

例えば：

• どんなユーザーが
• どんなシーンで
• どんな不便を感じていて
• それをどう変えたいのか

この「1分の共有」をするだけで、
会議が驚くほどスムーズになった。

● 技術議論に「理由」が生まれる

Before：
「この実装が最適です！（技術的に）」

After：
「ユーザーがミスを恐れているので、ステップ型UIが良い。そのためにはこの実装が必要です。」

同じ技術説明でも、
“誰のために必要なのか”
があるだけで理解されるスピードが全然違う。

---

■ 2. プロトタイプを捨てまくった1週間

——完璧主義を捨てたら、成果が倍速になった

ある短期プロジェクトで、海外メンバーと一緒にUIのプロトタイピングを担当しました。
そのときPMに言われたのが、この一言。

“We will make 10 prototypes in 7 days.”
（7日で10個プロトタイプ作るよ）

正直、耳を疑った。
“10個も？WPFで？無理じゃない？”
と思ったけど、実はそれが大きな転換点になった。

---

● ①「とりあえず作る」から始める

1個目：紙のラフスケッチ
2個目：Figmaの線だけUI
3個目：ボタンだけ動くWPF
4個目：ユーザーフローだけ
…

これをひたすら回し続ける。

やってみて気づいたのは、
完璧を目指すと遅い。
でも雑に作ると速いし、アイデアが湧く。

---

● ② 捨てることが前提だから、気がラクになる

以前の僕は「作ったものを否定される＝しんどい」だった。
でもデザイン思考では、

• 作る
• 見せる
• フィードバックをもらう
• 捨てて改善する

これが“普通”。

だから、ミスも失敗も「発見」に変わる。

---

● ③ エンジニアが圧倒的スピードで成長する理由

プロトタイプを作るたびに

• ユーザーの行動
• UIの反応
• 認知のクセ
• ミスしやすいポイント

これを短期間で大量に浴びる。

結果、
設計力が一気に跳ね上がる。

これがデザイン思考が「学習加速装置」と呼ばれる理由なんだと思った。

---

■ 3. ユーザーテストで“思い込み”が壊された経験

——現場で刺さったのは「正しさ」ではなく「使いやすさ」

ある画面の改善プロジェクトで、
僕は「これこそ最適解」というUIを作った。

自信もあったし、見た目も綺麗。
でも、テストでユーザーに見せたら第一声がこれ。

“I’m lost.”
（迷った）

え？
あれ？
そんなはずでは？

僕はUIの「美しさ」で判断していたけれど、
ユーザーは「操作の確信」で判断していた。

---

● 僕が学んだ“ユーザーは論理では動かない”という事実

理屈では完璧でも、
使ってみるとダメ
ということはよくある。

これを理解してからは
「設計＝人間理解」
という見方に完全に変わった。

---

■ 4. プロジェクトが“巻き戻らなくなる”魔法

——後戻りコストが激減した理由

長く海外の開発現場にいるとわかるけど、
プロジェクトの遅延はたいてい
“間違った理解のまま進んでしまった”
から発生します。

仕様変更
再設計
UIの作り直し
ユーザー不満
レビューの差し戻し

これが地獄。

しかしデザイン思考を取り入れると、
初期段階でズレを徹底的に潰す
ので、後戻りが減る。

● 僕のチームでは、デザイン思考導入後

• 手戻り率 40%→10%
• 初期テストでのユーザー指摘数が半減
• コミュニケーション摩擦が激減

数字にも現れて、チーム全体の空気が良くなった。

---

■ 5. 技術力 × デザイン思考 = “海外で評価されるエンジニア”

海外の現場では、
「コードを書ける」はあくまでスタートライン。

本当に評価されるのは、

• “正しい問題に取り組める”人
• “価値に基づいて実装を選べる”人
• “ユーザー視点で説明できる”人

つまり、技術の前に“思考”があるエンジニア。

僕自身、デザイン思考を取り入れたことで
「話の通じるエンジニア」
「信頼されるエンジニア」
と言われる機会が明らかに増えた。

技術 + 思考が揃うと、
海外でも圧倒的に仕事がしやすくなると実感している。

---

■ デザイン思考は、エンジニアを“作業者”から“価値の創造者”へ変える

ここが「転」の結論。

デザイン思考は
“デザイナーの道具”
ではなく、

エンジニアがチームで輝くための “共通言語”
です。

この考え方を取り入れただけで、
僕の海外エンジニア人生は明らかに変わった。

エンジニアだからこそ、デザイン思考が最強の武器になる

サブタイトル：明日から使える「価値創造エンジニア」へのロードマップ

デザイン思考は、海外の現場で働く僕にとって
**「言語」でもあり「武器」でもあり「生存戦略」**でもあります。

最後の「結」では、ここまでの学びを
**エンジニアがすぐ現場で活かすための“実践体系”**としてまとめます。

---

■ 1. デザイン思考は「問題発見力」を飛躍的に上げる

——技術力より希少なスキルは何か？

海外で働いていて実感するのは、
技術が強いエンジニアは山ほどいるけれど、
「本質的な問題に気づけるエンジニア」はとても少ないということ。

実際、プロジェクトが迷走する原因は
スキル不足ではなく“問題設定のズレ”です。

デザイン思考を使うと、問題を

• ユーザー視点
• シナリオ視点
• チーム視点
• ビジネス視点

で整理できるので、
正しい問題を選べるエンジニアになる。

技術よりも前に“価値の方向性”を正せる人は、
海外では間違いなく重宝されます。

---

■ 2. 毎日の仕事に「5フェーズ」を埋め込む方法

——習慣化できれば、成果は積みあがる

デザイン思考は特別なワークショップだけの話ではありません。
普段の仕事に“サブウェポン”として組み込める。

● ① Empathize（共感）を毎日のルーティンに

• ユーザーの一言メモを残す
• 顧客サポートのログを見る
• バグ報告の背景を推測する

たった数分でも“ユーザーの空気”に触れるだけで視点が鋭くなる。

---

● ② Define（定義）は毎回のタスク開始前に

• 「このタスクの本当の目的は？」
• 「成功の状態は？」
• 「誰が得をする？」

これを3行で書くだけで、実装がスムーズになる。

---

● ③ Ideate（発想）は1人でもできる

• 思いついた案を最低3つ書く
• 良案1つより、微妙な案を5つ

量を出す習慣をつけるとアイデア筋肉が鍛えられる。

---

● ④ Prototype（試作）は“軽く”やる

• 手書き
• モック
• 小さなWPFモジュール
• 仮UI

ポイントは“作り込まないこと”。

---

● ⑤ Test（検証）は“観察”に集中

• ユーザーの迷い
• 戸惑ったタイミング
• 意図しない行動

評価より行動を観察することで、深い学びが手に入る。

---

■ 3. 海外で「話の通じるエンジニア」になるための黄金法則

——コミュニケーションの質がキャリアを決める

海外の現場で長年働いていて気づいたことがあります。

▼ 技術力 ×
▼ コミュニケーション能力 ×
◎ 思考の透明性 ＝ 信頼されるエンジニア

“なぜその設計なのか？”
“誰のための選択なのか？”
“何を解決するためなのか？”

こういった説明ができる人は
プロジェクト内で一気に評価される。

---

■ 4. 「技術で議論する」から「価値で議論する」へ

——技術議論のストレスが激減する

僕がデザイン思考で救われた理由の一つがこれ。

昔は技術的な正しさで戦っていたけれど、
今はこう説明するようになった。

• 「ユーザーは誤操作を恐れている」
• 「だからここは単純化すべき」
• 「そのために必要なのがこの実装」

技術の前に“価値”を置くと、
議論がケンカではなく“合意形成”になる。

これは、海外で働くうえで超重要なスキルです。

---

■ 5. デザイン思考は“孤独なエンジニア”を救う

——1人で抱え込む必要はない

海外で働いていると、
言語の壁や文化の違いで
自分の意見が通らず、孤独になることがある。

でも、デザイン思考は

• 発想をチームで出す
• 問題を一緒に定義する
• ユーザーを共通の軸にする

ことで、
チームの会話の質を一気に高める。

僕自身、
「意見を言いやすい」「説明しやすい」環境を手に入れたのは
デザイン思考を使い始めてからです。

---

■ 6. これからのエンジニアは “価値を作れる人” が生き残る

——AI時代にこそ必要なスキル

AIがコードを書く時代、
純粋な技術力だけで勝負するのは厳しい。

じゃあ何が強みになるか？

「何を作るべきか」を決められる人。
これこそが、デザイン思考。

• どんな価値を提供するか
• どんなユーザーを救うか
• どの行動を変えるのか
• どんな体験を設計するか

こういう“問題選定能力”は
これからのエンジニアにとって最大の武器になる。

---

■ 7. 最後に：デザイン思考は今日から始められる“人生術”

デザイン思考は、
プロダクト開発だけではなく、
人生の意思決定にも応用できる。

例えば――

• キャリアの方向性を定義する（Define）
• 自分のストレスの原因を観察する（Empathize）
• 3つ以上の未来のシナリオを出す（Ideate）
• 小さな行動で試す（Prototype）
• 結果を振り返る（Test）

人生そのものが「プロトタイプ」になる。
だから失敗を恐れなくていい。

---

■ 結論：デザイン思考は、「海外で戦うエンジニアの必須リテラシー」

あなたが

• より良い設計をしたい
• 説明の説得力を上げたい
• チームで信頼されたい
• ユーザー視点の強いエンジニアになりたい
• 海外でもっと活躍したい

そう思っているなら、
デザイン思考は必ず大きな武器になります。

コードだけでは届かない場所まで導いてくれる
“エンジニアのための思考フレーム”です。