デザイン思考入門｜エンジニアが身につけるべき「人間中心」の設計法

「ユーザー目線で考えよう」——この言葉を耳にしたことがないエンジニアはいないだろう。だが実際にユーザーの行動を観察し、仮説を立て、プロトタイプで検証するプロセスを体系的に実践しているエンジニアは少数派だ。デザイン思考は、デザイナーだけのものではない。むしろ、技術的制約を熟知したエンジニアこそ、その恩恵を最大限に引き出せる。

デザイン思考とは何か——5つのフェーズ

デザイン思考は、スタンフォード大学d.schoolが体系化した問題解決のフレームワークだ。その核心は「人間の行動を出発点に、反復的に解を探索する」ことにある。

フェーズ	目的	エンジニアの役割
共感（Empathize）	ユーザーの文脈・感情・行動を深く理解する	ログ分析、ユーザーインタビュー同席、行動データの構造化
定義（Define）	真の問題を特定する	データに基づくペインポイントの定量化、技術的制約の明示
発想（Ideate）	多様なソリューション候補を出す	技術的実現可能性の即時フィードバック、新技術の提案
試作（Prototype）	素早く形にして検証可能にする	ローファイプロトタイプの実装、APIモックの構築
検証（Test）	仮説を実際のユーザーで確かめる	A/Bテスト基盤の構築、定量指標の設計

注目すべきは、このプロセスが直線的ではなく循環的であること。検証の結果、共感フェーズに戻ることも珍しくない。ウォーターフォール型開発に慣れたエンジニアにとって、この「戻ること」を受け入れるマインドセットの転換が最初の壁になる。

共感フェーズ——コードの向こう側にいる人間を見る

エンジニアは「ユーザー」を抽象的な存在として扱いがちだ。ペルソナをつくり、ユースケースを定義する。しかしデザイン思考における「共感」は、もっと生々しい。実際のユーザーが画面の前でどう迷い、どこで手が止まり、何に苛立っているかを観察する。

あるECサイトの事例を考えよう。カート離脱率が高いという問題に対して、エンジニアリング的なアプローチは「決済フローを3ステップから1ステップに短縮する」かもしれない。しかし共感フェーズでユーザーを観察すると、離脱の原因は「送料がカートに入れた後にしか分からない」ことだったりする。技術的な改善ではなく、情報設計の問題だ。

エンジニア的な仮説	共感フェーズで判明した実態
ページの読み込みが遅い	実は読み込み中にユーザーが離脱しているのではなく、価格を比較検討している
フォームの入力項目が多い	項目数よりも「なぜこの情報が必要か」が不明なことが不安を生んでいる
検索機能の精度が低い	ユーザーはそもそも何を検索すべきか分かっていない

技術的に正しい解決策が、ユーザーにとって正しい解決策とは限らない。この気づきが、デザイン思考の出発点だ。

発想フェーズ——「制約」を創造の燃料にする

デザイン思考の発想フェーズでは、まず制約を外してアイデアを広げ、その後で制約を戻す。ここでエンジニアが価値を発揮できる場面がある。技術的制約を知っているからこそ、「何がギリギリ可能か」という境界線上のアイデアを出せるのだ。

技術的制約はイノベーションの敵ではなく、方向性を与える力だ。Twitterの140文字制限がショートメッセージ文化を生んだように、制約がユーザー行動を形づくることがある。エンジニアは「できない」と言うのではなく、「この制約があるから、こういう方向に振ってみてはどうか」と提案できる。

プロトタイピング——「完成品」を作らない勇気

エンジニアの多くは、動くものを作るとき「ちゃんと動くもの」を作ろうとする。エラーハンドリングを書き、エッジケースを考慮し、テストを書く。しかしデザイン思考におけるプロトタイプは、検証したい仮説だけに集中した最小限のものだ。

プロトタイプの段階	目的	実装レベル
ペーパープロトタイプ	画面遷移と情報構造の検証	紙とペン。コードは書かない
クリッカブルモックアップ	ユーザーフローの検証	[Figma](/tag/figma) or 静的HTML。バックエンドなし
機能プロトタイプ	コアな体験価値の検証	最小限のバックエンド。認証・決済はスキップ
テクニカルプロトタイプ	技術的実現可能性の検証	見た目は不問。パフォーマンス・スケーラビリティのみ確認

「このプロトタイプで検証したい問いは何か」を先に決め、それ以外は意図的に省略する。この割り切りが、開発速度と学習速度の両方を上げる。

テストフェーズ——定性と定量を組み合わせる

エンジニアはA/Bテストや統計的有意性の判定に強い。一方で、数値では捉えきれないユーザーの感情や文脈の理解は弱い。デザイン思考のテストフェーズでは、この両方を組み合わせる。

定量データは「何が起きているか」を教えてくれる。コンバージョン率が5%下がった。ある画面で40%のユーザーが離脱している。しかし「なぜそうなっているか」は、定性調査でしか分からない。ユーザビリティテストで5人のユーザーに触ってもらい、声に出して考えてもらう（シンクアラウド法）だけで、数値の裏にある行動の理由が見えてくる。

デザイン思考を日常に組み込む

デザイン思考は特別なワークショップでだけ使うものではない。日常の開発プロセスに溶け込ませることができる。コードレビューで「この実装はユーザーのどんな行動を前提にしているか」と問う。スプリント計画で「このユーザーストーリーの背後にある感情は何か」を確認する。

技術的に正しい解決策を作れるエンジニアは多い。だが、ユーザーにとって正しい解決策を見つけられるエンジニアは少ない。その差を埋めるのがデザイン思考だ。あなたが最後にユーザーの「行動」を直接観察したのはいつだろうか。