エムスリーテックブログ

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

プロダクトマネジメント1年目に痛感したペルソナ×カスタマージャーニーの威力

これはエムスリー Advent Calendar 2019の12月1日の記事です。今後どんどん面白い記事が毎日更新されるので、ぜひ購読・拡散お願いします。

https://qiita.com/advent-calendar/2019/m3

軽く自己紹介

私はもともと機械学習系のエンジニアです。今もエンジニアですが、プロダクトマネジメントに挑戦しています。昨年もAI関連のプロダクトのマネジメントを行なっていましたが、今はもっと広い範囲のUXを考えることに挑戦しています。

私の経歴については先月に行われたLINE DEV DAY 2019の資料を見てください。資料作りに100時間くらいかかったので、見ていただけると非常に嬉しいです。(もうすぐ1万view達成です)

PdM1年目にやったこと

まず、この1年取り組んできたことについて紹介します。この1年は新しい情報系のサービスを立ち上げるために、クライアントやユーザーのヒアリングや仮説検証などを行いました。私にとってユーザーインタビューやペルソナの作成等は初めての経験だったので学びが多くありました。また、エムスリーのエンジニアリングGのVPoEかつPdMかつ私の上司の山崎聡さんの教えに従い、「基本に忠実であること」、「作る前に売ること」を徹底して実践してきました。

基本に忠実であること

様々な本を勧めていただき何度も繰り返し読みました。次の3つの本は弊社のエンジニアリングGのPdMにはバイブル的な本です。勉強会等でも繰り返しレコメンドしています。

またプロダクトや事業化をするために下記の本も読みました。

これらの本を繰り返し読んでいます。世界的にも評価が高い本が多く、何度読み返しても新しい学びがあります。

作る前に売ること

山崎さんはよく「良いプロダクトはモックの段階で顧客から評価される」と言っています。本当に革新的なプロダクトはそれを必要とする顧客が見るとすぐに自分に必要なものだと気づき、そのプロダクトから得られるUXが想像できるということだと思います。これはinspiredでもよく似たことが言われています。プロダクトマネージャーの最大の責任は顧客から評価される”製品を見つける”ことだと。弊社では基本的にこれを目指します。実際にこれは無茶な話ではなく、エムスリーデジカルはお手本のようにモック段階で評価されていますし、今私が進めているプロダクトもモックの段階で評価されています。

UXを考えることの難しさ

私はUXを考えることに苦戦していました。すぐにWebアプリケーションのUIに目が行きがちになり、アプリを使ったときだけでなく、その前後や背後にある実世界を含んだ体験を疎かにしがちでした。例えば「こんな感じで情報が見れたら良いのではないか?」「ページ遷移が少ないほうがいいのではないか?」などを考えてしまっていました。UIとUXが混同しているよくある例だと思います。このようなUIに関することはユーザビリティテストで検証しますが、それよりも前に「そもそも私達が解決しようと思っている課題が存在するか?」を検証する必要があります。この検証の重要性は前述した多くの本で主張されています。

UXを考えるためにペルソナとカスタマージャーニーが必須

最初に本でペルソナの話を読んだときは正直「ん?」という感想でした。名前や職業、年齢などをを設定する意味が分かりませんでした(今でも名前はいらないんじゃないかな?とは思う)。しかし、カスタマージャーニーと一緒にペルソナを活用することでUXにフォーカスを当てることができます。さらにはチームでのUXの議論で共通認識を持ちやすくなります(プロダクトチームを作るためには必須だと思います。プロダクトチームの話は別の機会に)。これらの効果(や私の現状での理解)について例を交えながら紹介したいと思います。

料理に関わるアプリを例にUXを考える

例として下記のようなペルソナを考えます。

  • 30歳男性、独身、会社員、飲み会が多く、平日に家で料理をするのは週に1〜2回ほど。あまり料理は得意ではない。

カスタマージャーニーの1つのイベントとして、まず次のようなものが考えられます。

  • 料理しようと思う → アプリを開く(接触) → 料理を作る

このときにペルソナを活用し、接触の前後におけるペルソナの行動や感情を考えます。まずは接触前を考えます。

  • 会社員だから会社からの帰宅直後だよね。
  • あまり料理をしないから材料はあまりない or 直前に買ってきた?
  • むしろアプリとの接触は帰りの電車の中では?
  • 得意じゃないから作るのは面倒だと思っているのでは?
  • 何で料理をしたいんだろう?そのときの気持ちは?普段飲み会が多いからヘルシーなものを軽く食べたいのかな?

