tebiki現場分析のプロダクトマネージャーをしている中山です。
機能開発では、みなさん、お客様の声を大事になさっているかと思います。当社ももちろんそうです。
この記事では、お客様の声をどう機能開発に取り入れているか、実際の作業について紹介します。
前提：この記事で出てくる用語等
tebiki現場分析はB2Bのクラウドサービスで、製造業、特に工場でお使いいただく記録・分析のデジタル化サービスです。
「現場」という言葉は、生産や検査など製造に関する作業をおこなっている場所を指します。
工場で、作業者の方がモノを組み立てたり機械が動いていたりするところを想像してください。
取り組みの効能
①利用率の高い機能≒お客様のほしい機能を開発できる確度が上がる
②機能リリースのスピードが上がる
既存のお客様、商談中のお客様に対し、いずれもポジティブな影響を得ています。
機能開発前後の業務の流れ
tebiki現場分析におけるPdM目線の業務の流れです。
この記事では、④・⑤の詳細について説明します。⑥も少しだけ触れます。
①PdMが「ロードマップ」と「機能開発の優先度判断軸」を作成
②カスタマーサクセス(以下、CS)が、お客様要望を取得し、PdMに所定の方式で伝達
③毎週、CSとPdMで①と②に基づいて優先度を決定
④優先度が高いものについて、要望から課題への変換を実施 (具体化)
⑤課題を場合分けし、ユースケース化 (抽象化)
⑥開発範囲の決定
⑦ソリューション検討(UI含む)
⑧開発・リリース
⑨開発後の利用状況の調査
1．要望から課題への変換 (具体化)
「お客様の声」をそのまま飲み込んではいけない
お客様が、ご要望やご意見を一生懸命伝えてくださるとき、そこには主観が色濃く混じります。
この主観が大事なインサイトでもあるのですが、ときには本当に必要なものや現場が困っていることから離れてしまっていることがあります。
例えば、「記録の承認が必要になったときは、承認者にメールを送信してほしい」という声。
これをこのまま機能開発することはもちろんできますし、開発すれば、お客様の声を取り入れていると言えるでしょう。
しかし、現場では、1日数十件の承認依頼が1ユーザーに対して発生します。
はたして「お客様の声」をそのまま飲み込んで機能開発してしまって良いのでしょうか？
要望から課題へ
要望というものは捨象すると、「AさんがBを欲しがっています」というレベルの情報量しか持っていません。
PdMとしては、「AさんがBを欲しがっています、すごく欲しいそうなので作ります」でゴリ押すこともできなくはないんでしょうが、これをし始めると声の大きいものが勝つ環境ができてしまい、「適切な優先度判断」とかいう理念は幻想となって吹き飛びます。
また、「欲しがっているもの」と「必要なもの」は違うことがままある、という経験則に照らしても、要望の状態のまま開発を進めるのは得策ではありません。
ですので、要望に背景情報を足していき、「AさんがCという業務でDに困っていて、解決するとEということが起きます」という形、つまり課題に変換することが重要だと考えています。「要望の具体化」と捉えてもよいでしょう。
要望から課題への変換における4観点
わたしの場合、以下4観点で、お客様の声に対して背景情報を足しています。
①業務の流れ
現場のどの工程のどの業務で何が起きているのか？
具体的には、誰がいつ何のために何をしているときに困ったのか？
PdMがお客様に直接ヒアリングして情報を得たり、②を使って類推したりしています。
②現場で実際に使っているもの
現状運用している帳票や分析ファイルの実物。もしくはこれから運用したいと思っているもの。
そして、それらの利用状況。
当社の場合、CS経由で頂戴しています。
③お客様のサービス上での動き
ご要望に関係する機能をどれだけ使っているか？ボタンをどう押したか？など、サービス上のユーザーの行動データ。
④お客様のなかでの優先度
その機能がないと、業務が滞るのか？ちょっとつらいだけなのか？
当社の場合、CSが要望とセットで報告してくれています。
例
では、実際に上記の観点で、要望を課題に変換してみます。
(なお、以下はあくまで例で、実際のお客様の状況を記載したものではありません)
■ 要望
記録の承認が必要になったときは、承認者にメールを送信してほしい。
⇩
■ 課題
・AさんはXX株式会社のYY工場の品質管理部門の課長。YY工場ではZZという製品を製造している。
(①の情報)
・Aさんは管理者で、記録の承認者が承認を忘れてしまうことに困っている。
承認を忘れると誤った内容の見落しにつながり、例えば不良の出荷を防げない。
また、監査時の指摘事項(管理不足)になることがあり、管理業務が増えたり、認証の取り消しなどにつながったりする。
Aさん1人で、承認者すべての承認モレをすべて管理するのは時間がかかる。(①の情報)
・承認者はN人いる。平均して、1人あたり1日XX件の記録を承認する必要がある。一方、1ヶ月で合計XX件の承認モレが発生している。(②の情報)
・承認者のサービスへのログイン頻度はXX回/日。(③の情報)
・優先度は「中：あると現行より改善ができる」ぐらい。(④の情報)
いかがでしょうか。要望だとメールについて触れられていますが、課題だと特にメールに関する内容はでてきません。実際に困っていることは「メールが送られてこないこと」ではないからです。
このように、各社から頂戴している要望について、1件ずつ情報量を増やして課題に変換しています。
2．課題を場合分けし、ユースケース化する (抽象化)
課題はまだ素材
1つの機能を開発するにあたり、要望1つだけを取り上げることはなく、類似の要望をいくつか集めてきてそれぞれ課題に変換しています。
課題は具体的な情報の集まりです。重要な情報ではありますが、それらがただ並んでいるだけではソリューション検討のポイントを絞れず、エンジニアやデザイナーとの会話がスムーズに進みません。
ですので、個々の課題を抽象化し、同じものはまとめつつ場合分けすることが重要です。
当社では、場合分けしたものを「ユースケース」と呼んでいます。
先ほどの例をユースケースにするならば、「承認者自身が承認が必要な状況に気がつくことができる」などになるでしょう。
(ユースケースはさまざまな事柄を指す言葉です。それぞれの会社で適切な単語があるかと思いますので、適宜読み替えてください)
課題からユースケースへの変換における手順
わたしの場合、以下のような手順で課題からユースケースに変換しています。
①各課題を一言で言ってみる
・各課題を一言でいうとこうだな、という観点で抽象化してみる。これが各ユースケースの名前となる。
(例) 承認者自身が承認が必要な状況に気がつくことができる
・主語を入れる場合、主語はサービスで定義されているペルソナを用いるのが望ましい。
(例) 記録者、承認者など（tebiki現場分析の場合)
②各ユースケースの相違点を項目化する
・書き出す項目は、扱うテーマによっても、開発するシステムによっても異なる。
・よくある例
(a) 行動の主体者：ペルソナ、システムにおける権限
(b) 行動のタイミング、頻度
(c) 対象の作業：作業の順番、行動の対象となるシステム上のオブジェクトなど
(d) その他：回数や量、期間
③表形式で相違点をまとめる
②を表現するのに適しているので、tebiki現場分析では表を使用しています。
④ユースケースごとの現場における要望の頻度を書き込む
要望されることの多い内容なのかどうかを「よくある」「たまにある」「ほとんどない」ぐらいの表現で書きこむ。
特に注意すべきは「②各ユースケースの相違点を項目化する」です。
ここを誤ると、ユースケースが必要以上に細かすぎる、または大雑把すぎてしまい、不要な検討ポイントに時間が使われたり、逆にポイントを見落としてしまったりということにつながります。
エンジニアや他のPdMに壁打ちを依頼してもよいかもしれません。
例
実際に上記の手順で、課題をユースケースに変換したものを掲載します。
各ユースケースの同一点と相違点について一覧的に見ることができます。
3．開発範囲の決定
ユースケースを元にした開発範囲の決定
当社では、ユースケースを使って開発の範囲を決定しています。
前項の例で言えば、3つのユースケースのうち、どれを実装するのか？すべてか？あるいは一部か？すべての場合タイミングはどうするか？ということを検討します。
ユースケース単位になっているので「小さくはあるが顧客の困りごとを解決できる」範囲にスコープを絞ることができます。
これにより、お客様が必要とするものを満たしつつ、リリースのスピード感も確保するという効能を得ています。
余談：文章化について
わたしたちのチームでは、ここまでの検討内容をすべて文章にしています。
スライドやfigmaなどのビジュアライズに優れたツールも利用はしますが、PdMとして、エンジニア、デザイナー、QAといったチームに説明する内容はすべて文章化します。
わたし個人はスライドづくりが大好きで、図式化にも(少しだけ)自信があります。
しかしながら、スライドは抽象化した結果を表現するには素晴らしいものですが、具体を深堀りし、再度抽象化していくプロセスを過不足なく記述するには、あまりに狭いです。
(スライドの枚数は問題でなく、あの四角いキャンバス領域そのものが記述の制約になります。抽象化にとって制約は有益ですが、その反対においては邪魔と言わざるを得ません)
チームが正確にお客様の声を理解し、ソリューション検討に進むためには、文章化が最適なプロセスだと考えています。
最後に
以上が、現時点でのわたしの取り組みとなります。
AIの活用も進めたいですし、わたし以外のPdMメンバーとも知見を共有し、よりよい方法を探っていきたいと考えています。
また、わたしの勉強が足りず、常日頃エンジニア、デザイナー、QA、CS、セールスなどチームに助けてもらいながら、この業務プロセスを進めています。
そのような発展途上のPdMの取り組みとして受け止めていただければ幸いです。
Tebiki社では一緒に働く仲間を募集しています！
ぜひ採用サイトをご覧ください。
▼採用HP
tebiki.co.jp
▼募集中のエンジニア求人一覧
herp.careers
