# 正しいものを正しくつくる　第5章②
## 5-3～5-7　セットベースに沿った価値探索
### 仮説検証型アジャイル開発における価値探索
仮説検証のうち、MVPの範囲を決めてプロダクト開発と繋げていく検証活動を **「価値模索」** と呼ぶ。
価値模索の基本は**モデル化とその検証の繰り返し**である。
モデル化は、分かっていることの棚卸であり、図式化・言語化する活動である。
モデルを検証し、得たフィードバックをもとに、またモデルを組みなおして検証する。モデル化のパターンは1つではない。
検証によってライトが当たった部分は良く見えるが、逆に影ができて見えにくくなる部分も出てくる。その部分を別の検証で照らすようにする。
検証による理解が増えなくなってきたら、次の段階の検証に移る。

### 検証の始点・検証活動・検証の終点・検証の発散と収束
検証の始点では、初期仮説の立案を行う。現状でどこまでわかっているかをもとに仮説を立て、検証活動の組み立てを行う。
検証活動は最低2回以上は行う。1回目は事実集めを重視し、2回目は裏付けを重視する。
このようにユーザーをより深く知り、課題を拾い集めることを仮説検証の **「発散」** という。これらの課題から最も解決したい課題を仮説立てる。
逆に、仮説検証の **「収束」** は、検証した課題の仮説に対して、適切なソリューションを特定することである。

### 課題仮説とソリューション仮説
1回目の検証活動では、想定ユーザーの課題に関する仮説（**課題仮説**）の検証を、
2回目の検証活動では、どのようなソリューションが有効であるか（**ソリューション仮説**）の検証を行う。

### 検証の終点とPSfit、PMfit
検証の終点の基準として**PSfit(Problem-Solution-Fit)** がある。
これは、解決すべき課題仮説に対して、どのソリューション仮説が適しているかという適合度合いのことを言う。7～8割だと成功で、4割を切るとPSfitの期待は持てない。
対して、PMfit(Product-Market-fit)は、問題解決の構造がどのように成り立つかを判断するために用いる。
検証の終点では、以下の3点で分析整理を行う。
* 課題仮説の定義（結論）
* 課題解決のために必要な機能性の定義
* 機能性を想定ユーザーに届けるためのインターフェースの方針

### 1回目のモデル化（課題仮説のモデル化）
#### 仮説キャンバス
**仮説キャンバス**を用いる。上中下の3段構造で、左右2つに分かれる。
* 上段：目的 ー ビジョン
* 中段：実現手段・優位性・評価指標・提案価値 － 顕在課題・潜在課題・代替手段・チャネル・状況（傾向）
* 下段：収益モデル ー 想定する市場規模
上段はWhyを検証する仮説、中段は製品についての価値に対する仮説、下段は事業として必要な仮説
左側は提供者側の目線、右側は対象者側の目線である。
キャンバスの項目の数や構造は、自分たちに適した形にアレンジする。
#### どこから仮説を立てる？
* 課題　最も基本的なパターン。課題→対象者→状況
* 状況　対象者がハッキリしている場合、状況からスタートできる。
* 実行手段　プロダクトが先にできており、活用方法を求める場合。
* 優位性　リソース・ベスト・ビューや、コアコンピタンス等の概念を利用し、リソースを競争能力に繋げる。
* 目的　なぜこの事業に取り組むのかを模索する。
* ビジョン　向かいたい将来像を描き、合意形成を踏まえた理想像を言語化する。

#### キャンバスである2つの意味
1枚のキャンバスにまとめた理由は2つある。
1. 隅々まで一度に視界に収められる。
2. 面の狭さが、思考を打ち切りやすくさせ、仮説をブラッシュアップする。

