Minimum Viable Product（実用最小限の製品） -- 最大限に誤解された概念
アジャイル文化の醸成と実行に成功した企業が、顧客価値とビジネス価値を創出するためにMVPを採用する理由。
By Arbi Vartan and Jeff Brinkerhoff（Translated by 鈴木良和、元記事はこちら）
MVP（Minimum Viable Product・実用最小限のプロダクト）は、アジャイルを実践する上で基本となる概念です。しかし、これは【長い期間と多大な予算をかけて、一度の開発を経て完璧なものを作り上げる】ウォーターフォール型の開発が根付いた組織において、時として抵抗や反発を生み出すものでもあります。
私達は、過去のクライアントの以下の発言を鮮明に覚えています。
「当社の幹部は最低限のことではなく、可能な限り最高の質と最大限の効果を望んでいます。なぜ、MVPなのですか？」
これは素晴らしい質問ですが、残念ながらMVPに関する誤解に基づいた質問でもあります。
MVPの歴史と定義
2001年にフランク・ロビンソンによって考案され、エリック・リースの著書「リーン・スタートアップ」を通じて広められたMVPは、世界中のハイパフォーマンスな開発チームを支える概念となりました。
Googleがこれほど長い期間IT業界にて絶対的な地位を維持できているのも、 Appleが世界で最も人気のある製品を世に送り出せたのも、Netflixが生き残れただけではなく旧来のDVD配送サービスのビジネスモデルを刷新して成長できたのも、全てに共通するのがMVPです。
では、MVPとは何でしょう？エリック・リースは次のように定義しています。
"That version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort."
「チームが最小限の労力で、最大量の顧客に関する有効で実証されたラーニングを収集できるプロダクトのバージョンである。」
これから明らかなように、MVPはプロダクトの一般公開に必要な最低限の機能を備えたバージョンのことではありません。というよりも、そもそもプロダクトを公開することとはまったく関係ありません。むしろ、MVPはプロダクトを開発するための科学的手法です。これは、ユーザー、プロダクト、ビジネスモデルに関する仮説を検証し、データに基づいたファクトを学習し、顧客のニーズを満たす要素を発見するメカニズムです。
MVPという用語を捨ててもOK
もし現場で混乱を招くようであれば、必要に応じてMVPという用語自体を捨てることも選択肢の一つです。ただし、その概念とマインドセットは必ず維持しましょう。
スラロームでは、プロダクト開発メソッドと戦略コンサルティング（ビジネスと組織モデルにアジャイルの原則と実践を組み込むアプローチの両方にMVPの概念を取り入れました。また、20を超える企業のデジタルトランスフォーメーション事例と数百のパートナーシップを経て得られた大きなラーニングとして、MVPなどの専門用語を強制しない方が簡単に目的を達成できる場合があることがわかりました。私達のクライアントには「Minimum Lovable Product」という用語に移行した企業もありますし、Spotifyのエンジニアリングカルチャーで知られている HenrikKniberg は、Earliest Testable、Earliest Usable、Earliest Lovable Products という用語の使用を提案しています。
アジャイルは特定の用語や方法論に関するものではなく、より幸せで生産的なチーム作りに関する原則と精神です。世にはびこる不明瞭で誤解を招くアジャイル論に対する私たちのアプローチは、用語そのものをスキップし、次の3つの質問を問うことです：
・なぜMVPをするのか？全ては基本的なアジャイルの原則である顧客満足、継続的な改善、そしてソリューションのシンプルさの達成に必要な【実証された学習】を迅速に達成するためです。
・私の組織でMVPを達成するためには何が必要か？これはひっかけ問題です。【何が必要か】より【どのような弊害やハードルが存在するのか】に注目しましょう。それは組織や構造的要因かもしれませんし、それ以外の要因（データ、テクノロジー、インフラ等）かもしれません。多くの場合、これらのブロッカーを洗い出すには組織横断的なステークホルダーとの協業が必要になります。
・MVPをしないとどうなるか？これもまた別のフレーミングが必要になります。【現状維持のコスト】に注目しましょう。これにより危機感が醸成され、新しい働き方に関するアライメントが生まれます。
現状維持のコストと危険性
あるクライアント企業は、200人を超える社内ユーザー向けソフトウェアのリリースに6か月を費やしました。従来のアプローチに則りチームは閉じこもって、開発とすべてのテストを完了し、その時点ではじめて少数のビジネスアナリストからのみフィードバックを求めました。実際のエンドユーザーを関与させないこの種の形式的な実証は、意味のある改善をプロダクトに与えるには遅すぎます。さらに、仮設の検証と学習に焦点を当てていない分、そもそもフィードバックを求めたとも言えない状態でした。
結果は目に見えていました。多くの時間とお金が既に費やされていたため、チームは前進を強いられ、中途半端なフィードバックセッションも実らず、リリース後は200人のユーザー全員がパフォーマンスの低さと使い勝手の悪さを訴え、ソフトウェアの導入と使用を拒否しました。6か月の期間と1,200万ドル（約12億円）以上を費やしたプロジェクトの結果は、事業部とITの避難合戦と指の差し合いでした。
ここで、プロジェクトの初期段階から実際のエンドユーザー向けににMVPを展開した場合を想像してください。開発チームは問題をすぐに把握し、実際のユーザーを巻き込みながらMVPを繰り返し改善し、プロダクトをリリースすることができます。さらに、テストに参加したユーザーは開発プロセスに関わりながら自らの時間を投資することにより、プロダクトのエバンジェリストにもなってくれます。
私達のプロジェクトは、まさにこのシナリオを実現することに成功しました。
こういった事例を何十件も目の当たりにしてきたからこそ、スラロームのプロダクト開発メソッドとデジタルトランスフォーメーション支援には、MVPの精神とオペレーティングモデルが強く根付いています。
= = = = =
あなたの組織は、アジャイル、DevOps、クラウド、顧客体験、イノベーションについてのビジネス課題をお持ちですか？アメリカの最新事例、ツール、ノウハウを使い、共にあなたの組織を変革しましょう。詳しくは tokyo@slalom.com まで。
= = = = =
スラローム・コンサルティングについて
スラロームは、戦略・アジャイル・クラウド・イノベーションに特化した、ハイペースで先進的な総合コンサルティングファームです。
私達の活動は、33ヶ所のオフィス、7つのビルドセンター、世界規模のコラボレーション文化と、トップテクノロジープロバイダーとのパートナーシップによって支えられています。
2001年に設立され、シアトルに本社を置くスラロームは、7,000人以上のコンサルタントと1,200社を超えるクライアントを抱える企業に成長しました。フォーチュン社の「働きがいのある企業ベスト100」などのランキングにも毎年名を連ねる、多様でインクルーシブな企業文化のあるコンサルティングファームです。