エムスリーテックブログ

エムスリー(m3)のエンジニア・開発メンバーによる技術ブログです

既存サービスをアプリ化する上でのプロダクトマネジメントの勘所

こんにちは。エムスリーエンジニアリンググループ、プロダクトマネージャーの中村です。

先日、「アスクドクターズ」というオンライン医師相談サービスのアプリ版をリリースしました。エムスリーでは珍しく、一般ユーザーが利用できるサービスです。ぜひダウンロードしてみてください。

AskDoctors

AskDoctors

  • M3, Inc.
  • ヘルスケア/フィットネス
  • 無料
apps.apple.com

play.google.com

今回のブログでは、アスクドクターズのアプリ開発を通じて学んだ、既存サービスをアプリ化する上でのプロダクトマネジメントの勘所についてまとめます。

f:id:kananakamu:20201111154037p:plain

はじめに

「アスクドクターズ」は、エムスリーが運営する日本最大級のオンライン医師相談サービスです。 2005年にサービスを開始し、250万症例のQ&Aがストックされています。

アスクドクターズは、今までWeb版のみでサービスを提供していましたが、コンシューマ領域におけるオンライン医療サービスの需要の高まりを受け、アプリ開発プロジェクトが始動することになりました。

今回のプロジェクトは、メインPdMをVPoE兼プロダクトマネージャーである山崎が担当し、私はアシスタントPdMというPdM二人体制で進めることとなりました。

この体制を取る狙いは、山崎のプロダクトマネジメント術を実戦形式で学び、プロダクトマネージャーとしてレベルアップすることにありました。

実際にどんな学びがあったのか、ブログにまとめることで振り返っていきたいと思います。お付き合いいただけますと幸いです。

ちなみに、山崎については以下の記事をご覧ください。

eng.kandc.com

プロジェクトのプロセス

まずは読者の方に、全体のイメージを把握していただくために、ざっとどのようなプロセス、時間軸で進めていったかを説明します。

企画の立ち上げ~製品の発見:2ヶ月

f:id:kananakamu:20201006105436p:plain

まず、PRD*1を作成し、ペーパープロトタイプを作成したうえで、インタビューを実施しました。1回目のインタビュー結果を踏まえペーパープロトタイプを更新した後、2回目のインタビューを実施しています。2回目のインタビュー結果を受け1stリリースのスコープが固まったので、プロダクトバックログを作成しました。

製品の開発~リリース:3ヶ月

約2ヶ月で開発した後、オープンベータ版を社内ユーザーに先行利用してもらい、不具合の検出を経て、Android版を正式リリースしました。

※iOSアプリはその後アプリ内課金の追加対応を行いました。

学んだこと

スコープを絞る

既存サービスをアプリ化するときに重要なのが、1stリリースのスコープをどこまでにするか、です。

Web版の良いとこどりをしようとスコープが広がったり、Web版には無い新たな価値を作ろうと考え始めたり…というのは陥りがちな罠ではないでしょうか。

実は、上記は、最初にPRDを書き始めた時に私が陥ったことでした。

それに対し、山崎からは「既存サービスの価値をアプリにより最大化しよう」とフィードバックがありました。

その結果、1stリリースのスコープは「アスクドクターズが既にユーザーに提供している『いつでも医師に相談ができる』という価値にフォーカスし、そこにPush通知を掛け合わせ、『医師から回答が来たらすぐに分かる』という価値を追加することで、質問体験を向上させること」となりました。

インタビューで更にスコープを絞る

上記のアプリの価値を検証するために、開発を始める前に、ペーパープロトタイプを活用したインタビューを行いました。

f:id:kananakamu:20200930214828p:plain
最初のペーパープロトタイプです。

実際に、このペーパープロトタイプをユーザーに見てもらい、アプリを利用したいか、Webより便利かどうかを聞きました。

ユーザーの反応としては「アプリで使いたいと思っていた」「通知が便利」というポジティブなものだったため、大きく外すことは無いだろうという確信が持てました。

また、1度目の検証の後、山崎から「1stリリースのスコープはもっと絞れるのでは?」というフィードバックがあり、さらにスコープを絞ったペーパープロトタイプを作成し、再度ユーザーインタビューで検証しました。

f:id:kananakamu:20200930214916p:plain
スコープを絞ったプロトタイプです。ステップ数がVer.1に比べ1ステップ増えているのは、検証する体験を見直したためです。

具体的には、ボトムナビゲーションバーから「お知らせ」を削りました。当初「お知らせ」画面には、医師からの回答通知を表示する予定でしたが、ペーパープロトタイプVer.2では、マイページに集約しました。

Ver.1からVer.2の変更点は、以下の図をご参照ください。

f:id:kananakamu:20201111175834p:plain

インタビューの結果、「お知らせ」を削ったことで、MVPの価値を損なわないことが確認でき、1stリリースのスコープが確定しました。

ペーパープロトタイプは雑に作る

ペーパープロトタイピングに関して学んだこととして、ペーパープロトタイプは手書きで作ること、そして作りこまないことです。

ペーパープロトタイプを作る目的は、体験を可視化することです。 そのため、この段階で画面を作りこむ必要はありません。伝えたい相手に伝わればOKなのです。

誤解を恐れずに言うと「雑」に書くことです。

丁寧に書くと、それだけ時間がかかりますし、一度書いたものを変更するのが億劫になるからです。

(ちなみに、私の場合は自分が思っている以上に「雑」に書いても、開発チームには十分伝わりました)

手書きプロトタイピングによって、「開発チームに共有し、フィードバックをもらって、改善する」というサイクルをスピーディに回せるようになりました。

まとめ

今回のブログでは、山崎を師匠としてアスクドクターズのアプリ開発プロジェクトを進める中で学んだことを振り返りました。

具体的には以下3点を学びました。

  • スコープを絞る
  • インタビューで更にスコープを絞る
  • ペーパープロトタイプは雑に作る

今回、山崎の仕事の進め方を体験したことで感じた自分自身のプロダクトマネジメントとの最大の違いは、スピード感でした。

なぜスピード感に圧倒的な違いが生じているかを考えると、山崎は徹底してプロダクトの価値にフォーカスし、素早く検証を行っていることに気が付きました。

この「スコープを絞って早くリリースし、スピーディに学びのサイクルを回していく」という点が、プロダクトマネージャーとしての自分自身の今後の伸び代だと感じています。今回の学びを活かし、更に成長していきたいです!

We’re Hiring

エムスリーではテクノロジーを活用して医療業界を変えるプロダクト作りに取り組んでいます。 エンジニア、プロダクトマネージャー、プロダクトデザイナーを絶賛募集中です。

jobs.m3.com

*1:Product Requirements Documentの略です。参考になるブログのリンクを掲載させていただきます。 初めて書くPRD(プロダクト要求仕様書)|櫛田 瑞穂|note