デザイン思考×DX｜デジタル変革に活かすユーザー中心設計
目次
「システムは稼働しているのに、現場では誰も使っていない」——DX推進の現場で、こうした声を耳にしたことはないでしょうか。ツールや予算を投じたにもかかわらず、現場への定着や事業価値への貢献という点で壁にぶつかるケースは多く見られます。
その根本にある原因のひとつが、「誰のどんな課題を解くか」という問いが不在のまま、技術導入が先行してしまうことです。
本記事では、DX案件を「技術起点」ではなく「ユーザー起点」で進めるためのプロセスとして、デザイン思考の考え方を「課題抽出→仮説設計→PoC→実装→運用」の各フェーズに沿って解説します。
デザイン思考のプロセス（共感・問題定義・アイデア出し・プロトタイプ・テスト）については、デザイン思考のプロセス｜共感からテストまでの手法とポイント を先にご覧いただくと、より理解が深まります。
① 課題抽出（共感/現場理解）｜ツール導入前にすべきこと
DX案件の最初の問いは、「何を作るか」ではなく「誰がどんな痛みを抱えているか」です。システム要件や機能リストを先に作ってしまうと、後から「要件は満たしているが現場に合わない」という事態が起きやすくなります。
この段階でやるべきことは、現場観察・インタビュー・データ分析を通じた ユーザーのペイン（課題・負担・不満）の定義 です。
- 現場観察： 実際の業務フローを目で見て記録します。「想定していた作業」と「実際の作業」の乖離を見つけることが目的です
- インタビュー： 現場担当者・管理職・エンドユーザーそれぞれに話を聞きます。「なぜその作業をしているか」の理由まで掘り下げます
- データ分析： エラーログ・問い合わせ件数・業務処理時間などの定量データで課題の規模感を確認します
成果物
- 課題リスト（優先度・頻度・影響範囲つき）
- ペルソナ
事例：SaaSプロダクトのUI評価・改善提案（株式会社リコー）
株式会社リコーが展開するSaaSプロダクトに対し、UX/UIの専門的な視点から評価と改善提案を実施しました。実際のユーザー行動やワークフローに基づいて現在のUIが抱える課題を抽出。複雑な経営業務を効率化するための画面レイアウトや視線誘導、フィードバックのあり方を再定義し、開発チームが即座に実装へ移せるよう、具体的なワイヤーフレームやデザイン案を作成し、プロダクトの品質向上に寄与しました。
「何を改善すべきか」が見えていない状態でシステム開発を進めると、優先度が決められず、議論が止まってしまうことがあります。課題の可視化こそがDXの起点となります。
ユーザー理解の型については、ペルソナとは何か？ブランディングに活かす顧客理解の基本知識・ペルソナシートの作り方と活用方法｜チームの「合意」をつくる実践テンプレート もあわせてご参照ください。
② 仮説設計と検証計画（問題定義→実験設計）
課題が可視化されたら、次は「どう解くか」の仮説を立て、その仮説を何で検証するかを設計します。よくある失敗は、課題の洗い出しが終わった直後にソリューション（システム機能）の議論へ入ってしまうことです。
デザイン思考では、問題定義フェーズで HMW（How Might We） を活用します。「○○な人が、△△できるようにするには、どうすればよいか」という問いの形に課題を変換することで、チームの思考の方向が揃いやすくなります。
事例：問い合わせ対応自動応答サービスのUI/UXデザイン支援（株式会社リコー）
株式会社リコーのAIチャットボットサービスのインターフェース支援では、複雑な設定が必要な管理画面を、直感的に操作できるデザインへと改善しました。プロジェクトのはじめに「ユーザー」という言葉の定義から着手したのがポイントです。問い合わせをする人・チャットボットの管理者・サポートスタッフ・導入の意思決定者——同じ「ユーザー」でも立場と課題は異なります。この整理を通じてチームメンバー間の課題認識と設計方針を揃えることで、ユーザーが迷わずFAQを構築・運用できるワークフローに基づいたナビゲーション設計につながりました。
仮説シート（PoC設計テンプレート）
| 項目 | 記入内容 |
|---|---|
| 課題 | 誰が・どんな状況で・何に困っているか |
| 仮説 | ○○を変えることで△△が解決できる |
| 検証指標 | 何をどう計測するか（定量・定性） |
| 期間 | いつからいつまで検証するか |
| 成功基準 | 続行・ピボット・撤退の判断ライン |
仮説キャンバスの段階で「指標と期間」まで決めておくことが重要です。「なんとなく良くなった」という感覚だけでは、PoC→実装の意思決定を合理的に進めることができません。
③ PoC（プロトタイプ→テスト）｜小さく早く学ぶDX
PoC（Proof of Concept＝概念実証）とは、仮説が正しいかどうかを小さな試作と検証によって確かめるプロセスです。DX案件では特に、大規模な開発や全社展開の前に「その方向性が本当に現場に合うか」を小さく確かめる意味で活用されます。
「全社展開を目指して大規模開発をしたが、現場には刺さらなかった」——これはDX案件の典型的な失敗パターンのひとつです。
PoCは、単に「技術的に動くか」だけでは不十分で、業務・運用・投資対効果まで含めて見るのが一般的です。 PoCでは、「どの操作でつまずくか」「どの機能が実際には不要か」「どのインプット方法が現場に合うか」といった、仮説段階では見えなかった具体的な学びを得ることが大事です。この学びをUIや設計に反映してから本格展開に進むことで、リカバリーコストを最小限に抑えられます。
PoCのスコープ例：
- 検証対象の業務・課題の明確化
- 実現したい効果やゴールの設定
- 対象機能・対象範囲の限定
- 技術的に実現可能かの確認
- 業務で使えるかの確認
- 運用面の課題整理
- 必要なデータやシステム連携の確認
- 費用対効果の簡易評価
- 次フェーズへ進むかどうかの判断基準設定
大規模投資の前に「学びを最大化するPoC」を行う——これを意識することが大事です。
④ 実装と組織連携｜IT/業務/CS/人事の役割分担
PoCで手応えを得たとしても、「本番実装」のフェーズでつまずくケースは少なくありません。その主な原因は、プロジェクトがIT部門（またはDX推進室）の中だけで閉じている ことです。
実装フェーズで現場定着を実現するには、IT・業務・CS（カスタマーサポート）・人事が連携した組織設計が必要になります。
このマップで特に重要なのは「人事・教育」の参画タイミングです。新しいシステムやプロセスを定着させるには、教育プログラムと現場リーダーのエンゲージメント が欠かせません。DXを「外向きの変革（顧客体験の向上）」と「内向きの変革（働き方・文化の変革）」として一体で設計することが、長期的な定着につながります。
事例：三豊工業株式会社 社会インフラ事業DX推進ビジョン策定支援
三豊工業株式会社のDX推進ビジョン策定支援では、ワークショップを通じて、技術者やマネジメント層が持つ未来像を引き出し、展開の言語として昇華しました。抽象的な「DX」という概念を、具体的なアクションへ繋げるための羅針盤として言語化・ビジュアル化。組織が同じ方向を向いて変革へ挑むための、文化的な基盤づくりを支援した事例です。
DXのビジョンは「技術ロードマップ」だけでは人を動かすことが難しく、組織に創造的思考のメンタルモデルを根付かせることが、実装フェーズへの道を開きます。
⑤ 評価と本格展開｜3つの視点で判断する
PoCの結果を本格展開に進める際、「手応えはあったが、どう判断すればよいか」という問いが経営層から出やすくなります。「使われているか」「成果が出ているか」「維持できるか」の3つの視点で評価指標を事前に定義しておくことが、このフェーズでの意思決定を速くします。
自社（デスケル）へのウェブフォーム問い合わせ対応を効率化するため、LLM（大規模言語モデル）を活用したAI振り分けシステムを導入した事例があります。スパムや的外れな問い合わせが増加する中、人手による選別を自動化し、対応優先度をAIが判別。パイロット運用から3ヶ月で人と同等の判別精度を達成し、その後は人では見落としていた見込み顧客の問い合わせも拾えるようになりました。「運用しながら成長させるAI」として、段階的に精度を高めていく設計も特徴のひとつです。
本格展開の判断において経営層に示すべきポイントは、「PoC期間中に何を学んだか」の透明性です。「成功した/失敗した」の二値ではなく、「何が検証でき、何が次の課題として残ったか」を明示することで、意思決定の精度と速度が上がります。
まとめ｜ツールから始めないDX
① 課題定義に時間をかける
ツール選定の前に、現場観察・インタビューで「誰がどんな課題を持っているか」を明確にします。株式会社リコーの事例が示すように、「何を改善すべきか」の共通指針がチームにあるかどうかが、開発の速度と方向性を決めます。
② PoCスコープを小さくする
いきなり全社展開を目指さず、1部門・限られたユーザーで小さく試して学びます。成功事例も失敗事例も、学びとして次の仮説設計に活かすことができます。PoCの過程で「当初想定していなかった価値」が顕在化するケースもあります。
③ 組織を横断してプロジェクトを設計する
IT部門だけでなく、現場リーダー・人事・経営を巻き込みます。三豊工業の事例が示すように、DXは「システム導入」ではなく「業務と文化の変革」です。共通言語と創造的思考のメンタルモデルを組織に根付かせることが、変革を持続させます。
著者情報
