商談の場で顧客から「この機能さえあれば契約する」と言われ、その場で前向きな返事をしてしまった。営業担当からは「あの案件を落とさないために、この要望は最優先でお願いします」と毎週のように言われる。気づけば開発ロードマップは、顧客ごとの個別要望を積み上げただけの一覧になっていた——プロダクトマネジメントを兼務する経営者であれば、一度は覚えのある状況ではないでしょうか。
機能要望を断る、あるいは後回しにするという判断は、技術的には単純です。難しいのは、断ることで顧客との関係が悪化するのではないか、営業の商談を潰してしまうのではないかという不安がつきまとう点にあります。特に創業間もない時期は、顧客との関係そのものが会社の資産であるため、「一度断ったら二度と頼ってもらえないのではないか」という恐れが、なし崩しの受け入れにつながりがちです。本記事では、顧客や営業からの機能要望を、関係を壊さずに断る・後回しにするための判断基準と伝え方を、4つのステップに整理して解説します。
なぜ機能要望を断れなくなるのか
機能要望を断れない背景には、いくつかの構造的な理由があります。
1つ目は、顧客からの要望が「売上」という分かりやすい言葉と直結していることです。「この機能があれば契約する」「この機能がないと解約する」という言い方をされると、目の前の売上や解約防止を優先し、プロダクト全体の設計や他の顧客への影響を後回しに考えてしまいます。
2つ目は、営業とプロダクト側の間で、要望を評価する共通のものさしがないことです。営業は個別の商談の温度感で要望の重要度を語り、プロダマネジメント側は開発工数や既存機能との整合性で考えます。ものさしがかみ合わないまま話が進むと、声の大きさや頻度で優先順位が決まってしまいます。
3つ目は、経営者自身が営業の窓口も兼ねているケースが多く、顧客と直接の人間関係があることです。担当者の顔が見えているからこそ、無下に断ることへの心理的なハードルが、社内の開発チームに対するよりも高くなります。
要望を受けた瞬間に確認すべき3つのこと
要望を断るか受け入れるかを判断する前に、その場で確認しておくべきことが3つあります。この確認を怠ると、後から「言った・言わない」のずれが生じ、関係悪化の原因になります。
1つ目は、誰の要望なのかという範囲です。 特定の1社だけが求めているのか、複数の顧客から共通して上がっている要望なのかによって、対応の優先度は大きく変わります。1社限定の要望を全顧客向けの機能として実装してしまうと、他の顧客には使われない機能に開発リソースを割くことになります。
2つ目は、要望の背景にある課題です。 顧客が言葉にした機能そのものではなく、その機能によって解決したい課題を確認します。「この機能が欲しい」という要望の裏には、多くの場合、より単純な運用回避策で解決できる課題が隠れています。要望をそのまま鵜呑みにすると、本来不要だった機能を作り込んでしまうことがあります。
3つ目は、いつまでに必要かという期限です。 「なるべく早く」という曖昧な期限で受け止めると、あらゆる要望が最優先に見えてしまいます。契約更新のタイミングなのか、社内の別の意思決定に紐づいているのか、具体的な期限とその理由を確認することで、他の開発項目と並べて比較できるようになります。
顧客の関係を壊さずに断る・後回しにする4ステップ
3つの確認を終えたら、実際の判断と伝え方に移ります。以下の4ステップで進めると、断る場合も後回しにする場合も、顧客との関係を維持したまま伝えられます。
ステップ1：要望を「機能」ではなく「課題」に翻訳する
顧客から受け取った要望を、社内で検討する前に、まず課題の言葉に翻訳します。「〇〇ボタンが欲しい」という要望であれば、「〇〇の作業に毎回時間がかかっている」という課題に置き換えます。この翻訳を経ることで、要望どおりの機能を作らなくても、別の方法で課題を解決できないかを検討できるようになります。
ステップ2：既存の優先順位づけの基準に載せて比較する
翻訳した課題を、他の開発項目と同じ基準で比較します。ここで独自の緊急対応ルートを作ってしまうと、次の要望も同じルートを通ろうとし、通常の優先順位づけの仕組みが形骸化します。
比較の際は、機能追加だけでなく、並行して検討している技術的負債の解消とも同じ土俵に載せます。目先の要望を優先し続けた結果、システムの保守性が落ち、結果的に新しい要望への対応スピードが落ちるという事態は珍しくありません。
ステップ3：判断結果を「理由つき」で顧客に伝える
比較の結果、断る、あるいは後回しにすると決まったら、その結論だけでなく理由もセットで伝えます。「他のお客様からも同様の声をいただいており、より多くの方に価値のある形で対応することを検討している」「現時点では別の開発を優先しており、今期中の着手は難しい」というように、判断の軸を顧客にも見える形で示します。理由が伝わらないまま結論だけを伝えると、顧客は「軽視された」と受け止めがちです。
ステップ4：代替案または見直しのタイミングを添える
断る、あるいは後回しにする結論を伝える際は、可能な範囲で代替案を添えます。要望どおりの機能はすぐに提供できなくても、既存機能の組み合わせで一部の課題を解決できる場合があります。代替案が用意できない場合でも、「次回のロードマップ見直しのタイミングで、あらためて検討対象に入れる」という次に検討する時期を伝えるだけで、要望が握りつぶされたわけではないという印象を残せます。
伝え方の型：関係を壊さない3つのフレーズ
ステップ3・4で使える伝え方の型を、具体的なフレーズとして3つ紹介します。
- 「今回は見送りますが、背景は教えてください」型：即座に結論を伝えるのではなく、要望の背景を確認する質問から入ります。「なぜその機能が必要だと感じたか、もう少し詳しく教えていただけますか」と聞くことで、顧客は自分の課題を理解しようとしてくれていると感じ、その後の結論も受け止めやすくなります。
- 「全体最適のために」型：1社だけの要望に個別対応しない理由を、多くの顧客への価値提供という文脈で説明します。「特定のお客様専用の機能ではなく、より多くのお客様に使っていただける形で検討したい」という説明は、断る理由として納得を得やすい言い方です。
- 「今はできないが、なくなったわけではない」型：後回しにする場合、要望自体を却下したのではなく、優先順位の中で順番待ちの状態にあることを伝えます。「検討リストには入れており、次のロードマップ見直しで優先度を再確認します」という言い方は、要望を無視していないことを示せます。
よくある失敗
- その場で「検討します」とだけ答えて、その後の連絡をしない：明確な結論を避けて先延ばしにすると、顧客は返事を待ち続けることになります。断る場合も後回しにする場合も、いつまでに結論を伝えるかを先に約束しておくことが重要です。
- 営業担当を通さず、顧客に直接厳しい返答をしてしまう：経営者自身が窓口を兼ねている場合、率直に断ることは悪いことではありませんが、営業担当が別にいる場合は、営業側の顔も立てながら伝え方をすり合わせておく必要があります。営業を飛ばして直接顧客に結論だけを伝えると、営業と顧客の間の信頼関係を損なうことがあります。
- 1社の要望をその場の勢いで受け入れてしまう：特に大口の顧客からの要望は、断りにくさから安易に受け入れがちです。しかし、受け入れた前例は次の要望のハードルを下げてしまいます。個別対応するかどうかは、必ずステップ2の比較を経てから判断します。
具体例：大口顧客の要望を個別対応せず、全体の機能として実現したケース
従業員18名、創業4年目のBtoB SaaSスタートアップの例です。売上の3割を占める大口顧客から「専用のレポート出力機能がなければ契約更新を見送る」という要望が届きました。営業担当は「この案件は絶対に落とせない」と強く主張し、経営者は当初、専用機能として個別に開発することを検討していました。
しかし、要望を課題に翻訳して確認したところ、実際に必要だったのは「月次の利用状況を経営会議用の資料に転記する作業を減らしたい」という課題であることが分かりました。社内の他の顧客からも似た要望が過去に上がっていたことを踏まえ、専用機能ではなく、既存のダッシュボードにCSV出力機能を追加する形で対応することに決めました。
この結論を顧客に伝える際は、「専用の機能ではなく、より多くのお客様にも使っていただける形で、月次のレポート作業を減らせる機能を用意します」と、理由と代替案をセットで伝えました。当初の要望とは異なる形での対応でしたが、顧客の契約更新は無事に決まり、追加したCSV出力機能はその後、他の顧客からも高い評価を得ています。
よくある質問(FAQ)
Q1. 顧客からの要望を断ると、解約につながるのではないかと不安です。どう見極めればよいですか。
すべての要望が解約に直結するわけではありません。ステップ1で要望を課題に翻訳した際、その課題が解決されないことで実際に事業運営に支障が出るのか、それとも「あれば便利」程度のものなのかを見極めることが重要です。前者であれば代替案の検討を急ぎ、後者であれば理由を丁寧に伝えたうえで通常の優先順位づけに載せて問題ありません。
Q2. 営業担当が顧客に先に「対応します」と約束してしまっていた場合、どうすればよいですか。
すでにした約束を覆すのは難しいため、まずは営業担当と事実関係をすり合わせ、なぜその約束をしたのかの背景を確認します。今後同じことが起きないよう、要望を受けた時点で必ずプロダクト側に一次確認を通すという社内ルールを、営業担当とあらためて共有しておくことをおすすめします。
Q3. 機能要望を管理する仕組み自体がまだありません。何から始めればよいですか。
まずは要望を受けた日付・顧客名・要望内容・翻訳した課題を1枚のシートに記録するところから始めれば十分です。記録が蓄積されると、複数の顧客から共通して上がっている課題が見えるようになり、個別対応か全体の機能かの判断がしやすくなります。
Q4. 断った要望について、後から顧客に再度検討状況を伝える必要はありますか。
伝えることをおすすめします。断った、あるいは後回しにしたと伝えたきり音沙汰がないと、顧客は「やはり軽視された」と感じやすくなります。ロードマップの見直しのタイミングで、対応の有無にかかわらず一度状況を伝えるだけでも、要望を継続的に扱っているという印象を残せます。
まとめ
顧客や営業からの機能要望を断る、あるいは後回しにする判断は、要望の範囲・背景の課題・期限の3点を確認したうえで、既存の優先順位づけの基準に載せて比較することで、感覚ではなく根拠を持って行えるようになります。結論を伝える際は、理由と代替案または見直しのタイミングをセットで示すことが、関係を壊さないための鍵になります。
まずは直近で保留にしている顧客からの要望を1件取り上げ、課題への翻訳と背景の確認から始めてみてください。
プロダクトマネジメントについてお気軽にご相談ください
プロダクトマネジメントの顧問支援や、1人目のPdM採用・育成のサポートを承っています。
「経営者が兼務してきたが、そろそろ限界かもしれない」という段階からでもお気軽にご連絡ください。
おおむね2営業日以内にご返信します。
