ダブルダイヤモンドフレームワーク

調査を始めたときの問題設定が、そのまま適切な開発課題とは限りません。
ダブルダイヤモンドは、問題を探して定める過程と、解決策を広げて選ぶ過程を、二つの菱形で表す枠組みです。
提唱元のDesign Councilは、Discover、Define、Develop、Deliverの四段階を示しています。

二つの問いを順に扱う

仮の例として、公共施設の申込画面を使いやすくする依頼を考えます。
最初の調査で、利用者が画面操作より、必要な書類がわからず手続きを繰り返しているとわかったなら、課題を定め直せます。
これが最初の菱形の働きです。
利用者と職員の作業を調べるDiscoverを経て、「申込前に自分に必要な書類を判断できるようにする」とDefineで整理します。

次の菱形では、その課題を解く複数の方法を考えます。
質問形式の案内、申込条件ごとの見本、窓口での事前確認などをDevelopで試し、利用者が判断できるかを比較します。
Deliverでは、残した解決策を実際の提供に向けて確かめます。
画面の改善だけを先に固定しないため、異なる提供方法も候補に残せます。

工程表として使うときの注意

四段階は、同じ日数で一度ずつ通過する規則ではありません。
試作品を使ってもらうと課題の理解が変わり、前の活動へ戻る場合があります。
図の位置を進めることより、何がわかり、次に何を判断するかを確認します。
調査結果が変わっても、承認済みの課題を変えられない運用では、枠組みの利点を生かせません。

また、この図だけでは予算、権限、品質基準、提供後の保守は決まりません。
開発の管理方法と組み合わせ、どの判断を誰が行うかを設計します。
申込案内の例なら、利用者が書類をそろえられた割合と、職員の確認負担を確認し、公開後も誤解が残る条件を調べます。
段階を終えたかではなく、問題と解決策のそれぞれについて得られた証拠を残すと、関係者が変更の理由を追えます。
すべての課題に大規模な調査を要求せず、誤った判断の影響に合わせて作業量を調整します。

関連する記事：発散思考、収束思考、コンセプトテスト。