MVPリリース後の改善プロセス

第1回記事では新規事業アイディアを立案するときに役立つフレームワークのご紹介、第2回記事ではユーザーインタビューとMVP開発についてご紹介しました。

今回は、MVP開発したプロダクトの改善プロセスを紹介します。そして、連載最後の次回記事では、PMF達成プロセスを紹介していきます。

MVPの復習

MVPを簡単に振り返ります。MVPとはMinimum Viable Productの略で、顧客の問題解決もしくは価値を提供できる最小限のプロダクトのことです。最小限のプロダクトにし、価値や問題解決をし得るコア機能のみをスピーディーに開発することで、時間と開発リソース、予算を最小限にすることが可能になります。そして、そこから得るフィードバックをもとに機能改善や機能拡充をしていきます。

プロダクト改善で役立つツール

プロダクトの改善を進めていく上で非常に役立つツールを2つ紹介します。当社ではこの2つのツールを組み合わせて、プロダクト改善管理をしています。

1.Trello

• Trelloイメージ

Trelloはプロジェクトとタスクをカンバンボードで管理するオンラインツールです。

私たちは横にタスクのステータス、縦に優先度が高いタスクごとにカードを設置しています。特にどのタスクが優先度高なのかをカンバン形式で可視化できるので、エンジニアチームがどのタスクから改善しなければならないのかがひと目でわかります。ただ、弱点はエンジニアチームの開発ベロシティ（決められた期間でどれだけの量の開発量を達成できたのかの数値）の管理が難しい点です。

この点を補うのが、

2.Backlog

• Backlogイメージ

Backlogも同様にプロジェクト管理オンラインツールです。

私達はBacklogで特定タスクに関するコミュニケーションのやりとり、また、マイルストーン（アプリバージョンごとに期間を設定したり、2週間ごとに期間を設定）ごとに管理したり、各エンジニアが合意した開発時間でタスクを完了しているかどうかのベロシティを図ることができます。このベロシティの数値によって、開発時間の見積もりが正しいのか、各エンジニアに正しく、タスクを振り分けられているのか、開発責任者がサポートすべきタスクを把握しやすくなります。ただ、弱点は優先度が高、中、小しか設定できず、高の中でもどれが最も優先度が高いのか、そして、BacklogもTrelloのようにカンバン形式でタスクを表示できるが、自由にそのカードを優先度が高い順に並び替えができません。

両ツールとも強みと弱みがあるので、当社ではこの2つを組み合わせて、プロダクト改善をするためのタスクを見える化しています。

プロダクトの改善数字検証ツール

• 数字検証ツールイメージ

さまざまなプロダクトの数字検証を把握するツールがありますが、代表的なものとして、WebはGoogle Analytics、アプリはFirebaseの2点は無償で使えて、一通りプロダクトの数字検証ができます。そして、これらのツールを活用している人が多いので、Webで検索するとさまざまな使い方や躓いたときに問題解決方法を紹介しています。特にPMF達成前に高額な数字検証ツールを導入する必要もありません。

プロダクト改善のための仮設検証

• KPIによるプロダクト改善

プロダクトを改善していく上で、仮設をたて、その仮設を検証し、効果があったか否かを数字でチェックしながら改善を進めていきます。　

MVPの解説でも記載したとおり、お客様の問題解決もしくは価値を提供できる最も近道をとるべきです。そこで重要なのが、数字で検証できる仮設をたてることと、どの仮設から検証すべきかが重要です。

数字で検証できるようにするためには、重要KPIを設定することが必要です。そして、どの仮設から検証すべきかもこの重要KPIをもとに、優先度をつけることができます。提供しているサービス・プロダクトをご利用することで、顧客の問題解決もしくは価値を提供できているポイントでKPIを設定します。

当社の事例をもとに解説をしていきます。

当社が手掛けているSmartMartのご提供したい価値は30分、顧客の手元に商品を届けすることです。顧客のステップとしては、どこかでユーザー登録もしくはログインをさせ、注文したい商品をカートにいれ、決済情報入力もしくは選択、配達日時選択、注文を完了し、私達が30分で商品をお届けすることです。プロダクト改善で設定しているKPIは注文完了のコンバージョン率（CVR）の改善（離脱ポイントの改善）です。

