MVPの本質を取り戻し、「リーン」な開発の旅を促進する5つの方法。

私はNetflixの「Is it cake? 」シリーズが好きです。このシリーズでは、パン職人たちが日用品によく似たケーキを作ることで、客を驚かせようとします。彼らは視覚的な錯覚によってゲストをだますことに成功し、ホストがナイフで切り開くまで、視聴者はどれがどれなのか区別がつかなくなります。

時に、本当に中身を理解するためには、物を切り開く必要があります。ピカピカの専門用語も同じです。IT業界では、自分の仕事を誇張するために専門用語やバズワードを使うことが多いのです。おにぎりを切ってみたら、実はケーキだったということはよくあることです！

今日は、最も誤用されている用語の1つであるMVP（minimum viable product）を切り開き、その本当の意味を検証します。さらに、リーン・スタートアップの手法から学んだことを、プロダクト開発プロセスにどのように応用できるかを探ます。

最小実行可能プロダクト（MVP）は、現代のソフトウェア開発の辞書で最も乱用されている用語の1つです。私は時々、私たちの業界がこの用語を総体的な語彙から削除することを望みます。

私は、この業界で「MVP」（minimum viable product）という用語が繰り返し誤用されているのを見てきました。MVPは一般的に誤解され、「プロダクトの初期バージョン」を表す言葉として使われているが、これは正しい定義から逸脱しています。

MVPの'M'は'minimum'の頭文字だからです。もしあなたのMVPがミニマムとは程遠く、そのリリースから何が学べるかについての明確な仮説を欠いているのであれば、その用語の使い方を間違えている可能性が高いのです。

正しい用語を使うことは、特にプロダクト開発においては、明確なコミュニケーションとコアコンセプトの共通理解を促進するために非常に重要です。MVP」という用語は、チームメイトの考え方を形成し、基本的な問題解決のアプローチを確立する上で極めて重要な役割を果たす。MVP」の解釈が個人によって異なる場合、対立は著しく激化する可能性があります。

エリック・リースが著書『リーン・スタートアップ』でこの言葉を広めたことは広く知られています。彼がこの概念を広めた根拠を十分に理解するには、それが適用される文脈を調べることが重要です。彼はMVPを特効薬として宣伝したわけではないのです。私たちは、MVPの適切な使い方を把握し、現実のシナリオで効果的に適用する方法を理解しなければならないのです。

「僕の本当の名前はリーン・スタートアップ・メソッドです！」 ©2001 スタジオジブリ

それは極度の不確実性を管理することである

エリック・リースは著書『リーン・スタートアップ・メソッド』の中で、極度の不確実性を効果的に管理する必要のある起業家のためのものだと明言しています。