#### 仮説の1本線
仮説キャンバスで見るべき仮説の構造は、**課題ー代替手段ー不満ー提案価値ー実現手段**という観点が繋がっているかどうかで、構想の筋の良さを判断できる。これを**仮説の1本線**という。
各項目について、以下の点を確認する。
* 課題は顕在課題だけでなく、潜在課題が上がっているか。
* 代替手段が上がっているか。
* 不満が顕在課題または潜在課題に追加されているか。
* 提案価値には、不満を解消し、スイッチングコストに負けないものであるか。

### 1回目の検証（ユーザーインタビュー）
ユーザーインタビューの方法論はRUNNING REAN等を参照。
ユーザーインタビューの結果を仮説と照らし合わせる。その結果から、立てた仮説が切実な課題として現れる状況を探索したり、逆に状況から課題仮説を捉え直したりを繰り返し実施する。
インタビューは10名程度を1セットとし、1セットごとに次のユーザーインタビューの実施を判断する。
課題仮説が状況と合致するところまで見いだせると、その後の流れは作りやすい。
一方で、仮説の1本線が成り立っても、課題の切実さが足りず、採用できない可能性もある。
#### ユーザーインタビューの注意点
1. **判断の根拠を確かめる。** ユーザーインタビューは、相手に正解を語ってもらう場ではない。直接的なユーザーからの言葉を得ても、根拠が無ければ意味がない。インタビューイーのタイプによっては、想像で無意識にこたえてしまう人もいるため、過去の事例や行動を具体的に挙げてもらうようにする。
2. **同じ質問をあえて繰り返す。** その場の流れで答えている可能性を減らすための工夫の一つ。言葉の表現だけを変え、同じ内容の質問を間をおいて繰り返す。
3. **主語を確かめる。** いつのまにか主語がすり替わってしまうことはよくある。時折主語をインタビューイーに戻す。
4. **比較による回答を得る。** 別の何かと比較してもらう方が、回答精度を高められる。既存の代替手段や、競合他社の手段などと比較する。
5. **インタビュー自体の仮説を立てる。** 1回のインタビューが終わるたびに振り返りを行い、インタビュー自体の仮説を立て、カイゼンを重ねる。

### 2回目のモデル化（ユーザー行動フローのモデル化）
モデル化の前に、仮説キャンバスをアップデートする。この際、仮説が成立しなかったものは、排除せず「不成立」として残しておく。
#### 動的なフローによるモデル化
ユーザーインタビューで得た情報をもとに、ユーザーの行動フローをモデル化する。（**動的なモデル化**：仮説キャンバスの静的なモデル化と対をなす。）
実施方法は、ユーザーストーリーマッピングや、カスタマージャーニーマップなど。いずれも左から右へ時系列に沿ってユーザーの行動を洗い出す。
インタビュアーや専門家など、多くの人に参加してもらい、それぞれの経験や知識から、フローに対する意見やアイデアを出してもらう。但し、内容の妥当性の判断基準は、ユーザーインタビューで得られた事実を第一とする。
#### ユーザー行動フローの書き方
進め方は、(1) 現状のフローからソリューション適用後のフローを描く。(2)新しいソリューションありきでフローを描く。の2種類がある。
場面は、ソリューションの利用前、利用中、利用後の３場面を想定する。
まず、各場面で想定される行動やその際に伴う感情を可視化する。
次に、行動や感情を踏まえて課題を洗い出す。
最後に、課題に対してソリューションが持つ機能性をマッピングしていく。
もし、フローに出てこない課題や機能性があれば、本当にその製品が必要なのかを問いただし、仮説の修正を行う。
#### 複数あるユーザー行動フローの使い分け
* サービスブループリント：ユーザー領域の他に、それを支える裏方部分も可視化するモデル。
* ユーザーストーリーマッピング：マップという成果物以上に、マッピングという行為を重視する。以下の3種類ある。
* コンセプトストーリー：状況説明（状況）、事故や事件の発生（顧客の問題やニーズ）盛り上げ（提案価値）等
* オリジンストーリー：ユーザーが製品に初めて出会って利用し始めるまでの流れを表現する。
* ユーセージストーリー ：オリジンストーリーの後想定ユーザーが、プロダクトをステップバイステップ使っていく過程を表す。

