ユーザー理解してる“つもり”から抜け出す──PdM視点で考えるアジャイルチームの落とし穴とは…

アジャイルチームに潜む「ユーザー理解できてるつもり」問題
ユーザーインサイトを深掘りする
- 📌 KA法分析（例：分析根拠に自信がないユーザー）
チームで観察することを仕組み化する
POが正解を持たない前提に立つ
「つもり」ではないユーザー理解に近づいた
まとめ：理解し続けるチームがユーザー中心を実現する
- 🗨️ポイントまとめ
We Are Hiring!

こんにちは！ABEJAでプロダクト企画に携わる中村です。この記事はABEJAアドベントカレンダー2025の18日目の記事です。

アジャイル開発の現場では、「ユーザー中心」「仮説検証」「データドリブン」といった言葉をよく耳にしますよね。ありがちなのが形だけ取り組んでみたものの、チームがユーザーを理解している“つもり”のまま進んでしまうとか、仮説のまま突き進むなんてケースも多いのではないでしょうか。

本記事では、私の開発チームでの経験を踏まえ、PdMの視点から「ユーザー理解の難しさ」とどう取り組むべきかを整理してみます。PdMだけでなく、開発、営業、デザインなど、ユーザーに価値を届けたいすべての人に届くようまとめてみました。

アジャイルチームに潜む「ユーザー理解できてるつもり」問題

例えば、インセプションデッキやペルソナ設定をしても、形骸化してしまうなんてケースは少なくありませんよね。私のチームでもまさにそんな経験をしました。

ユーザーとの接点は多少はあるものの、理解が中途半端で開発が進み、データ計測や効果検証ができていなかったため、チーム自体が仮説のまま勘と経験で突き進むなんてことになってしまっていました。ユーザーにいまひとつハマる機能にならない……これを深掘りしていくうちにようやくユーザーを理解した“つもり”のままだったことに気づきました。

この背景には、リソース不足の問題はもちろん、認知バイアスや検証不足など色々な問題が潜んでいました。結果として仮説のまま開発が進み、本質的な課題を見逃してしまいがちになっていたのです。

状態・現象	原因	結果
ユーザー理解できてる“つもり”	リソース不足・認知バイアス・検証不足	仮説のまま開発 → 本質的な課題を見逃す

ユーザーインサイトを深掘りする

ユーザーの課題をヒアリングすると、「この機能を作れば解決できる」と考えがちです。しかし、表面的な課題の奥には、より本質的な課題（インサイト）が潜んでいます。

例えば、あるユーザーから「分析根拠に自信がない」と相談を受けたとします。一見すると分析機能の改善が必要に思えますが、「KA法」という手法を使って掘り下げると、背景には組織の構造やデータ運用の課題が浮かび上がりました。

📌 KA法分析（例：分析根拠に自信がないユーザー）

項目	内容
K（出来事）- 事実・観察	・数値分析の結果に「本当に合っている？」と不安になる・比較対象データが分からず、判断が難しい・分析後にExcelや他の資料で再計算・確認し直している・上司やチームから根拠を求められると説得できない
A（解釈）- 心の声・意味づけ	・「基準がないから合っているか判断できない」・「分析方法が正しいか確信が持てない」・「比較対象が定義されていないから迷う」 👉 分析そのものより、“判断のよりどころ” が欠けていることが不安の源
Insight（気づき）- 暗黙価値	🔍 ユーザーは正確なデータや高度な分析スキルよりも、 👉 迷わず判断できる「基準・比較軸・安心材料」を求めている。
本質価値（価値へ翻訳）	✨ 根拠に迷わず、自信を持って意思決定できる状態。（＝自分の分析結果が正しいと確信し、他者にも説明できる状態）

つまり、表面的な課題だと「分析精度の向上」にしてしまいがちですが、本質的な課題は「意思決定の根拠に自信を持てるようなスキルや環境が乏しい」というところが見えてきます。

そしてこの本質的なユーザー価値から機能要件を導くとこのようになります。

UX要求仕様	ユーザーが感じたい状態	Why（背景価値）
🔹 分析結果の信頼性が視覚化される	「この結果は正しい」と納得できる	結果の裏付けが見えることで不安が消える
🔹 比較基準・推奨指標が明示されている（業界トレンドなど）	迷わず判断できる	自分で基準を考える負担がなくなる
🔹 根拠（データソース・計算ロジック）が確認できる	説明可能な状態になる	上司・関係者に説明できるようにしたい
🔹 判断サポート（例示・推奨ポイント）が提供される	自信を持って決断できる	「間違っていない」と認知できる

チームで観察することを仕組み化する

私がもう一つ行った重要な取り組みは、このユーザー理解をチーム全体で仕組み化することでした。

具体的には、ペルソナやユーザーストーリーマッピングの定期的な見直しを行い、営業チームも含め全員で意見を出し合います。

個人の解釈で終わらせず、チーム総出で精度の高いユーザー像を作る時間をなんとか確保しました。また営業チームとの協業によるユーザーアンケートやインタビューを定期的に行い、フィードバックサイクルを回すことで、ユーザー理解の解像度を高めます。

ただこの取り組みは、多忙なステークホルダーを如何にして集めたり、時間を確保するかというところに苦労や工夫も不可欠でした。

目の前にある顧客対応やタスクに追われるメンバーたちに、「一見遠回りに見える活動も、必ず効率化への道筋になる」と繰り返しお願いし、ひたすら地道に続けました。

こうして私のチームでは、ユーザー像の共通認識化やリファインメント、PBI作成の効率化など、早くも成果が出始めています。

POが正解を持たない前提に立つ

この変化を通じて改めて感じたのは、アジャイル開発ではPOが最初から正解を持っているわけではないという当たり前の事実です。ユーザー像がチーム内で共通認識化していなかった頃、リファインメントは「POに仕様やユーザー行動を確認する質問会」になりがちでした。しかし、ユーザー理解が共通言語になるに従い、開発者を含むステークホルダー全員が「このユーザーならどう感じるか？」を起点に考えられるようになります。

一見すると、「みんなで考えるのは時間がかかりそう」…遠回りのように思われるかもしれません。しかし実際にはその逆です。判断の前提が揃っている、ユーザー軸で議論できる、手戻りが減る、実装後の修正も減り「正解をPOが与える構造」から「チームで正解を探す構造」へ変わりました。結果として、リファインメントやPBI作成のスピードと質が向上していったのです。

このようにしてユーザー観察からナレッジ共有、ペルソナやユーザーストーリー更新、仮説検証、開発、のプロセスを回す仕組みを改善し、ようやくこれまで滞っていた血液循環を健全な状態に近づける手がかりを得ました。