機能要望の収集を一本化する方法｜棚卸しと受け皿の設計
機能要望は、様々な場所で発生します。Slackのチャンネル、営業の商談メモ、サポートへの問い合わせ、たまたま参加した勉強会での立ち話。要望が生まれる場所と、要望を管理したい場所は一致しないというのが、この工程の難しさです。
この記事では、散らばった収集チャネルを棚卸しし、ひとつの受け皿に集約する手順を紹介していきます。集めた後の整理や優先順位づけは、機能要望管理とは？収集・整理・優先順位付けの基本で全体像を解説しています。
- 顧客の言いやすい場所は残したまま、行き先を統一させる
- 商談メモ・解約時の声・社内の雑談から生まれる要望は失われやすい
- 今日から届くぶんだけを新しい受け皿に入れる
要望はどこから届いているか
まず棚卸しから始めていきましょう。自社の要望がどこで生まれているかを、実際に書き出してみてください。多くの場合、想像しているより様々な経路から要望が発生していることに気づくはずです。
| 経路 | 誰が受け取るか | 見落としやすさ |
|---|---|---|
| 問い合わせ・チャット | CS・サポート | 低い |
| アプリ内フィードバック | プロダクト | 低い |
| 商談・打ち合わせ | 営業 | 高い |
| 定例会・QBR | CS・営業 | 高い |
| 解約時のヒアリング | CS | 非常に高い |
| SNS・レビューサイト | 誰も担当していないことが多い | 非常に高い |
記録が残る経路は、後から拾い直せますが、見落としやすいのは下の3つです。とくに解約時に出た要望は、失われる確率がいちばん高いものです。解約対応は気まずいもので、記録するモチベーションが働きにくい性質があります。しかし解約理由に紐づく要望は、事業インパクトが最も明確な情報でもあるため非常に重要です。
入口を減らしてはいけない
「チャネルを一本化する」と聞くと、専用フォームに誘導する、といった発想になりがちですが、これはたいてい失敗してしまいます。
要望は、商談の雑談、チャットの流れ、定例会の最後の5分などで「ついでに言う」ものです。専用の窓口に改めてアクセスして書き込むという行為は、それ自体が高いハードルになってしまいます。
それにより、要望の総量そのものが減ります。要望が集まらなければ元も子もありません。
統一すべきなのは入口ではなく行き先です。Slackには専用チャンネルを用意してリアクションで受け皿に送る仕組みにしてもいいでしょう。商談メモのテンプレートに要望欄を作る、サポートツールにタグを1つ足して、後から抽出できるようにする形も良いです。
つまり、入口ごとに送る導線を用意し、集める場所だけを統一する。これが一本化の実像です。
どんな情報を記録するのか
受け皿には、要望の内容だけでなく出所を記録しましょう。これがないと、後で事業インパクトを判断できません。
必須にしたい項目は4つです。
誰が言ったか — 会社名と、可能なら部署・役職。既存顧客か見込み客かも区別します。
いつ言ったか — 日付。時期が集中していれば、外部要因（競合のリリース、法改正など）が背景にある可能性があります。
どの経路で届いたか — 商談なのか問い合わせなのか。経路によって要望の性質が変わります。営業経由とCS経由の違いは営業・CSからの機能要望をどう扱うかで詳しく扱っています。
元の言葉のまま — 要約せず、言われたとおりに残します。要約は解釈が入り、後から課題を読み解くときに情報が失われます。
優先度、想定工数、担当者、関連機能。あれば便利な項目はいくらでも思いつきますが、入力が重くなるほど記録されなくなります。
登録の時点で埋めるのは上の4つに絞り、判断に使う情報は後の工程で足していくほうが、結果的に多くの要望が残ります。
散らばった状態からどう移行するか
すでに何年ぶんかの要望がSlackやスプレッドシートに散らばっている場合、どこから手をつけるかが問題になります。
おすすめしたいのは、過去は遡らない ということです。掘り起こしから始めると、それだけで数週間かかることもあり、その間に新しい要望がまた散らばります。これにより、終わらない作業のように感じられ、管理が続かなくなってしまうでしょう。
受け皿を1つ決める
専用ツールでも、スプレッドシートでも構いません。この段階でツール選定に時間をかけるより、まず1か所決めて動かすことが重要です。
今日から届くぶんだけ入れる
過去は放置してもよいです。これから届く要望だけを新しい受け皿に入れていきましょう。判断に使える量として貯めていきます。
必要になった過去だけ拾う
「この要望、前にも聞いた気がする」と思ったときだけ、過去を検索して追加してみましょう。全件を移すより、実際に参照されたものだけを移すほうが効率的です。
入口ごとの導線を足していく
最初から全チャネルを繋ごうとせず、いちばん要望が多い経路から1つずつ導線をつくっていきます。
よくある質問
Slackで集めると流れてしまいます。どうすればよいですか？
Slackは要望が生まれやすい場所ですが、蓄積には向きません。専用チャンネルを用意したうえで、投稿にリアクションを付けると受け皿に転記される、といった導線をワークフロー機能などで作るのが現実的です。重要なのは、Slackで完結させようとしないことです。生まれる場所としてのSlackと、溜める場所としての受け皿を分けて考えてください。
チャネルが多すぎて、どこから一本化すべきか分かりません。
いちばん要望が多い経路から1つだけ導線をつくるのが確実です。全チャネルを同時に繋ごうとすると設計に時間がかかり、動き出せません。まず1経路だけ受け皿に流してみて、記録の粒度や項目の過不足を確かめてから、次の経路を足してください。
まとめ
収集の一本化でつまずく原因は、たいてい2つです。入口を減らそうとして要望の総量が減ること。そして過去の掘り起こしから始めて、終わらないまま止まること。
要望が生まれる場所は、そのままにしておいて構いません。行き先だけをひとつに決め、出所を記録し、今日届いたぶんから入れていく。この形で進めていきましょう。
