株式会社renue
renueについて
renueは、AIで業務を実装する会社です
AIコンサルティングから図面AI・広告運用エージェント・コールセンターAIまで、実際に動いているサービスをご覧いただけます。renueが何をしている会社か、まずはサービス一覧からご確認ください。
デザイン思考は、利用する人の経験を理解し、問いを立て、試作と検証から解決策を育てるための考え方です。5つの段階を順番に消化することが目的ではありません。本記事では、代表的な5つのモード、ワークショップの進め方、AIを使うときの確認点を、業務やサービスの改善につながる形で整理します。
デザイン思考とは:人の経験から問いを立て、検証する
デザイン思考では、作り手が想定した解決策をそのまま進めず、誰が、どのような場面で、何に困っているかを確かめます。インタビューや観察を通じて得た情報から問いを整理し、複数の案を形にして反応を見ます。見た目を整える作業に限らず、業務の手順、窓口、情報の伝え方なども検討の対象になります。
IDEOの公式説明は、人のニーズ、技術による実現可能性、事業として成立する条件を組み合わせる考え方を示しています。利用者にとって魅力があっても、運用できない、費用を支えられない場合は、そのまま実装する判断には進めません。人の経験を理解することと、技術・事業の条件を検討することをつなげます。
5つのモードは、理解するための枠組み
Stanford d.schoolのDesign Thinking Bootlegは、共感、問題定義、発想、試作、テストの5つをモードとして紹介し、どこからでも始められると説明しています。一方、IDEOのプロセス説明は7つの要素を示し、直線的な手順ではないとしています。段階数は一律ではなく、問いや検証結果に応じて行き来するための整理として使います。
新規事業に限らず、既存サービスの申し込みで迷う、社内の申請で差し戻しが多い、といった問題にも応用を検討できます。原因や対応方法が既に明確な作業まで、毎回すべてのモードを実施する必要はありません。分析や計画と対立させず、不明な前提を確かめるために必要な方法を選びます。
採用では、候補者の体験を改善する問いに使う
採用に応用するなら、募集情報を読む、応募する、日程を調整する、結果を待つなど、候補者が経験する接点を分けます。分かりにくい案内や待ち時間などを確認し、説明文や連絡の流れを試す対象にできます。体験の改善と候補者の合否判断は別の問題です。参加者の意見やAIの分析から、その人の能力や適性まで推定しないよう、扱う目的を揃えます。画面や操作の改善はUI・UX設計の原則とも接続します。
デザイン思考の5つのモードと、各段階で残すもの
以下は5つのモードを実務で使うための整理です。StanfordのME 113の説明でも、利用者の理解、情報の整理、多様な案、形にすること、観察とフィードバックによる改善を扱っています。各モードで何を学び、次に何を確かめるかを記録しておくと、チームの思い込みだけで進みにくくなります。
1.共感:経験と文脈を理解する
利用者に最近の具体的な行動を聞き、可能な範囲で仕事や利用場面を観察します。要望だけでなく、何をしようとして、どこで迷い、どんな工夫で補っていたかを確認します。発言・観察した事実と、作り手の解釈や推測を分けて残します。「本音が分かった」と早合点せず、分からない点は次の質問にします。調査の準備はユーザーインタビューの進め方を参照してください。
2.問題定義:誰の何を変えるかを絞る
集めた情報を整理し、対象者、場面、困りごと、その根拠を短く表します。POVや「どうすれば〜できるか」という問いは、整理の道具として使えます。「AIで自動化するには」と解決策を先に固定せず、「必要な情報を探し直さずに判断するには」など、別の案も検討できる問いにします。少数の発言を全利用者の意見に広げないことも大切です。
3.アイデア発想:案を広げてから選ぶ
最初から一つの案に絞らず、手順を減らす、説明を変える、道具を変えるなど複数の方向を考えます。まず個人で案を書き、その後に共有する方法も使えます。発散と評価を分けたうえで、利用者にとっての価値、実現条件、次に試せることを比較します。投票で人気だったことと、課題に効くことは区別します。
4.プロトタイプ:確かめたい部分を形にする
紙の画面、操作の流れ、説明文、ロールプレイ等から、問いに合う形式を選びます。例えば案内文の理解を確かめるだけなら、システム全体を作る必要はありません。何を実装し、何を仮の内容にしたかを明示し、完成度を上げる前に学べる範囲を探します。
5.テスト:反応を見て、問いや案を更新する
利用者に想定する作業を行ってもらい、迷い、理解、期待との違いを確認します。説明して正しい操作へ誘導する前に、どこで止まったかを記録します。結果に応じて画面を直すだけでなく、対象者や問題定義まで戻ることもあります。変更した理由と、次に残る不確かな点をセットで記録します。
ワークショップの進め方:練習と実際の調査を区別する
ワークショップは、チームで問いや案を共有し、小さく作って学ぶ機会として設計できます。最初に、手法を練習する場なのか、実際の事業判断に必要な情報を集める場なのかを決めます。参加者が利用者役を演じる練習と、実際の利用者から得る調査結果は、同じ証拠として扱いません。
6つの進行枠を使った時間配分の例
次は進行を検討するための例です。一般的な標準時間や、効果を保証する日程ではありません。参加人数、事前調査、試作の形式、実際の利用者が参加できる時間に合わせて調整し、休憩や移動、説明の時間は別に確保します。
| 進行枠 | 時間の例 | 残すもの |
|---|---|---|
| 準備 | 30分 | 目的、テーマ、担当、参加・共有の条件 |
| 共感 | 60〜90分 | 事実、発言、解釈、未確認事項の区別 |
| 問題定義 | 30分 | 対象者・場面・困りごとと根拠 |
| 発想 | 45分 | 複数案、選ぶ基準、残る仮説 |
| 試作 | 60分 | 確認する部分と、仮に置いた内容 |
| テスト・振り返り | 45分 | 観察、変更点、次の確認と担当 |
事前にテーマを狭め、関係する資料や既知の事実を揃えます。利用者に参加してもらう場合は、目的、記録の方法、共有する範囲、扱う情報を説明し、参加の条件を確認します。業務上必要のない個人情報や顧客情報を、付箋や共有ボードへ持ち込まないよう、使う素材も準備します。
進行中は、発言量が多い人の案だけに寄らないよう、個人で考える時間と共有する時間を設けます。進行役は結論を決める人とは役割を分け、反対意見や少数の経験も記録します。仮説、観察した事実、決定したことを同じ欄に混ぜないと、後から判断の根拠をたどれます。
最後に、次の検証で何を確かめるか、誰が担当するか、いつ判断するかを決めます。付箋の枚数や参加者の満足だけで成功とせず、利用者に確かめる前提が明確になったか、具体的な行動につながったかを確認します。事業の仮説を小さく試す進め方はリーンスタートアップとMVP、技術や実装条件の確認はPoCの設計と本番移行も参照してください。
AIの活用:調査・発想・試作を補い、利用者との検証へ戻す
AIは、調査メモの整理、見落とした視点の候補、案の比較、画面や文案のたたき台などに活用を検討できます。どの作業を任せ、何を人が確認するかを先に決めます。「数週間の調査が数日になる」「偏りが解消する」と一律に期待するより、対象作業の品質と、確認・修正を含む負担を評価します。
IDEOの2026年8月のデザインリサーチ記事は、速さや量だけでなく、視点を広げる、細部に気づく、前提を問い直す等の目的に合わせてAIを使う考え方を示しています。これは同社の実践に基づく提案として読み、あらゆる調査で同じ成果が出る条件としません。
AIが作った人物像は、実際の利用者の回答ではない
AIに利用者役を演じさせた回答は、モデルが生成した内容です。質問案の練習や仮説づくりに使う場合も、実際の観察・インタビュー記録と分けます。IDEOの2025年の記事も、合成された利用者への依存に注意を示しています。実際の人の経験や、その場の文脈を確認する工程を残します。
調査メモをAIで要約・分類するときは、発言者や元の箇所に戻れるようにし、少数意見や矛盾が消えていないかを確かめます。調査で使える情報でも、そのまま外部のAIへ渡せるとは限りません。利用目的、参加者への説明、入力する項目、サービス側の保存・利用条件、社内の閲覧権限を確認します。採用の体験改善でも、候補者の情報を目的外の評価へ転用しないよう整理します。
速く作った試作と、本番で運用できる仕組みを分ける
AIで画面やコードの案を作る場合も、仮のデータや未実装の操作を明示します。利用者の反応を確かめる試作から本番へ進む際は、品質、データ連携、権限、例外時の対応、運用担当を別に確認します。見栄えのよいデモが動くことだけで、実際の業務で使えると判断しないことが大切です。
ユーザー課題を整理し、試作・実装から現場での確認や運用へつなげたい場合は、renueのFDE支援が検討候補です。対象業務、利用者、既存システムとデータ、検証範囲、品質・承認・引き継ぎの条件を確認して支援内容を決めます。支援の選び方はAIコンサルティングの型、初回相談の整理は相談前に準備することも参照してください。
