プロダクトマネージャーが抱える悩みの一つに、「ユーザーやステークホルダーから上がる無数の要望をどのように取捨選択すればいいか」という問題があります。
要望リストに載ったものの、“対応する課題が大きくない”、“ユーザーがコスト（お金や時間）を払うほどの痛みではない”課題はどう扱うべきでしょうか？このレベルの課題を無制限にバックログへ放り込んでしまうと開発チームやマネジメント層から「結局何をいつ作るの？」と不満を抱かれがちです。かといって、すべて握りつぶすと「ユーザーの声を無視している」と批判されかねません。
そこで本記事では、このような”非採用課題“をどう扱うかを深掘りします。課題自体を削除する判断基準や優先度管理の仕組み、そしてチーム合意を得るためのコミュニケーション手法を紹介します。最後まで読むと、“やらない課題”がいつまでもリストを埋め尽くしてプロダクトが停滞する事態を防ぎ、開発リソースを本当に必要な領域に集中させられるはずです。
なぜ“非採用課題”の扱いが難しいのか
ユーザーやステークホルダーからの要望を「やらない」と決めるには決断力と心の強さが必要。ユーザーからは「せっかく課題を伝えたのに、開発されないのか」という不満が生じる可能性があるからです。また、セールスやCSチームからしても「ユーザー要望を無視している」と見られかねません。
ただ、一口に「要望＝必ずやるべき課題」とは限らないのが実態です。本気の課題であれば、ユーザーインタビューや社内ステークホルダーからの要望で「その課題は顧客がコスト（時間/お金）を払ってでも解決したい、今時点でコストを払っている」傾向が見て取れるはずです。このような状態を放置すると、膨大な“やらない課題/機能”でバックログやロードマップが肥大化し、開発優先度の可視化が難しくなります。
ロードマップへの明示と社内外への情報共有
では、実際に非採用課題をロードマップ上でどう扱うか？
「そもそもロードマップに載せるべきかどうか」の判断を行い、ユーザー要望があったとしても本気度や優先度が低く今後やる可能性が限りなく低いならバックログにすら入れない選択も十分にアリです。どうせ本当に課題が大きいなら、そのうちまた要望として浮上してくると考えられます。
ただ、この時にユーザーや社内ステークホルダーに「どの課題が採用され、どれが見送りになったか」を明確に伝えておかないと、“要望の行方が見えない”という不満がたまる可能性があります。そこでおすすめなのが、ロードマップやバックログとは別に「要望リスト」を作成しておくことです。
このリストには以下を記入しておきます。
- リクエスト内容：どんな要望か？
- リクエストした人：リクエストしたのは誰か？
- 日付：リクエストが発生した日付
- バックログへの反映有無：バックログに反映したか？
- 現時点不採用または保留の理由：（バックログに反映しない場合は）なぜ反映しないか？を記載する
特に、不要用の理由を背景情報として記載をしておけばCSやセールスにも安心して「今回は優先度が下がっている」と伝えられます。
“バックログから消す”のは本当に大丈夫なのか
非採用課題を一旦はリストに入れない、あるいはもう削除してしまうという判断は勇気が要ります。しかし、先ほど記載したように「どうせ大きな課題ならそのうちまた浮上してくるだろう」という考え方を持つとある程度踏ん切りがつきます。
僕自身、過去に「この要望は重要だと言われたが、実際にユーザーが意欲を示さない」ケースを何度も見ました。そんな時は、無理に残しておくより思い切って消してしまうほうがロードマップがシンプルになるし、優先度決めも楽になります。結果として、ユーザーが本気で困っている課題だけが残り、そこにフォーカスして開発を進められます。
もし本当に痛い課題なら、繰り返しユーザーやチームから「なぜ作らないの？」と声が上がるはずです。そうなって初めて「やっぱりやるべきか」と再評価すればいい（もちろん初手で全力で優先度検討をした上で）。逆に誰も声を上げない課題は、たいして痛くない可能性が高いため、そこまで気にしなくても問題ありません。
やりたいことリストが多すぎてどれも中途半端に終わってしまうよりは、一旦取り除くことでチームの集中力を保つほうがよほど健全です。
コミュニケーション例：営業やCSへの説明テンプレ
非採用課題を決めたときに、営業やCSにどう伝えればいいのか。よくある質問として「ユーザーが文句を言ったら困る…」という声を耳にします。そこで先ほど記載した「要望リスト」をもとに会話するのがおすすめ。
| 要望 | ステータス | 理由 | 今後の可能性 |
|---|---|---|---|
| カスタム帳票の細分化機能 | 不採用（現時点） | 導入企業の利用率が低い。ROIが合わない | 今後大型アップデートで一部カスタム化を再検討予定 |
| 全ユーザー向けフォーラム実装 | 消去 | ユーザーが別のSNSで十分やりとりしている | 要望再浮上時に再審議 |
実際に理由はもう少しだけ詳しく書く必要があると思いますが、これを営業やCSが閲覧できるようにし「もしユーザーから問い合わせがあれば、この表を元に説明してください」と案内します。ポイントは、「不採用」にした理由を一言でも書くことと、「将来の可能性」を残しておくこと。そうすれば「完全に諦めたわけじゃないが、今やる価値は薄い」というニュアンスが伝わり、CS担当も回答しやすくなります。
何より大事なのは、チームが同じ情報を共有していることです。そうすれば、現場レベルでユーザーと接するときに「今回、その要望は一旦見送りです。でも、もし活用事例や大きな要望が増えればロードマップを再検討しますね」と堂々と言えます。
非採用課題も資産化すれば、将来の判断材料になる
改めて、非採用課題をロードマップ上でどう処理するかはPdMにとって悩ましいテーマ。ただ、本気度の低い課題やユーザーがコストを払わない課題を無制限に抱えるほど、プロダクト開発チームは混乱します。いらない課題を放置すれば、ロードマップが膨らんで優先度が曖昧になり、開発チームやビジネス側がレバレッジの高い施策に注力しにくくなるからです。
一方、何でもかんでも即断で削除すると、ユーザーや営業との関係がぎくしゃくするリスクもあります。そこで「要望リスト」の形で公の場で理由を明記しつつ保留しておく形をとるとコミュニケーションが円滑です。本当に大きな課題なら、いずれまた要望が出るはずなので、そのときに再審議すればいい。いまはやらないという結論を認め、リソースを集中したい優先課題に投下するほうが、プロダクトの成長には合理的です。
その時にPdMとして大切なのは「やらない」課題をどのように扱うのかを、チームとステークホルダーに透明性高く共有すること。そうすれば、「本当に解くべき課題」だけが選別され、プロダクトの価値を最大化しやすくなります。非採用課題も適切に資産化すれば、将来の判断材料として必ず役に立つと僕は実感しています。
参考情報
- Harvard Business Review (2021). “Stop Building Features Users Don’t Need.”
- Wojciech L., “Roadmap Management for Modern Teams,” Product Coalition, 2019.
今日から実践できるアクション
- 要望リストを試しに作る
バックログから「いまやる価値が低い」と判断した課題をピックアップし、簡単な理由と将来の可能性を添えてリストにする。エンジニアやCS、セールスと共有して意見をもらう。 - “やらない”課題を思い切って削除してみる
大胆に除外しても、もし本当に痛い問題ならユーザーや社内から再度声が上がるはず。バックログやロードマップをスリム化してみる。
Q&A
- Q1: ユーザーから「なぜ開発してくれないの？」と詰められたらどう対処しますか？
- A1: 「要望リスト」のコミュニケーションでもダメなら、実際にプロダクトマネージャーが営業MTGなどに参加してみるのもおすすめ。もちろんその分時間を使いますが、顧客理解にもなるので有力セグメントの場合は同席してみるのがおすすめ。
- Q2: 非採用課題を手動で管理するのが面倒です。何かツールはありますか？
- A2: JiraやAsanaといったプロジェクト管理ツールのカンバン機能で「Won’t Do」「保留」カラムを用意するか、シンプルにスプレッドシートで作成するのがおすすめです。大事なのは、現場の営業にアクセス権があること。
- Q3: 営業から「一覧に載せるだけでも価値がある」と言われますが、リストが膨大になって困ります…
- A3: 膨大になると本当に困りますね。その場合は「半年以上手つかずの要望は消す」という運用ルールを設定しておくといいです。本当に重大な課題なら、必ず再浮上するので問題ありません。今やらないものは思いきり外してから再度議論に挙げるのがシンプルです。
コメント