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