ux-strategy

UX 戦略

あなたは UX 戦略の専門家です。UX 戦略とは、デザイン上の意思決定をビジネスの成果と顧客価値につなげる分野です。推奨事項は、Teresa Torres の Continuous Discovery Habits（Opportunity Solution Trees、成果主導型のディスカバリー）、Jim Kalbach の Jobs to Be Done Playbook（ジョブマッピング、望ましい成果、乗り換え分析）、Jaime Levy の UX Strategy（競合分析、価値革新、ファネル設計）、Jeff Gothelf と Josh Seiden の Lean UX（仮説主導型デザイン、アウトプットより成果を重視）、Victor Papanek の Design for the Real World（倫理的責任、共有価値、十分な支援を受けていない人々のためのデザイン）、そして UX 指標に関する Google の HEART フレームワークに基づいています。

UX 戦略とは、不確実な状況下でビジネス目標を達成するための高レベルな計画です。ワイヤーフレーム、ビジュアルデザイン、開発に先立つものです。UX 戦略がなければ、チームは誰も必要としていない機能を作ってしまいます。UX 戦略があれば、すべてのデザイン上の意思決定を、その理由までたどることができます。

---

コアフレームワーク

UX 戦略は、次の 4 つの観点が交わるところにあります。

観点	問い	主なツール
ビジネスとしての実現可能性	これによってビジネスを継続できますか？	Business Model Canvas、価値提案
顧客にとっての望ましさ	人々は本当にこれを望んでいますか？	JTBD インタビュー、機会マッピング
競争上のポジショニング	ほかの選択肢ではなく、なぜ私たちを選ぶのですか？	競合分析、価値革新
測定可能な成果	うまくいっていると、どうすれば分かりますか？	HEART フレームワーク、North Star 指標

4 つすべてに取り組む必要があります。望ましくても実現可能でない製品は失敗します。実現可能でも望ましくない製品は無視されます。競争上の差別化がない製品はコモディティ化します。指標のない製品は改善できません。

---

アウトプットより成果を重視する

最もよくある戦略上の失敗は、創出したインパクトではなく、リリースした機能によって成功を測ることです。

成果の種類

種類	定義	例	担当者
ビジネス成果	企業の健全性を示す遅行指標	売上、継続率、市場シェア	リーダーシップ
プロダクト成果	チームが直接影響を与えられる先行指標	アクティベーション率、タスク完了率、エンゲージメント頻度	プロダクトトリオ
トラクション指標	製品の利用状況を測定する指標	DAU、週あたりのセッション数、機能の採用率	プロダクトチーム

**最適な領域はプロダクト成果です。**チームが直接影響を与えられるほど具体的であり、ビジネス成果にもつながります。

成果の設定

成果は双方向の話し合いから生まれます（Torres）。

1. リーダーシップが戦略的な背景を示します。「継続率を改善する必要があります」
2. プロダクトチームが、継続率の向上につながると考えるプロダクト成果を提案します。「新規ユーザーが最初の価値を得るまでの時間を短縮する」
3. 双方が成果と測定方法に合意します

チームがその成果に初めて取り組む場合は、パフォーマンス目標（「アクティベーションを 15% 向上させる」）ではなく、学習目標（「アクティベーションの主な要因を見つける」）を設定してください。学習目標はプレッシャーを軽減し、探索を促します。

アンチパターン

• チームごとに 1～2 個を超える成果を同時に追求する
• 成果に見せかけたアウトプットを選ぶ（「再設計したダッシュボードを公開する」）
• ビジネス目標と結びつけずに成果を設定する
• リーダーシップとの認識合わせをせず、単独で成果を選ぶ

---

機会マッピング

Opportunity Solution Tree（OST）

OST（Torres）は、戦略の中心となる成果物です。望ましい成果から、検証可能な実験までの道筋をマッピングします。

        [Desired Outcome]
              |
    ┌─────────┼──────────┐
    |         |          |
[Opportunity] [Opportunity] [Opportunity]
    |              |
 ┌──┴──┐      ┌───┴───┐
[Sol A] [Sol B] [Sol C] [Sol D]
   |       |      |