### 2回目の検証（プロトタイプによる検証）
1回目の検証は、言葉に頼ったインタビューであったが、2回目の検証は、より**実際の体験を含めたインタビュー**とする。
プロトタイプは実際の利用に即するほど精度は高まるが、そのためにコストを掛けることは避け、「わかることが増える」スピード重視で行う。
対象は行動フローを基に決定する。作り込みは、ビジュアルを評価の要素から予め抜いておく考え方と、ビジュアルを作り込んでおく考え方の2つがある。前者には、手書きのペーパープロト等がある。手軽というメリットはあるが、インタビューイーが想像しにくいため精度の低い評価となってしまう可能性がある。逆に後者はこうした想像の問題は解決するものの、ビジュアルの良し悪しだけで評価が先行してしまう可能性がある。
自分たちでプロトタイプをつくる他に、類似・競合プロダクトを利用した代替プロトタイプによる検証も考えられる。検証したい項目が代替プロトタイプで賄える場合、プロトタイプ作成の手間が省けるメリットがある。
検証の終了は、PSfitの視点で行う。

## 5-8,5-9 その他の仮説検証と補足
### その他の検証手段
* アンケート　課題仮説や想定ユーザーがわからない場合、仮説検証に先立ってアンケートを取り、その結果から想定ユーザーや仮説を置く方法がある。
* ランディングページによるチャネル検証　ソリューションを1枚のウェブページにまとめ、想定しているチャネルに広告を展開し、その反応を見る。チャネルとして有用であるかどうか、クリック率（広告の効率性）、コンバージョン率（興味関心）を計測する。ある程度仮説を検証したタイミングで行う。
* ユーザーや現場の観察　事件は現場で起こっている･･･ではないが、ユーザーの普段の状況を観察することは、手段として大いに有効である。素の状態でのユーザーの行動を確認できる点が、インタビューとは大きく異なる。仮説を立てて検証を行うのが望ましい。
* アクティングアウト　現場の再現による検証。これまでに得た普段のユーザーの行動フローのデータを元にユーザーの状況を再現し、自分達でソリューションの有用性を確認する。アクティングアウトの結果は写真や動画に残し、後からフィードバックのネタとして活用できるようにする。
* 検証キャンバス　Why How Whatの3段階で構成された検証のためのキャンバス。Whyでは何のために何を検証すべきなのかを明確にし、その指標と事前期待を書く。Howではどのように検証するかの手段と、MVPのタイプ・機能や、検証環境・スケジュールなどの情報を書く。Whatでは、検証結果とそこから得た学び、そして次にすべきことを記述する。キャンバスを用いることで、関係者と認識を共有しやすいメリットが生まれる。

### 仮設検証の補足
#### 3種類の仮説
* 課題仮説：本質
* 機能仮説：実体
* インターフェース仮説：形態
課題仮説で、実現すべきこと＝本質を捉え、機能仮説で実現のための機能を捉え、インターフェース仮説で機能を満たす手段＝形態を捉える。
この区別を知ることで、自分たちが現在捉えている課題の深さを測れる。また、検証活動が本質と合致しているかを確認できる。
#### 2つの失敗
* 採用の失敗：プロダクトの構想を図る基準が無いまたは緩いため、理解が曖昧なまま誤った選択肢を採用して失敗するパターン。組織が比較的若く、フラットな構造の場合に起きやすい。→「正しくないものを作らない」の考え方を採用する。
* 却下の失敗：基準を厳しくしすぎて仮説検証で取り得る選択肢が狭く、少ない選択肢がいずれも不適合の場合に詰んでしまうパターン。組織に歴史があって成功した前例が存在したり、意思決定が多段階である場合に起きやすい。→不確実性に向き合う前提を整える。

###### tags: `読書`