Sansan PMOの尾部です。こちらはSansan Advent Calendar 2019 12月25日🎄の記事です。
先日ユーザの方とワークショップをしたのでご紹介します。私達もユーザの方も楽しく意味があるイベントにできました。 CSが企画するMeetupへの参加や1対1でのヒアリングは行っていますが、ワークショップ形式は初めてでした。
1. 「You are not the user」プロダクト開発プロセスとユーザを意識するタイミング
Sansanはすべての社員が利用することで最も力を発揮しますが、一般的に名刺交換や外部との接点が多い営業や調達部門の方が、やはりコアユーザであることが多いサービスです。翻って、プロダクトを作っているメンバーはエンジニアやデザイナーが中心です。
私は「You are not the user」という言葉を大事にしています。 少しのユーザの言葉から多くのことを想像できる優秀なプロダクトマネージャーやデザイナー、エンジニアもいるかと思いますが、それは非常に稀だと思っています。個人的な意見ではありますが、「ユーザのことを分かっている」という自負はただの思いこみであることがほとんどで、怠慢にならないためにも「仮説はハズれる」と自分を疑って検証し続けたいと強く意識しています。
本題に入る前に、私がプロダクト開発において、ユーザを意識するタイミングをご紹介します。
① プロダクトバックログに積む前に、ユーザの課題は何なのかを調査します。
プロダクトマネージャーにはプロダクトバックログに積む前に心のバックログがあり、「ユーザはきっとこれに困っているのでは？」という仮説を持っているのですが、実際にユーザと会話しながらその仮説が確からしいか、それとも別にあるのかを確認していきます。
やり方としてはNPSや日々のフィードバックを元にすることもできますが、ユーザに直接ヒアリングすることが最も課題を的確に捉えやすいと考えています。理由は2つあります。1つはNPSやフィードバックのようにユーザが言語化できるものだけが課題とは限らず、こちらから引き出す必要があるから。もう一つはその場でプロダクトを操作する手元を見せてもらったり、その瞬間に考えていること、不安などをヒアリングし様々なカットで課題の背景を深堀りできるからです。
② プロダクトバックログに課題を積んだ後、更に深堀りする調査をします。
①で特定した課題に対して、具体的な解決策を考えるためです。 方法はアンケートを取ったり、コミュニティサイトで聞いてみます。例えば、「検索体験が悪い」という課題がわかっているなら、「何を解決したくて検索するのか」「検索した後何をするのか」「どんな時に苛立つか」などを聞きます。
③ ラフやモックアップを触ってもらい、仮説を検証します。
これはコーディングせずともInvisionなどを使った紙芝居的なもので十分です。当社は幸いエンドユーザに当たる営業系職種のメンバーが社内にいるので都度触ってもらったり、CSが企画しているMeetupで触ってもらっています。いずれも操作中に考えていることを全て言葉にしながらです。
先程 「仮説はハズれる」と自分を疑って検証し続けたいと書きましたが、この時に一番痛感するはずです。ユーザは自分達が思い描いていた通りには操作してはくれません。
この一手間をすっぽかしたため、開発が終わってリリース直前に「これでは成立しない」と気づき、ゼロから開発しなおしたプロジェクトもありました。どちらのコストが大きいでしょうか。
④ リリースしたものがきちんとユーザに届いているかを調査します。
プロダクト開発はユーザの課題解決をしてこそ意味をなします。プロモーションはマーケティングやCSの範疇でありプロダクト作りには直結しないように見えますが、プロダクトが無視して良いものではないと考えています。
なぜユーザが機能に気づけなかったかについて、ユーザ自身はフィードバックをくれません。こちらから取りに行くしかありません。今のところはCSのコミュニティで収集してもらっています。 使ってもらえなければユーザの課題解決に繋がらないし、私達も検証・改善ができません。ユーザが心地よく機能に気づき、心地よく使い始められる方法を探るために、プロダクトが向き合うべき必要なステップだと考えています。
⑤ 実運用後のフィードバック
ようやくリリース後にユーザに使ってもらってフィードバックをもらいます。主にはCSメンバーからユーザにヒアリングしてもらいます。
①〜④の検証をスキップして「早く作って早くリリースして検証・改善すべき」という論調もありますが、どちらか一方を取るのではなく案件毎に柔軟に対応することが必要だと考えています。UIのちょっとした変更で後から簡単に直せるものであればそうあるべきでしょう。また検証目的で他機能と依存関係が無く、さっとクローズできるものであればそれでも良いでしょう。ですが、Sansanのような大規模プロダクトであれば依存関係も多く、数ヶ月かかる機能開発も沢山あります。その時々で費用対効果が見合う方法を取るセンスが問われているのです。
今回のワークショップは①のステップが対象でした。①〜⑤の中で最も難しいと考えています。 「プロダクトマネージャーはWhyとWhatに責任を持つ」とよく言われています。Whyを間違うと、WhatもHowも全てが間違います。 課題の断片だけを見て、解決策に飛びつくと結果が違うことの例を書いてみました。
「断片的な課題の鵜呑み」「解決策に飛びつく」って怖いですよね。 課題を適切に捉えるためにも、「なぜ」を問える環境作りが必要で、中でもユーザの方と直接会話できる場が大事だと考えています。
2. ワークショップイベント "Sansan User Lab"
参加者は、SansanからはPM（元エンジニア）/PMO 3名、 デザイナー 3名 、CS 1名 、そして社外のユーザの方 2名の計9名。 この中でSansanのメインターゲットになる営業経験者は半分の5名。まさにYou are not the userです。
まず1on1ヒアリングを30分×2名行った後、残り1時間でお弁当を食べながらワークショップに移ります。
① 1 on 1 ヒアリング
私からユーザの方に1対1でヒアリングしました。
まずは、「その行動をすべき背景に何があるのか」を問いました。例えば、
- 「Sansanがどう使われているか」の背景を知るために普段の営業活動がどういうものか
- 「普段の営業活動」の背景を知るために、各営業マンは何を果たすために活動しているのか。何を期待されているのか
- 「各営業マンが期待されていること」の背景を知るために、どんな顧客がいて、どんなビジネスをして、どんな評価をしているのか
といった内容です。
次に「その行動を取る手段や具体的なタスク」を聞きました。例えばこのような内容です。
- 営業マンが成果を出すために、日々どんな行動をしているのか
- それはどんなツールを使って、どんな頻度で、どのように使っているのか
- その時営業マンはどんな不安や苛立ちがあるのか
この間、他のメンバーはポストイットに「追加の質問」「課題」「Sansanで改善できそうなこと」「マインドや活動を改善できそうなこと」など、何でもいいので書いていきます。Sansanメンバーだけでなくユーザの方にもお願いしました。
② ワークショップ「Diverse team are powerful」
それぞれが異なる背景を持ったPM、デザイナー、CS、ユーザが混ぜこぜになり、同じ課題に向き合う、Diverse team。 ちなみに「Diverse team are powerful」はメルカリUSのBrad EllisさんがProductManagerConference2019で仰っていて、素敵だなと思って拝借しました。（Ellisさんは開発国の違いを仰っていたので厳密には違いますが。）
ワークショップでは、提出されたポストイットに対して、更に深堀りして議論したいものに投票します。 後から振り返る時の参考になるよう、ポストイットと投票シールは職種別に色分けしています。
- User (Yellow)
- CS (Pink/Red)
- PM/PMO (Blue)
- Designer (Green)
沢山の気づきが得られました。気づきについて書き始めるとブログが一本できそうなので割愛します。
ワークショップの課題とワークショップを使う価値
ワークショップの課題
話したいことが沢山出たのに時間が足りないことです。普段のヒアリングで1名1時間聞いても足りないくらいなのに1名30分だと質問しきれませんでしたし、ワークショップでも沢山付箋を出してもらったにも関わらず、5つくらいしかピックアップできなかったことは課題に感じました。 改善していきたい点です。
ワークショップを使う価値
状況の違うユーザ対ユーザを比較することで、共通点、相違点が見えました。
今回お越しくださったユーザ様は食品卸業とインフラ支援業と全く業種が異なります。調達先があり営業先があるという点では共通していますが、営業先の業界も規模も商材の単価も営業活動の頻度も異なります。その上で普遍的な課題なのか、個社に特化する課題なのか、比較することで見えた気がします。
例えば共通点は、電話営業に切り替わっており、訪問件数が減り、伴って名刺交換の機会も減っている。つまり名刺を持たずに新規顧客と付き合うことが増えている。行動指標も過去とは違う。などです。
1on1のヒアリングだと見えない「あー、それわかります！うちもです！」「こういう時困りますよね」 ユーザの言葉で会話されるので、社内で営業やCSから又聞きするより臨場感がありました。
また、「気付きませんでした」「気づかないですよね、何故かっていうと、ほとんど開かないですしね」「一覧でタグ表示されるから便利そうだなって最初に思ってしまいました」「確かに、私もそうかもしれません」というように、ユーザ様同士で深堀りしてくださるシーンもありました。
比較できるメリットを感じられているので、デメリットは他で補いつつワークショップは継続していきたいです。 最初はお互いに緊張していたかと思いますが、最後は同志となって課題に向き合っていました。
3. やった感で終わらせない「後日、社内でワークショップ」
こういったイベントをやると、「なんかわかった感」「なんかやった感」「楽しかった」という満足感が増幅します。しかし、「なんかやった感」で終わらせず、きちんとプロダクトに活かせるナレッジとして整理するために、後日参加メンバーで更にワークショップを行いました。 オレンジ色の付箋が追加したものです。
課題を深堀りし、一般的な課題なのか個社的な課題なのかを整理し、どう解決するかを考えました。 これからラフを作りユーザの方に触ってもらえるようにしたいと思います。
後記
B2Bプロダクトは開発側とエンドユーザが遠いです。プロダクト開発から営業マンまでの間にはいくつかの隔たりがあります。プロダクト開発 ↔ CS ↔ 顧客側のSansan管理者 ↔ 営業マネージャー ↔ 営業マンといったように、誰かを介さなければ直接お声がけすることができません。 またこの企画でワークショップの参加ユーザが直接メリットを得られるものでもないので、お忙しい時間を割いてお越しいただくのは難しいのです。この2つのハードルから集客にかなり手こずりました。
そんな中にも関わらずご参加くださり、作り手に沢山の気づきを与えてくださったユーザ様には本当に本当に感謝しています。プロダクトで恩返しできるように日々尽力してまいります！
buildersbox.corp-sansan.com
