「DVF の D が弱い」という指摘を会議で受けたとき、次にどう動くべきか分からなかった——そういう声をワークショップでよく聞く。

DVF（Desirability / Feasibility / Viability）は IDEO が提唱した検証の三軸だ。「Desirability を検証する」と言われると、多くのチームが Reaction Cards に一直線に向かう。しかし Reaction Cards は Desirability 検証の一手段に過ぎない。

「欲しいと思うか」を測る問いに対して、手法の選択肢は複数ある。 どの場面で何を選ぶかが分かっていないと、手法が目的化して検証の質が落ちる。

本稿は、DVF における Desirability の理論的位置づけを整理したうえで、Reaction Cards 以外の検証手法と、その選択基準を実務レベルで解説する。

DVF フレームワークとは何か

DVF は Tim Brown と IDEO が体系化した、イノベーション設計の評価枠組みである。2009年に出版された Tim Brown の著書 Change by Design（邦訳『デザイン思考が世界を変える』、早川書房、2010年）において明示されており、IDEO の実践を通じて広まった。

三軸の定義は以下の通りだ。

軸	問い	検証の主体
Desirability	人々がそれを欲しいと思うか	ユーザーリサーチ、テスト
Feasibility	技術的・組織的に実現可能か	エンジニアリング、オペレーション
Viability	事業として持続できるか	ビジネスモデル、財務

IDEO の定義では、三軸が重なる領域に「優れたイノベーション」が宿るとされる。どれか一軸だけを満たしても、イノベーションとして機能しない。 技術的に動くが誰も欲しがらないプロダクト（F あり D なし）、欲しがられるが事業として持続しないサービス（D あり V なし）は、実際のプロジェクト現場に無数に存在する。

D と F・V の相互作用

DVF の三軸は独立していない。D の検証結果が F と V の設計を更新する。

たとえば、ユーザーインタビューで「使いたいが価格が高すぎる」という Desirability の限界が見つかった場合、Viability の収益設計を見直す必要が生じる。「欲しいが、毎日使いたいわけではない」というインサイトは、サブスクリプション型から従量課金型への Viability 再設計を示唆する。逆に「欲しいが、今の技術では出せない」は Feasibility の壁を浮かび上がらせる。

Desirability Testing は、この相互作用を引き出すための入口に位置している。 D の検証を怠ったまま F・V に多くのリソースを投じると、後続で抜本的な設計変更が必要になるリスクが高まる。

デザイン思考の5フェーズとの対応

D の検証が始まるのはテストフェーズだけではない。共感フェーズのユーザーインタビューも、ある種の D の事前調査として機能する。テストフェーズでの Desirability Testing が他と異なるのは、具体的なプロトタイプや概念に対する反応を測定する点だ。 抽象的な「こういうものがあったら欲しいですか？」ではなく、「この形で見たとき、どう感じますか？」という問いに変わる。

Desirability 検証の三つのアプローチ

Microsoft Reaction Cards（Benedek & Miner, 2002, “Measuring Desirability: New Methods for Evaluating Desirability in a Usability Lab Setting”）は代表的な手法だが、状況によって使い分けるべき選択肢がある。

アプローチ1：感情語彙インタビュー

プロトタイプを体験した直後に、オープンエンドで「どんな言葉が浮かびましたか？」と問い、参加者自身の言語で印象を語ってもらう方法だ。Reaction Cards と異なり、カードという「選択肢の枠」を与えない。

向いている場面: コンセプトの初期段階で、想定していない感情的反応を探したいとき。カードに載っていない言語が出てくる可能性が高い段階。

手順の骨格:

プロトタイプを体験してもらう（10〜20分）
体験直後に「今どんな気持ちですか？最初に浮かんだ言葉を教えてください」と問う
出てきた言葉を付箋に書き取り、参加者に「その言葉を選んだのはどの場面ですか？」と掘り下げる
複数参加者の語彙を収集後、アフィニティ・マッピングで感情クラスターを整理する

注意点: ファシリテーターが「使いやすかったですか？」のような行動評価に引っ張ってしまうと、感情的印象の語彙が出にくくなる。最初の問いは必ず「気持ち」「印象」の軸に留める。

アプローチ2：比較ランキング法

複数のデザイン案またはプロトタイプを並べて提示し、「どれが最も〇〇に感じましたか？」と感情軸で順位をつけてもらう方法だ。UX リサーチの実務では、単独評価より比較評価の方がユーザーの判断が安定しやすいとされている。

向いている場面: デザイン案が2〜4案あり、感情的な優劣を比較したいとき。A/B テストの前段として、定性的な方向感を確認したいとき。

手順の骨格:

2〜4案を同一参加者に順番に体験させる（順序効果を打ち消すカウンターバランス設計を推奨）
全案体験後、「信頼できそうだと感じたのはどれですか？」「また使いたいと思ったのはどれですか？」など感情軸の問いで順位づけを依頼
各軸ごとの順位をマトリックスに記録し、感情的優位案を特定する
「1位に選んだ理由を教えてください」でデブリーフに移行

