MVP (実用最小限の製品)
MVP(実用最小限の製品)とは、実際の利用者が本当に使うことができ、それによって意味のあるフィードバックが得られる、製品の最小バージョンである。
MVPという言葉は、エリック・リースのリーンスタートアップの考え方を通じて広く知られるようになった。これは、実際の利用者で中核的な仮説を検証できる、構築に最小限の労力しかかからない製品バージョンを指す。何か月もかけて完全な解決策を開発する代わりに、最も価値を生み、最も重要な仮説を検証する一つの機能に集中する。目標は、推測に基づいてさらに計画を進めるのではなく、できるだけ早く本物の反応を得ることである。それにより、誰も欲しがらない機能に時間とお金を注ぎ込むリスクが下がる。
MVPは中途半端なプロトタイプでも、クリックできるだけのデモでもない。viable(実用可能)という言葉は、機能や仕上がりが非常に限定的であっても、利用者がそれで実際に何かを成し遂げられることを意味する。注文アプリのMVPは、決済処理や洗練されたデザインがまだなくても、実際に注文を受け付けられなければならない。この基準を満たさなければ、しっかりしたフィードバックの代わりに、アイデアについての単なる意見しか得られない。
実務でMVPを扱うということは、構築・測定・学習のループを回すことを意味する。動作する最小のバージョンを開発し、利用者が実際にどう振る舞うかを測定し、それをもとに次に何を変えるかを決める。このサイクルは何度も繰り返され、長い計画フェーズを短く検証可能な学習ステップに置き換えていく。最大のリスクは、MVPを削りすぎて製品の本当の価値を示せなくなることであり、そうなると収集するデータ自体が無価値になってしまう。
実践例
ある職人企業が、作業依頼を管理するアプリを構築したいと考えている。スケジューリング、請求書発行、顧客ポータルをすぐに実装する代わりに、まずはシンプルなオンラインフォームから始め、チームに自動でメールが送られる仕組みにする。6週間以内にこのフォームを通じて40件の依頼が寄せられ、そのデータから、顧客の半数以上が空いている予約枠も見られることを期待していることがわかる。この気づきを得て初めて、企業は開発予算とされる約15,000ユーロを、最初から推測するのではなく、まさにその機能に投資する。
Leanshiftの活用方法
MVPはプロジェクトの出発点に適用されたKaizenである。仮定に基づく一つの大きな賭けの代わりに、小さなステップ、実際のフィードバック、的を絞った調整を行う。このマインドセットは、現場での改善作業にも直接受け継がれる。大規模に展開する前に、まず小さな規模で改善を試すという点でも同じである。それは製品だけでなく、同じ学習のリズムを他の場面にも応用できるチームの能力を改善する方法でもある。
よくある質問
MVPはプロトタイプと同じものか?
いいえ。プロトタイプは通常、社内でのデモやテストのためのものだが、MVPは実際に利用する実利用者の手に渡り、単なる意見ではなく実際の利用行動が得られる。
MVPはどれくらい小さくできるのか?
できる限り小さく、ただし最も重要な仮説を検証するのに必要な限度より小さくはしない。重要なのはいくつの機能を含めるかではなく、その一つの中核機能が完全に機能することである。
MVPはいつ完成したと言えるのか?
MVPは従来の意味では決して完成しない。次の開発判断を下せるだけの確かなフィードバックが得られた時点で、完了したとみなされる。