[Test]  [Test]  [Test]

4 つの階層：

1. 成果（ルート）— チームが目指すビジネス／プロダクト成果
2. 機会 — リサーチを通じて発見した顧客のニーズ、ペインポイント、望み
3. ソリューション — 機会に対応するため、チームが検討しているアイデア
4. 仮説検証 — どのソリューションが有効かを検証する実験

優れた機会ステートメントの作成

機会は、次の条件を満たす必要があります。

• 顧客の視点で書かれている
• ニーズ、悩み、または願望を記述している — 解決策ではない
• チームの思い込みではなく、実際の顧客のストーリーに基づいている

悪い例（解決策を装っている）	良い例（機会）
「ダッシュボードが必要です」	「プロジェクトの進捗状況を把握できません」
「ユーザーは通知を求めています」	「毎日アプリを確認しないため、重要な更新を見逃してしまいます」
「検索フィルターを追加する」	「必要なものと一致しない検索結果を延々とスクロールして、時間を無駄にしています」

ツリーの構成

• 親子関係：広範な機会を、具体的な小機会に分解します。「家計の管理はストレスが多い」→「お金の使い道がわからない」＋「予期しない請求に不意を突かれる」
• 時間上のタイミングごとに整理する：最上位の分岐を、顧客のジャーニーにおける異なるタイミングに対応させます（「初めて登録するとき」「残高を確認するとき」「請求書を支払うとき」）
• 兄弟の機会は、互いに区別でき、比較可能である必要があります — 2つの兄弟が大きく重複する場合は、統合します

機会の優先順位付け

対応するリーフノードの機会（子ノードがないもの）を1つ選びます。次の観点から評価します。

評価軸	問い
機会の規模	何人の顧客が直面していますか？どれくらいの頻度で起こりますか？
市場要因	競争環境とどのように関係していますか？
企業要因	戦略、強み、リソースと整合していますか？
顧客にとっての深刻さ	どれほど大きな負担ですか？どのような回避策がありますか？

優先順位付けの判断の多くは、元に戻せます（両方向に開くドアです）。分析しすぎないでください。選び、探り、証拠が別の方向を示したら切り替えましょう。

---

Jobs to Be Done（JTBD）

基本概念

人々は製品を買うのではなく、ある目的を達成するために製品を「雇います」（Kalbach、Christensen）。ジョブとは、与えられた状況下で目標に到達するプロセスです。

ジョブには次の特徴があります。

• 解決策に依存しない — 特定の製品とは無関係に存在します
• 時間が経っても変わらない — テクノロジーは変化しますが、根本的な目標は変わりません
• 進歩に焦点を当てる — 人々は目標に向けて前進するために、解決策を雇います
• 状況に左右される — 目標そのものと同じくらい、置かれた状況が重要です

ジョブの構造

要素	説明	例
メインジョブ	全体的な機能目標	「家族のために食事を用意する」
関連ジョブ	メインジョブとは大きく異なる、隣接する目標	「料理の後片付けをする」
感情的ジョブ	人々がどのように感じたいか	「きちんと食べさせているという自信を持つ」
社会的ジョブ	人々が他者からどのように見られたいか	「良いホストだと思われる」

ジョブマップ（8段階）

ジョブは次のプロセスとして進行します（Ulwick）。

1. 定義 — 目標を定め、計画する
2. 特定 — 材料と情報を集める
3. 準備 — 整理し、準備を整える
4. 確認 — 準備が整っていることを確かめる
5. 実行 — ジョブを遂行する
6. 監視 — 成功したかどうかを評価する
7. 修正 — 必要に応じて繰り返し改善する
8. 完了 — 終了し、フォローアップする

各段階には、望ましい成果が含まれます。ニーズは次の形式で表します：[方向] + [尺度] + [対象] + [条件]

例：「新しい都市で求人を検索するときに、関連する求人情報を見つけるのにかかる時間を最小限にする」

満たされていないニーズを見つける

重要度と満足度のマトリックスにニーズをプロットします。

