試行錯誤の世界では、最も早くエラーを見つけることができた人が勝ちます。 このアプローチを「フェイルファスト」と呼ぶ人もいます。 エリック・リースはこれを「リーン」と呼び、ケント・ベックや他のソフトウェア開発者はこれを「アジャイル」と呼びました。
どのように呼ぶにせよ、ポイントは、実際のユーザーからできるだけ早くフィードバックを得ることで、製品に関するどの前提が間違っているかを見つけることなのです。
アジャイルな方法論は、製品開発をスプリントに分割することを前提としており、それによってリスクを減らし、必要な変更に迅速に対応することができる。
アジャイル方法論は、顧客フィードバックに基づく反復プロセスの考えに基づいて構築されているため、MVPはアジャイル開発において中心的な役割を果たす。
MVP (Minimum Viable Product) の構築は、早期採用者を満足させるのに十分な機能を備えた新製品を提供し、貴重なフィードバックを得て、後に完全な機能セットを構築するのに役立ちます。
MVP の概念は、製品の生存能力をチェックするためにソフトウェア産業で主に実施されている。
今日のソフトウェアの大部分は、アジャイル方法論を使用して開発されています。 アジャイル環境では、MVP（minimum viable product）というフレーズをよく耳にします。
この用語は簡単に言うと、「ターゲット顧客のほとんどにとって十分に機会に対処し、市場と製品を検証するために構築できる最も最小限の機能を備えたもの」という意味です。
言い換えると、顧客に達成させようとしている中核的な機能について考える場合、その目標を達成させるために構築できる最もシンプルな製品は何でしょうか。 アプリの中核的な機能は、読者に情報を提供することでしょう。 そのため、最も簡単に構築できる製品は、ニュースの見出しのリストと更新ボタンになるでしょう。
繰り返しになりますが、MVPを成功させる鍵は、アプリの追加機能の構築に時間を費やすのではなく、新鮮なニュースというアプリが提供する中核価値に焦点を当てることです。
MVPは、製品が悪いものであるべきという意味ではないことに注意してください。 真実は、それが行うことに非常に優れているべきだが、いくつかの中核機能のみを行うことに集中すべきであるということです。
一言で言えば、MVPの主な特徴は次のとおりです。
- 人々が最初にそれを使用するか購入することを望むほどの価値がある
- 早期採用者を維持するために十分な将来の利益を示す
- 将来の開発を導くためのフィードバックループがある
なぜMVPを開発するのにアジャイル手法を使用すべきですか。
アジャイルと他の方法論の重要な差別化要因は、アジャイルがMVPを活用することです。 アジャイルアプローチでは、できる限りシンプルなものを作り、顧客がそれをどのように使うかについてデータを集め、必要であれば製品を改良します。
これによって、顧客が気にしないものを作って時間を浪費するのではなく、顧客が必要とし、使用する機能だけを作って、非常に効果的に作業することができます。 他のアプローチを使用すると、想像しうるすべての機能を備えた「完璧な」製品を構築しようと多くの時間を費やすことになるかもしれませんが、いったんそれが現実の世界に出てしまうと、顧客は自分が考えていた機能の半分も使っていないことに気づきます。 Dropbox
Drew Houston 氏 – Dropbox の CEO は、クラウド ストレージ スタートアップの MVP を動画の形で作成することにしました。
彼らは説明ビデオを作成し、それをネットワークで共有して、人々の反応を測定しました。 3分間のビデオは、Dropboxが何であるかを説明し、それがどのように人々を助けるかを実演しました。
ビデオを公開した後、同社は「早期アクセス」のサインアップを一晩で5,000人から75,000人に増やしましたが、これはすべて実際の製品を持っていない状態でのことでした。
つまり、MVP を構築する (アジャイル) 主な利点は次のとおりです:
- Initial Consumer Research
製品がターゲット ユーザーに早く届くほど、フィードバックを得て顧客の課題または好みを分析するのも速くなります。 もしユーザーがMVPに価値を見いだせなければ、ピボットして他の価値提案をテストするスペースがあります。
あるいは、逆の場合は、開発した機能がターゲット顧客にとって有用であることを確認し、前進することができます。
- Testing Stage
MVPを開発する最大のメリットは、さまざまなビジネスモデルやコンセプトをテストできることです。
機能偏重の製品とは異なり、MVPがローンチされると、どのようなソーシャルグループが最もアクティブなユーザーで、彼らがどのように製品と関わり、どのようにマネタイズできるかを特定する能力が得られます。
- Cost Efficiency
高品質の製品は、何年もの開発の結果であり、適切な価格設定がされています。 しかし、これらの製品はより長い期間をかけて反復して作られたものであるため、コストは時間と共に分散されます。
MVP のアプローチも、製品が複雑になりすぎるのを防ぐことで、節約につながります。
アジャイルおよびSCRUMの方法論についてもっと学びたいのであれば、SCRUM Instituteによる、詳細なステップバイステップのプロセスでSCRUMマスターになる方法についてのこの記事をチェックすることをお勧めします。
MVPを構築するプロセス（アジャイル）
さて、MVPとは何か、なぜアジャイルで使われるのか、その利点は何か、がわかったところで、MVPの構築に必要な6つのステップを見てみましょう。
ステップ1: どのような問題を誰のために解決するのかを特定する
新製品のバージョンを開発するとき、ほとんどの人は、解決しようとしている問題を定義し、それらの問題がなぜ重要であるかを明確にすることに十分な厳密さを持ち合わせません。 このプロセスがないと、製品は機会を逃し、資源を浪費することになりかねません。 だからこそ、正しい問題に取り組むために、正しい質問をすることができるようになる必要があるのです。
製品のアイデアを見て、自分自身に問いかけてみましょう：
- ターゲットユーザーは誰ですか？
この段階で行き詰まった場合は、自分の個人的課題を特定するようにしてください。 適切なツールがあれば、もっとうまくできることはないでしょうか。
- ターゲット層はなぜこの製品を必要としているのか？
これにより、製品の主目的と潜在顧客のニーズに対するソリューションを特定できます。
- どんな状況でそれを使用するのか？
ソース。 Metabeta
注意: 上記の質問に対する答えを特定する過程では、すべてを現実的にし、さらに時間とコストの見積もりを行うことが重要です。
ステップ 2: 競合他社の分析
自分が解決する問題を把握したら、次は他の企業がこの問題をどう解決しているか、少なくともそれを解決しようとしているかを確認します。 この時点で、市場に類似の製品がある場合は、競合他社の分析を行う必要があることは明らかです。
また、直接の競合相手がいないと思う場合でも、製品の独自性に対する信頼が、自信を持って製品を市場に投入する根拠になることを覚えておく必要があります。
Step #3: ユーザー フローの定義、ワイヤーフレーム & デザイン
将来の製品のユーザー フローを定義するには、主要な目標に直接焦点を合わせる必要があります。 主なユーザー フローを定義するために、まずプロセス段階を定義する必要がありますが、これは実際に簡単です。なぜなら、製品の主な目標に到達するために必要な手順を説明するだけでよいからです。
この時点では、機能について考えるのではなく、エンドユーザーが製品を使用するときに持つ目標の種類、彼らの期待など、基本的なタスクに焦点を当てる必要があります。 ワイヤーフレームは、どのようなインターフェイス要素が重要なページに配置されるかを明確にしたレイアウトです。
ワイヤーフレームの例:
ユーザー インターフェイス (UI) の設計では、インタラクション デザイン、視覚デザイン、情報アーキテクチャの概念をまとめます。 ここでは、エンド ユーザーに驚きと喜びを与えるエクスペリエンスを作成するために、前のフェーズで学んだことを生かす必要があります。 ユーザー テストは、新しいアプリを成功させるために不可欠です。 ユーザー テストの結果が準備できたら、ワイヤーフレームを繰り返し作成し、ユーザーに対して再テストを行います。
ワイヤーフレームがテストされたら、各プラットフォーム (iOS、Android、Web など) で異なる設計フェーズに進みます。
Step #4: 機能の分析
45% 以上のソフトウェア製品内蔵機能がほとんど使われていないことをご存知ですか?
ユーザー フローを作成したので、統計情報を念頭に置きながら、各ステージでより詳細な機能のリストを作成することができます。
各ステージに対する機能をレイアウトしたら、優先順位をつける必要があります。 ユーザーに完了させたい最も重要なアクションは何でしょうか。
機能の優先順位付けの方法の1つに、MoSCoWというものがあります。 機能の必要性を測定するために使用される別の手法は、ビジネス価値（開発に要する時間 vs. 持っていると便利なもの vs. コスト）に基づきます
ソース。 ProductPlan
Step #5: 開発 & テスト
MVP (minimum viable product) の機能がわかったので、次はそれを実践する番である。 開発段階に移行すると、製品をテストし、その品質を向上させるために取り組む必要があります。
ワイヤーフレームの承認後、セットアップ アーキテクチャ、データベース、および API、管理、およびすべてのバックエンドの開発を開始する必要があります。
異なるシナリオで製品のパフォーマンスをテストする最も人気のある方法の一部としてアルファおよびベータ テストがここで役に立ちます。 テストを調整し、ユーザー エクスペリエンス全体に影響を与える変更のみを行うようにします。
標準として、アプリを起動する前に、制御された環境で次のテストを実装する必要があります。
- 機能テスト
- ユーザビリティテスト
- 互換性テスト
- 群集テスト
- インターフェーステスト
- パフォーマンステスト
- セキュリティテスト
開発プロセス中、実装したすべての機能について継続してテストする必要があります。
たとえば、ここ Cleevio ではモバイル アプリを構築しており、ベータ版のビルドのリリースは、Google のアルファ/ベータ テストおよび Apple の TestFlight にアップロードされています。 内部テスト ビルドは、Appcenter (Microsoft による公式ツール) にあります。
「リリース候補」（市場に出す準備ができた製品）の準備ができたら、オープンまたはクローズド ベータ テストを実施します。 この時点で、市場投入を早めるためにスタートアップ資金を調達するか、失敗するかです。
モバイル アプリの場合、通常は、MVP を AppStore と Google Play にリリースするときに「ソフト ローンチ」を行いますが、この時点ではアプリのマーケティングは一切推奨していません。
アプリのユーザー数が増えるにつれて、いくつかのバグが発生することがありますが、早急にすべてを修正するようにしています。 通常、1 日おきに新しいビルドをリリースしています。 アプリが安定し、クラッシュのないユーザー率が99.9%以上になったら、マーケティングを開始し、より多くのユーザーを獲得することをお勧めします。
データは本当に重要なので、MixpanelやGoogle Firebaseアナリティクスでユーザーの行動を監視して、ユーザーが実際にどのようにアプリを使用しているかを理解することをお勧めします。
製品の開発に終わりはありません。 非常に重要なのは、ユーザーからのフィードバックを求め、製品を繰り返し使用することです。 ユーザーが増えたら、A/Bテストを実施して、さまざまなソリューションをテストできるようにし、ユーザーエンゲージメントを高めるのです。 結論
Cleevio では、過去 10 年間で 120 以上の MVP を開発してきましたので、十分な経験があり、どの MVP がスケールし、どれが燃えて死んでしまうかを知っています。
MVP のアイデアのためにロードマップ、ドキュメント、ワイヤーフレームを準備するのは少し大変だと思いますので、お気軽にご連絡ください。