# 正しいものを正しくつくる　第5章①
## 第5章　仮説検証型アジャイル開発　わからないものをわかるようにする 5-1, 5-2　基準と仮説検証型アジャイル開発
### 自分たちの基準を作る
プロダクトとして何が正しいのかを見定めるチームの共通理解が「基準」である。
この基準を作るには、個人の「基準」を外在化する必要がある。
そこで、必要十分な粒度を保ちつつ基準を外在化でき、シンプルな一枚絵で仮説構造を表現する **「仮説キャンバス」** が役立つ。

### プロダクト作りの民主化に向けて：分からないものを減らし分かったことを増やす活動
「基準」はチームで持つべきである。そこで、プロダクト作りの民主化を進める必要がある。
そのためには、まず誰も分かっていないことを知る必要がある。不確実性が高い状況では、正確な基準は出せない。そこで**仮説を置いて検証し、不確実さを減らしていく。この「仮説検証」を続けていく。**
### 開発の計画づくりと、検証の計画づくり
#### 開発の計画づくり
いつまでにどこにたどり着きたいかというゴールが定められており、ゴールに至る道筋を組み上げるものである。
計画は頻繁に更新され、計画づくりも頻繁に行われる。
余白の戦略やスプリント強度の強化では補えない不確実性を持たずに進められるよう、ローンチタイミングという目標を置けるように状況の整理をつけ、意思決定する必要がある。
#### 検証の計画づくり
わからないものをわかるようにするための「検証計画」である。
プロダクトを通じて想定ユーザーのどのような状況を作りたいかのビジョンを描く。そのビジョンの実現のために、わからないことを「仮説検証」する。
重要なのは **「どのようなタスクをいつ実施するか。そのために必要な準備は何か。誰がそれを行うのか」** といった行動計画である。
**現在地点（今わかっていること）** と、ビジョンに向かうと見えてくる **「次にやること」** を把握することが大切である。

### 仮説検証のアンチパターン
仮説検証でやってはいけないことが3点ある。
#### ・わからないからとにかく始める
仮説検証では、やみくもに始めてしまうと、得た知識がどんな意味を持つのかが分からなくなる。**いくら情報（事実・データ）をたくさん得たところで、必要としている知識に一致しなければ意味がなく、** 対象が大きくなるほど取り出しは難しくなる。
検証は、最小限の活動で学びが最大になるようにする。現時点で分かっていることを踏まえた上で検証を行う。

#### ・わからないから教科書通りに進める
教科書に載っているやり方をそのまま適用しても、失敗に終わることが多い。手段をいくらまねしたところで、**「何を学ぶつもりなのか」** がハッキリしていなければ無駄に終わる。情報を獲得する活動自体の精査が必要となる。

#### ・わからないから唯一分かっていることだけを頼りに進む。
分かっていることを頼りに進むと言えば聞こえはいいが、分かっていることの範囲でしかわかっていないのである。その外側に分からないものがあると認識したうえでの意思決定と、認識しない決定では大きな差がある。もし認識していないと、後々になって「井の中の蛙大海を知らず」状態になりかねない。
**「何が分かっているのかが分かっていない」** という可能性がある前提に立ってプロダクトづくりに臨む必要がある。

### 仮説検証前の状況調査（エスノグラフィー）
仮説検証の前に、状況やユーザなどの基本的な理解が不足しているなら、**エスノグラフィー調査**が必要になる。
エスノグラフィーとは、文化人類学の調査手法で、実際に現場に赴き、生活や行動を共にして記録した詳細データのことである。
ユーザを明確にするためには、こうした調査で理解を深めると良い。但しあくまでも調査であり、仮説を立てる前提条件にすぎない。

### 仮説検証で持つべき意識
仮説検証は、ユーザの反応を通じて不確実性を詰めるための活動であり、どれが絶対的な正解であるというものは無い。自分たちに足りないものは何かを探す心づもりで。
多くの場合で帰ってくる否定的なフィードバックは、**条件を変えて仕切り直す（ピボットする）の判断材料**となる。反応が好ましくない部分を修正したり、ユーザ対象が間違っていると気づいたりと、不確実性を詰めた上でプロダクトを正しい方向に向かわせてもらえる救世主とも言える。
一方、ポジティブなフィードバックをもらうと嬉しいものだが、勝って兜の緒を締めよ。**そのポジティブな反応が「本物」になるのは、実際に製品としてプロダクトを利用してもらった時である。** ここで致命的な問題がフィードバックされてしまうと、もはや手遅れである。
ポジティブな反応を無駄にしないためにも、実際の利用状況に近い検証を行う必要がある。そのためには、仮説検証は1度きりではなく、複数回にわたり段階的に行う事になる。
仮説検証は、**「正しくないものを作らない」** ためにある。

### 正しくないものを作らないための原則
正しくないものを作らないためには、**セットベース**と呼ばれる、時間の経過とともに選択肢を絞り込む考え方が必要である。
以下、3段階に分けて絞り込んでいく。
#### 1. 目的選択の段階
初期アイデアが人々の問題解決や欲求を充足するものになるかどうかを検証する。
#### 2. 実体選択の段階
ユーザの欲求のうち、最初に取り組むべきものの選択と、そのために必要な機能の定義、適したインターフェースの選択を行う。
#### 3. 手段選択の段階
機能設計、UIデザイン、データ構造について、必要な選択を行う。

これらの選択には、いずれも一つ前の段階の意思決定の影響を受ける。
#### 不確実性のコーン
時間軸で不確実性を表したグラフの形からとったもの。
初期は不確実性がほぼ無限にあり上下にグラフが大きく広がっているが、、時が経つとともに中央寄りに近づき、最終的には真ん中付近で上下のグラフがくっつく。
スティーブ・マコネルが「ソフトウェア見積もり」という書籍で示した概念である。
### セットベースを支えるのは、リーンの原則
セットベースは「リーン製品開発」を支える概念の一つである。
意思決定の選択の幅を残しながら作り進める。

一方で、選択肢をあらかじめ一つに絞り込み、試行錯誤すること無く作り上げる **「ポイントベース」** もある。
どちらの方法を取るかはケースバイケース。どちらかに決め打ちするのはリーンの原則に反する。

**前半はセットベース、後半はポイントベースに行うと良い。**
### 探索+アジャイル開発=仮説検証型アジャイル開発
セットベースからポイントベースへの切り替えは、事業としての意思決定を行う節目でもある。
このタイミングではもう、予算やローンチの時期感や、MVPの範囲の特定を終わらせておく必要がある。
MVPは検証しないと分かるものが増えず、その検証のためにソフトウェアを作る必要があるという判断に達したとき、はじめて開発される。

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