次に接触後を考えます。

  • 作った料理は一人で食べるよね。
  • テレビや映画を見ながらゆっくり食べる or ささっと食べて何か趣味の時間にする or すぐ寝たい?
  • 作り置きとかはするのかな?次の日の朝食とか?
  • 理想や及第点はどういった状態だろう?

ざっと考えてみても色んな仮説が上がると思います。具体的にペルソナを設定したことで、帰りの電車での最初の接触や、料理をしたあとにどうやって過ごしているのか?といったところまで考えが及びます。想定した接触ポイントの前後にもアプリとの接触ポイントはありそうです。

ただ、この状態では分からないのでユーザーインタビューを行い、上記のペルソナやカスタマージャーニーを何度も更新していく必要があります。

違うペルソナを想定する

次にペルソナの種類を増やします。

  • 45歳男性、既婚、共働き、14歳の子供(男)がいる、料理は妻と交互に行なっている。そこそこ料理は得意。

先程と同様にこのペルソナにも”料理しようと思う → アプリを開く(接触) → 料理を作る”の前後にどのような行動や感情があるか考えます。先程とはぜんぜん違う体験を求めているのでは?ということがわかると思います。

ソリューションの話はしていない

このように自分たちが提供できる体験は【ペルソナ数×接触ポイント数】ほどあることが明確になります。この各組み合わせに対して仮説を立ててユーザーインタビューを行い、その一連の流れを何度も繰り返し行うことで、ユーザーが「どういうとき」に 「どういった状態・感情」から「どういった状態・感情」になりたいかを発見できると思います。

ここでUXの話を考えていますが、アプリについては【料理に関する何か】ということしか決めていません。課題発見のフェーズでは課題を発見することに集中し、その課題をどのように解決するかはできるだけ考えないようにしています。私自身はエンジニアなのですぐに解決策を考えたくなるのですが、基本に忠実にペルソナやカスタマージャーニーを活用することでUXを考えることに集中できます。

見つけた課題が本当に存在するかを確かめる

INSPIREDの著者のマーティ・ケーガンさんがYouTubeでも話しているように、PdMの一番の責任は【製品を発見する】ことです。本当にその製品を使いたいと思っている顧客がいることを検証する必要があります。確認する方法はペルソナ等を使ったユーザーインタビューだけではなく様々な方法があります(また別の機会に紹介します)。

MVPを考える

課題を発見したら、次にMVPを考えます。MVPというのは「機能が少ない/小さなプロダクト」ではなく、その課題を解決する「最小限の生存・継続できるプロダクト」というものです。課題(「どういうとき」に 「どういった状態・感情」から「どういった状態・感情」になりたいか)が明確になっている必要があります。ある種の状況で状態・感情のbefore/afterが達成できる最低限のプロダクトを設計する必要があり、課題の明確化が必須だと思います。

「課題の発見」以上の効力がある

ペルソナやカスタマージャーニーの活用は「課題の発見」だけではなく、プロダクトチームを築いていくうえでも効力を発揮します。ここでいう「プロダクトチーム」は「フィーチャーチーム」と対比する概念を指しています。

プロダクトチームはプロダクトマネージャー、プロダクトデザイナー、1人から10人程度のエンジニアで構成されます。プロダクトチーム全員がUX実現に向けて協力してプロダクト開発を行えるのが理想です。これを実現するためには実装する仕様だけではなく、そのプロダクトによって実現するUXの共有が必須です。チーム全員がUXへの共通認識を持つために、ペルソナやカスタマージャーニーについてチーム全員で議論する必要があります。

プロダクトマネジメントは基本が大事

プロダクトマネジメントを学び始めたときは「ぐだぐだ言ってないでさくっとプロトタイプ作ったほうが早いのでは??」と思っていましたが、大きなビジョンを持ったプロダクト開発を進めるなかでチームでUXについて議論をすることの大切さを知りました。そのUXの議論をするためにペルソナやカスタマージャーニー、それらをサポートするユーザーインタビューが有効だと気づきました。巨人の肩に乗るためには基本が大切ですね。

We’re hiring

エムスリーエンジニアリングGでは一緒に医療を革新するプロダクトを作る仲間(プロダクトマネージャー、プロダクトデザイナー、エンジニア)を募集中です。ぜひ一度カジュアル面談などをしましょう。よろしくお願いします。 jobs.m3.com