要望を“要求”に変える。プロダクトが本当に使われるようになった改善プロセス

法人向けSaaSプロダクトを展開するF社のプロダクト開発チームには、顧客、営業担当、社内メンバーから毎日たくさんの「こうしてほしい」という声が届いていました。その声に応えて機能を追加しても、「使いにくくなった」といった声が上がり、実際の利用率は思うように伸びませんでした。改善を重ねているはずなのに、なぜかプロダクトが良くならない。そんなジレンマを抱えていました。

株式会社deflagは、「お客様の声をそのまま開発するのではなく、その奥にある本当のニーズを見極め、優先順位をつけて進める」プロセスを構築。

F社のプロダクト開発チームが自ら判断し、継続的にプロダクトを進化させられる体制を整えました。

本件は当社メニュー「プロダクト開発体制支援」「プロダクトロードマップ策定支援」を活用した事例です。

– deflag にご依頼いただく前の課題感を聞かせてください。

F社のプロダクト開発チームの担当者様：

当時、弊社のプロダクト開発チームには、日々さまざまな立場から要望が寄せられていました。

声が多すぎて、何から手をつければいいか分からない

お客様からの要望、営業担当からの「こういう機能があれば売りやすい」という声、社内メンバーからの改善案。多すぎる要望に対して優先順位がつけられず、どこから手をつけるべきか分からない状態でした。

営業現場で大口顧客から要望が入ると、つい優先的に対応してしまう。一方で、他の多くのユーザーが困っている改善点は後回しになりがちでした。

結果として、声の大きさやタイミングに引きずられて開発を進めることが多く、全体を見た優先順位がつけられていませんでした。

対応したのに「使いにくくなった」「使われない」

せっかく要望に応えて機能を追加しても、「かえって使いにくくなった」というフィードバックが返ってきたり、追加した機能が全然使われなかったりすることがありました。

例えば、あるお客様から「この画面に〇〇の情報も表示してほしい」と言われて対応したところ、他のお客様からは「情報が多すぎて見づらい」と苦情が来る。個別の要望に応えるたびにプロダクトが複雑になり、結果的に使われなくなるという悪循環が起きていました。

プロダクトの方向性が定まらない

目の前の声に反応し続けた結果、「このプロダクトは結局、誰のために、何を実現するものなのか?」という方向性が曖昧になっていました。その影響で、中長期的なロードマップや開発・リソース計画を立てることも難しく、常に“目の前の対応”に追われる状態になっていました。

開発チームも、次々に来る要望に追われて疲弊。「本当にこれを作るべきなのか?」と疑問を感じながらも、止まれない状態が続いていました。

– どのような理由で deflag 社を選ばれたのですか？

F社のプロダクト開発チームの担当者様：

弊社がdeflagを選んだ理由は、単に「開発のやり方」を教えてくれるだけでなく、プロダクトの目的に立ち返りながら、事業に合った運用体制を一緒に作ってくれる点でした。

deflagは多くのプロダクトの開発・運用支援を手がけてきた経験があり、「お客様の声をどう扱うべきか」「優先順位をどうつけるか」といった実践的な知見を持っていました。

多くの支援会社は「お客様の声を大事にしましょう」と言います。しかしdeflagは、「お客様の言うことをそのまま開発するのはダメ。その奥にある"本当に成し遂げたいこと(要求)"に落とし込んで、優先度をつけていく必要がある」とはっきり伝えてくれました。

また、deflagは弊社の事業状況やチーム体制を理解したうえで、現実的で実行可能な進め方を一緒に考え、ハンズオンで支援してくれる点も評価されました。

– deflag 社の支援内容を教えてください。

F社のプロダクト開発チームの担当者様：

deflagは、弊社のプロダクト開発チームが「お客様の声に振り回される開発」から脱却できるよう、“要望を整理し、要求へ上位化して優先順位をつける”プロセスを導入してくれました。

