ユーザーの成功体験を探せ！

エムスリー、プロダクトマネージャーの坂（ばん）です。2021年6月、医療従事者専用サイト『m3.com』のコンテンツ配信準備を支援する社内業務システムをリリースしました。

プロダクトリリース後は、PMFを目指したグロースの戦略が必要です。

今回のリリースでは、ユーザー（エムスリー社員）から多くの改善要望が集まりました。これらに順次対応する戦略もありますが、私はほぼ全ての改善要望をいったん無視することにしました。そして、提供システムでユーザーが得た成功体験を探し始めました。

なぜ改善要望を無視したのか、どうやってユーザーの成功体験を探したのか、どんな良い事があったのかを記載します。

開発チームに加わる

日本最大級の医療従事者専用サイト『m3.com』で配信するコンテンツは、製薬企業とエムスリーの協働で制作されています。コンテンツを配信するまでに、画面素材／掲載する文面／画面レイアウト／配信リストなど複数の準備物があり、多数の作業工程が存在します。

今回提供する社内業務システムは、スケジュール管理機能を有し、ユーザーのスケジュール管理業務の工数削減を目的として開発されました。私はテストフェーズから開発チームに加わり、テスト完了後トライアルを経てリリースを迎える予定でした。

しかし多くのユーザーから、システムを使用するためには改善が必要だとの意見が出たため、リリース日を再検討しました。

リリースを決意する

再検討の結果、1件だけ改善要望に対応してからリリースすることにしました。

多くの改善要望を無視してリリースを決意した理由の1つは、開発期間です。1年以上に渡り開発を続けており、この長い開発期間が改善要望を生んでいるように感じました。リリースを大幅に延期すれば、実務で使用したユーザーの反応を見ることなく、開発を継続することになります。それは避けるべきリスクであるように感じました。

2つ目の理由は、全ての改善要望を叶えてもユーザーは大きく増えないと感じたからです。開発当初と異なり、多くのユーザーグループが自製Excelツールを構築していました。集まった改善要望は、この自製Excelツールと比較して生じている可能性が高いと考えました。貴重なエンジニアリソースを投下し、自製Excelツールと同じ機能を構築しても、ユーザーが乗り換える理由にはなり得ません。

とはいえ、使ってもらえないと意味がないため、温度感の高い1件の改善要望には対応することとしました。

2021年6月、リリースを迎え、ユーザーへの価値提供が始まりました。

ユーザーの成功体験を探す

リリース後、宣伝を兼ねた説明会を開催し、業務部門担当者と各グループを周りました。既出の改善要望含め、さらに多くの改善要望が集まりました。全ての改善要望に目を通し、ユーザーにとって必要な仕組みは何か考えました。

集まってくる改善要望、説明会でいただく厳しいフィードバックは、提供システムを否定されているようにも感じました。

一方で「全てダメなんてことはあるのか？」という疑問も生まれました。ユーザー数は多くありませんでしたが、ゼロでもありませんでした。価値を感じ使用しているユーザーがいました。使用したが離脱したユーザーがいました。全ての機能に幻滅したわけではなく、価値を感じた機能はあったのではないかと思いました。

私はユーザーの中から成功体験を探すことにしました。

アンケートで成功体験を見つける

Googleフォームでアンケートを作成し、DBから抽出したシステム利用者にメールで回答を依頼しました。アンケート項目は、NPS測定のための総合満足度（0〜10の11段階）と各要素別の満足度（未使用、不満〜素晴らしいの6段階）の2つにしました。設問は機能でなく、開発チームが狙った成功体験を意識して記載しました。

×「スケジュール作成機能」

○「条件を入力すればシステムが自動でスケジュール作成してくれるところ」

結果、総合満足度が9点で、「条件を入力すればシステムが自動でスケジュール作成してくれるところ」に素晴らしいと評価するユーザーを見つけることができました。

このユーザーに個別連絡をとりインタビューすることで、具体的な成功体験エピソードとユーザー属性を得ることができました。

当該業務を初めたばかりでスケジュール分岐の条件や各タスクの所要日数を社内Wikiで調べて作成せねばなりませんでした。提供したシステムは、条件を入力すればシステムが自動でスケジュールを作成してくれるため、非常に有り難かった。

Googleフォームで作ったアンケート

ユーザーを定点観測し、成功を可視化する

コンテンツ配信準備の予定があるユーザー2名に協力いただき、週次で削減工数を測定しました。

提供システムと従来方法の2パターンで、「ツールへのアクセス回数」「1回あたりの作業時間」「スケジュール作成にかけた時間」などを調査しました。結果、提供システムは従来方法に比べ、コンテンツ配信1件あたり約1時間の工数削減ができることが判りました。

業務体験で、自ら成功する

業務代行スタッフとして、実業務で提供システムを自ら使用しました。実業務を体験することで、提供システムの価値を肌で感じることができました。

スケジュール作成では、条件がリスト化されていることが1つの価値になっていました。不足している情報を把握でき、条件を埋められると安心感を得られました。

また条件は決まり次第降りてくるため、スケジュール作成は一度ではなく、何度も引き直す必要がありました。ボタン1つで自動作成される体験は間違いなく快適でした。

成功体験で、ユーザーを増やす

上記活動を通じ、私たちは具体的な成功エピソードとそのユーザー属性を入手できました。

成功体験はアンケート回答者だけのものではなく、属性の近い潜在ユーザーは、同じ成功体験を得られる可能性があります。私たちは、同属性のユーザーにアプローチし、ユーザー数を増やすことに成功しました。

成功体験の横展開は、改善要望対応と比べて、以下2点で優れていると感じました。

1点目は、追加開発が必要ない点です。実装済み機能をユーザーに届けるため、エンジニア開発工数がかかりません。

2点目は、ユーザー獲得の確度です。ユーザーの成功体験の背景には、従来方法よりも提供システムが上手く課題を解決した事実があります。似た状況で似た課題をもつユーザーは、同じ成功体験を得られる可能性が高いはずです。

成功体験を追加開発の材料にする

リリースに踏み切り成功体験を探すことで、当初立てた仮説が正しかったのか間違っていたのか検証できました。改善要望を見つめ、ユーザーに思いを馳せる前に、わかったことを確認するのが先だと感じました。

「条件を入力すればシステムが自動でスケジュール作成してくれる」体験は、業務経験の浅いユーザーには間違いなく響くことを確信できました。

まとめ

今回のプロダクトリリースでは、ユーザーの成功体験を探し強みを活かす戦略をとりました。 結果、ユーザーを獲得し、開発当初の仮説も検証できました。

多くの改善要望を無視してリリースは、少し緊張しました！ 最善の方法であったかは判りませんが、リリースして良かったです。

ユーザーの反応はとても気がかりで、どうしても弱み（改善要望）に目が行きがちです。 一方で、強み（成功体験）は提供システムを肯定する気持ちで、積極的に探さないと見つかりませんでした。

プロダクトの強み探しは、プロダクトマネージャーが意識的に行わねばならないと学びました。

We are hiring！

エムスリーでは、プロダクトマネージャーを募集しています。エムスリーには様々な経験を活かせる場、新たな挑戦ができる場があります。ぜひお問い合わせください。

jobs.m3.com