MVPとは「実用最小限の製品」という意味を持っており、Minimum Viable Productの略からそう呼ばれています。MVP開発は「ユーザーからのインサイトが得られる必要最小限の機能」を中心に実装し、素早く検証可能な状態を目指す開発手法のことをいいます。
MVP開発におけるプロジェクトマネージャーは、ユーザーの声を聞きながら検証・改善を繰り返す必要があります。ユーザーの声を全て反映していてはプロダクトの軸がぶれてしまうため、最終的なゴールをしっかりと認識しておくことが必要です。
MVP開発のキモは「機能を必要最低限に絞る」ことです。全ての機能を実装してリリースするのではなく、そのサービス・機能を必要とするユーザーがいるかどうかを正しく把握しながら進めていくため、ユーザーに受け入れられるコア機能を見極める必要があります。
MVP開発は素早くかつコンパクトにプロダクトを開発する手法です。そのため些細な改善でも即時に実行する必要があるため、少数精鋭の開発体制で臨むことが理想となります。要望・改善があった時に即座に対応できるスキルが求められるのです。
MVP開発では必要最低限のコア機能から実装を行うため、「そもそもそのコア機能が求められているのか」がダイレクトに分かります。さらに追加機能が必要であれば要望が出てくるはずなので、その声をプロダクトに反映することが可能になります。
コア機能の実装から求められる要素を追加していくMVP開発では、ユーザー側のニーズに対応して機能を追加していくため求められていない要素・機能を実装するような無駄な時間を省くことができます。
MVP開発はコア機能のみを実装しスピーディーにプロダクトを提供することができます。そのため、早期に新市場へ参入したり自ら市場を作り出すなど、スピード感を持って先行者利益を狙いにいくことができ、その上でユーザーの反応を見ながら追加していく対応が可能です。
MVP開発は思いついたアイデアをすぐに形にする開発手法ですが、規模の大きなプロジェクトや多くの機能を必要とするプロダクトには向いていません。リリースまで2か月以上を要する場合はMVP開発向きではない、といえるでしょう。できれば1か月程度、早ければ1週間から2週間程度でのリリースを目指すプロダクトが向いています。
大規模開発に導入されるようなウォーターフォール型の開発にも、MVP開発は向いていません。事前に要件定義・開発スケジュールをしっかりと決めてから進めるウォーターフォール型は開発が始まってから仕様変更がしづらく、MVP開発は根本的にプロセスが異なるため注意が必要です。
MVP開発の手順としてはここまで説明した通りですが、まずはじめに必要最小限の機能のみを実装したプロダクトを開発します。この必要最小限の機能のみを実装した状態からユーザーの反応・要望を踏まえて検証を行い、さらに追加・修正を施したもののユーザーの反応を得る、というように反応と検証を繰り返しながら開発を進めていく手法です。ユーザーが欲しいだろうと思われる機能を全て盛り込むのはNGとされており、「何を検証すべきか」を考えながら進めていく手法です。
MVP開発と通常の開発手法の違いは、短期間で検証を繰り返しながらスピーディーに開発を進めていく点です。通常は時間をかけて完成品を作り上げていくのに対し、MVP開発はコア機能のみを実装し、ユーザーからの反応を受けながらスピーディーに検証を行うことを重視します。
ペーパープロトタイプは手書きで作るワイヤーフレームのことをいいます。手書きのメリットはとにかくスピードが速いことですが、コピー・ペーストが容易なITツールも発達してきているため、昨今ではペーパープロトタイプを用いる事例も少なくなっています。
技術検証プロトタイプは、「技術的に実現可能かどうか」を検証するために作成するプロトタイプのことをいいます。実現したい要素や機能を実装・検証するにあたって、技術的な面で不安要素がある場合などに活用されることが多いプロトタイプです。
UIアニメはユーザー操作によってアニメーションが発生し、そのインタラクティブ性を検証する時に作成するプロトタイプです。静的MODELプロトタイプは「バックエンド通信をゼロにし、フロントエンドだけで何ができるか」を検証するためのプロトタイプです。
UIデザインを具現化したプロトタイプで、ターゲットユーザーにトンマナが受け入れられるかなどデザインを中心に検証を進めたい場合にUIデザインプロトタイプを作成します。検証・改良を経ることにより、よりユーザーのデザインに合うデザインへと近づけていけます。