また、私達のビジネスモデルの場合、プロダクト以外に重要なKPIとして顧客が注文完了してから何分で私達が手元に商品を届けられるのか、配達拠点からどのエリアまで、30分以内に届けられるのかを検証していくのも重要です。

そして、もう一つ私達が改善しなければならない点は、顧客への認知拡大です。この配達最適化と認知拡大に関しては、次回のPMF達成で詳しく事例をもとに解説していきます。

事例からみるプロダクト改善：注文完了のコンバージョン率の改善

前記したとおり、私達のプロダクトでユーザーフローはどこかでユーザー登録もしくはログインをさせ、注文したい商品をカートにいれ、決済情報入力もしくは選択、配達日時選択、注文を完了し、私達が30分で商品をお届けすることです。

1つプロダクトの改善ポイントとして、ユーザー登録をどのステップでさせるかを改善させることで、注文完了率を向上させています。

現時点でユーザーが注文までにインプットが必要な情報として名前、メールアドレス、パスワード、そして携帯番号（SMSによる認証）、決済情報、お届け日時情報、お届け先住所です。ご覧の通り、顧客のインプット量が多いです。このインプットをユーザー登録時にさせるのか、それとも注文の過程でインプットするステップを分けるべきかを検証しています。

お届日時情報ですが、これは毎回注文ごとに異なるため、ユーザー登録時には不要ですので、お買い物途中で選択してもらうことにしました。それ以外のインプットとして、決済情報、お届け先住所、この2点はご注文したいという欲求が高まったときにインプットさせた方が途中離脱が少なくなりました。特に注文プロセスの早いタイミングで、まだお買い物するかどうか、ユーザーが迷っている段階で決済情報とお届け先情報の入力を求められると、離脱が多く出ました。

残りのお名前、メールアドレス、パスワード、そして携帯番号のインプット、これらを1つのステップですべて行わせたほうが離脱は少なくなりました。理由はユーザーがさまざまな他サービスのユーザー登録でこれらの情報をまとめてインプットすることが多く、自然だったためです。

そして、一番多くの仮説検証が必要だったのが、このユーザー登録をどのステップでさせるかでした。具体的にアプリ起動時、商品が並んでいるTOPから特定商品をカートにいれるタイミング、カートから次のステップに進むタイミングの3案をユーザー離脱率が最も低くなるかを検証しました。

結果として、TOPから特定商品をカートにいれようとしたタイミングでユーザー登録をさせることが最も離脱率を低くすることができました。ユーザーの心理として、どんな商品が販売しているのか把握する前にお買い物するかまだ決めかねている中、ユーザー登録をさせるのは負担が大きいですし、すべてカートに注文する商品をいれてから、さらにユーザー登録しないと次に進めないのかという心理的なハードルが原因で離脱率が増えたのではないかと結果を推測しています。

次に現在もまだ検証途中ですが、再注文時の購入率を改善するために、カートのステップ後に住所選択、お届け日時選択、決済選択し、最終注文確認を踏ませてから注文完了させるべきか、カートページにすべての情報のインプットを必須にし、前注文時の住所、決済が入力された状態にし、最後にお届け日時を選択して、注文完了させるべきか、どちらが改善するかを検証しています。私達の仮設としては、クリック数やステップを減らしたほうが購入率は向上するため、後者の方が改善するのではと考え、検証をしています。

今回はMVPリリース後の改善プロセスをご紹介しました。

改善プロセスには優先すべき改善ポイントの発掘とスピードが重要です。顧客の問題解決もしくは価値を提供できる最も近道の改善ポイントはどこなのか、そして、その改善をどれだけ早く、多くの検証をするかが大事です。私達はマイルストーンの単位を基本的に２週間にしています。シリコンバレーに拠点をおいているテック系企業はそれよりも早く１週間にしているところもあります。スピードは改善を繰り返していくと組織にナレッジがたまり、スピードアップしていきますので、最初は時間を要しても落胆せずに、繰り返していくことがポイントです。

次回は最終回です。PMF達成プロセスをご紹介します。