Eric Ries氏がリーンスタートアップで定義した実用最小限製品(MVP)の目的は最小限の努力とお金で顧客について知ることだ。 the problem with a lean startup: the minimum viable productというブログ記事で、オンラインマーケッターのPaul Kortman氏が自身の実用最小限製品開発の経験を記している。氏はリーンスタートアップを説明することから記事を始める。
リーンスタートアップの考え方の基本はユーザからのフィードバックを受け取り、ユーザにテストしてもらって、これから開発する製品や開発中の製品を人々が使ってくれるか(お金を払ってくれるか)判別することです。
リーンスタートアップは、開発したいと思っている製品のニーズがあるのかどうかを素早く検知することで、より組織をより効率的にする。しかし、組織にとっては実用最小限製品を定義するのは難しい。
誰もが製品という言葉が何を意味しているのか知っています。そして、最小限ということも解っています。つまり、なんとか製品としてやっていける本質的な部分は何なのかということです。
氏は自身が実用最小限製品を開発する中で直面した課題を説明する。
私たちの製品が製品として成り立つのはどの時点なのか
- いつクリティカルマスに達するのか
- いつすべての機能を搭載できるか(決してこんなことは起きない)
- いつ収益が生まれるのか
- いつ儲けが出るのか
Forbesの記事the times are changin': the evolution of enterprise softwareでは、YammerのエンタープライズストラティジのディレクターであるBrian Murray氏リーンスタートアップで企業向けソフトウエア開発の何が変わっているのか、そしてなぜそのような変化が必要なのか説明している。
従来の企業向け開発の不効率性は顧客にリリースする前に完璧な製品を作ろうとするために生まれます。 (…)今や開発チームはMVPを構築することに注力しています。(…)こうすることでサービス提供者側は効率的に仮説を検証し、最終的には人々がそうあるべきだと考える製品ではなく、ゆっくりと継続的にあるべき姿へ進化していく製品を作り上げることができます。
minimum viable product vs minimum delightful productというブログ記事で、Adam Berrey氏は企業向けの実用最小限製品に対する考えを披露している。
(…) 企業向けビジネスシステムが成功するのは、技術的イノベーション、機能やセールス/マーケティングのためです。販売を始めるのに十分な機能が揃ったら、製品として成立しているということでしょう。
Jesus Rodriguez氏はthe enterprise minimum viable product: focus on viable Instead of minimumというブログ記事で、企業向けソフトウエア開発と消費者向け製品の開発で実用最小限製品でどのような違いがあるのかを説明している。企業向けのマーケットではソフトウエアのユーザは買い手でもある。企業ではこのようなことは起らない。したがって製品のフィードバックを得るのは難しい。
(…) MVPを使う人が購入の意思決定をすることはほとんどありません。(…)企業向けソフトウエアのスタートアップはMVPからのフィードバックを注意深く評価できなければなりません。潜在的な顧客と関係のある製品へと進化させてくれる機能からノイズを除去するのです。
企業向けソフトウエアの実用最小限製品の難しさは、企業が機能に基づいて製品の購入を決定することだ。Jesus Rodriguez氏はこれを“機能過剰文化”と呼んでいる。
何十年の間、企業向けソフトウエアは製品の単純さや使いやすさよりも機能の数を評価する文化の中で進化してきました。なので、企業に製品のMVPバージョンを見せると、製品内の機能の数で製品の力や企業向け製品として準備ができているかを評価されてしまうという偏見の壁にぶつかってしまうかもしれません。
lessons from agile – the minimum viable productというブログ記事で、Sam Palani氏は複雑な企業の動きに対してなぜ 実用最小限製品を使うのか説明している。
たくさんのデータを持ち、複雑なETLやインターフェースを書いてデータを抽出したり操作してりしていました。しかし、実際のビジネスの機能は将来のリリースとこれから計画するスプリントで提供するつもりでした。理想的にはこれまで計画してきた方法で成功できるのでしょうが、現実にはステークホルダーの我慢が限界に達するリスクがありました。
そして、氏は最小限実用製品に対する考え方、MVPを使って最小限の望ましい製品を開発する方法について説明する。
最小限の望ましい機能を持った製品は、製品として成立する機能を超えたスコープと機能を含みます。理想的にはMVPを、最大限のビジネス価値と顧客満足を提供するための次のイテレーションで、アジャイルなリリースやスプリントを用いてMDPの状態へ推し進めます。
氏は企業で最小限実用製品を定義する5つのステップについて説明している。まず、ステークホルダー、スコープ、機能間の依存関係を特定し、プロトタイピングを経て、ビジネスニーズに基づいて最小限実用製品を定義する。3番目の機能に関するステップについては、
MVPに含まれる依存関係のある機能の数を制限します。製品として成立することに着目しますが、最小限にすることを念頭に置きます。依存関係のある機能の数が多すぎると最小限の機能のとどめておくことができなくなります。