PdMだけじゃない！営業やCS、エンジニアも使える要望整理術（フォーマット付き）
背景
10年近くメガベンチャー、スタートアップでエンジニア、PdMとして働いていて、お客さんや自分の要望を社内メンバーがうまく伝えることが難しいと感じている
課題
お客さんや自分の要望をうまく伝えられないと、
・実は、システムの既存機能や運用で対応できるのにシステムに追加開発をしてしまう
・システムに追加開発をしても解決できない
・コミュニケーションに時間がかかる
・結果的に、お客さんに価値を提供できないまたは、提供するのに時間がかかってしまう
という課題が発生する。
本記事で記載する範囲
PdMではない営業、CS等社内メンバーがお客様から要望された内容や、自分の要望をPdM、エンジニアに伝えるための整理、書き方
要望等を整理したものとして、PRD（プロダクト要求仕様書）があるが、営業、CS等社内メンバーが書くのは難しいし、当たり前だが、そこまで書いていたら、要望を書かれなくなってしまうので、対象外
メインの利用としては、営業、CS等社内メンバーが書く想定だが、toBのお客さんにも展開して、書いてもらうこともアリ。ただし、ただ単に要望だけを書いてもらうよりかは、手間なのと、そこそこ難しいので、お客さんに適切に書いてもらうという過度な期待はしないほうがよい
PdM、CSがいない会社では、エンジニアがお客さん、社内のシステム利用ユーザから直接要望をもらうことも多々あるので、エンジニアが要望を整理する際にもにも活用できるはず。
フォーマット
■背景・前提・事実（現在、どういう業務を行っているのか。システムはどうなっているのか）
■課題（誰が、どう困っているのか。頻度、緊急性、エンドユーザへの影響はどの程度か。代替手段はないか）
■要望（本来はどうあるべきか。どうして欲しいのか）
メガベンチャー時代から、独自に、秘伝のタレ的に使っているフォーマット。
前職で、PdMのマネージャーみたいなこともしていて、他PdMメンバーが関与しているプロダクトでなかなか要望の整理がうまくいかなかったときに、アドバイザー的な感じで入って、このフォーマットを使って、複数のプロダクトを安定させたことがあるので、ある程度有用なはず。
前職の大きなプロダクトはROIを算出するところまで求められていたが、要望記載のハードルを高めてしまうと、要望が集まらなくなってしまうので、バランスが大事だと思っている。
このフォーマット自体も、まずは、要望を記載してもらうだけだったが、記載後に、私が、「この要望の課題って何なのですか？」とか、「ちょっとその課題の背景がわからないのだけど、背景を教えてもらえますか？」と、毎回毎回聞いていたので、項目として足して、ブラッシュアップしていったものになる。
なぜ、要望に、背景と課題が大事なのか
お客さんにとって、要望の元となっている課題が解決できることが大事であって、要望だけだと、その要望に対応することが適切かどうか判断できないためである。
お客さんの要望には元となっている課題があり、課題を明確にせず、要望のまま対応することは、下記の観点からよろしくない。
・そもそも課題認識が間違っているかもしれない
・大きな課題ではないかもしれない
・要望をそのまま対応することで、逆に、大きな課題が発生するかもしれない
・オペレーションの変更、システムの既存機能で代替できるかもしれない
・要望をそのまま対応すると、開発に数ヶ月かかって、お客さんを待たせるかもしれない
そして、課題の前提となる「現在、どういう業務を行っているのか。システムはどうなっているのか」といった情報が背景である。お客さんによって、業務が異なっていたり、特殊なケースがあったりするので、要望を読む人が認識をあわせられるようにするために、背景も大事である。
要望ヒアリングの仕方
お客さんは、背景、課題を省略して、要望から言ってくることが多い。また、言葉が曖昧なことも多い。
ケースとして、専任トレーナーが付くトレーニングジムの予約システム（お客さん側と店舗側両方で予約が可能）を提供しているプロダクトで考える。
店舗のスタッフから「予約する際に、名前を入れなくてもよいようにして欲しい」という要望があった際に、どうするか？
アプローチとして、3つの流れで確認するとよい。
①まずは、背景と課題を確認する
②仮説を当てにいく
③5W1H、曖昧な単語を確認して、掘り下げる
①まずは、背景と課題を確認する
素直に、「背景と課題を教えてもらってもよいですか？」と聞いてしまうと「背景は、予約する際に、名前を入れなくてもよくして欲しいんです。課題は、予約する際に、名前を必ず入れないといけないので困っているんです」のように、背景、課題として、不十分な回答になることがしばしばある。「予約する際に、名前を必ず入れないといけない」は背景の一部にはなるが、「困っている」だけでは、どう困っているのかという課題がわからない。そもそも、背景と課題と要望の違いを正確に理解して回答してもらうこと自体が難しい。
そのため、「誰が、どのように困っているんでしょうか？」と、まず答えやすい聞き方で、課題を聞いてみるのが一番よいと考える。質問の結果、「ジムのスタッフがお客さんから予約があった際に、名前の漢字がわからず、困っているんです」といった回答がもらえれば、最低限の課題の理解ができるようになる。
最低限の課題が理解できれば、自分の方で「今のシステムの仕様では、お客さんの漢字の名前が必須になっている」というシステムの背景を書いて補足することができるようになる。
だだ、これだけでは、「お客さんの名前の漢字がわからないってどういう時だろう？」といった疑問が浮かび、課題、背景として、よくわからないことも多い。そのため、次の「②仮説を当てにいく」確認が必要になってくる。
②仮説を当てにいく
ドメイン知識や経験が必要になるが、闇雲に質問するよりも、仮説を当てにいくほうが、要望を出す側としては、仮説が当たっていた場合は、話が早くて楽だし、当たっていなかったら、こういうことですと訂正してくれるので、効率的になる。
上記の例だと、「新規のお客さんからの電話予約があった際に、漢字の名前を聞きにくいので、入力にお困りでしょうか？」とか、「外国人のお客さんからの予約で、漢字の名前がない場合の入力でお困りでしょうか？」のように、今までの経験や、ドメイン知識、想像力を駆使して仮説を当てにいく方法がある。
そもそも、どうやって、仮説を出すのか
仮説を立てるためには、その課題が起きている現場をリアルに想像できることと広い観点が大事で、いわゆる解像度の深さと広さが必要だと考える。
「解像度を上げる」に記載されている下記によって、仮説を作る力が身につき、精度を増すことができると考えている。
注意点としては、ドメイン知識や経験が必要なため、そもそも仮説が出ないとか、あまりにピント外れな仮説な場合、「この人は任せて大丈夫なのだろうか？」と信頼感が失われるリスクがあるため、「②仮説を当てにいく」を省略して、次の「③5W1H、曖昧な単語を確認して、掘り下げる」の確認をするのも有用である。
③5W1H、曖昧な単語を確認して、掘り下げる
5W1Hを確認
いわゆる5W1H（「When（いつ）」「Where（どこで）」「Who（だれが）」「What（なにを）」「Why（なぜ）」「How（どのように）」）で質問していく。
今回の「ジムのスタッフがお客さんから予約があった際に、名前の漢字がわからず、困っているんです。予約する際に、名前を入れなくてもよいようにして欲しい」という例だと、「Who（だれが）」、「What（なにを）」、「When（いつ）」、「Why（なぜ）」までは分かったが、「Where（どこで）」、「How（どのように）」が不明である。「どういう時ですか？どの画面でですか？今は、どのようにやっているのですか？」みたいに必要に応じて、網羅的に聞くことができる。
注意点としては、あまりに5W1Hが入ってない回答があった際に、網羅的に、いろいろと一度に聞きすぎると、要望を出した側が、質問されまくっているな、、答えるのが面倒だな・・と思われるリスクがあるし、質問する側としても、効率的ではない。その場合は、「②仮説を当てにいく」方法をTRYしたいところである。
5W1Hの中でも、システムの要望において優先して確認すべきなのは「Who（だれが）」、「What（なにを）」、「Where（どこで）」そして「Why（なぜ）」を確認することが重要であり、「When（いつ）」、「How（どのように）」の確認は、後から必要に応じて確認するのがよい。「Who（だれが）」、「What（なにを）」がわからないと何も始まらないし、システムなので、基本的には、画面なりがあるはずなので、「Where（どこで）」という情報が重要である。そして、日本語は、主語を抜いても成立する言葉なので、「Who（だれが）」が抜けることや、「Where（どこで）」が抜けるがしばしばある。逆に、「When（いつ）」は、常にそうして欲しいのかもしれないし、「How（どのように）」は、「Where（どこで）」≒どの画面かが分かると、ある程度想像が付くことが多いため、確認は必須ではない。
曖昧な単語を確認
曖昧な単語として、今回、「予約」、「名前」という単語がある。
どういうシステムなのかにもよるが、予約といっても、ジムのお客さんがWebから予約するのか、店舗のスタッフが予約するのかによって対象となる画面が異なったり、ジムのお客さんだったとしても、新規なのか、すでに通っているのかによって、対象の画面が異なったりする場合がある。そのため、どういった予約なのかを確認するとよい。
名前については、「漢字がわからず」という話があったから、お客さんの漢字の名前なのだと思われるが、ふりがなの名前なのか、それとも専任トレーナーの漢字の名前なのか等も考えられる。そのため、どの画面のどの名前が対象なのかを明確にするため確認するとよりよい。
5W1Hも曖昧な単語を確認するコツとしては、対象の人がシステムの画面なりを使っているところを具体的にイメージしてみること。イメージができないのであれば、そこが不明確なので、確認するとよい。
課題の掘り下げ応用編
そもそも、なぜ要望を書くのかというと、PdM、エンジニアに伝えて、課題を解決するために、機能開発なりをするためである。PdM、エンジニアにただ正確に伝えられたら機能開発がなされるかというと、そういうわけでもなく、どこの会社も開発案件が多いため、課題が大きく、課題を解決できた時に、価値が高いと判断される課題、要望の方が、機能開発される可能性は高い。
私が作った課題のフォーマットとして、「■課題（誰が、どう困っているのか。頻度、緊急性、エンドユーザへの影響はどの程度か。代替手段はないか）」としている。「誰が、どう困っているのか」の部分が課題の根幹となる部分である。
「頻度、緊急性、エンドユーザ・決裁者への影響はどの程度か、代替手段はないか」を確認、書くことは、課題の大きさを判断するための大きな判断材料になる。頻度は、月に1回なのか毎日何回もなのか、緊急性は、業務が止まるリスクがあるくらいなのか、ちょっと不便なくらいなのか等によって課題の大きさが異なる。toCビジネス場合は、社内の手間よりもエンドユーザへの影響を重視する傾向があるため、こちらも課題感としてよい判断軸となる。「代替手段はないか」については、既存のシステム機能や他システムを使って、業務を回せるのであれば、課題感として、大きくないのではないか？と判断するためのものである。
「頻度、緊急性、エンドユーザ・決裁者への影響はどの程度か、代替手段はないか」は確認、書く方がベターではあるが、毎回確認することも手間なので必須とはしておらず、開発の優先度を上げたい場合の補足情報として、使うのがよいと考える。
課題の掘り下げについては書いたが、「要望」の掘り下げは書いていない。それは、課題さえ明確になっていれば、対応方法はいろいろと考えられ、それは、PdM、エンジニアが掘り下げて、対応方法として、比較検討すべきことだからである。そのため、私が要望について営業、CSとミーティングする際は、要望はいったん置いておいて、課題と背景の明確化をまず行っている。
課題記載のNG例
営業、CS等がよく課題に記載するNG例と対応案をいくつか挙げる。
「XXができなくて困っている」、「XXXが表示されておらず分からない」、「XXXできるようにして欲しい」という記載で、課題がわからない
どう困っているのかがわからない。誰が困っているのかわからない。誰が、どのように困っているのかを確認して、書いて欲しい。
課題に、背景に書かれるべき事実だけが書かれることが多々ある。「XXXが表示されておらず分からない」から、「お客さんの取り違えリスクが発生し、お客さんからクレームになるリスクがある」のか、「スタッフが別の画面まで見ないといけなくなり手間である」のかくらいまで書いて欲しい。
ある特定のケース、設定、状況において発生する課題だが、課題、背景に書かれていない
なかなかこれを書くことは難しいようなのだが、けっこうありがち。「予約する際に、名前を入れなくてもよいようにして欲しい」という要望を書く際に、外国人の予約なのか、新規の予約なのか等の特定のケースがきちんと書かれていると、伝えられる側も理解しやすい。
「XXに困っているんだと思います」のように課題の内容が想像
「XXが表示されておらず分からない」といった背景を元に、営業、CSが、「XXに困っている」、「XXに困っているんだと思います」と想像で書くことがたまにある。これはまさに課題の仮説であり、仮説が間違っている可能性もある。せっかく仮説が立てられているということでもあるので、きちんとお客さんに仮説を当てて確認しよう。
「すでにあがっていた要望NoXXと同じ」という記載
同じ背景、同じ課題であれば、問題ない。しかし、例えば、同じ「予約する際に、名前を入れなくてもよいようにして欲しい」という要望があった際に、課題が異なり、
・新規のお客さんからの電話予約があった際に、漢字の名前を聞きにくいので、入れたくないのか
・外国人のお客さんからの予約で、漢字の名前がないので、入れたくないのか
と別だった場合に、頻度、課題の大きさは違うはずなので、別で要望を書くべき。
会社によってルールがあるだろうが、同じ背景、同じ課題、同じ要望でも要望を記載すること自体は、いろんなところで同じ要望があがっているというよい情報なので、よいと思う。
代替手段を提示したが、NGだったことを記載していない
課題フォーマットに「代替手段はないか」も記載しているが、代替手段を要望を出した方へ提示したが、NGだった際に、書かれていないことが多々ある。営業、CSとの要望ミーティングの際に、PdMが同じような代替手段を提示したり、エンジニアが開発途中で、実は、開発しなくても、この代替手段で解決しませんか？と相談されたりする。その代替手段でNGなことも重要な背景であり、課題なので、書いて欲しい（結局、PdMが追記することが多い）。
複数の課題が混ざっている
・新規のお客さんからの電話予約があった際に、漢字の名前を聞きにくいので、予約の名前を入れたくない
・外国人のお客さんからの予約で、漢字の名前がないので、入れたくない
という別の課題を「予約する際に、名前を入れなくてもよいようにして欲しい」という１つの要望に書いた時に、もしかしたら、一つの対応で解決できるかもしれないが、前述したとおり、頻度、課題の大きさも違い、片方の課題は機能開発ではなく、オペレーションで解決できるかもしれないため、基本的には分けて書いて欲しい。
背景について
ここまで課題の書き方、掘り下げ方について書いてきたが、それでは、背景を書くコツは何なのだろうか？
根本的に、背景、課題、要望の中で、課題が一番重要であり、背景は課題を説明するための情報だと考えている。
極端な話、課題の記載だけで、PdM、エンジニアに課題の内容、大きさが伝わるのであれば、背景を無理して書く必要はない。現在のシステムがどういう仕様になっているか、どういうお客さんなのか、お客さんの行動、業務がどのようになっているか、について記載することが多いが、特に、後者の情報は、直接やり取りをしている営業、CSは暗黙的に把握しているが、PdM、エンジニアには分からない情報なため、重要である。
Saasの場合、いろんなお客さんがプロダクトを使っていて、そもそも営業中のお客さんなのか、導入済みのお客さんなのか、お客さんでも決裁者からの要望なのか、現場スタッフからの要望なのかによっても、課題の大きさ、対応するスピードの必要性が変わってくるため、誰からの要望なのかというのも背景として重要な情報である。
また、今回の例だと、「専任トレーナーが付くトレーニングジムの予約システム」という前提を出したが、店舗によっては、外国人の比率が多い店舗とか、試験的に専任トレーナーが付かないトレーニングジム店舗をやっているみたいなケースはあるわけで、そういった特殊事情がある場合も、情報として書くほうがよい。
この記事が気に入ったらサポートをしてみませんか？