こんにちは。Quipper採用担当の鈴木です。今回の記事は、PMの@haruhiko-tanoによる「ユーザーに求められるプロダクトをムダなく作る方法 〜スタサプ新サービスをリーンに開発した話〜」です!是非、ご覧ください!
こんにちは、QuipperのPMの haruhiko-tano です。
2019年4月にスタディサプリの新サービスである 中学生向け個別指導コースをリリースしました。
今回はMVP(実用最低限の商品)を使ったリーンなプロダクト開発にチャレンジしたので、そのプロセスを紹介したいと思います。
ムダなものを極力作らない。リーンスタートアップとは
リーンスタートアップとは実用最低限の商品(MVP)を早期に市場に投入し、ムダなく顧客に価値のあるものを最速で提供していくための方法論です
- ユーザーに対するMVPの提供
- 定量、定性での計測
- 計測による学び
というサイクルを回していくことで、思い込みでムダなものを作るリスクを排除し、最低限の工数で成功確度の高いプロダクトを開発していくことを目指した手法です。
個別指導コースにおけるリーンな開発プロセス
個別指導コースは企画がある程度固まったところから、7ヶ月ほどでプロダクト開発をしてリリースしました。
進め方としては、まずユーザーストーリーベースで全体像を設計して、細部の要件に関しては、仮説を立ててMVPを用いたユーザーテストで検証しながら進めました。
ユーザーテストは実際に大学生コーチを用意して、数ヶ月間モニターとして実際の中学生に協力してもらい、実際にコーチとやり取りしながら進めました。
この時にMVPを用いた高速な検証をしたかったので、 動画に関してはスタサプで元々あったものを利用していますが、他のシステム開発が必要な部分は全て、既存のサービスと手運用を使って行いました。
例えばスタサプ内で行う生徒とコーチのチャットは、Google Hangoutを代用として検証を行いました。
実際の製品 - スタディサプリでの神授業 - コーチとチャットできる機能(採点や最適なコーチを選ぶバックエンドあり) - プロフィールや申込み導線などの周辺機能
ユーザーテストで利用したMVP - スタディサプリの神授業 - Google Hangout - Google Spreadsheet
これによりほぼシステム開発なしでMVPをユーザーに使ってもらうことができ、実際に使ってもらって検証した内容をもとに、プロダクトの細部の要件を決めることが可能になりました。
特にプロダクト開発に影響を及ぼした仮説検証を2つほど紹介します。
私立、中高一貫校の学生をターゲットにするかどうか
個別指導コースでは、授業の進度に合わせた学習計画を毎週コーチが作成します。提示された学習計画をもとに中学生は、スタサプの教科書対応の講義動画を見て学習していきます。
公立中学は基本的に教科書通りに授業は進んでいくため、ある程度テンプレ化できるのですが、私立、中高一貫校に関しては学校ごとの独自のカリキュラムで進んでいくため、個別の対応が必要になります。
当初は私立、中高一貫用の生徒を集中させた大学生コーチを用意すれば対応可能と思っていたのですが、実際に検証してみた結果、学校ごとに
- 進み方
- 速度
- 教材
が本当にバラバラで現状の体制、講義動画では十分なクオリティを提供できないことがわかってきました。
検証結果をもとに、初期リリース時は公立限定としてリリースすることを決めました
ユーザーに個別最適化された学習計画を届けるために必要な情報とヒアリング方法
個別指導コースでは、ユーザーの勉強可能な時間など個別の学習状況に合わせた学習プランを提供しています。
最適な学習プランを提示するために必要な情報は何か?、どのようにヒアリングすべきか?を ユーザーテストの中で実験してみました
最初の仮説では
- 何曜日にどれくらい勉強可能かは中学生はわからず、入力できないだろう。部活や塾の日を入力してもらって、そこから推測、徐々に最適化していくのがいいのでは
- 必要な情報はチャット上で聞けばいいのでは
と思っていましたが、実際にユーザーテストをやってみた結果
- そもそも1日に学習可能な時間が30分、1時間くらいの単位でわからないと、どの講義をどれくらい見てほしいか最適な学習プランが作れない。最適でないものを送ってもほとんどの生徒がやらない
- 勉強可能な時間は意外と中学生は正しく入力できる。なおかつしっかりそれを守っている
- チャット上だと、レスポンスが途切れ途切れになってしまい、学習プランを作るまでに数日かかってしまう
ということがわかりました。
検証結果をもとに、初回ログイン時に学習計画を作るのに必要な項目を入力するアンケートの機能を優先度を上げて開発しました。
リリース後も初回アンケート回答ユーザーは、無料期間終了後の継続率が非常に高く、強い相関が見られる結果が出ています。
おわりに
上記を実践して
- 思い込みで仕様を決めない。MVPで仮説検証をする
- リスクの高い仮説があるものは、検証できるまで可能な限り開発を後ろ倒しする
- 仮説検証結果はチーム全体で共有、議論する
と、フルスロットルで開発しつつも、検証結果によるピボットに柔軟に対応できるプロセスが実現できたと思います。
QuipperではこのようにBiz、PM、Devが一丸となってプロダクトを作っていける環境があります。
(リリース後はリリースまでの約半年間のタイムラインをステークホルダー全員で振り返りました)
少しでも興味持っていただいた方は気軽にお話できればと思います。