作って終わりにしないための顧客検証ループづくり ～顧客ヒアリングを「価値検証フェーズ」として組み込んだ話
- 🧭 これまでの課題
- 🔁 今回整えた流れ
- 🌱 「PBI の種」という考え方
- 🌊 実際に感じている変化
🗣️ 実例：VoC 整理から生まれた改善テーマ
- 🧾 まとめ
- We Are Hiring!
こんにちは、ABEJA でプロダクト企画に携わる中村です。
今回は「ABEJA Insight for Retail（略称：IfR）」で取り組んだ、
“作って終わり”にしないための顧客検証ループづくりについてまとめます。
🔁 今回整えた流れ
そこで今回、リリース後の顧客ヒアリングを「価値検証フェーズ」として、開発サイクルの中に組み込みました。
流れとしては、以下のような形です。
開発・改善→ 顧客ヒアリング→ PBI の種化／顧客分析→ PBI 整理・精緻化→ 次の開発へつなげる
（※PBI→プロダクトバックログアイテムの略）
今回ポイントにしたのは、ヒアリング内容を単なる「感想の共有」で終わらせず、
- 次の改善候補として残す：PBI 化
- 顧客価値の観点で整理する：定性分析
の 2 つを並行して進めることです。
具体的には、顧客ヒアリングで出てきた違和感・困りごと・要望などを、まずは「PBI の種」としてそのまま残します。
一方で、同じ内容を KA 法なども使いながら整理し、
- 本当に解くべき課題は何か
- 他顧客でも起こりうるか
- どの価値につながるか
といった観点で分析を行い、次の開発につなげるようにします。
以前は「作ること」が中心になりがちでしたが、今は「作った後に何を学ぶか」まで含めて、プロダクトサイクルとして回し始めています。
🌱 「PBI の種」という考え方
今回、もう一つ大きく変えたのが PBI の扱い方です。
これまでは主に PO や PdM が PBI を起票していましたが、今回からは「PBI の種」という形で、より柔軟な起票の仕組みを導入しました。
ビジネスメンバーに限らず、顧客接点を持つ全員が、気づきや違和感をそのまま残せるようにしています。
特に意識したのは、「まずは声を取りこぼさないこと」です。
そのため、
- 重複していても OK
- 粒度が揃っていなくても OK
- 解決策まで整理されていなくても OK
という形で、入口のハードルをかなり下げています。
※PBI（Product Backlog Item）の種を PBI にするフロー（整理・統合など）については別途運用として整備しているため、こちらはまた別の機会に紹介できればと思います。
🌊 実際に感じている変化
まだ運用を始めたばかりではありますが、少しずつ変化も出てきています。
例えば、
- 顧客の声が次の改善につながりやすくなった
- 「顧客価値を届けられる」開発・リリースが増えてきた
- Biz（ビジネス）、Dev（開発）、PO（プロダクトオーナー）、PdM（プロダクトマネージャー）で同じ課題を見ながら議論しやすくなった
- 開発後（スプリントレビューなど）の会話が「作った」ではなく「価値につながったか」に変わってきた
など、プロダクト開発の見方そのものが変わり始めています。
🗣️ 実例：VoC 整理から生まれた改善テーマ
ここで一つ、ヒアリングと分析から見えてきた改善の実例を挙げてみます。
KA 法（KJ 法の A 型）で VoC（Voice of Customer：顧客の声）を整理する中で、「数値だけでは分からない現場の判断や背景も一緒に扱いたい」というニーズが見えてきました。
さらに顧客ヒアリングの中でも、「AI の分析結果に SV（Store Visitor：来店者）や店長の声を追加し、現場の意見を交えながら振り返りたい」という声が上がっていました。
以前であれば単発の要望として流れていたかもしれませんが、
今回は分析結果とヒアリング内容を整理したうえで PBI 化し、次の改善サイクルにつなげています。
🧾 まとめ
今回の取り組みは、派手な新機能というよりも、プロダクト開発の“回し方”を整える試みでした。
作って終わりではなく、作ったものを次に活かせる「気づき」や「判断材料」に変えていく。そのループを少しずつ強くしていくのが今回の狙いです。
今後もこのサイクルを改善しながら、より再現性のある形に育てていきたいと思います。
※KA 法（KJ 法の A 型）
：集めた定性情報（発言・観察メモなど）を整理し、課題や示唆を抽出する方法
参考（KA 法とは）：https://popinsight.jp/blog/?p=39265#i
We Are Hiring!
ABEJA は、テクノロジーの社会実装に取り組んでいます。技術はもちろん、技術をどのようにして社会やビジネスに組み込んでいくかを考えるのが好きな方は、下記採用ページからエントリーください！（新卒の方やインターンシップのエントリーもお待ちしております！）
原文を表示
- 🧭 これまでの課題
- 🔁 今回整えた流れ
- 🌱 「PBIの種」という考え方
- 🌊 実際に感じている変化
🗣️ 実例：VoC整理から生まれた改善テーマ
- 🧾 まとめ
- We Are Hiring!
こんにちは、ABEJAでプロダクト企画に携わる中村です。
今回は「ABEJA Insight for Retail（略称：IfR）」で取り組んだ、
“作って終わり”にしないための顧客検証ループづくりについてまとめます。
🔁 今回整えた流れ
そこで今回、リリース後の顧客ヒアリングを「価値検証フェーズ」として、開発サイクルの中に組み込みました。
流れとしては、以下のような形です。
開発・改善→ 顧客ヒアリング→ PBIの種化／顧客分析→ PBI整理・精緻化→ 次の開発へつなげる
（※PBI→プロダクトバックログアイテムの略）
今回ポイントにしたのは、ヒアリング内容を単なる「感想の共有」で終わらせず、
- 次の改善候補として残す：PBI化
- 顧客価値の観点で整理する：定性分析
の2つを並行して進めることです。
具体的には、顧客ヒアリングで出てきた違和感・困りごと・要望などを、まずは「PBIの種」としてそのまま残します。
一方で、同じ内容をKA法なども使いながら整理し、
- 本当に解くべき課題は何か
- 他顧客でも起こりうるか
- どの価値につながるか
といった観点で分析を行い、次の開発につなげるようにします。
以前は「作ること」が中心になりがちでしたが、今は「作った後に何を学ぶか」まで含めて、プロダクトサイクルとして回し始めています。
🌱 「PBIの種」という考え方
今回、もう一つ大きく変えたのがPBIの扱い方です。
これまでは主にPOやPdMがPBIを起票していましたが、今回からは「PBIの種」という形で、より柔軟な起票の仕組みを導入しました。
ビジネスメンバーに限らず、顧客接点を持つ全員が、気づきや違和感をそのまま残せるようにしています。
特に意識したのは、「まずは声を取りこぼさないこと」です。
そのため、
- 重複していてもOK
- 粒度が揃っていなくてもOK
- 解決策まで整理されていなくてもOK
という形で、入口のハードルをかなり下げています。
※PBI の種をPBI にするフロー（整理・統合など）については別途運用として整備しているため、こちらはまた別の機会に紹介できればと思います。
🌊 実際に感じている変化
まだ運用を始めたばかりではありますが、少しずつ変化も出てきています。
例えば、
- 顧客の声が次の改善につながりやすくなった
- 「顧客価値を届けられる」開発・リリースが増えてきた
- Biz・Dev・PO・PdMで同じ課題を見ながら議論しやすくなった
- 開発後（スプリントレビューなど）の会話が「作った」ではなく「価値につながったか」に変わってきた
など、プロダクト開発の見方そのものが変わり始めています。
🗣️ 実例：VoC整理から生まれた改善テーマ
ここで一つ、ヒアリングと分析から見えてきた改善の実例を挙げてみます。
KA法でVoCを整理する中で、「数値だけでは分からない現場の判断や背景も一緒に扱いたい」というニーズが見えてきました。
さらに顧客ヒアリングの中でも、「AIの分析結果にSVや店長の声を追加し、現場の意見を交えながら振り返りたい」という声が上がっていました。
以前であれば単発の要望として流れていたかもしれませんが、
今回は分析結果とヒアリング内容を整理したうえでPBI化し、次の改善サイクルにつなげています。
🧾 まとめ
今回の取り組みは、派手な新機能というよりも、プロダクト開発の“回し方”を整える試みでした。
作って終わりではなく、作ったものを次に活かせる「気づき」や「判断材料」に変えていく。そのループを少しずつ強くしていくのが今回の狙いです。
今後もこのサイクルを改善しながら、より再現性のある形に育てていきたいと思います。
※KA法（KJ法のA型）
：集めた定性情報（発言・観察メモなど）を整理し、課題や示唆を抽出する方法
参考（KA法とは）：https://popinsight.jp/blog/?p=39265#i
We Are Hiring!
ABEJAは、テクノロジーの社会実装に取り組んでいます。 技術はもちろん、技術をどのようにして社会やビジネスに組み込んでいくかを考えるのが好きな方は、下記採用ページからエントリーください！ （新卒の方やインターンシップのエントリーもお待ちしております！）
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み