注意点: 比較ランキングは「相対評価」のため、「最も好き」が「十分に好き」を意味するとは限らない。比較の優勢は、絶対的な Desirability の水準とは別に扱う必要がある。

アプローチ3：行動観察との統合（感情マーカー記録）

ユーザビリティテストの観察に感情的反応のマーキングを重ねる手法だ。記録係がタスク実行中の発話・表情・身体反応（前のめり、顔をしかめる、笑う等）に対してリアルタイムでタイムスタンプ付きの感情マーカーを記録する。

向いている場面: ユーザビリティテストをすでに実施する予定があり、追加コストを最小化したいとき。「どの場面で感情が動くか」を時系列で把握したいとき。

手順の骨格:

通常のユーザビリティテストのプロトコルを組む
記録係に感情マーカー記録シートを用意する。列は「時刻 / 発話内容 / 表情・身体反応 / 推測感情（仮）」
テスト終了後、マーカーの時点と一致する画面・タスクを照合し、「どの体験が感情を引き出したか」を特定する
感情が正負どちらに振れたかは参加者本人に事後確認する（感情を勝手に解釈しない原則）

注意点: 観察者によって同じ表情が「楽しい」「困惑」のどちらに見えるかが異なる。マーカーはあくまで「要確認フラグ」として運用し、解釈は参加者本人との事後確認で固める。推測を事実として記録することが最大のリスクだ。

どの手法を選ぶか——判断マトリックス

条件	推奨アプローチ
初期コンセプト、想定外の反応を探したい	感情語彙インタビュー
複数案あり、感情的方向感を比較したい	比較ランキング法
ユーザビリティテストと同時に実施したい	行動観察との統合
複数時点での変化を追跡したい	Reaction Cards（比較・追跡に強い）
ビジネス指標との接続が必要	Reaction Cards + NPS（感情 ROI 化）

一つのプロジェクトで複数手法を組み合わせることは合理的だ。 初期段階では感情語彙インタビューで語彙のマップを作り、中期段階で比較ランキング法で方向感を確認し、最終段階で Reaction Cards で定点測定する、という順序設計はよくある実務パターンである。

DVF の三軸を実際に動かすまで

D の検証から F・V の更新まで

ワークショップで実際に起こるのは、D の検証結果を「なるほど、ユーザーに聞けた」で終わらせてしまうことだ。Desirability Testing の結果は、F（Feasibility）と V（Viability）の設計に直接フィードバックして初めて価値になる。

具体的な接続のパターンを整理する。

感情語彙インタビューの結果 → Feasibility への接続例: 参加者から「操作が重そうで怖い」という語彙が複数回出た場合、これは感情的な Desirability の問題だが、実装する機能の応答速度という Feasibility 課題に翻訳できる。エンジニアリングチームへのフィードバックとして「軽快感の体感速度を目標設計に含める」という要件に変換できる。

比較ランキング法の結果 → Viability への接続例: A案（シンプル・機能最小）が B案（高機能・複雑）より感情的に優位だったとする。この結果は、高機能による追加課金モデルよりシンプルなフラット料金の方がユーザーの感情的受容度が高いという Viability への示唆を含む。価格設計の見直しを促すデータとして使える。

よくある失敗——D を F の代替にしてしまう

「技術的には作れるかどうかまだ分からないが、まずユーザーに聞いてみよう」という動機で Desirability Testing を実施するケースがある。しかし、Desirability Testing は Feasibility の代替にはならない。「欲しいと思う」はプロダクトを選ぶ動機だが、「作れる」かどうかは独立した問いだ。

D の検証が先行することで F の検討が後回しになると、「欲しいが作れない」ということが後になって判明し、リードタイムと費用が膨らむ。D と F の検証は並行して進め、どちらかの結果がもう一方を更新する形で往復させるのが現実的な設計だ。

結果をチームで使うための共有設計

Desirability Testing の結果は、ファシリテーターが抱え込むと死蔵される。

感情クラスターマップ: 収集した語彙・選ばれたカード・観察マーカーをプロダクトの画面や体験フローに対応させて壁面に貼る。「どの体験が、どんな感情を引き出したか」が空間として把握できる状態にする。

DVF マッピングへの統合: 感情クラスターマップを DVF の三軸図に重ねる。D 軸で弱い領域が明確になれば、その領域の改善を F・V の誰が担うかをチームで分担できる。

ステークホルダーへの報告: 経営層や開発責任者への報告では、感情的な印象を直接示すより「感情的な弱点がどのビジネス指標に影響するか」という接続を示す方が動きにつながりやすい。「3名が”信頼できない”を選んだ」という結果は、継続率や推薦意向への影響として翻訳したうえで提示する。

Desirability Testing は手法ではなく、問いに答えるための道具だ。 DVF の D 軸とは「人々が本当にこれを欲しいか」という根本的な問いを体系化したものであり、その問いに答える手段は状況によって変わる。

Reaction Cards を知っているかどうかではなく、どの問いに答えたいかを先に決めてから手法を選ぶ習慣が、Desirability Testing の実効性を決定づける。