機能追加はどう決める？｜顧客の要望をそのまま作らず判断する方法

はじめに

サービスを運営していると、

「この機能が欲しい」
「○○と連携してほしい」
「競合にはあるので追加してほしい」

といった要望が少しずつ集まってきます。

要望が複数届くと、

「これだけ言われているなら、作った方がいいのでは？」

と考えたくなります。

しかし、
顧客が欲しいと言った機能と、本当に解決すべき課題は同じとは限りません。

たとえば、

「CSV出力が欲しい」

という要望でも、

• Excelへの転記作業を減らしたい
• 手元にデータを保存しておきたい
• 競合にもあるので欲しい
• なんとなく便利そう

では、
背景にある問題がまったく違います。

この記事では、
顧客の機能要望をそのまま開発仕様にせず、

要望 → 背景課題 → 行動 → 代替手段 → 機能追加判断

の順番で整理する方法を解説します。

結論：機能要望は「答え」ではなく「課題を探る入口」

顧客から、

「○○機能が欲しい」

と言われたとき、
最初に考えたいのは、

「その機能を作るべきか？」ではありません。

まず確認したいのは、

「なぜ、その機能が欲しいのか？」

です。

たとえば、

「Slack連携が欲しい」

という発言だけでは、

• Slackから情報を探すのが大変なのか
• 転記作業が面倒なのか
• 転記忘れが起きているのか
• 単に連携機能が好きなのか

までは分かりません。

要望は、
顧客が考えた解決方法であることがあります。

そのため、

機能要望
↓
背景課題
↓
本当に解決したいこと

まで分けて考える必要があります。

まず「要望」と「課題」を分ける

機能要望を受け取ったら、
まずそのまま記録します。

たとえば、

「CSVで出力できるようにしてほしい」

なら、

要望：CSV出力

です。

ここで、

「Excel転記が大変なのだろう」

と勝手に補わないことが重要です。

顧客本人が、

「毎月Excelへ手入力しているので、
CSVで出せると助かる」

と話しているなら、

• 要望：CSV出力
• 背景課題：Excelへの手作業による転記
• 発生場面：月次報告
• 現在行動：画面を見ながらExcelへ入力

まで整理できます。

一方、

「CSVで保存できると安心」

だけなら、
背景は転記作業とは限りません。

データを手元に置きたい、
サービスへの依存を減らしたいなど、
別の目的かもしれません。

ただし、
本人が話していない理由まで推測してはいけません。

同じ機能要望でも背景は違う

たとえば5人が、

「エクスポート機能が欲しい」

と言っていても、
その中身は次のように違うことがあります。

利用者	発言の背景
A	月末の報告資料へ転記したい
B	データを手元に保存しておきたい
C	毎日のExcel管理表への転記を減らしたい
D	便利そうだが使う予定はない
E	競合にもあるので、あった方がよさそう

表面上は同じ要望ですが、
一つの「エクスポート需要」として同じ重みで数えるのは危険です。

まず要望の背景を整理したい場合は、
「機能要望分析」のAIフローを使うと、
要望・背景課題・利用場面・現在行動・未確認事項を分けて整理できます。

機能要望分析のAIフローはこちら

「欲しい」と「使う」は分ける

顧客発言を見るときは、
言葉の強さを混同しないことも重要です。

たとえば、

• 「あると便利そう」
• 「欲しい」
• 「あれば使う」
• 「ないと困る」
• 「これがないから購入しなかった」

は、
同じ意味ではありません。

特に、

「あれば使います」

という発言があっても、

実装すれば本当に使う

とは限りません。

同じように、

「ないと困る」

と言われても、
実際の購入・継続・解約に影響しているとは限りません。

発言と実際の行動は、
分けて整理します。

実際の行動も確認する

機能要望だけを見るより、
現在の利用行動まで確認すると判断材料が増えます。

たとえば、

「Gmail連携が欲しい」

という要望があったとします。

そのとき、

• Gmail連携がなくても購入している
• Gmail連携がなくても継続利用している
• 毎回メールを手作業で転記している
• 転記忘れによる情報欠落が起きた

では、
それぞれ意味が違います。

要望があっても必須機能とは限らない

複数の有料利用者から要望が出ていても、
その機能なしで購入・継続しているなら、

「現在のサービスを使うための必須条件ではない」

という事実もあります。

これは、

「だから作らなくてよい」

という意味ではありません。

単に、

「欲しい」
と
「なければ利用できない」

を分けて考える材料になります。

実害がある場合は重要な材料になる

一方で、

転記を忘れて、
最新情報が整理結果から抜けた

というような実際の問題が起きている場合、
単なる「便利そう」という発言より強い材料になります。

ただし1件の事例から、

「多くの顧客にも同じ問題が起きている」

と一般化することはできません。

事例があることと、
広く起きていることは別です。

顧客が出した解決策が最適とは限らない

顧客から、

「Slack連携を作ってほしい」

と言われたとします。

背景を聞くと、

Slackから必要な情報を探して、
サービスへコピーする作業が面倒

だったとします。

この場合、
本当に解決したいことは、
Slack連携そのものではなく、情報探索・転記負担の削減です。

Slack連携は、
その課題を解決する候補の一つです。

しかし、

顧客がSlack連携と言った
↓
Slack連携が唯一の解決策

とは限りません。

まず、

• 現在何をしているのか
• どの作業が負担なのか
• どこで失敗しているのか
• 何を減らしたいのか

を整理した方が、
解決方法の選択肢を狭めすぎずに済みます。

複数人から同じ要望が出ても、すぐ一般化しない

