顧客からの要望を断れない状態は、担当者の交渉力の問題ではありません。断ってよい要望を判定する基準が無く、断る権限が誰にも与えられていないことが原因です。

基準が無ければ、すべての要望は同じ重さに見えます。重さが分からないまま開発へ渡せば、判断は開発側に押し付けられ、優先順位は起票の早さや声の大きさで決まります。本記事では、要望を出す人の偏りの見方、要望の種類の分け方、優先度の数値化、そして断り方の型までを扱います。

断れないのは交渉力ではなく、基準と権限が無いから

「NO」と言えない組織で起きていることを整理すると、個人の資質ではなく手続きの欠落だと分かります。

項目個人の問題という見方手続きの欠落という見方
原因担当者が押し切られている却下の基準と権限が定義されていない
現れ方特定の担当者だけが要望を持ち帰る担当者を変えても件数が減らない
打ち手交渉の研修判定基準の明文化と権限の付与
効果の持続担当者の異動で元に戻る手続きとして残る

見分け方は単純です。担当者を入れ替えても要望の流入量が変わらないなら、原因は個人ではありません。

権限の設計とは、「この条件に当てはまる要望は、開発に回さずその場で断ってよい」と組織が事前に宣言することです。宣言が無ければ、現場は判断を避けて上へ流します。

要望を出す人は、顧客全体を代表していない

要望を分類する前に、母集団の偏りを押さえておく必要があります。問い合わせ窓口や自由記述に書き込むのは、顧客のうち一部に限られます。書かない顧客の大半は、満足しているか、不満を言わずに離れていきます。

ここから2つの帰結が出ます。

  • 要望の件数は、需要の大きさの指標にならない。同じ顧客が繰り返し起票していれば件数は増えます
  • 要望が来ないことは、問題が無いことを意味しない。言わずに離脱した層の声は、要望として記録されません

したがって、要望を集計するときは件数ではなく、影響を受ける顧客の数と、その顧客層の位置づけで数えます。発信者が1社なのか、同じ条件に当てはまる顧客が数十社いるのかで扱いは変わります。顧客をどう層に分けるかは顧客セグメンテーションの設計を扱った記事で整理しています。

なお、要望が多いこと自体を問題視する必要はありません。問題は、要望の熱量を重要度として読み替えてしまうことです。

要望の種類を分ける：狩野モデル

要望を「やる／やらない」の2択で見ると、判断が難しくなります。要望が満たされたときと満たされないときで、満足度への効き方が違うためです。

この違いを整理した枠組みに、狩野紀昭・瀬楽信彦・高橋文夫・辻新一が1984年に日本品質管理学会誌『品質』第14巻第2号で発表した「魅力的品質と当り前品質」があります。品質要素を次のように分類するものです。

分類定義要望としての扱い
当たり前品質充足されていても当たり前と受け取られるが、不充足なら不満を引き起こす欠けていれば最優先。満たしても評価は上がらない
一元的品質充足されれば満足、不充足なら不満を引き起こす投じた分だけ効く。費用対効果で判断する
魅力的品質充足されれば満足を引き起こすが、不充足でも仕方ないと受け取られる差別化の候補。後回しにしても不満は増えない
無関心品質充足・不充足のいずれも満足度に影響しない断ってよい領域
逆品質充足されていると不満を引き起こす実装しないほうがよい

実務で効くのは、「無関心品質に当たる要望が一定量ある」と組織が認めることです。すべての要望が満足度に効くという前提に立つ限り、断る根拠は作れません。

分類は要望を受けた側が行い、迷ったものだけを合議に回します。なお、要望を「成果に直結するもの」「使い方で解決するもの」「個別最適」「不満が要望の形を取ったもの」に切り分ける実務的な整理は、カスタマーサクセスの役割を扱った記事にまとめています。狩野モデルは、そこで残った要望の優先度を考えるときに使います。

優先度を数値化する：RICE

分類の次は順序付けです。順序を合議だけで決めると、発言力の強い部門の要望が上がります。

広く使われている枠組みのひとつに、Intercom の Sean McBride が2018年に公開した RICE スコアリングがあります。次の4項目で要望を評価し、スコアを算出します。

項目見るもの
Reach（到達範囲）一定期間内に影響を受ける人数
Impact（影響度）1人あたりへの影響の大きさ
Confidence（確度）見積もりへの自信の度合い
Effort（工数）全メンバーの合計所要時間（人月）

スコアは (Reach × Impact × Confidence) ÷ Effort で求めます。分子が期待できる効果、分母が投入資源なので、単位資源あたりの効果を比較する形になります。

この枠組みを使う際の注意は2つです。第一に、スコアは順序を決めるための道具であって、正解を出す装置ではありません。桁が違う要望を仕分けるには十分ですが、僅差の比較に意味はありません。第二に、入力者を分けることです。到達範囲と影響度は要望を受けた側、工数は開発側が入れます。一人が全項目を埋めると、通したい要望の点数が高くなります。

却下の権限と、断り方の型

基準とスコアがそろったら、誰がどこまで断れるかを決めます。

区分判定者条件
その場で断る要望を受けた担当者無関心品質に該当、または既存機能で対応可能
保留して再検討要望を受けた担当者同条件の顧客が一定数を超えたら再判定する
スコアリングに回す要望を受けた担当者上記以外
採否を決めるプロダクト責任者定例の判定会で決定する

断る際の返し方は型にします。含める要素は次の3つです。

  1. 判断の理由：なぜ今回は対応しないのか（方針、対象範囲、優先度）
  2. 代替手段：既存機能での回避策、運用での代替、他の手段
  3. 再検討の条件：どうなれば再び検討するのか

3つ目を省くと、顧客には「断られた」という結果だけが残ります。条件を添えると、同じ要望が繰り返し出てきたときに、感情的な押し問答ではなく条件の充足を確認する会話になります。

却下した要望も記録します。記録しないと同じ内容が新規として起票され、判断のやり直しが発生します。判断日、理由、再検討の条件を残してください。

運用の落とし穴

落とし穴1：判定会が開かれなくなる。 定例の判定を止めると、要望は「開発に伝えてあります」という状態で滞留します。滞留した要望は、期日が迫った案件から順に個別対応されます。頻度を落としてでも定例は維持してください。

落とし穴2：断った件数だけが評価される。 却下率を指標にすると、拾うべき要望まで落ちます。見るべきは却下率ではなく、採用した要望が実際に利用されたかどうかです。

落とし穴3：現場が断れる範囲を狭く取りすぎる。 その場で断ってよい条件が曖昧だと、担当者は全件をスコアリングに回します。判定会の議題が膨らみ、結局は先着順に戻ります。断ってよい条件は、迷いが生じない粒度まで具体化してください。

落とし穴4：要望対応の指標だけで支援を評価する。 要望を通した件数で担当者を評価すると、要望の伝達が仕事になります。評価指標の置き方についてはカスタマーサクセスの御用聞き化を止める設計の記事で扱っています。

まとめ

  • 断れない原因は交渉力ではなく、却下の基準と権限が定義されていないことです
  • 要望の件数は需要の大きさを表しません。影響を受ける顧客の数で数えます
  • 狩野モデルで種類を分けると、満たしても満足度に効かない要望が存在することを組織として認められます
  • RICE は順序を決める道具です。入力者を分け、僅差の比較には使いません
  • 断るときは、理由・代替手段・再検討の条件の3点を返します。却下した要望も記録します