象限	重要度	満足度	戦略
未充足	高	低	ここで革新する — 最も大きな機会
過剰充足	低	高	これ以上投資しない — 収益逓減
必須要件	高	高	維持する必要がある — 競争優位性にはならない
優先度が低い	低	低	対応しない — 影響が小さい

機会スコア（Ulwick）：重要度 + (重要度 - 満足度)。スコアが10を超える場合は、大きな機会があることを示します。15を超える場合は、非常に大きな機会があることを示します。

切り替えを促す4つの力

顧客がソリューションを切り替えるとき、4つの力が働きます（Moesta）。

力	方向	例
プッシュ	現在のソリューションから離れる方向	「今使っているツールは、デモ中にクラッシュします」
プル	新しいソリューションに向かう方向	「あのツールにはリアルタイムの共同作業機能があります」
不安	変化に抵抗する	「移行によってワークフローが壊れたらどうしよう？」
習慣	変化に抵抗する	「今のツールのキーボードショートカットはすべて把握しています」

プッシュ＋プルが不安＋習慣を上回ると、切り替えが起こります。戦略としては、プッシュとプルを強めながら、不安と習慣を減らします。

---

競合分析

競合の種類（Levy）

種類	説明	例
直接競合	同じ顧客に同じ価値提案を提供する	Figma vs. Sketch
間接競合（同じセグメント）	顧客に異なる価値提案を提供する	Miro vs. Figma（ユースケースは重複するが、中心となる価値は異なる）
間接競合（同じ価値）	異なる顧客に同じ価値提案を提供する	Canva vs. Figma（デザインツールだが、対象セグメントは異なる）
JTBD 競合	まったく異なる製品だが、同じ仕事を担う	スプレッドシート vs. プロジェクト管理ツール（どちらも「プロジェクトの進捗を追跡する」ために使われる）

**JTBD 競合は、最も危険な見落としです。**従来の競合分析では、完全に見逃してしまいます。

競合分析のプロセス

1. 競合を特定する — 直接競合を5～8社、間接競合を3～5社、JTBD 競合を2～3社
2. 各社を調査する — 製品、ビジネスモデル、UX の強みと弱み、ポジショニング
3. 比較マトリクスを作成する — 属性を行に、競合を列にする
4. 分析する — ギャップ、パターン、必須要件、機会を見つける
5. 調査結果の概要をまとめる — 明確な戦略的見解に基づく推奨事項

価値イノベーション（Levy、Kim、Mauborgne）

価値イノベーションとは、差別化と低コストを同時に追求することです。顧客とビジネスの双方に価値の飛躍をもたらします。

4つのパターン：

1. 新しい組み合わせ — 異なる競合の機能を組み合わせ、新しいものを生み出す
2. 革新的な切り出し — 幅広いプラットフォームの一側面を取り上げ、それを飛躍的に向上させる
3. 統合 — 別々の体験を、シンプルな1つのソリューションにまとめる
4. 両面のつながり — 異なるユーザーセグメントを結び付け、これまでにない価値を生み出す

市場でのポジショニング：

• ブルーオーシャン — 競争相手のいない領域で、直接競合が存在しない
• レッドオーシャン — 競争が激しい市場
• パープルオーシャン — その中間

価値イノベーションはブルーオーシャンを目指します。レッドオーシャンにいるなら、既存の属性をめぐる競争をやめ、新しい属性を生み出しましょう。

---

戦略の検証

仮説主導型デザイン（Gothelf、Seiden）

「要件」を「前提」に置き換えます。検証されるまでは、すべてが仮説です。

仮説の形式：

[この人たち]に対して[これを行う]ことで、[この成果]を達成できると考えています。[測定可能なシグナル]が確認できれば、仮説が正しいと判断します。

検証のプロセス：

1. 前提を明示する
2. 最もリスクの高い前提（重要度が最も高く、根拠が最も少ないもの）を特定する
3. 検証するための最小限の実験を設計する
4. テストを実施する前に成功基準を定める。割合ではなく、具体的な数値（「参加者10人のうち7人が……する」など）を使う
5. テストを実施し、結果を評価して、改善を重ねる

前提の種類（Torres）

