担当者は機能要望の投票をどう使う？票数と背景を確かめる運用
目次
票が多い機能要望から開発すべきか、迷っていませんか。機能要望への投票とは、顧客が既存の要望に賛同を示し、担当者が関心の集まり方を把握する方法です。ただし、投票数だけでは、顧客が困る場面や開発に必要な工数までは分かりません。
この記事では、法人向けサービスの担当者が投票を集め、背景を確認し、判断を顧客へ伝える運用を扱います。要望の受付全体を整える手順は、機能要望管理の基本で確認できます。
- 投票者数と社数を分けて、関心の広がりを確認する
- 投票した顧客に、困った作業と回避策を聞く
- 判断理由と次の連絡日を、顧客へ伝える
担当者は、投票の意味を募集前に伝える
担当者は、顧客が投票を開発の約束と受け取らないよう、募集時の説明を用意します。顧客が「一定の票が集まれば必ず実装される」と期待すると、見送る理由を伝えても、両者の認識はそろいません。
顧客フィードバック管理ツールのCannyは、投票の運用ガイドで、票を判断材料のひとつとして扱い、製品の方針や開発の負担と組み合わせる考え方を示しています。投票の入口には、次のような説明を置けます。
私たちは、皆さまの投票とコメントを、要望の背景を理解するために使い、困っている業務、製品の方針、開発の負担を確認して対応を検討します。投票数は、実装や提供時期を約束するものではありません。
この文は募集時の説明例で、アーコレの実際の運用を示すものではありません。あわせて、投票できる対象者、結果を確認する担当、次に状況を伝える日も決めます。投票後の流れは、顧客が読める場所にまとめておきます。
候補の説明から、顧客が対象の業務を読み取れるかも確かめます。「通知を改善する」だけでは、顧客はどの通知を指すか判断できません。「承認担当者が未処理の申請に気づけるようにする」のように、対象の業務と目的を添えます。似た候補を見つけた場合は、重複統合の考え方を使って、同じ課題かを先に確かめます。
投票者数と社数は、分けて記録する
法人向けサービスでは、同じ会社の複数人が投票する場合があります。投票者数だけを読むと、要望が何社に広がっているかを見落とすかもしれません。担当者は、投票者数と社数を別々に残します。
たとえば、架空の業務ツールで、承認通知への投票が集まった場面を考えます。次の数字は数え方を説明するための架空の値で、実在する顧客の実績ではありません。
| 確認する項目 | 架空の記録例 | 読み取れること |
|---|---|---|
| 投票者数 | 6人が投票した | 6人が関心を示している |
| 所属する社数 | 6人は2社に所属している | この要望は2社から票を得ている |
| 業務の背景 | 投票理由をまだ聞いていない | 困り事が共通しているかは判断できない |
同じ会社から集まった票も、捨てる必要はありません。複数の職種が同じ作業で困っている可能性もあるため、会社ごとの広がりと、社内で影響を受ける役割を分けて読みます。投票者の所属を確認できなかった場合は、社数を推測で埋めず、未確認のまま記録します。
本人の投票と、営業やサポートが会話を記録した要望も区別します。受付元が残っていれば、同じ顧客の連絡を重ねて数えていないか確認できます。また、投票に参加しなかった顧客について「要望がない」とは判断できません。投票の案内が届いた範囲を確認し、必要に応じて参加していない顧客にも話を聞きます。
投票した顧客には、困った作業を聞く
担当者は、票の多さから困り事の深刻さを決めず、投票した顧客に具体的な場面を尋ねます。Cannyの投票ごとの重要度に関する公式説明でも、管理者が投票者にとっての重要度を設定する仕組みが説明されています。これはCannyの仕様であり、すべての投票ツールやアーコレに同じ機能があるという意味ではありません。
背景を聞くときは、「この機能があれば便利ですよね」と賛成を促す質問を避けます。英国政府のサービス設計ガイドは、インタビューの進め方で、中立的な質問と具体的な出来事への掘り下げを勧めています。この聞き方は、投票理由の確認にも使えます。
- 「直近でこの作業を行ったとき、どの場面で困りましたか」
- 「今は、その作業をどのように済ませていますか」
- 「その作業を完了できない場合、誰のどの業務に影響しますか」
顧客の回答と、担当者自身の解釈は分けて記録します。「通知が欲しい」という回答だけで、原因を通知不足と確定することはできません。顧客は、担当の引き継ぎや確認場所の分かりにくさで困っているかもしれません。詳しい質問の組み立て方は、ユーザーインタビューの進め方で扱っています。
判断理由と次の連絡日は、顧客へ伝える
背景がそろったら、製品の方針と開発の負担も合わせて検討します。要望を横並びで評価する方法は、開発する機能の優先順位を決める方法で扱っています。投票を管理する担当者の役割は、評価に必要な背景を渡し、決まった内容を投票者へ返すことです。
要望ごとに「今回の判断」「判断理由」「未確認点」「次の連絡日」を残します。まだ実装を決めていないなら、顧客への連絡で提供日を約束する必要はありません。追加で確かめることと、次に状況を伝える日を知らせます。具体的な文例は、機能要望への返信文例を参照できます。
投票の記録と回答を別々に管理すると、どの顧客へ連絡するかを追いにくくなる場合があります。要望と投票者、背景、判断理由を、同じ記録からたどれるでしょうか。株式会社Covvyは、要望の集約や投票、公開ロードマップを備える要望管理SaaS「アーコレ！」を準備しています。
投票を運用するときのよくある質問
何票集まったら開発を決めるべきですか？
票数だけで共通の採用基準を決めることはできません。投票した顧客の業務への影響、製品の方針、開発の負担を確認し、判断理由を残します。
投票が少ない要望は見送ってよいですか？
先に、投票が少ない理由を確かめる必要があります。対象の顧客に案内が届いていない場合や、限られた役割だけが行う業務の場合もあります。参加状況と困り事を確認してから判断します。
投票の背景を、判断につなげる
担当者は、投票者数と社数を分け、投票した顧客に困った作業と回避策を聞きます。そのうえで、判断理由と次の連絡日を伝えるところまでを、投票の運用に含めます。票を集めたあとに誰が何を確かめるかを決めておけば、チームは要望を検討する材料を残せます。
