エムスリーテックブログ

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

ユーザーインタビューを通じてリーン顧客開発を実践する

f:id:iwata1990:20161027132832j:plain
『リーン顧客開発』の著者 Cindy Alvarez

こんにちは。 エムスリーエンジニアリンググループ、プロダクトマネージャーの岩田です。
今回はユーザーインタビューを通じてリーン顧客開発を実践した話を書きます。

MVPの要件が全くミニマムでなくなってしまう、PDCAのサイクルが遅すぎる、といった(ありがちな)お悩みをお持ちのプロダクトマネージャーの皆様に役に立てるような情報を発信できればと思います。

MVPの要件は自然と膨らむ

MVPでサービスを出しましょうという話になった時、あれよあれよという間に要件がてんこ盛りになることってありませんか? しかし組織のリソースは有限です。プロダクトマネージャーはなぜその要件は(今は)作らないのか、ということを周囲に説得しなければなりません。

発想を変えましょう。そもそも仮説検証でMVPは本当にいつでも必要でしょうか?

『リーン顧客開発』では仮説検証の手法としてユーザーインタビューを提案しています。なぜならMVP開発に比べれば圧倒的に低コストかつ早期に実施できます。したがって仮説が間違っていると分かれば修正してまたインタビューをすれば良いのです。MVP開発で何回もリリースするためには多大な労力とコストがかかりますが、ユーザーインタビューではほんの数日から1週間でPDCAが回せます。

以下では、私が担当するプロダクトにおいて、ユーザーインタビューを用いてリーン顧客開発を実践した事例をご紹介します。

プロダクトの紹介

事例紹介の前に、私が担当しているプロダクトについてご紹介させて下さい。 エムスリーデジカル(以下デジカル)は、開業医向けのクラウド型電子カルテです。
「開業医の手間を削減する」というコンセプトに基づき、直感的なUI、アルゴリズムを活用した入力補助、紙カルテのような書き心地のiPadアプリなどを提供しています。

digikar.co.jp

デジカルでリーン顧客開発を実施した事例

ここからはデジカルにおけるリーン顧客開発の事例を紹介します。

解決したかった課題

医師は患者の傷病を診断し、これを治療するために必要な薬の種類だけではなく、その処方量も判断する必要があります。そしてシロップや粉末系の薬などは処方量を患者の体重によって判断することがあります。

デジカルでは当時、こうした体重換算を行う機能が存在しませんでした。シロップや粉末系の薬は特に小児科で多く処方される傾向にあるため、こうしたユーザーからの要望が特に強く届けられていました。

ユーザーインタビューを通じて検証したかった仮説

当初私はこの機能を「めんどうな計算作業から医師を解放する」というイメージで捉えておりました。そこで患者の体重を入力値とし、指定された薬剤の処方量が自動で入力されるようなUXをまず考えました。 以下にXDで作ったプロトタイプを貼っておきます。ただしこれはブログ用にブラッシュアップしたもので、当時は更に簡素なものでした。

f:id:iwata1990:20200313145147p:plain

画面の右側に、タイトルが「メイアクトMS小児用細粒10%」と表示されているポップオーバーのようなものが表示されています。患者様の体重を入力し、それに対応する処方量を強調表示しております。なお体重については一度入力すれば前回の値を覚えるため、同じ患者様であれば次回以降は入力が省ける場合がある(ただし体重は増えたり減ったりするので、前回測定日を下部に表示する)という仕様になっています。

この仮説を検証するため、以下の質問を立てました。

  • 患者の体重が分かれば処方量は一意に決まるという理解はあっていますか?
  • 今はデジカルに体重換算機能は無いが、どのように対応していますか?
  • あなたが欲しい体重換算機能は、計算の面倒さを解消してくれるものですか?

設問の立案時は、ユーザーインタビューにおける以下の罠を回避することを意識しました。

  1. ユーザは話を要約しがち
  2. ユーザの話は時系列に沿ってなかったり抜け落ちがあったりする
  3. ユーザは例外を無視しがち

例えば「体重を入力したらそれに応じて処方量を自動入力する機能が欲しいか?」と聞くとおそらく多くのユーザーは「はい」と答えると予想されます。自分が使ったことがない機能に対する回答は、上述のように要約されていたり、例外が無視されがちになります。

この辺りのユーザーインタビューの罠の話は以下が参考になりました。ぜひ併せてご参照頂ければ幸いです。

ユーザーインタビューを実践して見えたこと

今回実施したユーザーインタビューでは以下のような答えが多く返ってきました。

  • Q: 患者の体重が分かれば処方量は一意に決まるという理解はあっていますか?

    • A: 場合による。患者の容態で処方量は調節する
  • Q: 今はデジカルに体重換算機能は無いが、どのように対応していますか?

    • A: よく出す薬の体重換算表を紙で用意しておいて、それを見る
  • Q: あなたが欲しい体重換算機能は、計算の面倒さを解消してくれるものですか?

    • A: それもあるが、処方量は医師が診療する上で判断する重要な事項。例えば副作用などがその患者にとって望ましくなければ減らすこともある