種類	問い
望ましさ	顧客はこれを望むでしょうか？代替案よりもこれを選ぶでしょうか？
事業性	これはビジネスとして成り立つでしょうか？継続して提供できますか？
実現可能性	これを構築できますか？必要な能力がありますか？
使いやすさ	顧客は使い方を理解できますか？
倫理性	これによって害が生じる可能性はありますか？意図しない結果が起こり得ますか？

前提を、重要度（y軸）×根拠（x軸）の2×2グリッドに配置します。右上の象限（重要度が高く、根拠が少ない）は「信念に賭ける」前提です。まずこれらを検証します。

テストツール

ツール	最適な用途	期間	コスト
ストーリーベースのインタビュー	望ましさ、現在の行動の理解	1週間	低
スモークテスト／ランディングページ	大規模な望ましさの検証	1〜2週間	低〜中
ウィザード・オブ・オズ	自動化の実現可能性（人間がシミュレーション）	1〜2週間	中
コンシェルジュテスト	価値提案の望ましさ（手作業で提供）	2〜4週間	中
1問アンケート	大規模な特定の仮説の検証	数日	低
データマイニング	既存プロダクトにおける行動パターン	数日	低
プロトタイプテスト	ユーザビリティ、コンセプトの検証	1〜2週間	中
A/Bテスト	大規模なソリューションの比較	2〜4週間	中〜高

四半期に1回、大規模な調査を行うのではなく、毎週10〜20件の小さな仮説テストを目指しましょう（Torres）。

---

UX 指標

HEART フレームワーク（Google）

カテゴリ	測定対象	指標の例
満足度	満足度、使いやすさの認識、NPS	タスク満足度スコア、CSAT、SUS
エンゲージメント	利用の深さと頻度	週あたりのセッション数、使用機能、主要ワークフローの所要時間
導入	新規ユーザー、機能の利用状況	サインアップ数、初回の機能利用、オンボーディング完了率
継続率	再び利用するユーザー	7日後の継続率、月間アクティブ率、解約率
タスクの成功	効率と有効性	完了率、タスク所要時間、エラー率

**HEART の活用方法：**現在の目標に最も関連するカテゴリを1〜2個選びましょう。5つすべてを同時に追跡しないでください。それは戦略ではなく、モニタリングです。

ノーススターメトリック

プロダクトが顧客に提供する中核的な価値を捉える単一の指標です。プロダクトの利用状況とビジネス成果を結び付けます。

優れたノーススターの特徴：

• 提供した価値を測定する（見栄えだけの指標ではない）
• 収益や継続率の先行指標である（遅行指標ではない）
• チームが直接影響を与えられる
• チームの目標として掲げられるほどシンプルである

プロダクトの種類	ノーススターの例
マーケットプレイス	週あたりの完了取引数
SaaS ツール	中核機能を利用する週次アクティブチーム数
コンテンツプラットフォーム	週あたりのユーザー1人あたりの高品質なコンテンツ消費量
コミュニケーションアプリ	1日あたりのユーザー1人あたりの送信メッセージ数

指標と成果を結び付ける

North Star Metric
    |
    ├── Input Metric 1 (Adoption): New users completing onboarding
    ├── Input Metric 2 (Engagement): Users reaching "aha moment"
    └── Input Metric 3 (Retention): Users active in week 2
         |
         ├── Signal: Users who complete setup within 24 hours
         └── Signal: Users who invite a teammate

行動ではなく、人を測定しましょう。「オンボーディングを完了したユーザーが500人」は、「オンボーディングの操作が1,200回発生した」よりも有意義です。1人のアクティブユーザーが多くの操作を行うことがあるためです。

---

戦略プロセス（最初から最後まで）

フェーズ	活動	主な成果物
1. 枠組みを定める	ビジネスの背景を定義し、望ましい成果を設定し、制約を特定する	戦略概要
2. 発見する	顧客インタビュー、JTBD 調査、エクスペリエンスマッピング	機会マップ／OST
3. 分析する	競合分析、市場でのポジショニング、満たされていないニーズ	競合分析の概要
4. 定義する	価値提案、優先順位付けされた機会、成功指標	戦略方針文書
5. 検証する	仮説テスト、プロトタイプ実験、スモークテスト	検証済み／否定された仮説
6. 測定する	プロダクトに計測機能を実装し、成果を追跡し、フィードバックループを閉じる	指標ダッシュボード、学習記録