1. 「要望」と「要求」の違いを明確にする

まず、deflagは弊社のプロダクト開発チームに「要望」と「要求」の考え方を浸透させました。

• 要望:お客様が「こうしてほしい」と言った"手段"や"方法"

  例:「この画面に〇〇の情報も表示してほしい」

• 要求:その要望の奥にある"本当に成し遂げたいこと"

  例:「顧客の状況を素早く把握して、対応をスムーズにしたい」

お客様の要望をそのまま開発していては、プロダクトが複雑になり使いづらくなります。

そこで、要望の背景を掘り下げ、“要求”として整理・構造化するプロセスを定着させました。

2. 溜まっていた要望リストを整理・グルーピング

弊社のプロダクト開発チームには、これまでに顧客や営業、社内から寄せられた約500件の要望リストが蓄積されていました。

そこでdeflagは、プロダクトマネージャー（PdM）・エンジニア・デザイナーの各チームを巻き込み、全要望を一つ一つ確認しながらテーマ別にグルーピングしました。

単なる分類ではなく、

• 「プロダクトのコアバリュー（中核価値）に沿っているか」

• 「事業ゴールへの貢献度は高いか」

• 「影響を受けるユーザーの数」

• 「実現難易度」

  といった複数の観点をもとに優先順位づけのフレームを設計しました。

これにより、声の大きさやタイミングではなく、事業とユーザーの双方にとって本当に重要な改善から着手できる判断基準が明確になりました。

3. PdM中心に“日々の要望整理サイクル”を仕組み化

これまでは、お客様・営業・社内など、要望の出どころがバラバラで管理しきれない状態でした。

そこでdeflagは、すべての要望を1つのシートに集約し、共通のルールで整理できる仕組みを整えました。

新たな要望を一覧化 → ラベル付け → グルーピング → 「要望 → 要求 → 優先度付け」の流れで整理され、その結果をロードマップ（開発計画）に反映する運用が定着しました。

この仕組みによって、PdMを中心にチーム全体が同じ情報を見ながら議論・判断できる状態が実現。deflagはテンプレートや運用ルールも整備し、弊社のプロダクト開発チームが自走できる体制を構築しました。

– deflag 社の支援を受けて、具体的な成果はありましたか？

F社のプロダクト開発チームの担当者様：

プロジェクトの結果、弊社のプロダクト開発チームでは次のような変化が生まれました。

1. 「何を作るべきか」が明確になった

蓄積されていた大量の要望リストが整理され、「お客様が本当に求めていることは何か」「事業のゴールに近い優先順位の高い要求は何か」が明確になりました。

また、チーム全体で、「なぜこれを作るのか」を理解したうえで動けるようになりました。

2. プロダクトが"使われるもの"に変わっていった

「要望をそのまま開発する」のではなく、「要求を見極めて優先順位をつける」プロセスが定着したことで、本当にお客様が求めている機能を届けられるようになりました。その結果、追加した機能がしっかり使われ、お客様からの満足度も向上していきました。

3. 自分たちで判断し、改善を続けられる体制が整った

最も大きな成果は、自分たちで要望リストを整理し、優先順位をつけ、プロダクトを進化させ続けられる体制が整ったことです。deflagの支援後も、PdMが定期的に要望リストを整理し、ロードマップに反映していくサイクルが回り続けています。

弊社のプロダクト開発チームは今、ユーザーの声に振り回されるのではなく、声を活かしてプロダクトを磨き続ける組織へと成長しています。

まとめ

今回のF社のように、「ユーザーの声が多すぎて整理できない」「開発の優先順位がつけられない」といった課題は、成長フェーズのSaaS企業に多く見られます。

deflagでは、チームが自ら判断し、継続的にプロダクトを進化させられる仕組みづくりを支援しています。

プロダクト開発の混乱を整理したい、チームを自走させたいと感じている方は、ぜひ一度ご相談ください。