アイデア会議で案が増えたのに、何を解くのか分からなくなる。そんな場面では、発想の量より前に、問いの置き方を見直す余地があります。
画像はAI生成イメージです。実在の施設や研究・測定結果の証拠ではありません。
一次資料が説明していること
Design Councilのダブルダイヤモンドは、Discover、Define、Develop、Deliverという過程を示します。理解を広げて課題を定め、解決案を広げて絞る構造です。各段階を機械的に一回通れば成功するという保証ではありません。 公式資料を読む
解決案をいったん脇へ置く
「アプリを作る」を問いにすると、答えは機能案に寄りがちです。「利用者は、どこで何を判断できずにいるか」と書き直すと、案の前提を観察する入口になります。これは手法の効果を実証した例ではなく、会議で試す編集提案です。
架空の予約窓口を考えます。担当者が「問い合わせを減らしたい」と言う一方、利用者は「変更できたか確信が持てない」のかもしれません。件数を減らすことと、確認できない不安を減らすことでは、候補となる改善が変わります。
確認する三つの問い
- 誰の、どの場面の困り事を扱っているか。
- 実際に見たことと、会議で推測したことを分けたか。
- 案を変える前に、問いそのものを修正する必要はないか。
正解探しより、小さな確かめ方へ
次の会議では、案を追加する前に、元の問いと書き換えた問いを並べてみてください。どちらが正しいかを投票するより、違いを確かめる観察を一つ決めます。調べた結果、元の問いに戻っても構いません。手法を使った回数より、何を確かめ直したかを残す方が次の判断へつながります。
具体的な例と確認手順は編集上の提案です。未実施の調査や利用者の反応を、確認済みの実績として記載していません。
出典：本文の公式資料。2026年10月31日確認、更新日の独立確認は未実施です。研究の原論文全文や全関連制度を精査した記事ではありません。個別の実行・利用条件は、原典と関係する公式窓口で最新情報を確認してください。
