実践 NEW
DX推進におけるデザイン思考の実装——現場で機能させる3つの条件
DX推進の現場でデザイン思考を単なるワークショップに終わらせず、実際に機能させるための3つの構造的条件を解説
14分で読める
DX推進の現場で、デザイン思考は「使われているが機能していない手法」の筆頭になりつつあります。
経営会議でデザイン思考の言葉が出る。社内研修でワークショップが開催される。「共感」「プロトタイプ」「ユーザー中心」というキーワードが資料に並ぶ。しかし現場では、日常的な意思決定のプロセスも、システム開発の進め方も、何も変わっていない。
この断絶の原因は、デザイン思考の「学習」と「実装」を区別できていないことにあります。デザイン思考の実装とは、思考の方法論を組織の構造に埋め込むことです。ワークショップで学ぶだけでは、実装は起きません。
本記事では、DX推進の文脈でデザイン思考が実際に機能するための3つの構造的条件を、現場の実態から整理します。
なぜDXとデザイン思考は相性が悪く見えるのか
DX推進にデザイン思考を導入した組織が、最初にぶつかる壁があります。DX推進とデザイン思考は、その優先ロジックが根本的に異なります。
DX推進が動く論理は、効率とスケールです。 システムを統合し、プロセスを自動化し、データを一元管理する。投資対効果が明確で、ROIで意思決定できる。スピードが求められ、「まず決めてから動く」という実行志向が強い。
デザイン思考が動く論理は、発見と検証です。 ユーザーを観察し、問いを定義し、仮説を立ててプロトタイプで検証する。「まだ答えが分からない」という不確実性を前提にする。時間をかけて理解を深めてから動くという探索志向が強い。
この論理の差異を無視して「DXにデザイン思考を導入する」と決定すると、実際には「DXのスピードにデザイン思考を合わせる」という変形が起きます。2時間のワークショップで共感フェーズを「完了」させ、翌日には仕様書を書き始める。デザイン思考の形式だけが残り、機能する余地がなくなります。
これは手法の失敗ではありません。実装条件の設計が欠けているための失敗です。
条件1：「探索の時間」を構造として確保する
DX推進の現場でデザイン思考が機能するための最初の条件は、ユーザー理解と問い直しのための時間を、プロジェクト計画に構造として埋め込むことです。
「時間があればやる」ではなく「やらなければプロセスが進まない」という設計でなければ、実務の圧力に負けます。
具体的な設計の例として、システム開発プロジェクトのフロントに探索専用のスプリントを設ける方法があります。2週間から4週間の期間を、成果物を定義した上で確保する。成果物は「ユーザーインタビューの実施（最低5名）」「インサイトをまとめたアフィニティ図」「POV文の定義」「HMWの問い設定」という形で具体化する。この期間をプロジェクト計画の公式なフェーズとして位置づけることで、省略が構造的に難しくなります。
現場でよく観察される失敗パターンがあります。「ユーザーリサーチをする時間を作ってください」という依頼を現場に投げると、「業務が忙しいので来月以降で」「リサーチの担当者がいない」という返答が来て、結局リサーチなしで仕様策定が始まります。これはリサーチを「任意のオプション」として設計しているからです。
このアプローチでは、経営層またはプロジェクトオーナーから「この2週間は探索フェーズであり、仕様策定はその後に始まる」という承認を事前に得ます。リサーチが省略されると開発フェーズに入れない、という設計にすることで、探索の時間が守られます。
もう一つの実装パターンは、既存の会議体にデザイン思考的な問いを埋め込む方法です。週次の進捗会議の冒頭15分を「ユーザーフィードバック共有」に固定する。月次のプロジェクトレビューに「ユーザー視点の発見事項」を必須アジェンダとして設定する。これにより、リサーチの時間を別途確保しなくても、ユーザー視点が意思決定の場に構造的に入ります。
探索の時間を「文化」ではなく「構造」で確保することが、最初の条件です。文化は長期的な変革の結果として生まれますが、構造は設計によって今日から変えられます。
条件2：「意思決定の接続」を設計する
デザイン思考の実装で最も見落とされがちな条件は、リサーチとインサイトが、実際の意思決定に接続される経路を設計することです。
ユーザーインタビューを実施し、アフィニティ図を作り、インサイトを言語化した。しかし、そのインサイトが「誰の、どの意思決定を、どのように変えるか」が設計されていなければ、成果物は資料フォルダに格納されて終わります。
接続の設計には3つのレベルがあります。
接続レベル1：機能仕様への接続
ユーザーリサーチのインサイトが、システムの機能要件・非機能要件の定義に直接反映される経路を作る。具体的には、機能仕様書のテンプレートに「このインサイトを根拠とする」という参照フィールドを追加します。「なぜこの機能が必要か」の答えがインサイトへのリンクになる。この設計により、仕様策定者はリサーチ成果物を参照する習慣が生まれます。
接続レベル2：優先順位の意思決定への接続
DX推進のプロジェクトでは常に「どの機能から作るか」という優先順位の決定が発生します。この決定がコスト・スケジュール・技術的制約のみで行われると、ユーザー視点は入りません。優先順位の評価基準に「ユーザーインパクト」という軸を明示的に追加し、インサイトに基づく評価を義務化します。
接続レベル3：経営報告への接続
DX推進の経営報告は多くの場合、KPI・コスト・スケジュールで構成されます。ここに「ユーザー理解の更新」という項目を追加します。「今月発見した、ユーザーに関する新しい事実」を経営報告の定例項目にすることで、経営層がユーザー視点に触れる機会が構造化されます。
意思決定の接続を設計しないと、デザイン思考はリサーチチームの内部活動に留まります。インサイトが組織の外に出ない。デザイン思考の価値は、インサイトが意思決定を変えるときにしか発揮されません。
実際に有効だったアプローチとして「インサイトカード」の活用があります。ユーザーリサーチで得られた各インサイトを1枚の構造化されたカードにまとめ（インサイトの要約・根拠となる観察・設計への示唆・HMWの問い）、プロジェクトの意思決定者全員に物理的に配布します。議論の場にインサイトが持ち込まれ、参照されます。デジタルで共有するより、物理的に手元にある状態の方が、意思決定の場で参照される頻度が高くなります。
条件3：「失敗の許容」を評価制度で担保する
デザイン思考の中核にあるのは、仮説をプロトタイプで検証し、失敗から学ぶというサイクルです。このサイクルが機能するための前提は、「失敗」が罰せられないことです。
しかし多くのDX推進組織では、評価制度が失敗を罰します。「計画通りに進んだか」「期日を守ったか」「コストを超えなかったか」という基準で評価される環境では、プロトタイプを作って「機能しなかった」という結果を出すことは評価上のリスクになります。担当者は「プロトタイプで失敗する」よりも「プロトタイプを作らずに仕様書を書く」ことを選びます。
評価制度の変革なしに、デザイン思考の実装は完成しません。
これは評価制度の全面改定を意味するわけではありません。既存の評価制度に「学習と実験に関わる評価項目」を追加する、というアプローチが現実的です。
具体的には、次の3つの評価項目を追加することが有効です。
「ユーザーリサーチの実施と共有」——今期に実施したリサーチ件数と、組織内への共有実績を評価する。リサーチを行動として起こすことが評価に繋がる設計にする。
「プロトタイプ検証の実施」——本開発前にプロトタイプを用いた検証を行ったプロジェクトの数を評価する。検証ステップを省略しないことが得になる設計にする。
「学びの言語化と共有」——失敗した仮説や中断したプロジェクトから得た知識を言語化し、チームに渡した実績を評価する。失敗を隠すよりも開示する方が得になる設計にする。
最も重要なのは、「失敗した実験の共有」を評価対象にすることです。「うまくいかなかった検証の結果を共有し、チームの知識を増やした」という行動に対して、ポジティブな評価が付く設計にすることで、失敗の隠蔽よりも共有が得になります。
評価制度の変革と合わせて、リーダーシップの行動変容が必要です。マネージャーが「なぜ計画通りに進まなかったのか」と問う代わりに「そこから何を学んだか」と問うようになる。この問いの変化が、チームの行動を変えます。制度と行動が一致したとき、失敗の許容が文化として定着し始めます。
3つの条件の相互作用
3つの条件は独立したチェックリストではなく、相互に支え合う構造を持ちます。
探索の時間（条件1）があっても、得られたインサイトが意思決定に接続されなければ（条件2）、リサーチは形骸化します。インサイトが意思決定に接続されても、失敗が許容されなければ（条件3）、検証プロセスは省略されます。失敗が許容されても、探索の時間が確保されなければ、検証する仮説が生まれません。
3つの条件はパッケージです。どれか1つだけの実装では、効果が出にくい。
実装の順序としては「条件1から始め、条件2、条件3の順に整備する」というアプローチを推奨します。まず探索の時間を構造として確保し、リサーチの実績を作る。次にそのリサーチ成果物が意思決定に使われる経路を設計する。最後に、実験と失敗を評価する仕組みに着手する。この順序には理由があります。条件2・3の整備には組織全体の関与が必要ですが、条件1はプロジェクト単位で始められます。
DX推進への具体的な統合シナリオ
3つの条件を踏まえたDX推進プロジェクトの典型的な流れを示します。
Phase 0（2〜4週間）：探索フェーズ
プロジェクト開始前に設ける探索フェーズ。ユーザーインタビュー（5〜10名）・現場観察・既存データのレビューを実施し、アフィニティ図とインサイトカードを成果物として定義する。成果物のレビュー完了を、Phase 1開始の条件として設定する（条件1の実装）。
Phase 1（システム設計）：インサイトからの仕様定義
Discovery Sprintのインサイトを元に、機能要件を定義する。仕様書の各機能に「根拠インサイト」を記載する欄を設け、インサイトのない機能要件は追加しない運用ルールを設ける（条件2の実装）。
Phase 2（プロトタイプ〜本開発）：検証サイクルの制度化
主要機能の本開発前に必ずプロトタイプ検証を実施するルールを設ける。検証結果を「仕様の更新根拠」として記録し、スプリントレビューで共有する（条件3の実装）。
このシナリオは理想的な状態ですが、現実には「Phase 0を1週間に圧縮せざるを得ない」「インタビューが3名しか実施できなかった」という制約が生じます。制約の中でも「ゼロよりは1人でもインタビューする」「仕様書に根拠フィールドだけは追加する」という最小単位の実装を維持することが重要です。構造の痕跡を残すことで、次のプロジェクトでの改善が可能になります。
機能する実装の共通点
複数のDX推進プロジェクトで機能した実装に共通するパターンがあります。それは「デザイン思考を特別なものとして扱わないこと」です。
「今日はデザイン思考のワークショップです」という形で導入するのではなく、「プロジェクトの開始前にユーザーインタビューを実施する」「仕様書に根拠インサイトを記録する」「本開発前に低解像度のプロトタイプで検証する」という具体的な行動として、通常のプロセスに埋め込む。
デザイン思考という言葉を使わずに、デザイン思考の実践を組み込む——この逆説的なアプローチが、特にDXの実務文脈では有効に働きます。DXのリーダーは「デザイン思考を導入したい」という要求よりも「DXプロジェクトの成功率を上げたい」「ユーザーに使われないシステムを作るリスクを減らしたい」という問いを持っています。その問いに対して、デザイン思考の具体的な実践を「解決手段」として提示すると、導入への抵抗が大幅に下がります。
DX推進におけるデザイン思考の実装は、方法論の選択ではなく、組織の意思決定構造の再設計です。3つの条件——探索の時間の確保、意思決定への接続、失敗の許容——を構造として設計したとき、デザイン思考は「ワークショップの記憶」から「日常業務の論理」に変わります。