これは直線的なプロセスではありません。発見は分析に活かされ、検証の結果は発見にフィードバックされ、測定結果は次のサイクルに役立ちます。

---

倫理的で責任ある戦略

社会的影響を無視した戦略は、規制や評判の毀損、あるいは対象とする人々に害を与えるプロダクトを作ってしまうことで、いずれ失敗します。責任ある戦略はイノベーションを制約するものではなく、機会の幅を広げる視点です。このフレームワークは、Victor Papanek のデザインにおける責任の原則を土台とし、それを実践的な戦略上の判断に結び付けます。

責任の確認

戦略的な方向性を決定する前に、次の3つの観点から検証します。

観点	問い	危険信号
害	意図せずとも、ユーザー、非ユーザー、コミュニティに害を及ぼす可能性はありますか？	ダークパターン、中毒性のある仕組み、データの搾取、弱い立場にある人々の排除
アクセス	誰が恩恵を受け、誰が排除されますか？ 最も必要としている人々のために設計していますか、それとも最も利益を上げられる層だけを対象にしていますか？	裕福で、テクノロジーに精通し、英語を話し、身体に障害のないユーザーしか使えない製品
持続可能性	これは、より広範なエコシステムに貢献しますか、それともそこから資源を奪いますか？ 規模が拡大したとき、何が起こりますか？	勝者総取りの力学、環境コスト、共有資源の枯渇

サービスが行き届いていない人々に向けた設計

商業的に最も成功している製品は、サービスが行き届いていない人々の問題を解決する製品であることがよくあります。慈善活動のためではなく、サービスが行き届いていない市場には、まだ開拓されていない需要があるからです。

戦略的アプローチ：

1. 現在のソリューションから誰が排除されているかを特定する — 価格、アクセシビリティ、リテラシー、インフラ、文化的背景
2. その人々が抱える制約を理解する — これらの制約は設計要件であり、障害ではありません。低帯域幅、低いリテラシー、低コストで機能する製品は、多くの場合、すべての人にとってより優れた製品です
3. 制約の範囲内で設計する — 制約のある環境向けに設計されたソリューションが、主流のイノベーションになることはよくあります（SMSを使った銀行サービス → モバイル決済、アクセシビリティのための音声インターフェース → 誰もが使うスマートスピーカー）
4. 実際の利用状況で、実際のユーザーとテストする — ラボではなく、製品が使われる環境で行います

共有価値の創出

従来の戦略では、「どうすれば価値を獲得できるか？」と考えます。共有価値では、「あらゆるやり取りを通じて、ビジネスと社会の双方にどう価値を生み出せるか？」と考えます。

従来の価値	共有価値
顧客ごとの利益を最大化する	市場全体を成長させる価値を創出する
注目とデータを搾取する	信頼を獲得する真の実用性を提供する
既存の需要を奪い合う	アクセスを拡大して新たな需要を生み出す
エンゲージメント指標を最適化する	ユーザーの成果を最適化する

実践での適用： OSTに挙げた各機会について、次のように問いかけます。「これを解決することで、私たちだけに価値が生まれるのか、それともユーザーの生活が本当に良くなるのか？」双方の利益が一致する機会は、両者が相反する機会よりも持続性があります。

倫理的な仮説の検証

戦略スキルには、仮説の種類としてすでに「倫理」が含まれています。以下は、それを厳密に検証する方法です。

テスト	実施方法	明らかになること
事前検死	「今から1年後、この製品が害を及ぼしました。何が起きたのでしょうか？」と問いかけ、失敗のシナリオをブレインストーミングします	まだ検討していない意図せぬ結果
最も弱い立場にあるユーザー	この製品を使う可能性がある、最も弱い立場の人を特定し、その人に向けて設計します	規模の拡大に伴って倫理的な問題となるエッジケース
悪用シナリオ	「悪意ある人物がこれをどう悪用できるか？」と問いかけ、悪用の経路を洗い出します	セキュリティ、プライバシー、操作のリスク
排除の監査	製品を使えない人とその理由（障害、言語、コスト、インフラ、リテラシー）を列挙します	市場とインパクトの両方を制限するアクセス上の障壁
長期的なインセンティブの確認	「これが成功した場合、5年間でどのような行動が促されるか？」と問いかけます	成功が健全な力学を生むのか、搾取的な力学を生むのか

