どちらも「ユーザーのため」だった —価値の対立を仮説検証に変えて

Scrumfest Osaka 2026での登壇資料です。
https://www.scrumosaka.org/

ある日やってきた「これを導入すればユーザー体験が改善する」という機能提案に、プロダクトマネージャーの私は「改善にはならない」と考え、議論は平行線。より上位の管理職に決めてもらうという話も出ましたが、ユーザーに近い現場の方が絶対によい意思決定ができるはず。

そこで私は、賛成も反対もやめて、現場により近い別のチームも巻き込み「指標がどうなれば成功ですか」「ガードレールを引いた上で検証しましょう」と提案しました。ガードレール指標が一定ラインを下回ったら撤退する。閾値は、組織の歴史から引用してきました。

結果として、対立は「どちらが正しいか」ではなく「仮説をどう検証するか」、そして「そもそも今やるべきか」という生産的な問いに変わりました。

このアプローチは、飯沼亜紀さんがRSGT2026『「アウトプット脳からユーザー価値脳へ」がそんなに簡単にできたら苦労しない 』で提示された「会話の設計」「KPIの設計」という考え方に多くを負っています。本セッションは、その枠組みを実際の、少し前提の異なる現場の対立に応用してみたら何が起きたか、という実践報告です。

「価値」をめぐる意見の対立を「価値観の違い」で終わらせず、価値を産むための行動に変えるにはどうすればいいのか。定性的な意見の対立を仮説検証の枠組みに変換する、具体的なアプローチを共有します。

Transcript

1. どちらも「ユーザーのため」だった ⸺価値の対⽴を仮説検証に変えて Scrum Fest Osaka 2026 | 2026年7⽉31⽇〜8⽉1⽇ Aki Tanaka / mamedai Scrum Fest Osaka 2026 1 / 17
2. ⾃⼰紹介 Aki Tanaka / mamedai toC サービスのプロダクトマネージャー その前はBtoB SaaSのPMなど。 関⻄在住。 mamedaiという名前でnoteを書いています。 X : @mamedai55 note:@mamedai55 Scrum Fest Osaka 2026 2 / 17
3. 組織内で対⽴したら？ ある⽇、担当プロダクトにある機能の導⼊提案がありました 提案者: 「これを導⼊すれば、ユーザー体験が改善する。⾒積もりをお願いします。」 わたし(PM): 「ユーザー体験の改善にはならない。」 お互いが本気で「ユーザーのため」を考えて主張し、平⾏線。 Scrum Fest Osaka 2026 3 / 17
4. どちらかが正しいのではなく “ Everyone is right — partially. みんな正しい、ただし部分的に ” Scrum Fest Osaka 2026 4 / 17
5. 対⽴のよくある解消⼿法     1. 声の⼤きい⼈ 2. エスカレーション 3. ユーザーテスト 4. ビジョン 声の⼤きさでの決定は ただの「抑圧」にな り、価値探求できな い。 偉い⼈に委ねれば、 「ユーザーから遠い ⼈」に決めてもらうこ とになる。 どのユーザーに聞くか で結論が変わってしま う危うさがある。 ⾃分の都合に合わせて 解釈し、正当化できて しまう。 これらは「誰が正しいかを決める」⼟俵から降りていない。 Scrum Fest Osaka 2026 5/ 17
6. 話し合いだ！ Scrum Fest Osaka 2026 6 / 17
7. 偉い⼈に決めてもらいます でも、現場の⽅が絶対にいい意思決定ができるはず。 Scrum Fest Osaka 2026 6 / 17
8. 思い出したフレームワーク 飯沼亜紀さん（※mamedai視点） 引⽤元：「アウトプット脳からユーザー価値脳へ」がそんなに簡単にできたら苦労しない #RSGT2026（飯沼亜紀） Scrum Fest Osaka 2026 7 / 17
9. 会話の設計 STEP 01 STEP 02 STEP 03 STEP 04 誰のどんな⾏動が どう変わったか？ その変化はどの指標 にあらわれている？ それは事業や数字に どう効くか？ それを受けて 次に何をするか？ アウトプット（ビジネス）vsユーザー価値が前提のフレームワークをユーザー価値vsユーザー価値に応⽤できるのでは 引⽤元：「アウトプット脳からユーザー価値脳へ」がそんなに簡単にできたら苦労しない #RSGT2026（飯沼亜紀） Scrum Fest Osaka 2026 ８/ 17
10. 説得をやめて仕事をしよう 引⽤元：「アウトプット脳からユーザー価値脳へ」がそんなに簡単にできたら苦労しない #RSGT2026（飯沼亜紀） Scrum Fest Osaka 2026 ９/ 17
11. 仮説検証の設計へ 成功指標 （提案者の視点） ガードレール （わたしの懸念） ‧機能導⼊で顧客の⾏動はどう変わる？ ‧その結果、どの事業指標が動けば成功？ ‧「ユーザー体験を損なった」と 判断できる閾値はないか？ ビジネスとしてのアウトカム 安全に検証するための境界線 Scrum Fest Osaka 2026 10 / 17
12. 現場により近いチームを巻き込む エスカレーション 現場を巻き込む 「ユーザーから遠ざかる」⽅向。 「ユーザーに近づく」⽅向。  現場とのコラボレーション 顧客と接し、指標を⽇常的にモニタリングしている他の現場チームを議論に⼊れ、 成功指標、ガードレールを共同設計する。 Scrum Fest Osaka 2026 11 / 17
13. ガードレールの閾値はどこで引くか 閾値を誰かの主観で引くと、 主観の対⽴に戻る 閾値は、客観的で、動かしがたい根拠を持つ必要がある 組織の歴史でひく 過去、ある指標が⼀定以下まで下がったとき組織として⼤き な判断を下した。その「痛みの記憶が伴う値」を客観的な物 差しとして使う Scrum Fest Osaka 2026 12 / 17
14. 対⽴が共同の「問い」に変わる [Before] 主観の戦い [After] 客観への探求 どちらが正しいか？ 仮説をどう検証するか？ 「ユーザー体験が良くなる」 vs 「良くならない」という、 「撤退ラインを超えずに成果をえられるか？」 結論を互いに証明できない不⽑な対⽴。 に問いが変化し、検証へと思考がシフト。 Scrum Fest Osaka 2026 13 / 17
15. 想定外の結末 検証の設計を通じて、成功指標とリスクの共通認識ができた。そして、 検証は実⾏されなかった。皆はそれを受け⼊れた。 「とにかくリリース」ではなく、仮説の⼀つとして相対的に扱われた結果、他の 施策が優先された。そして仮説の質は成果の質に直結する。 Scrum Fest Osaka 2026 14 / 17
16. わかり合えないまま、⼀緒に進む どれほど⽬的や価値観を共有するチームであっても、 どこかで解釈の違いや対⽴は⽣まれるかもしれない。 それでも建設的に前に進むことはできます。 Scrum Fest Osaka 2026 15 / 17
17. References / 参考⽂献 飯沼 亜紀 ⽒ 「アウトプット脳からユーザー価値脳へ」がそんなに簡単にできたら苦労しない #RSGT2026 https://speakerdeck.com/aki_iinuma/autopututonoy-karayuzajia-zhi-noy-he-gasonnanijian-dan-nidekitaraku-lao-sinai-number-rsgt2026 Scrum Fest Osaka 2026 16/ 17
18. ありがとうございました X : @mamedai55 Scrum Fest Osaka 2026 17/ 17