これは起業家と、彼らに責任を負わせる人々のための本です。（...）起業家精神という概念には、私が定義するスタートアップの中で働くすべての人が含まれます (...）スタートアップは単なるプロダクトではなく制度であるため、極度の不確実性という状況に特化した新しい種類のマネジメントが必要となります。

リーン・スタートアップ

そうでなければ、すぐに資本が枯渇し、クローズに直面するリスクがあります。限られたリソースの中で持続可能なビジネスを確立することは、ベンチャー企業が生き残るための重要な課題です。

ベンチャー企業はまた、極度の不確実性を管理するという課題にも直面しています。つまり、自分たちの新しいアイデアが実際に市場でヒットするかどうか、まったくわからないことが多いのです。彼らは、正しい答え、つまりプロダクトと市場の適合性を見つけるために、ソリューションを改善し、ピボットする継続的なプロセスに従事する必要があります。

MVPという響きがかっこいいし、みんながやっているからという理由で、最初のプロダクトバージョンをMVPとラベリングしたくなる気持ちはわかります。しかし、本当の意味をよく吟味することなく、バズワードの誇大広告に屈しないようにしましょう。

本当にプロダクトをMVPと呼びたいのであれば、最終プロダクトの可能性を閉ざすのではなく、オープンにしておくことが重要です。例えば、重要なステークホルダーから必須とされ、合意・確認・ラミネート・封印された30の開発項目リストがあるとしましょう。

このシナリオでは、プロダクトと市場の適合性を積極的に追求するよりも、これらの項目を完成させてリリースすることに重点が置かれります。したがって、最初に30項目のうち10項目を開発し、それを3回に分けて提供する計画であれば、それは単にプロダクトの最初のバージョンのままであり、MVPではありません。

ビルド-ビルド-ビルドではなく、ビルド-測定-学習であるべき。

プロダクトをMVPとして区別するのは、科学的にアプローチするかどうかです。プロダクトをリリースする前に重要な仮説を立て、実験に対するオープンな考え方を維持することが不可欠です。

真の実験は科学的手法に従います。何が起こるかを予測する明確な仮説から始まります。科学的な実験が理論に基づいたものであるように、スタートアップの実験はスタートアップのビジョンに導かれたものです。"

リーンスタートアップ

例えば、エッグタルトを食べるときに、パンくずが服に落ちたり、指が汚れたりして、人々が困難に直面していることを観察したとしましょう。この観察に基づいて、私は次のような仮説を立てた：「エッグタルトの形を変え、包み方を改良すれば、消費者はもっとエッグタルトを買いたくなるでしょう。

次のステップでは、紙で包んだ棒状のものなど、別の形のエッグタルトを焼き、潜在的な消費者を対象にテストを実施します。それがMVPです。ウェブサイトやアプリである必要はないのです。必要なのは、シンプルな紙切れ、Eメール、インスタグラムのアカウントなど、あなたの仮説をテストするために活用できるものだけでいいのです。

ですから、もしあなたのプロダクトをMVPと呼びたいのであれば、これらの質問に対する明確な答えを持っている必要があります：

どのような問題を解決しようとしているのか？
どのような仮説を検証しようとしているのか？
どのようなデータや知見を集めようとしているのか？

例えば、棒状のエッグタルトを潜在的な消費者にテストしたところ、彼らはそのアイデアに肯定的な反応を示さなかったとしましょう。彼らは、パンくずを拭き取ったり指をきれいにしたりする手軽なソリューションを好んです。このような場合、次のバージョンは、エッグタルトとウェットティッシュをセットにしたパッケージにすることもできます。それが2つ目の最小実行可能プロダクトになるかもしれないのです。

この例では、あなたは何かを作り、アイデアをテストし、データを収集することで、構築-測定-学習のフィードバック・ループの1ラウンドを完了したことになります。スタートアップ企業にとって重要なのは、車輪を高速で回転させ続け、最小限の労力で最大の洞察を得て、プロダクトを常に調整することです。もしあなたが、自分のアイデアを検証することなく、ただビルド-ビルド-ビルドしているのであれば、あなたが作っているものはMVPには分類されないのです。

このような場合、あなたのプロダクトはおそらくMVPではない

ここまで、MVP開発の背景とアプローチについて述べてきました。では、あなたのプロダクトを切り開き、MVPに値するかどうかを調べてみましょう。以下のどれかに心当たりがある場合、あなたのプロダクトはMVPにはなりにくいでしょう。

作るべきものがすでに決まっており、探求の余地がない。
常にトップダウンで決定され、実務者からのインプットがない。
失敗を受け入れない文化の中で運営されている。
テストも行わず、プロセスから学ぶこともなく、作ることだけに集中している。
顧客やデータの洞察に基づくのではなく、個人的な好みや飛躍的な思い込みに基づく提案をしている。
明確な根拠もなく、その場しのぎで機能や特徴を追加したがる。
人々はそれを「アジャイル」と呼ぶが、それは単にウォーターフォール型の開発プロセスを複数のバッチに分けたものに過ぎない。
人々は、最も重要な問題を適切に特定したり、仮説を立てたりすることなく、短い時間枠の中で実装できるものをすべて詰め込むことを「MVP」と呼ぶ。

MVPであろうとなかろうと、プロダクト開発プロセスを改善するために何ができるか？

何を作るのかを明確に理解することが重要です。それがMVPになるかどうかは別として、リーンスタートアップの考え方を取り入れることには価値があります。開発プロセスの生産性と成熟度を高める方法を探ってみよいます。

1. 正しい用語を使う

リーンスタートアップの手法は、どんな状況でも通用するわけではないのです。プロジェクトによっては、不確実性が限られた、あらかじめ決められた要件が必要な場合もあります。そうでない場合は、「MVP」という用語を使わないようにしましょう。アルファ版」、「概念実証」、「パイロット版」、あるいは単に「バージョン1.0」でしょうか？自分の仕事を正確に定義し、それを正確に伝える努力をしましょう。

2. 質問する

何を作っているのかわからないときは、ためらわずに質問しましょう。なぜこのプロダクトを開発するのか？誰が恩恵を受けるのか？このプロダクトをリリースすることで何を達成したいのか？なぜ正当な理由もなく機能を追加するのか？プロダクトの核となる価値や問題の真の原因がわかるまで、理由を問い続けよいます。

このような質問を投げかけることで、チームはプロダクトのビジョン、ビジネス上の成果、顧客の反応を探り、その結果、より多くのMeasure-Learn活動を取り入れることになります。最も重要なことは、これらの質問はあなたの仕事に意味を与えるということです。その価値を本当に信じることができれば、自分の作っているものに満足感を感じることができます。

3. 最も重要な問題に集中する

どの活動が価値を生み出し、どれが無駄の一形態なのか？ リーン・スタートアップ

お金、時間、頭脳はすべて限られた資源です。それらを効率的に活用し、純粋に仮定に基づく100万のことで自分自身を過負荷にしないようにします。問題に優先順位をつけ、最も重要な問題に集中することが重要です。一度に1つの問題に取り組みましょう。

4. 人と話す

ユーザー中心設計を実践していると言いながら、実際のユーザーとほとんど話をしない人がいかに多いことか。そうならないように。 ユーザー・エクスペリエンス・チーム

プロトタイプを作成し、適切な人材を集め、彼らと話す。簡単なことです。覚えておいてほしいのは、私たちはユーザーではないということです。そして、彼らと話をしない限り、私たちのソリューションについて彼らがどう感じているのかを真に把握することはできないのです。彼らの意見がなければ、フィードバックのループは不完全なものになってしまいます。

5. 失敗を受け入れる文化を育てる

失敗は貴重な学習の機会です。振り返りセッションを実施し、リスクを取って失敗から学ぶことを奨励します。他人のせいにしないのです。失敗を有効な選択肢として受け入れる企業文化がなければ、社員は新しいアイデアを提案することをためらうようになります。失敗が受け入れられ、進歩への足がかりと見なされる環境では、イノベーションが成功します。