このやりとりだけで、事前に考えていたことに多くの誤りがあることが分かります。体重を入力したら処方量が出るというUXはユーザーにとって分かりづらい(今の方法と違いすぎる)上に、欲しい結果を必ず与えられるわけではない(実務では体重が決まれば処方量は一意、ではない)ことが明確になりました。

ユーザーインタビューを経てアップデートしたもの

アップデート後のイメージを載せます。こちらもXDで作ったプロトタイプです。

f:id:iwata1990:20200313145150p:plain ※テンキーの有無は今回は関係ないので無視してください。

前回とは異なり、医師は処方量を入力する際に患者の体重は画面に打ち込む必要がありません。枠内で上下にスクロールし、処方しようと思う処方量を選択できます。これは従来から使っていた紙の体重換算表と全く同じイメージですので、どなたでもすぐに使い方が分かります。

以前のものと、今回のものをモックアップでユーザー様に見ていただいた所、全員後者の方が欲しいとお答え頂きました。これを検証するに辺りかけたエンジニアの工数はゼロ、要した期間は準備を含めて2週間程度でした。これがユーザーインタビューの威力です。以前のもので開発を進めていたことを考えるとゾッとします。

ユーザーインタビューを導入する際に周囲から聞かれたこと

こうしたユーザーインタビューを初めて導入する際は周囲を説得が必要になるかもしれません。幸い私の場合はVPoE山崎がユーザーインタビュー肯定派(というより彼のアドバイスによりユーザーインタビューを実施した)という環境であるため比較的容易に導入できましたが、それでも周囲に説明を求められることは度々ありました。この時のやりとりの一部を列挙します。皆様の組織にユーザーインタビューを導入する際の一助になれば幸いです。

インタビューをする分、却って機能リリースが遅れるのでは?

ビジネスサイドは、特に上の立場になればなるほど案件が滞りなく進むということを重視します。組織のリソースは有限なので、不必要なことにリソースを割くのを嫌います。そうした背景や立場をきちんと理解する、リスペクトするということが必要になります。

  • エンジニアの工数はゼロで済むので、今進めている案件自体に影響が出るわけではない
  • エンジニアのリソースが空く範囲内で仮説検証をするだけなので、全体の進行に滞りは出ない
    • ただしインタビューをした結果、ユーザーからの反応が想定外だった場合はそもそもの開発の是非を検討する必要がある
    • しかしこれは不必要なものを開発するリスクの緩和にもつながる。必要なものをリリースしてそれをメンテナンスするためのリソースを考えれば、ここで立ち止まることは遥かに安いのではないか

プロトタイプもなしで、手ぶらでユーザーに話を聞くことは、彼らから許容されるか?

普段からユーザーと接している営業の方からすれば、相手にとって益になる材料を一切持たずに話を聞きに行くということでレピュテーションが下がることを非常に恐れます。せっかく自分が築き上げたユーザーの信頼を、自分が関知しない開発サイドとのやりとりによって毀損されてはたまったものではありません。

  • むしろ可能であればユーザーインタビューの場に同席頂きたい
  • 一般論として、自分が困っていることに対して話すことを人は嫌がるどころか好む傾向がある
    • そうでなれば愚痴を言い合う飲み会やTwitterなど存在しないはず
  • 基本的には相手が話したいと感じることを話してもらうように注意する。事前に設問は用意するが、そもそもそこに関心を示すか示さないか、という部分も重要なインサイト
  • 逆にプロトタイプを見せてしまうことで、相手の想像力を狭めてしまう場合も多い

ユーザーインタビューの結果、開発が要らないと判断するのは早計でないか

これは最も難しい問題です。事実その通りで、聞き方や聞く相手の選び方や、層の偏りの問題によって事実が見えなくなるリスクは大いにあります。

  • 開発を止める、止めないの二元論では考えていない。判断材料を集めるための手段でしか無いことを伝える
  • インタビュー設計や設問などを事前に見てもらう
    • 設問数に限りがあることを注意
  • 可能な限り多くの方にユーザーインタビューの結果を速やかに共有する。自分の解釈に間違いがないかどうかを周囲にも判断してもらう

まとめ

ユーザーインタビューを実践することで事前の思い込みを排除し、ユーザーが本当に欲しいものを短期間かつ低コストでリリースできうるというお話をしました。ユーザーインタビューは周囲の説得に苦労したり、とても緊張したりと最初のハードルがなかなか高いかもしれませんが、上手く使えば非常に強力なツールですので、積極的に活用頂ければと思います。

We are hiring!!

エムスリーではテクノロジーを活用して医療業界を変えるプロダクト作りに取り組んでいます。 エンジニア、プロダクトマネージャー、プロダクトデザイナーを絶賛募集中です。 ご興味があればぜひカジュアル面談をしましょう。

jobs.m3.com