MVP（Minimum Viable Product）の意味を理解する。そして、なぜ私はEarliest Testable / Usable / Lovableを好むのか。

ANKR DESIGN

2021-11-17

ー

‍

この記事はスウェーデンのコンサルティング会社である Crisp社のブログ記事からの翻訳転載です。著者の示すガイドラインに従い配信しています。
　Making sense of MVP (Minimum Viable Product) – and why I prefer Earliest Testable/Usable/Lovable

‍
数年前、私はこんな絵を書いて、アジャイル開発やリーン開発のついての様々なプレゼンで用いた。

そこから、この絵は急速に広まっていった！記事、プレゼン、さらには本（Jeff Pattonの”User Story Mapping”という素晴らしい読み物なのだが）にまで至る所で姿を見せた。多くの人がこの絵は反復型開発、リーンスタートアップ、MVP(minimum viable product)の本質をよく捉えていると伝えてくれた。しかし、元の文脈から切り離して物事を捉える際にはごく自然なことであるのだが、この絵を誤解している人がいる。簡素化しすぎだと非難する人もいる。（正しい指摘である）

この絵はあくまで比喩である。実際の車の開発の話ではなく、車を比喩とした一般的なプロダクトの開発の話なのである。

とにかく、これらのバズからこの考えの背景を話す時だと判断したのだ。

１つ目の例：not like this!

上の行は反復型開発(別名:アジャイル開発)にまつわるよくある誤解を解説している。

‍

‍

多くのプロジェクトはbig bang delivery（つまり、完璧な状態まで作り上げてから顧客に提供）するがためにひどく失敗をしてしまう。このせいで失敗したプロジェクトを私は数え切れない程見てきた。（例についてはスクロールしてほしい）しかし、それに代わるものとしてアジャイル開発が示されると、人々は未完成のプロダクトを顧客に提供するという考えに対して時々顔をしかめる。「誰が車の半分を欲しがるのか？」

想像してみて欲しい

「どうぞ、これが私たちの第一のバージョン、前輪です。どう思いますか？」

‍

‍

顧客はこうなる。「いったいどうしてタイヤなんかみせるんだ？車を注文したんだよ！これでどうしろというのさ！」

