機能要望は誰が決める？受付・判断・回答の役割を分ける方法
営業から届いた機能要望を会議に出しても、「誰が決めるか」が曖昧なまま残っていませんか。機能要望は、自社の製品方針と開発の優先順位に責任を持つ人が、関係者の情報を集めて判断する形を決めておくと扱いやすくなります。役職名だけでなく、決められる範囲を明確にすることが大切です。
この記事では、受付から回答までの役割を分け、意見が割れた場合にも次の行動を決める方法を扱います。要望を比較する基準は、開発優先順位の決め方で紹介しています。
- 最終判断する人と、その人が決められる範囲を確認する
- 受付・情報収集・判断・回答の役割を分ける
- 意見が割れたら、不足する根拠と次の判断日を決める
最終判断する人と、決められる範囲を確認する
最初に確認するのは「この要望の対応可否と優先順位を、誰が決められるか」です。PMという役職があっても、予算や契約上の約束まで一人で変更できるとは限りません。
スクラムを採用するチームでは、2020年版スクラムガイドが、プロダクトオーナーにプロダクトの価値を最大化する責任と、プロダクトバックログを効果的に管理する責任を置いています。ただし、これはスクラムの役割定義です。すべての企業で、同じ役職名の人が自動的に最終判断者になるという意味ではありません。
自社では「通常の機能改善」「追加予算が必要な開発」「特定顧客との契約条件を変える対応」など、判断する範囲を分けて確認します。権限の範囲を超える場合は、誰へ相談するかも合わせて決めます。
たとえば、架空の小さなSaaSチームなら、通常の改善は製品責任者、予算の追加は事業責任者へ確認する形が考えられます。これは役割分担の例であり、役職を増やす提案ではありません。同じ人が兼ねる場合でも、何を決めているかを分けると説明しやすくなります。
受付と判断を同じ責任だと考えない
顧客から要望を受けた人は、受付を進められても、実装を約束できるとは限りません。受け取った段階で約束できることと、判断後に伝えることを分けます。
AtlassianのDACIという意思決定の役割分担では、進行を担う人、最終判断する人、専門情報を提供する人、決定を知らされる人を区別しています。要望管理へ取り入れるなら、顧客との受付・回答も含めて、次のように整理できます。
| 役割 | 担うこと | その役割だけでは決めないこと |
|---|---|---|
| 受付 | 原文と困った場面を記録する | 実装する機能や期限 |
| 情報収集・進行 | 不足情報を集め、判断の場を用意する | 権限のない予算や契約変更 |
| 最終判断 | 対応可否と優先順位、判断理由を決める | 技術的な確認を省いた実現性 |
| 顧客への回答 | 決まった範囲と次の連絡を伝える | 未定の対応を独自に約束すること |
この表は本記事の運用案で、DACIの名称をそのまま置き換えた正式な定義ではありません。小さなチームなら一人が複数の役割を持てますが、要望の記録には次に動く人が分かるように残します。
受付で背景情報をそろえる方法は、営業・CSの顧客要望を開発へ渡す方法が参考になります。渡す先が「開発チーム」だけでは個人の行動につながらない場合は、最初に確認する窓口も決めておきます。
判断を頼むときは、選択肢と不足情報をそろえる
最終判断者に渡すのは、要望の一覧だけではありません。何を決めてほしいかと、その判断に使える情報を短くまとめます。
たとえば、架空の申請管理ツールで代理承認の要望を検討するとします。「重要な顧客の希望です」だけでは、判断する範囲が分かりません。「担当者の不在時に申請が止まる。今回は回避策を案内するか、追加調査するかを決めたい」と書けば、会議で決めることを絞れます。
記録には、顧客が困った作業、現在の回避策、関係する顧客の範囲、実現性の確認状況を添えます。まだ工数を見積もれないなら、その理由を残し、見積もりの前に確認する人を決めます。根拠のない数字で欄を埋める必要はありません。
判断する人には、実装以外の選択肢も渡します。案内の改善、運用での対応、追加調査、今回は見送りといった候補があれば、作るか作らないかの二択だけで話が止まることを避けられます。
意見が割れたら、次に確認する根拠を決める
営業と開発の意見が異なる場合は、何を重く見ているかを分けて確認します。営業は契約の判断時期を、開発は既存機能への影響を見ているかもしれません。片方の意見を多数決で消す前に、それぞれの根拠を残します。
会議を終えるときには、決定か、次の判断に必要な確認のどちらかを残します。「継続検討」だけで終わらせず、「顧客の代替手順をCSが確認する」「開発が権限への影響を調べる」のように、確認する内容と担当を具体化します。
判断を先送りする場合は、いつ情報を持ち寄るかも決めます。日付は実装の約束ではなく、次に判断材料を確認する時点です。返答が得られなかった場合にどう扱うかも決めておくと、同じ議題が説明なしに残り続けることを防げます。
権限を超える対立なら、合意できた点と未解決の点を分けて、相談先へ渡します。最終判断者が変わった場合も、顧客への回答担当を曖昧にしないようにします。
判断後は、理由と再検討の条件を受付の記録へ戻します。見送った理由が「対象の顧客が分からない」なら、追加の利用場面が分かったときに再確認できます。以前の判断を無視して同じ話を始めずに済み、顧客への説明もそろえられます。
よくある質問
PMがいないチームでは、誰が決めればよいですか？
製品方針と開発の優先順位に責任を持つ人を確認します。専任のPMを置くことより、判断する範囲と、範囲を超えたときの相談先を明確にすることが大切です。
営業が顧客へ実装を約束していた場合はどうしますか？
約束した内容、時期、前提を事実として確認し、対応を判断できる人へ共有します。受付担当だけで約束を上書きせず、実現性と顧客への説明を関係者でそろえてから回答します。
全員の賛成がそろうまで待つべきですか？
意思決定の方法を先に決めます。関係者の懸念を記録したうえで、最終判断する人が決められる範囲なら判断を進めます。根拠が不足する場合は、必要な確認と次の判断時点を残します。
まとめ
機能要望を誰が決めるかは、最終判断する人と、その人が決められる範囲から確認します。受付・情報収集・判断・回答の役割を分け、意見が割れたら不足する根拠と次の判断日を決めます。止まっている要望を一件選び、この役割が埋まっているか確かめると、次に誰が動くべきかが見えてきます。
