２つの新規事業立ち上げで経験したタイプ別MVP検証の進め方
この記事は MICIN Advent Calendar 2022 の23日目の記事です。
前回は高橋さんの医療分野のセキュリティニュース総まとめ 2022でした。
はじめまして。MICINで医療機関向け、薬局向け事業・サービスの担当をしている熊沢です。前職含めて数回新規事業の立ち上げに携わっており、MICINでも複数のプロダクトの新規立ち上げに携わっています。その中で気づいた”MVP（Minimum Viable Product）”での検証の違いについてお話いたします。
まず、私の自己紹介から。
MICINにはまだ20人ほどのころからジョインをしており、前職はリクルートという会社で複数の新規事業に携わり、自ら起案したサービスも事業化をしてその責任者をしていました。その中で経験した成功・失敗、教えてもらったことを元にMICINでの新規事業開発をしています。
リクルートさんの新規事業開発プロセスについて興味ある方は下記の記事をご参照ください。
リクルート流･新規事業｢最短距離で育てる方法｣ | リクルート | 東洋経済オンライン
本記事では「curonお薬サポート」「Karin by MICIN」という2つのサービスの立ち上げ時のプロセスを比較する中でMVPによる検証のアプローチを比較してみようと思います。
はじめに：MVPによる検証とは
そもそもMVPって
MVP（Minimum Viable Product）とは、顧客に価値を提供できる最小限のプロダクトのことを指します。
完璧な製品・サービスを目指すのではなく、顧客が抱える課題を解決できる最低限の状態で提供します。
ただし、MVPの「P」はProductですが、プロトタイプであって市場投入される製品のことではないとされています。
検証におけるポイント
リスクには最後ではなく最初に取り組む
下記にあるリスクを最初に潰しておくためにMVPによる検証を行います。
価値のリスク：顧客が購入するか
ユーザビリティのリスク：ユーザーが使い方をわかるか
実現可能性のリスク：必要なものが作れるか
事業実現性のリスク：ビジネスの問題がないか
プロダクト立ち上げのフェーズに合わせて考える
新規のプロダクト開発はIdea→CPF（Customer Problem Fit）→PSF（Problem Solution Fit）→PMF（Product Market Fit）というプロセスをたどりますが、MVPはどのフェーズの何を検証したいかによって作るものが変わります。CPFでは課題・ニーズが存在すること、PSFではプロダクトが課題解決をしてニーズを満たすことを検証する必要があります。検証したいことが何かを明確にして、それぞれにあったあプローチをとることが求められます。
作る前に検証できる「営業チラシ」が超重要
前職では新規事業を考える際の構想中のサービスの仮の営業資料のことを「営業チラシ」と呼んでいました。営業資料には解決する課題、提供価値、サービス内容が含まれているはずで、これを作成することでプロダクトの内容がシャープになります。作成してみてイマイチだと思うのであれば、それはまだ企画が練れていないため、リーンキャンバスからやり直します。
営業チラシができたら、顧客にさもそのサービスがあるかのように提案をすることで、顧客から生のフィードバックを得ることができ、一切プロダクトの実装をすることなく、多くのことを学習することができます。
curonお薬サポートの開発
curonお薬サポートとは
curon（クロン）
オンライン服薬指導機能を始め、薬局と患者さんがオンラインでつながるサービスです。
curonお薬サポート立ち上げの経緯
まず立ち上げのきっかけとなったのは2020年2月28日、コロナ禍の特例措置として処方箋の原本がなくても医療機関からのFAXにより薬局で服薬指導（薬剤師による患者への薬の服用についての説明・指導）を受けて薬を受け取ることが可能になり、その一報を受けてMICINの一部有志が自発的にサービス開発を開始したところから始まります。
その機能は数人で3日間で開発されてリリースされ、いきなり数千店舗の薬局にサービス提供を開始することになりました。
その後、9月に解禁されるはずだったオンライン服薬指導は4月に前倒しされることになり、そこに合わせてα版をリリース、9月の正式な法改正の施行に合わせて正式版としてオンライン服薬指導サービスを世の中に出していきます。
外部環境が予想外のスピードで激変する中、顧客である薬局からのニーズは急激に高まり、それに合わせて複数の競合も立ち上がり、スピードもユーザビリティも譲れない、そして医療の領域として品質も担保しなければいけない状況の中、α、β、正式版と、ステップを踏んでリリース。結果的にはサービス開始から1年で5000を超える薬局で使われるサービスになりました。
サービスリリースのプロセス
時間もリソースも限られる中、まだ誰も体験したことのない「オンライン服薬指導」のサービスを顧客のニーズに合わせて、競合よりも早く良いものを提供する必要があります。そこでの開発プロセスは聞いてから作るのではなく、聞きながらつくるでした。
プロセスとしては
サービスの機能全体像を描く
営業資料に落とす
営業資料ベースでヒアリングして優先順位を固める
優先順位の高いものからFigmaで要件を詳細化
Figmaベースでヒアリングをして要件を確認
実装→リリース
4〜6を繰り返す
ポイントになったところ
機能群を大きく三分割して段階リリース
機能の全体としては、処方箋FAX、決済、医薬品配送、オンライン服薬指導（予約、問診、ビデオ通話）がありますが、
サービス全体像
全てを開発してからリリースをするのでは遅くなってしまうため、α・β・正式版とフェーズを分け、価値提供が可能になったものを順次リリースして早く市場に投入することで、プロダクトの学習と顧客開拓を前倒しできるようにしました。
機能リリースステップ
ビデオ通話を後ろ倒し
一番初期のα版のリリースではオンライン服薬指導のサービスでは必須のはずのビデオ通話を後回しにしています。
営業資料ベースでヒアリングを進める上で、コロナ禍で薬局の喫緊の課題となっていたのは決済と配送の業務でした。感染拡大を防ぐため、患者は通院をせず電話での診療・服薬指導が行われ医薬品を薬局が配送するオペレーションが既に敷かれていました。その際、薬局への支払いは銀行振り込みが主流で、せっかく自宅で診療から薬の受け取りまでができているのに、わざわざ外出して振り込みをする必要がありました。また、医薬品の配送は薬剤師にとって追加業務として負担になっていました。
そこで、薬局の現場で課題となっている患者管理・決済・医薬品配送の機能だけでリリース。オンラインで患者と会話をする部分は電話で代替をしてもらうようにしました。
結果、顧客からは「現場のことをよくわかっている」との声をいただき、開発者の思い込みで優先順位を決めるのではなく、顧客に聞いて優先するものを決めていくことの重要さに改めて気付かされました。
Karin by MICINについて
Karinとは
医師が患者の情報をカルテに記載するように、薬剤師は「薬歴」に患者の情報を記録します。その薬歴に記載する文章を薬剤師と患者の服薬指導会話から自動でAIが作成するサービスです。
MICIN AI搭載の薬歴入力サポートシステム「Karin by MICIN」β版 限定リリース開始 ～薬剤師の負担軽減および服薬指導の質向上を実現～ | 株式会社MICIN
Karin立ち上げの経緯
curonお薬サポートの数千店舗の薬局に追加の価値提供ができる新サービスを検討。複数のサービスの候補の中から顧客の課題・ニーズが大きく、MICINの技術力を活用して顧客の課題を解決できるサービスとし薬歴のAI自動作成サービスを企画・開発して2022年10月にβ版をリリース。
サービスリリースまでのプロセス
ニーズを発見するために、顧客の業務観察から始め、仮説を立て、顧客のフィードバックを元に仮説をブラッシュアップしていきました。その結果、単なる業務効率化ではなく、医療者が患者と向き合える時間を創り出すサービスとしてβ版のリリースに至っています。
プロセスとしては、
薬局の業務を観察し業務プロセスを見える化
プロセスの中で課題を抽出して課題仮説を立てる
課題を解決するソリューションの案を複数企画
優先度の高い複数のアイデアを営業資料に落とす
営業資料をベースにヒアリングしニーズを確認
ニーズの高いサービスに絞り込んでプロトタイプを開発
プロトタイプで現場検証
プロトタイプでの検証結果を元にプロダクト開発
ポイントになったところ
観察とヒアリングからインサイトを抽出
複数の医療機関、薬局に半日ほど滞在して、業務の観察を行った上でヒアリングを実施。その結果わかったことは、薬剤師は患者に服薬指導をした後にかなりの時間を薬歴の記載に時間を使っていること、そして、単純に業務を効率化したいということ以上に、医療者は患者と向き合うことに時間を使いたいと思っていて、極力機械に向き合う時間を減らしたいと感じていることでした。
検証に優先度を付けた上で並行して走らせる
技術的な実現可能性のハードルが高いため、営業資料・コンセプト動画でニーズの検証をしながら同時に機械学習による薬歴文章作成のモデル開発に着手しました。序盤はアプリケーションによるUIの作り込みは行わずに、認証もない簡易なプロトタイプでユーザーに使ってもらい、ニーズを満たすものになる可能性があるのかを探りました。
2つのサービスのMVP検証の違い
curonお薬サポートとKarinの大きな違いは、前者は0→1で、後者は無→0→1であることです。つまりは、前者は既に作るサービスも納期も決まっていて、PSFを目指してWhat〜Howを考え、後者はCPFを目指し、「何を作るのか？」「なぜ作るのか？」のWhy〜What〜Howを考える必要があります。
お薬サポートのMVP
検証するポイントはサービス全体のニーズのあり/なしではなく、どの機能が重要なのか？、どうすれば使いやすいのか？のため、優先度の低い機能を削ぎ落とし、ニーズの高い機能の要件をユーザーの求める形で実装することになります。したがって、まずは資料＋会話で機能を絞り込み、詳細はFigmaで見える化することによって、実装する前に詳細を確かめます。機能を削ることでMVPとし、実装したものは段階を置いてそのまま製品として市場に投入されています。
KarinのMVP
検証するポイントはニーズが本当に存在すること、技術的に実現できることの２つのため、営業資料＋動画によるニーズ検証とAIによる要約モデルの技術検証を同時に走らせました。MVPのアプリケーションはサービスを体験できる最低限のものを開発し、β版としてリリースする際にはそれを捨てて作り直しをしています。
両方に共通して言えることは「いかにつくらずに検証をするか」なので、企画をする側はそれに知恵を絞る必要がありますし、実装をする側は「それって本当につくらないとダメですか？」と企画者に問いかけるぐらいが良いかと思います。
さいごに
今医療業界は環境の変化により急速なデジタル化が進んでいます。今押し寄せる波の最先端でこれからの医療のアタリマエを切り開いて、一緒にMICINを成長させていきませんか？
MICINではメンバーを大募集しています。
「とりあえず話を聞いてみたい」でも大歓迎ですので、お気軽にご応募ください！
MICIN採用ページ：https://recruit.micin.jp/