こんにちは、タイミーでプロダクトマネージャを務めている高石 ( @tktktks10 ) です。
戦略やロードマップの策定から、プロダクトの成果を最大化するための課題発見や優先順位付けを日々の業務としていますが、今回はその中でも顧客と直接顔を合わせる「ユーザーインタビュー」を起点とした取り組みの話をしようと思います。
ユーザーインタビューの積み重ねから組織のアライメントを生み出す
タイミーでは最近新たに入社頂いたPMMの影響もあり、ユーザーインタビューの頻度を大幅に増やしています。きっかけは単に顧客解像度を上げようという至ってシンプルなものでしたが、横断的に継続する中で次第に部署や役職を超えた共通の顧客像*1（セグメント）が出来上がり、最近では全社戦略やプロダクトロードマップ、個別の施策にも引用されるまでになってきました。
一言で言えば、「横断的なユーザーインタビューの積み重ねから組織として顧客像を定義し、戦略や施策に活用している話」となります。
組織全体で共通理解のある顧客像は、全社戦略からチームレベルの施策全てにおける主語となり、自ずと各所の取り組みが同じ方向を向く、所謂アライメントが取れている状態を生み出します。アライメントが取れている状態ではあらゆる場面でコミュニケーションコストが削減される他、マーケティング、プロダクト開発、カスタマーサクセスまでなど、一気通貫した課題解決に繋がります。
ユーザーインタビューやペルソナ、個別具体に関する記事は多いものの、実際に構築から運用までを紹介した実例を見かける機会は少ないように思い、今回はタイミーにおける実際のプラクティスをまとめました。
*1 厳密には顧客とユーザーの双方が存在しますが、ここではまとめ上げられたもの呼称として"顧客像"（セグメント）に統一することとします
『組織として』顧客を理解し続ける意味
組織がスケールして部署やチームの数も増えると、それぞれのミッションや取り組みも新たに生まれるでしょう。この過程において全員の向き先を揃える顧客像が不足していれば、皆が少しずつ異なる顧客像を持ち始め、異なる方向に向かい出してしまいます。顧客像や注力対象がズレた状態では、連携する際のコミュニケーションコストが増大する他、部署やチーム間で時には対立を生んだりなどの問題が発生します。優れた組織設計の元ではこれらの摩擦が起きづらいものですが、それでも少なからず分業や連携というものは発生するのが現実です。
このようなサイロ化が進む状況で、いくらサイロの中にいるチームや個人から顧客像を打ち立てても、中々根本の問題は解消しません。 組織がスケールする中で個人やチーム同士を繋ぎ止めて速度を落とさないためには、役割や役職を跨ぐ形で組織として顧客を理解し、戦略や各部のアクションに還元し続ける必要があります。
以下、実際に横断的なインタビューの積み重ねから全社共通の顧客セグメントを構築しているサイクルと、得られた顧客セグメントを戦略や施策に還元したことで得られた成果の順で紹介したいと思います。なお、タイミーはBtoCのサービスですが、今回の取り組みはtoC側を対象にしたものです。
実際に行っているインタビューのサイクル
継続的な取り組みですのでサイクルという表現になり、 下記1~3のプロセスを日常的に回しています 。全体を通して、具体から抽象を見出すことを意識した設計になっています。
1. 共通理解を築きたい人とインタビューを行う
主にインタビュアー2人のデプスインタビューを継続的に行っています。1人が主な進行を担当し、もう1人が視点をフォローするようなサポートをします。現在ミニマムで週5回ですので、毎日1回はどこかしらのペアがインタビューを行なっているくらいの頻度になります。
この時、共通理解を築きたい人（裏を返せば、理解に溝がある人）を同席相手に選定します。プロダクトマネージャである自分は、戦略の議論が必要な場合経営陣や関連部署のメンバー、バックログレベルで解像度を上げたい場合開発チームと同席することが多いですし、マーケティング部では既存メンバーが新しく入社したばかりのメンバーとオンボーディングの一環として同席しています。実際の顧客を目の前にして時間を共有することは、内輪の会議からは得がたい強力な共通理解を築く方法です。
また、インタビュー自体にも様々なテクニックはありますが、基本的には事実を聞くように徹します。後述する共通理解を築く上で、主観ではなく事実を把握しておくことは非常に重要です。個人的には下記のアンチパターン集*2*3などは参考になりました。
*2 良いユーザーインタビュー、悪いユーザーインタビュー｜Mizuho Kushida｜note
*3 失敗から学んだ、ユーザーインタビュー23の心得｜Goodpatch Blog グッドパッチブログ
2. インタビューで得られた事実について考察をし、ユーザーの特徴を簡潔にまとめる
インタビューが終わったらその直後、遅くとも記憶が新しい翌日までに考察の振り返りを行います。インタビューで得られた事実を基に、ユーザーの利用開始文脈や現状解決している課題、解決しきれていない課題などに対して協力して解釈（厳密には仮説）を当てます。
当然異なる2人が解釈を当てるので、双方自分には無かった観点が飛び交います。この過程ではお互いの観点を共有して見方を増やし解釈の精度を上げることにフォーカスしますが、ユーザーを起点にしてお互いの考え方を知る時間でもあります。
考察が一通り終わった後は、ユーザーの特徴を3~4行で簡潔にまとめあげます。このまとめが思いの外重要であり、2人で協力して特徴をサマライズすることで「この人はこういう目的でタイミーを使っていたよね」といった、ユーザーに対する共通理解が生まれると同時に、後からこの文書をみたときにユーザーの顔やインタビュー内の会話をスッと思い出せる入り口にもなります。
3. インタビュー結果を集合させ、顧客像を定義・アップデートする
個々のインタビューとその考察で得られた情報を、集合知にするプロセスです。
最初こそまとめ方は模索しつつ皆でインタビュー結果をホワイトボードに貼り出して考察を重ねたりしていましたが、総インタビュー数が30~40回を超え始めたところで利用目的、即ち解決している課題が大きく異なる顧客像が2つ浮かび上がり、皆が腑に落ちる形でセグメントとして言語化・定義されました*4。結果こそシンプルですが、過程は決して事務的な作業ではなく、殆どが会話によるワークショップ的な時間を通して出来上がったものになります。
利用目的が異なるというのがポイントで、これは解決しているジョブが異なることを意味します。一般的にセグメントといえば職業や年齢などから成るデモグラベースの物が多いかもしれませんが、今回定義されたのは解決している課題別、即ちジョブベースのセグメントであり、プロダクトの4階層を借りるならばWhyに相当するもの*5です。
なお、一度セグメントが定義された後はここに立ち返る形で新たなインタビュー結果を照合し、継続的に内容や理解をアップデートし続けています（現在では開始から4ヶ月で計100~150人程になりました）。この2つのセグメントが組織内の共通言語になっており、後述する戦略や施策などの前提として利用されることになります。
*4 本記事では取り上げていませんが、実際はある程度定量データで裏付けをとりながら定義を進めています
*5 何のためにペルソナをつくるのか - 4つの使い分け｜小城久美子 / ozyozyo｜note
得られた顧客像の活用例とその成果
ここまでの過程をプロダクトに関わる全ての役割・役職が協力することで、個人でもなくチームでもなく『組織として』顧客像を作り上げているのがポイントです。自分たちで作っているので都度背景を説明する必要もなく、以降の活用フェーズにおいて既知の共通言語として利用することができます。
全社戦略やロードマップにおける注力セグメントとして利用されることで、部署やチームを一気通貫した課題解決に繋がる
以前からも全社戦略やロードマップは運用されていたものの、顧客像の認識は今より曖昧であり、部署やチームの施策レベルで目的の分散が起きてしまう課題が起こりつつありました。今思い返すと、データを元にした会話は多かったものの、インタビューなど顧客のWhyに触れる定性的な時間を共にする機会は少なかったように感じます。
一方、最近戦略やロードマップがアップデートされたタイミングで今回作り上げた顧客像を引用したことに加え、事業の方向性やプロダクトビジョンと照らし合わせた上で注力するセグメントと目指すべき方向性も自ずと決定されました。これは、中長期的・組織的な目線において「 誰をどんな状態にしたいのか 」の方針が立ったことに相当します。重ねての強調になりますが、そもそも組織的に作り上げた顧客像であるため、この時点で既に関係者間で共通理解がある状態です。したがって、後からドキュメントによる追加の補足や翻訳作業などもほとんど必要ありません。
結果的に、獲得施策からプロダクト開発、マーケットインまで共通の顧客像を持つことで、以前よりも正しい顧客に正しいプロダクトを届けるための連携ができるようになってきました。部署やチームの前に顧客像とフォーカスが決まっていることで、組織全体を活かした課題解決に繋がっています。
部署間の前提が揃うことで、プロダクト開発の優先順位付けが効率化した
こちらはもう少し具体に近い、日々のバックログに対する優先順位付けの話です。
共通の顧客像とフォーカスができる前は、そもそも向いている顧客像が若干ズレていて視点が広がりすぎているために、ステークホルダからの要望に対して都度目線の調整したり断ることが多かったように思います。もちろん個別の施策に対してコストの軽いものから随時実行するという判断もできなくはないですが、フォーカスの定まらない表層の改善だけが連続してしまうことになります。本質的な課題を解決し中長期的な成長を目指すには、同一のゴールに対して継続的に改善を試みる選択と集中が必要であるため、そういった状況になることは好ましくありません。
一方、共通の顧客像とフォーカスが決まってからは自ずと施策レベルの方向性も揃い始めたため、目線の調整や断るケースがかなり減りました。また、プロダクト開発における直近の注力テーマをステークホルダに理解してもらうことで、その間は開発を必要としないプロダクト外で並走できる改善に取り組んでもらうなど、むしろ協力する機会も増えてきたように思います。根っこの目線が揃うことでコミュニケーションコストが削減されるのはもちろん、以前より効率的な分業もできるようになりました。
開発時に引用され、ものづくりにおける意思決定の促進に繋がる
前述した優先順位付けにもつながりますが、顧客像とそのフォーカスが決まっていることで、バックログ自体も自然と流れを持った構成になります。また、これはまだ一部ですが、バックログリファインメントで開発チームが顧客セグメント引用することで、自律的に機能開発の方向性を決定できるケースも出てきました。ただし、UI/UXレベルの意思決定を精度良く高く行うには、もう一段階具体に寄ったWhatレベルの顧客像が必要であるとも感じます。この辺りは最近取り組み始めたUXリサーチやプロトタイピングを通じて、組織としての仮説検証能力を上げていきたいポイントでもあります。
今回の取り組みを始める際にやってよかったこと
最初はとにかく量を重ねること
正直なところ、インタビュー開始当初は目的設計も曖昧でした。しかし今思い返すと、顧客解像度が低く目的設計が曖昧になるためインタビューが起こりづらいが、インタビューが起こらないため顧客解像度が上がらない負のスパイラルに陥っていたように思います。
一方、ひとたび顧客の解像度が上がりはじめると自ずと新たな疑問（仮説）が生まれます。その疑問を解消するために次のインタビューを設計して…、というポジティブフィードバックサイクルが生まれれば、後は勝手に自走するでしょう。まずは目的が曖昧でも良いので、量を重ねてみることをおすすめします。
インタビューの参加コストを抑える仕組みを同時に作ったこと
こちらは以前出した記事の内容になるのですが、タイミーでは思い立てば誰でもインタビューに参加できる社内の仕組みが構築されています。実際インタビューを行うにはインタビュイーの選定から実際の募集、謝礼の受け渡し、当日までの連絡など、様々な附帯業務が発生する訳ですが、これらをインタビューを支えるチームがサポートすることで、参加者はインタビューのコンテンツだけに集中できるようになっています。
前述したポジティブフィードバックサイクルに乗るためにも、インタビューを行う人とインタビューの設定をサポートする人を分離したことは、今回の取り組みに一役買ったと感じています。
おわりに
最初は何気なく始めたユーザーインタビューでしたが、今では拡大し続ける組織において顧客の共通理解を保ち続ける重要なプロセスとなりました。プロダクトマネジメントにおいても、共通の顧客像が主語になることで、組織でものづくりをする力がついてきているように感じます。
とはいえ、タイミーは急成長中のプロダクトで課題もまだまだ転がっています。もっと具体的に話を聞いてみたい方、ユーザーインタビューに限らずプロダクト開発やプロダクトマネジメントについて興味がある方、もちろんタイミー自体に興味のある方、職種問わずお気軽にお話しましょう！（ Twitter からDMを頂けると助かります）
