顧客から「CSVで出力したい」と頼まれたとき、出力機能の有無だけを調べても、その要求の理由はわかりません。
別の部署に報告するためか、他のシステムに取り込むためかによって、必要な解決策が変わります。
顧客ニーズ(Customer needs)は、顧客がある状況で解決したい問題や、達成したい状態を指します。

機能の要望から目的を確かめる

たとえば、経費精算サービスの顧客がCSV出力を求めているとします。
直近の月次処理について聞いたところ、経理担当者は精算結果を表計算に移し、部門ごとに未処理の金額をまとめているとわかりました。
この場合、「月末に部門別の未処理金額を確認し、予算超過を早く見つけたい」がニーズの候補になります。
CSV出力のほかにも、画面内の集計や既存の会計システムとの連携を検討できます。

ニーズの記述には、誰が、どの状況で、何を達成したいかを含めます。
Nielsen Norman Groupのニーズの記述方法も、利用者、必要なこと、その目的を結びつけています。
ただし、記述を整えただけで顧客の意図を確認できたことにはなりません。
元の発言や行動に戻り、解釈が合っているかを本人にも確かめます。

ニーズの強さを判断する材料

開発の優先順位を考えるには、目的に加えて、その問題が顧客にどれほど影響しているかを調べます。

  • 直近ではいつ起こり、どのくらいの頻度で繰り返すか。
  • 放置すると、時間、費用、業務の品質にどんな影響があるか。
  • 現在はどの方法で対処し、何を負担しているか。
  • その問題を解くために、すでに人や予算を使っているか。

先ほどの例で、集計が毎月数分で済み、予算管理にも使っていなければ、別の問題を先に解く判断ができます。
反対に、締め作業が遅れて請求や支払いに影響しているなら、調査と試作を進める理由になります。
これらは仮の判断例であり、実際の優先順位には対象顧客の範囲や開発費用も含めて考えます。

複数人に聞くときは、同じ言葉で語られていても、利用場面が同じかを確認します。
「早く終えたい」という発言でも、毎日の入力と月末の報告では問題が異なります。
共通する目的と異なる条件を残すことで、誰に向けた改善かを明確にできます。

機能要望を捨てない

ニーズを探るときも、顧客が指定した解決策と、その理由の両方を残します。
CSV形式が取引先の指定であれば、その形式自体が満たすべき条件です。
「本当は別のものが欲しいはず」と開発側が決めつけると、現場の制約を見落とします。
ニーズを広く捉えることと、明示された条件を無視することは別です。

複数の顧客に共通する問題を整理するには顧客の声(VOC)、顧客がまだ説明していない問題を探るには顧客現場訪問を使います。
解決したときに提供できる便益は、価値提案として具体化します。

参考資料