試すために出しただけでは、試せていない

なぜこれを記録するか

不確実なら、小さく出して学ぶ。この言い方自体は、ほぼ正しい。

しかし現場では、次のような置き換えが起きることがあります。

• 不確実だから検証する
• 小さいから出せる
• 出せるから出す
• 出したからフィードバックが来る

最後がいちばん危うい。

機能としては小さい。一見すると便利にも見える。だからまず出して、使ってもらい、意見をもらえばよい——そう説明されることがあります。ところが、ユースケースの中に置くと手順が増え、判断が増え、途中で止まる。利用者は価値を受け取っていない。返ってくるのは「この画面は何か」「使いにくい」であり、構想の可否ではありません。

出したことと、試せたことは、同じではありません。

二つの「小さい」

小さくすることには、少なくとも二種類あります。

	機能として小さい	価値として小さい
切るもの	画面、処理、項目、状態	対象顧客、対象業務、責任範囲
残るもの	途中までの操作	一連の目的が完了できること
確認できること	実装できたか、操作できるか	その方向に価値があるか
失敗の形	未完成を本番に置く	対象が狭すぎて一般化できない

前者は、作る量を減らします。後者は、引き受ける範囲を減らします。

記録003では、価値の流れを途中で切るのではなく、プロダクトが引き受ける責任を小さくすると書きました。004で問うのは、その小さくした単位が、検証として成立しているかです。

機能が小さいことは、学びが小さいことの条件ですらありません。途中で切れた操作は、小さい実験ではなく、未完成の業務を渡しているだけになり得ます。

検証したい対象がすり替わる

MVPという言葉が使われるとき、検証したいことは、本来だいたい次です。

• この業務を、プロダクトが引き受けてよいか
• この切り方で、利用者は先へ進めるか
• この最小形の上に、次の構想は載るか

ところが「とりあえず出す」になると、確認されるのは別のことになります。

• 画面があるか
• 操作できるか
• 仕様どおり動くか

これらは実装の確認です。実装の確認は必要です。しかし、それはプロダクトの仮説を閉じたことにはなりません。

フィードバックが欲しいなら、相手が何かを完了したあとでないと、構想への意見は出ません。完了していない相手に「どうでしたか」と聞いても、返るのは途中で止まった体験の感想です。学びの対象が、最初からずれています。

便利そう、は検証を壊す

孤立した機能は、説明の場では便利に見えます。入力が減る、一覧ができる、ボタンがある。部分だけ見れば、ないよりあったほうがよいように見えます。

ユースケースに入れると、話は変わります。

前後の業務と繋がらない。必要な判断が足りない。できたことに見えて、次の人へ渡せない。例外の逃げ場がなく、通常の作業が遅くなる。このとき利用者は「この機能は要るか」を評価していません。「このプロダクトで仕事をしたくない」に近い感想を持つだけです。

部分の便利さと、一連の業務での価値は、別のものです。前者を出して後者のフィードバックを期待すると、検証は壊れます。

未完成版と、最小形

よくある理解は、こうです。

いずれ大きな価値になる。今はその一部だけ出す。残りは想像してもらう。

これはデモや説明には使えます。しかしMVPとしては弱い。利用者は、ない部分を補って評価する義務を負っていないからです。想像で埋めた感想は、当たっている構想の証拠にも、外れている証拠にもなりません。

置き換えるなら、こうです。

MVPは、大きな価値の未完成版ではない。
大きな価値の、今いま成立する最小形である。

未完成版は、あとでつながるはずの穴を残します。最小形は、今の体験そのものが次の構想の一部になっています。

たとえば、最終的には判断まで自動化したい業務があるとします。最小形は「判断画面の前半だけ」ではありません。特定の担当者が、特定の案件を、人の確認を含めて最後まで完了できることです。自動化はまだ持たない。しかし完了は成立している。その利用から、「この完了の形の上に、自動化は載るか」を見られます。

小さくしているのは機能の途中ではなく、対象と責任範囲です。

何を小さくし、何を残すか

小さく出すなら、少なくとも以下を先に考えます。

1. 誰の、どの業務か
   全顧客の全例外ではなく、今検証する対象を狭める。

2. その人が何を完了できるようになるか
   画面があることではなく、目的が終わること。

3. プロダクトはどこまで持ち、どこを人へ戻すか
   切った先に、成立する受け渡しがあるか。

4. これで閉じたい問いは何か
   操作の感想ではなく、構想の可否。うまくいったとき、次に何が可能になるか。

「小さいから出す」ではありません。「この問いを閉じるために、ここまで出す」です。

記録002で書いたように、事業として試したいことは、プロダクト上の選択へ変換しないと検証になりません。「早く市場に出す」は目的になり得ます。しかし、出す単位が価値として成立していなければ、市場に出しても市場は答えられません。

実験と、本番の断片は別物

仮説を試す方法は、本番の機能リリースだけではありません。説明用の画面、手動のオペレーション、限定した利用者との同行。それらは、実験として設計されていれば学び得ます。参加者も、何を試しているかを共有できます。

問題は、本番の機能断片を、実験だと言って出すことです。利用者は実験に参加しているつもりがなく、未完成の業務を渡されます。返ってくる信号は、仮説の可否ではなく、途中で止まった仕事の不満になりやすい。

実験なら実験として設計する。プロダクトとして出すなら、完了できる最小形にする。二つを同じ「MVP」と呼ぶと、出す理由だけが残って、学びの設計が消えます。

試せているかを確かめる

機能を小さくしたことが、検証になったことになっていないかを見るための三つの問いがあります。

1. 完了テスト — 利用者は、何を最後まで終えられるか。
2. 信号テスト — 返ってきてほしいのは、操作の感想か、価値の可否か。後者なら、完了した人からしか来ない。
3. 接続テスト — うまくいったとき、次の構想の何が載るか。載らないなら、それは最小形ではなく断片である。

一つめに答えられなければ、出しても試せていません。二つめに答えられなければ、フィードバックの取り方を決めていません。三つめに答えられなければ、小さくした理由が「今はこれしか間に合わない」だけです。

まとめ

• 小さく出すこと自体は、不確実へのまともな応答である
• ただし、機能として小さいことと、価値として小さいことは別である
• 途中で切れた機能を出しても、構想の可否は検証できない
• 「便利そう」は部分の印象であり、ユースケース上の価値ではない
• MVPは大きな価値の未完成版ではなく、今いま成立する最小形である
• 本番の断片と、実験として設計した学びは、同じ「出す」ではない

試すために出す、という言い方は残してよい。残してはいけないのは、出したという事実を、試せたという事実の代わりにすることです。