(ちなみにここでは、プロダクトマネージャーやプロダクトオーナー、アーリーアダプターのような人々を表すための包括的な用語として「顧客」という言葉を使っている）

プロダクトが提供されるごとに完成に近づいてはいくが、顧客は実際にそのプロダクトが使えないために依然として怒っている。それはまだなお車の一部分にすぎないのだ。

‍

‍

そしてついにプロダクトが完成した時、顧客は「ありがとう！ついにだ！どうして、他の使えないものを飛ばして最初からこれを提供してくれなかったのか？」となる。

‍

この例において、最終的な完成品は顧客の注文通りであったため満足している。

しかし実際のところ、大抵そうはならない。ユーザーテストをせずに多くの時間が費やされ、その結果人々の求めるものに関する誤った仮定を基にして設計上の欠陥まみれのプロダクトが作られる可能性が高いのだ。よって、この最後の顧客の笑顔は極めて理想論なのである。

いずれにせよ、この最初の行は「粗悪なアジャイル」を表している。厳密に言えばこれは反復型型開発になるのかもしれない。しかし、実際のフィードバックループを回転させないことは非常にリスクが高く、間違いなくアジャイル開発ではない。

このようなわけで、「not like this」という見出しなのだ。

2つ目の例：Like This!

下の行に移ろう。

‍

ここでは全く別のアプローチをとっている。顧客が車を注文したという前提で始めよう。しかし今回はただ車を作ることはしない。その代わりに顧客が求める潜在的ニーズに注目する。彼の潜在的ニーズが「AからBに早く到着する必要がある」ということがわかり、車はそれに対して考えられる解決策の一つに過ぎないことがわかる。車は単なる比喩であることを忘れないでくれ。あらゆる製品開発の状況を頭に浮かべてほしい。

よってこのチームは、顧客に対してテストができ、かつフィードバッグをもらえるような、思いつく限りで最も小さなものを提供する。これをMVP（Minimum Viable Prodduct ）と呼ぶ人もいるが私はEarliest Testable Product(これについては後述する)と呼ぶ方が好きである。

好きなように呼んでほしい。（この比喩から、プロダクトの「スケートボードバージョン」と呼ぶ人までいる…）

これに顧客が満足する可能性は低い。彼の注文した車とはかけ離れている。しかしそれでいいのである！ここにはスケートボードがあり、我々はこの段階で顧客を満足させようとしているのではない。もしかしたら一部のアーリーアダプターを満足させる（または実用主義者を苦しめる）かもしれないが、この段階においての私たちの主たる目的はただただ学ぶことなのだ。理想的には事前にこのことをしっかりと説明することで、そうすれば顧客もそんなに悲しまなくて済む。

‍

けれども、最初のシナリオに登場した前輪とは対照的に、スケートボードは顧客がAからBまで移動するのに実際に役立つプロダクトなのである。素晴らしいブロダクトではないが何もないよりはほんの少しましだろう。よって私たちは顧客に「心配いりませんよ。このプロジェクトはまだ完了しておらず、これは数あるバージョンの中の最初に過ぎないのです。我々は今もなお、車を作り上げることを目標にしていますがその間にこれを試して私たちにフィードバックをください」と伝える。大きく考えるが、小さく機能的に実行可能なインクリメントで提供するのだ。

我々は驚くべきことを学べるかもしれない。「そのスケートボードは嫌だ」と顧客が言ったとしよう。理由を尋ねると、「色が嫌だ」という。「なるほど、色？それだけですか？」「そうだ、ブルーにしてくれ！それ以外は大丈夫だ！」と。これで車を作らず、多くのお金を節約したことになる。ありそうもない話に聞こえるが、それは誰も知る由がない。

カギとなる問いは「一番コストをかけずに早く学べる方法は何か？」である。スケートボードよりもさらに前に、何かを提供することはできるだろうか？バスのチケットはどうだろう？

これは顧客の課題を解決するだろうか？多分、おそらく解決しないだろう。しかしこのバスチケットを実際のユーザーの手に渡すことで、確実に何かを学べるのである。リーンスタートアップはユーザーにまつわる実際の仮説を基にした素晴らしいモデルを提供し、ユーザーに対して有効だったかそうでなかったかシステム的に機能する。

全てのユーザーに対してプロダクトの検証する必要はないし、何かの検証のためにプロダクトを作り上げる必要もない。一人のユーザーにだけでもプロトタイプの検証をすることで、ゼロではない何かを学ぶことができるのである。

まあよい、スケートボードの例に戻ろう。

オフィスの中でそれを乗り回したあと、顧客はこう言う。「いいね。楽しい感じがするしコーヒーマシーンまで早く行ける。だが、安定しないんだ。すぐに転んでしまう。」

そうすると、この問題を解決するもしくは少なくともその問題について学ぶための次のバージョンがこれだ。

‍

これで顧客は転ばずに動き回れる！

満足であろうか？いやそうでもない。彼はある程度はまだ車を欲している。しかし、その間にも実際にこのプロダクトを使いフィードバックをくれる。顧客の最大の不満は、車輪が小さく、休憩もとれないためビルの間のような長い距離を移動するのが難しいということだ。そうしたら、プロダクトを次は自転車のようなものに変えてリリースする。

‍

これで顧客はキャンパスを疾走できる。いえええええい！

これまでのことから学ぶことがある。顧客は顔に新鮮な空気を感じることが好きなのである。彼はキャンパスにおり、移動といえばほとんどビルの間を動き回ることなのだ。

本来想定されていた車より、自転車のほうがはるかによいプロダクトだと判明するかもしれない。実際には、プロダクトの検証をしながらいずれにせよ車が通るには道が狭すぎると知るかもしれない。我々は顧客の多くの時間とお金を節約し、時間をかけずにより良いプロダクトを提供したのである！

ここであなたはこう考えるかもしれない。「でも、それは顧客の状況やニーズを通して先に把握しておくべきではないですか？」良い視点である。しかしこれまで私がみてきた実生活の多くのプロダクト開発においてはどんなに事前調査をしても、それが実際のユーザーの手に渡ると、やはり驚くことはあり、多くの仮説が大きく外れたいるとわかるのである。

事前調査をし、開発を始める前にできるかぎりのことはやる。しかし、それに時間を割きすぎたり、分析結果を過剰に信じるのはやめてほしい。そうではなく、プロトタイプをしリリースすることから始めて初めて、本当の気づきが生まれるのである。

それはともかくとして、ストーリーに戻ろう。おそらく顧客は更なるものを求めている。他の街に行くこともあり、自転車では遅すぎるし、汗をかいてしまう。そうしたら、次のバージョンでエンジンを付け足す。

‍

このやり方はとりわけソフトウェアに適しているだろう。ソフトウェアは、まあ、ソフト＝柔らかいからだ。基本的に毎回作り直さなければならないハードウェアとは対照的に、進捗とともにプロダクトを変化させることができる。しかしながらハードウェアのプロジェクトにおいてもまた、顧客のプロダクトの使い方を観察し、気づきを得るためのプロトタイプの提供が大きなベネフィットをもたらす。これは製品開発の期間が少し長くなるだけである。（数週間ではなく数ヶ月になる）トヨタやテスラのような実際の自動車メーカーでさえ新作のカーモデルを開発する前にたくさんのプロトタイプ（スケッチ、3Dモデル、実寸台のクレーモデルなど）を行っている。

さて今度はどうしよう？再びではあるが、おそらく顧客はこのバイクに満足している。予定より早めにこのプロジェクトを終わらせることもできるだろう。大半のプロダクトは複雑であったり、誰も使わないような機能にまみれていたいりする。この反復的なアプローチはリリースを少なくし、最も単純でコストをかけずに顧客の課題を解決するための方法を見つけるための方法なのだ。最高のものにたどり着くための道のりを最小限にする。禅だね。

それかまた、顧客が必須要件に対する修正を加える、もしくは加えずに続けたいと選ぶこともできる。結局、最初に望まれていたものと全く同じ車になることも実際にはあるかもしれない。しかし、それまでのプロセスで重大なインサイト得てわずかに違うものが出来上がる可能性のほうがはるかに高い。例えばこんな感じである。

‍

顧客は大喜び！なぜだろう？ここまでのプロセスにおいて、彼が顔にあたる新鮮な空気を味わっているということを知っていたからオープンカーになったのだ。顧客はついに車を手に入れたーそれももともと考えていた車よりもピッタリな車を！

それではここで、一歩引いて考えてみよう。

あなたにとってのスケートボードはなんだろう？

顧客が全く使えないものを提供し続けるため、最初のシナリオはひどいものだ。自分が何をしているのかわかっている場合（プロダクトの複雑さやリスクはほとんどなく、もしかすると何百回とその前に同じタイプのものを作り上げているもの）、先に進みただビッグバンを起こすのだ。ものを作り、作り終えたら届けるのである。

しかしながら、私が見てきた製品開発に関する取り組みの多くはずっと複雑でリスクも高く、ビッグバンアプローチはほとんどの場合、莫大な費用のかかる失敗となる。だから、鍵となる質問はあなたのスケートボードは何であるか？ということである。

製品開発において（誰に対して何の問題を解決しようとしているのか説明した後に）最初にあなたがすべきことの一つは、スケートボードに相当するものを特定することである。

スケートボードは、実際のユーザーの手に渡しリアルなフィードバッグを得られる最小のものの比喩だと考えてほしい。バスチケットの方がうまく機能しそうであれば、それを比喩として使用しても構わない。

これにより、非常に必要なフィードバックループが提供され、あなた自身と顧客の双方共にプロジェクトをコントロールできるようになる。計画に従って最善を尽くすのではなく、学習して変更を加えることができるのだ。

実際の例をいくつか見てみよう。

例1：Spotify music player

「7500万人以上のユーザーがいるため、Spotifyの無い時代を思い出すのは難しいですが、しかし、確かにありました。私達がみんな新しいCDのためにTarget（訳者注：アメリカの大型スーパー）の通路で悩んでいたとき。Napsterで全員で泥棒になったとき。iTunesが一つ2ドルで曲を買うことを私たちに強制してきたとき。そしてやっと、Spotifyが登場したのです。」

Spotifyは今ではかなりイケてるプロダクトだが、はじまりはそうではなかった。私は、この素晴らしい旅のかなり早い段階で関わりをもったことは幸運であったと思う。（そして、今でも関わり続けている）。

‍

2006年、Spotifyはスタートアップとして大きな仮説を持って設立された。その仮説とは、人々は自分が音楽を所有することよりもストリーミングすることに満足していること、アーティストやレーベルは人々に合法的にストリーミングしてほしいと思っていること、そして高速で安定したストリーミングが技術的に実現可能であることである。

これは（real playerのような）音楽ストリーミングがかなりひどい体験であり、海賊版は極めて普通だった2006年だと言うことを忘れないでほしい。技術的な面での課題は「再生ボタンを押してすぐに音楽をストリーミング再生することはそもそも可能なのか？厄介な「バッファ中の」プログレスバーを取り除くことは可能なのか？」ということだった。

小さく始めることは、大きく考えることができないという意味にはならない。これが彼らが念頭に置いていたものの初期のスケッチの1つだ。

‍

しかし、開発者は製品全体を構築するのに何年も費やしてから仮説が成り立つかどうかを調べるのではなく、基本的には座って技術的なプロトタイプを作り上げ、自分のパソコン上にあるテキトーな音楽を入れて、高速で安定した再生方法を見つけるために思いのまま実験を始めた。

重要視した点は、「再生ボタンを押してから音楽が聞こえるまでに何ミリ秒かかるのか？」だった。ほぼ瞬時に再生され、途切れることなくスムーズに再生されるべきなのである。

「誰も気にしないにも関わらず、私達は音楽が再生され始めるまでの時間にあり得ないほど長い時間をかけて集中をしました。なぜならハードディスクに世界中の音楽がすべて入っているように感じさせることに夢中になっていたからです。細部にこだわると、非常に大きな違いを生むことがあります。それが、MVPの考え方についての最大の誤解であると私が考えていること、MVPのVの部分です。」共同創設者兼CEO、ダニエル・エク

きちんとしたものができると彼らは自分自身や、その家族・友達に対してテストを始めた。

‍

最初のバージョンは広くリリースすることはできないものだった。完全に洗練されておらず、ハードコードされたいくつかの曲を見つけて再生する機能以外の機能は基本的になく、法的合意や経済モデルもなかった。これが彼らのスケートボードであった。

しかし、彼らは恥じることなくスケートボードを実際のユーザー（友人や家族）の手に渡して、必要な答えをすぐに得た。技術的に可能であったし、人々はその製品（というよりもその製品がどうなっていくか）を非常に気に入ってくれた。仮説は実証されたのだ！この連続したプロトタイプは、音楽レーベルや投資家を説得するのに役立った。あとはご存知の通りである。

例2：Minecraft

‍

Minecraftは、特に開発コストを考慮すると、ゲーム開発の歴史の中で最も成功したゲームの1つだ。早い段階で何度もリリースすると言う考え方の究極の例の1つである。一人の男による6日間のコーディングのみで最初の公式リリースが行われたのである。最初のバージョンでは多くのことができなかった。

それはおおよそ、ブロックを掘り起こし、他の場所に配置して粗雑な建物を建てることのできる、醜いブロック状3Dランドスケープだった。

‍

これがスケートボードであった。

しかしユーザーは非常に熱心に関わってくれた（かなりおかしなことではあるが、開発者とユーザーのコミュニケーションのほとんどがtwitter上で行われた）初期のユーザーの中には私と私の4人の子供がいた。最初の1年間に100を超えるリリースが行われた。ゲーム開発とは、楽しみを見つけることである。（私が協力してきた一部のゲーム会社では、「Definition of Done」ではなく「Definition of Fun」という用語を使用している）

そのための一番良い方法は、実際にそのゲームをプレイしてもらうことだ。今回の場合、実際にお金を払って早期アクセスバーションを試し、ゲームを改善したいと個人的に思ってくれていた数千人もの人が存在した。

小さな開発チームが徐々にゲーム周りに作られていき（実際にはほとんど2人）、ゲームは世界中で大ヒットした。私はMinecraftをプレイしていない子供に会ったことはないと思う。そして昨年、ゲーム（というより、ゲームを中心に設立された会社）は25億ドルでマイクロソフトに買収されました。非常に素晴らしい。

例3：大きな政府のプロジェクト

2010年頃、スウェーデン警察は、警察が交番よりも現場でより多くの時間を過ごすことができるようにするための大きな取り組みを始めた– PUST（Polisens Utrednings STöd）

この魅力的なプロジェクトに、私はコーチとして関わり、私たちが何を行い何を学んだかについての本を書いた。（Lean from the Trenches）

‍

今回のアイデアは、パソコンを車に搭載し、ソフトウェアをカスタマイズして、警察が容疑者に尋問する時などリアルタイムで必要なシステムにアクセスできるようにすることであった。（タブレットがまだない時代である）

彼らは、過去にも何度か似たようなシステムを構築しようとしていたが惨めにも失敗していた。主な理由は、ビッグバンの考え方にある。彼らは、以前の試みの1つは開始してから最初のリリースまで7年かかったと私に伝えてきた。7年！もちろん、そのときまでに全て変わってしまいプロジェクトは完全なる失敗に終わってしまった。だから今回は違う方法で行いたかったのである。

後に「PUSTJava」と呼ばれるこの60人のプロジェクトは、大きな政府プロジェクトとしては特に、驚くほどうまく成功した。（CIOアワードの「Project of the Year」でも2位にもなった）主な成功要因の1つは、すべてを一度に構築しようとしなかったことだ。2つの軸に沿って分割した。

・地域別。スウェーデン全土に一度にリリースする必要はない。1つの地域にリリースすることから始めればよい。

・犯罪の種類別。最初は犯罪の種類全てをサポートする必要はない。1〜2種類の犯罪をサポートすることから始めればよい。

‍

これが最初のバージョン1.0。スケートボードであった。

わずか2種類の犯罪をサポートする小さなシステムであり、 Östergötland（スウェーデンの地域）の少数の警官でのフィールドテストだった。他の犯罪については、交番に行き事務作業をするという昔ながらの方法で対応しなければならなかった。彼らは自分たちが実験台であり、プロダクトは完成から程遠いところにあることはわかっていた。しかし、別の選択肢がどういうものかを知っていたため喜んでフィールドテストに取り組んだ。彼らは、初期のユーザーフィードバックが不足しているプロセスから生まれるくだらないシステムを見ており、今回ついに、システムが作られていく中で影響を与える機会を得られたのだ！

彼らのフィードバックは厳しく、正直だった。我々の仮説の多くはそこでふるい落とされた。実際のユーザーフィードバックが入ってくるにつれて、事前に注意深く作成された想定ユースケースのは実情とはかけ離れたものになっていき、それにどう対処するかが最も大きなジレンマの一つであった。（ウォーターフォール型開発をしてきて、多大な事前分析を行う習慣のある組織だった）

とにかく、簡単に言えば初期のフィードバックは製品の改善に向けられ、Östergötlandの警官が製品を好きになり始めたので犯罪の種類を増やして、より多くの地域に拡大させることができた。全国展開と12000人もの警察官の訓練を伴う大きなリリースのver.1.4にたどり着く頃には私たちは大きな心配はしていなかった。これまでに非常に多くリリースを重ねてきたし、たくさんのユーザーテストを行ってきた。だから全国的なリリースの夜はぐっすり眠ることができたのだ。

残念なことにこの快挙は長くは続かなかった。これに続いて行われたプロジェクト（PUST Siebel）が台無しにしてしまい、再びウォーターフォール方の思考に戻ってしまった。おそらく長年の習慣のせいだろう。リリースやユーザーテストを行わずに2年間の分析とテストを行った後、12,000人の警察全員に「次世代」の製品としてビッグバン的にリリースした。それは目も当てられない状態で、半年にわたる損失の後、彼らはすべてを終了させた。開発費は約2000万ユーロだったが、内部調査によると、スウェーデン社会への費用は（警察はひどいシステムによって障害を負っていたため）約10億ユーロでだったのだ！

学ぶには高すぎる金額だ！

例4：Lego

私は現在レゴで働いているが、毎年確実に新しい大ヒットを生み出していることに驚いている。どうやっているのかたくさんの興味深い話聞くのだが、共通しているのはプロトタイピングと初期段階のユーザーテストなのだ！オフィスで子供たちを見かけるごとがよくあり、デザイナーは地元の幼稚園や学校、家族と協力して新製品のアイデアをフィールドテストしている。

最近の例– Nexo Knights（2016年1月リリース）

‍

最初にこのコンセプトを探り始めたとき、彼らは紙のプロトタイプを作って小さな子供たちのもとに持っていった。子供たちの最初のリアクションは「ねえ、だれが悪いやつなの？だれが良いやつでだれが悪いやつなのかわからないよ！」おっと…そこでデザイナーは、子供たちにちょうどいいデザインが見つかるまで、繰り返しテストを続けた。上の写真では誰が正義で誰が悪かがわかると思う…

この話の中でどこにスケートボードがあるのか正確には分からないが、実際のユーザーからの初期段階でフィードバックをもらうという考えがあることは分かるだろう！ただ製品を設計してすべてを作り上げるのではない。彼らがもともとの設計の仮説に基づいて製品を作り上げ世界中の店舗に何千もの箱を配達した後に、問題に気づいたと想像してみてくれ！

レゴは、苦労して稼いで失敗したこともある。

Lego Universeはその例の一つだ。大規模なマルチプレイヤーオンラインレゴワールドである。楽しそうだろう？問題は、彼らが野心的になり、世界にリリースする前にすべてを完璧に作り上げようとしてしまったことだ。

‍

約250人もの人々が4〜5年間働き（完璧主義による絶え間ない仕様変更のため）ついにリリースされたのだが、受け手の反応は…生ぬるいものだった。完成されたゲームは美しかったが期待していたほど楽しいものではなかったので、この製品は2年で終了してしまったのだ。

これはスケートボードではない。

なぜか？スケートボードは素晴らしいものではない。（少なくとも車を望んでいるのなら）そして、レゴの文化は素晴らしい体験を届けることに尽きるのだ！デンマークのビルンにあるレゴ本社で働く場合、この巨大な壁画を毎日通り過ぎる。

‍

大まかに言うと、「最高のものだけで十分です」という意味である。これは、80年以上前に会社が設立されて以来、レゴの指針であり、世界で最も成功した会社の1つになるのに役立ってきた。しかし、今回の場合、原則は誤って適用されてしまった。完璧への執着が不可欠なフィードバックを送らせ、ユーザーが何が好きで、何が好きでは無いのかに関する誤った仮定を導いた。Minecraftの正反対である。

興味深いのが、Lego Universeチームは実際にスクラムを組み、Minecraftの人たちと同じように頻繁に反復型開発に取り組んでいた。しかし、リリースは内部的なものにすぎなかった。そのため、スケートボードや自転車などであった可能性は高いが、これらの製品は実際のユーザーには届かなかった。スクラムはこのように活用されるものではない。

これは高くつく失敗だったが、レゴはそこから学び初期段階のテストとユーザーフィードバッグで常に良くなっている。

Improving on MVP

さあそして（深呼吸）、MVPの話に戻ってくる。根底にある考え方は素晴らしいのだが用語自体は多くの混乱と不安を引き起こす。「MVPのプロダクトなんて全くもって欲しくない。最終形を提供してくれ！」というような顧客に多く会ってきた。多くのチームがいわゆるMVPの状態で提供し、バグのある未完成な商品を顧客の下に残してさっさと次のプロジェクトへと移る。一部の顧客にとってはMVP＝MRC（Minimum Releasable Crap）つまり、「最低限リリースできるレベルのゴミ」なのだ。

‍

わかってる、わかってる。ここで悪いのはMVPという用語というよりずさんな管理の問題だろう。それでもやはり、この用語は誤解を招く。「Minimum＝最小」と「Viable＝実行可能」は、人によって意味が異なり、問題を引き起こす。

そこで代替案だ。

まず、「Minimum」という単語を「Early」に置き換える。MVPでのリリースの背後にある重要な考え方は、初期段階でフィードバックを得ることだ。完璧な製品ではなく、必要最小限の機能を搭載した製品を提供することで早くフィードバックを得ることができる。

「Minimum=必要最小限」を望む顧客は少ないが、ほとんどは「Early=早く」製品が届くのを望んでいる。よってこれが私たちの最初の変更である。

Minimum＝>Earliest

次に「Viable＝実行可能な」という単語を削除する。これは曖昧すぎるのだ。あなたにとっての「Viable」は私にとっての「horrible」にもなる。Viableは「テストしてフィードバックを得ることができるもの」と考える人もいれば、「顧客が実際に使用できるもの」と考える人もいる。そのため、3つの異なるもの分けてより明確にしよう。

‍

Earliest Testable Product（最も初期のテスト可能な製品）はスケートボードまたはバスのチケットだ。顧客がそれを使って実際に何かをすることができる最初のリリースだ。問題は解決していないかもしれないが、少なくとも何かしらのフィードバックは生み出す。学ぶことがこのリリースの主たる目的であり、実際の顧客価値はおまけである、ということを私たちは明確にしている。

Earliest Usable Product（最も初期の使用可能な製品）はおそらく自転車だ。アーリーアダプターが実際に積極的に使う最初のリリース。これは完成しておらず、あまり好まれないかもしれない。しかし、確実に以前より顧客を良い状態を提供しているのだ。

Earliest Lovable Product（最も初期の愛すべき製品）はおそらくオートバイだ。顧客が愛し、友達に話し、喜んでそれに対してお金を払う、最初のリリースだ。まだ改善の余地が多くあり、最終的にはコンバーチブルか、飛行機か、その他のものになる可能性がある。しかし、真に需要のある製品を手に入れられるようになる。

より初期の段階でさらに早い段階で「最も早いフィードバック可能な製品」を追加することを検討した。これは基本的に、顧客から最初のフィードバックを得るペーパープロトタイプやそれと同等のものだ。しかし、4つのステップは多すぎるように思われるしFeedbackableという単語はちょっと…。しかしそれでも、これは大切なステップである。ペーパープロトタイプをEarliest Testable Productと呼ぶ人もいるが、それはTestableをどのように定義するかによると思う。詳細については、MartinのMVPガイドを参照して欲しい。最小限の投資で早い段階でのフィードバックを得る方法の非常に具体的な例がたくさんある。

もちろんEarliest Testable/Usable/Lovableを誤解する可能性もあるだろう。しかし少なくともMinimum Viable Productより一段階明確なのである。