「3人から同じ要望が出た」

という情報は、
もちろん無意味ではありません。

しかし、

3人が言った
＝多くの顧客に必要

とは言えません。

確認したいのは、
単に機能名が同じかではなく、

背景課題も同じか

です。

たとえば、
3人とも「Slack連携」を希望していても、

• A：毎回の検索・コピーが面倒
• B：複数チャンネルの転記が多い
• C：転記忘れを防ぎたい

という違いがあるかもしれません。

大きく見れば、

Slackからの手動転記負担

という共通課題はあります。

しかし、
必要な仕様まで同じとは限りません。

共通課題と共通仕様は別です。

反対事例も残しておく

要望分析では、
欲しいと言った人だけを見ると判断が偏ります。

たとえば、

「Slack連携があると便利そう」

と言いながら、

「自分はメール中心なので、今のままで困っていない」

という利用者もいるかもしれません。

この人を、

Slack連携希望者1人

として単純に数えてしまうと、
実際の需要を強く見積もりすぎます。

反対に、

• 現在の方法で困っていない
• その機能を使う予定がない
• 別の運用で問題なく利用している

という事例も残しておきます。

反対事例は、
仮説を見直し、
「どんな人に必要なのか」という条件をより正確にする材料になります。

要望を分析した後に、機能追加を判断する

背景課題が整理できたら、
次に初めて、

「この機能を作るべきか？」

を考えます。

ここでは、

• 背景課題は確認できているか
• 実際の行動に影響しているか
• 既存機能で対応できないか
• 他の方法で解決できないか
• 対象になる利用者は誰か
• 開発・保守負荷はどの程度か
• 小さく試せるか
• まだ重要な未確認事項が残っていないか

を見ます。

要望数だけでは決めない

たとえば、

ダークモードが欲しい

という要望が5件あったとします。

それだけで、

「5件もあるから作ろう」

と決めるのは早いです。

もし、

• 多くが「見た目が好き」という発言
• 現在の画面で具体的に困った経験はない
• 購入・継続への影響も確認できない
• 実装範囲は広い
• 今後の保守負荷も増える

のであれば、
まず課題の強さを確認した方がよい場合があります。

一方、

• 利用のたびに発生する作業負担がある
• 実際に情報欠落が起きている
• 現機能では解消できない
• 小さく試せる

のであれば、
限定的に追加して試す判断もあり得ます。

機能を追加するか迷った場合は、
「機能追加判断」のAIフローで、

今追加する / 小さく追加する / 先に検証する / 代替案で対応する / 保留する / 追加しない

のどこに当てはまるか整理できます。

機能追加判断のAIフローはこちら

「作る・作らない」の2択にしない

機能追加を考えるとき、

作る
作らない

だけで考えると、
判断が極端になりやすくなります。

実際には、

• 今追加する
• 小さく追加する
• 先に検証する
• 代替案で対応する
• 保留する
• 追加しない

という選択肢があります。

たとえば、
必要性はある程度確認できているものの、
正式実装には不確実性が残る場合、

一部利用者だけに限定版を提供する

という方法もあります。

逆に、
要望はあるものの背景課題がほとんど確認できていない場合は、

まず実装せず、
具体的な困りごとを確認する

方が適切なこともあります。

開発が簡単だから作る、も避ける

機能追加では、

「簡単に作れそうだから、とりあえず追加する」

という判断も起こりがちです。

しかし、
開発負荷が低いことと、必要な機能であることは別です。

一方で、

開発が大変だから作らない

とも限りません。

判断するときは、

課題・証拠の強さ
×
開発・運用・保守負荷

を合わせて見ます。

特に、

• 実装範囲が広い
• 継続的な保守が必要
• 外部サービスへ依存する
• 既存ユーザーへの影響が大きい

場合は、
より強い根拠を確認してから進めた方が安全です。

機能要望から追加判断までの流れ

機能要望を受け取ったら、
次の順番で整理すると判断しやすくなります。

1. 要望をそのまま記録する

まず、

「何が欲しいと言われたか」

を解釈せず残します。

2. 背景課題を確認する

次に、

「なぜそれが欲しいのか」

を確認します。

3. 現在行動を見る

• 今はどう対応しているか
• どのくらい頻繁に起きるか
• 何か実害が起きているか

を整理します。

4. 求めている結果を整理する

機能名ではなく、

「何を減らしたいのか」
「どうなりたいのか」

を見ます。

5. その機能でなければならないか確認する

顧客が出した解決方法を、
唯一の方法とは決めつけません。

6. 実装するかを別途判断する

最後に、

• 課題
• 行動証拠
• 対象範囲
• 代替手段
• 開発負荷
• リスク
• 未確認事項

を合わせて、
機能追加を判断します。

まとめ

顧客から機能要望が出たとき、
そのまま開発仕様に変える必要はありません。

重要なのは、
「何を作ってほしいと言われたか」ではなく、
「なぜそれが必要なのか」を整理することです。

特に、

• 要望と背景課題を分ける
• 同じ機能名でも背景の違いを見る
• 発言と実際の行動を分ける
• 「便利そう」と実利用需要を分ける
• 顧客が出した解決策を最適解と決めつけない
• 反対事例も残す
• 複数人の発言をすぐ市場全体へ一般化しない
• 開発負荷も合わせて判断する

ことが重要です。

機能要望を整理するときは、
機能要望分析。

その結果を使って、
実際に追加するか判断するときは、
機能追加判断。

と分けると、

「顧客に言われたから作る」

ではなく、

確認できた課題と行動をもとに機能追加を判断する

流れを作りやすくなります。