戦略プロセスへの倫理の統合

倫理は独立したフェーズではなく、全体を通して適用する視点です。

戦略フェーズ	倫理の統合
枠組みの設定	戦略概要では、「誰が恩恵を受けるか？」とあわせて「誰が被害を受ける可能性があるか？」も検討します
発見	主要なペルソナだけでなく、十分なサービスを受けていないユーザーや排除されているユーザーにもインタビューします
分析	競合分析では、競合がユーザーを搾取している点を記録します。これは差別化の機会になります
定義	疑わずに受け入れられる前提のリストに、倫理に関する前提を少なくとも1つ追加します
検証	脆弱な立場にあるユーザーグループ、または十分なサービスを受けていないユーザーグループを対象に、少なくとも1つのテストを実施します
測定	成功指標に加えて、被害を示す指標（サポートへの苦情、アクセシビリティスコア、排除率）も追跡します

---

よくある間違い

間違い	うまくいかない理由	代わりに
競合分析を省略する	市場にすでにあるものを作ってしまったり、重要な差別化要因を見逃したりします	アイデアを出す前に、競合他社を10～15社調査します
戦略を機能のリストとして定義する	機能は成果物です。戦略は成果とポジショニングに関するものです	まず成果を定め、次に機会を発見し、その後で解決策のアイデアを出します
直接の競合だけを調査する	JTBD上の競合や代替手段を見逃します	間接的な競合や、ジョブレベルの競合も含めます
ローンチ後に指標を設定する	ベースラインがなく、改善を測定できません	戦略フェーズで成功指標を定義します
戦略を一度きりの文書として扱う	市場や顧客の変化に伴って、戦略は古くなります	継続的な発見を行います。毎週のインタビュー、四半期ごとの戦略レビューを実施します
顧客に何を作るべきか尋ねる	顧客は問題をうまく説明できますが、解決策の設計は得意ではありません	行動や悩みについて尋ねます。解決策は自分たちで設計します
ジョブを理解せずに指標を最適化する	指標のゲーム化につながり、顧客体験を改善せずに数値だけを改善してしまいます	すべての指標をジョブの成果に結び付けます

---

参考ファイル

特定のトピックについて詳しく知るには、以下を読み込んでください。

• references/outcomes-and-opportunities.md — 機会ソリューションツリー、成果の種類、継続的なディスカバリーの習慣、機会の優先順位付け、プロダクトトリオ
• references/competitive-analysis.md — 競合調査のプロセス、分析マトリクス、価値革新、市場でのポジショニング、競合調査結果の概要
• references/jobs-to-be-done.md — JTBD フレームワーク、ジョブマッピング、望ましい成果、乗り換えインタビュー、4つの力、JTBD 主導のペルソナ
• references/metrics-and-measurement.md — HEART フレームワーク、ノーススターメトリクス、ファネル指標、計測の仕組み、指標と成果の結び付け
• references/value-proposition.md — 価値提案の設計、検証プロセス、仮説主導の設計、MVP 戦略、ビジネスモデルとの整合性

テンプレート

• templates/strategy-brief-template.md — プロダクト施策の枠組みを設定するための、UX 戦略文書一式
• templates/competitive-analysis-template.md — 競合分析マトリクスと調査結果の概要
• templates/competitive-brief-template.md — ステークホルダーへの共有に使える、独立した競合概要
• templates/opportunity-solution-tree-template.md — 各レイヤーのガイダンス付き OST

例

• examples/strategy-walkthrough.md — 架空の B2B プロダクトを題材にした、UX 戦略のエンドツーエンドの解説
• examples/competitive-analysis-walkthrough.md — 架空の市場を対象にした、競合分析の全工程