競合や要望に流されない─B2B SaaSでミニマム要件を決めるリアルな取り組み / Don't be swayed by competitors or requests - A real effort to determine minimum requirements for B2B SaaS

2025/12/4
pmconf 2025
https://2025.pmconf.jp/

競合や要望に流されない─B2B SaaSでミニマム要件を決めるリアルな取り組み

山下 亜梨沙
プロダクトマネージャー

Transcript

1. 競合や要望に流されない── B2B SaaSでミニマム要件を決める リアルな取り組み 株式会社カミナシ ⼭下亜梨沙 2025
2. 株式会社カミナシ プロダクトマネージャー ⼭下 亜梨沙 @96kemu96 • Webディレクター、データ分析（レバレジーズ） 
 • Webマーケコンテンツ制作（ユーザベース） 
 経歴とバックグラウンド • 「カミナシ 従業員」のプロダクトマネジメント 
 ◦ これまで：「カミナシ レポート」「カミナシ 設備保全」
 主な仕事内容 • ユーザー視点で考えること 
 ⼤事にしていること ⾃⼰紹介
3. ノンデスクワーカーの 才能を解き放つ Mission
4. カミナシは“現場の基盤”となる領域で 4つのプロダクトを展開 Method 作業 Men ⼈ Machine 設備 電子帳票
 マニュアル・研修
 コミュニケーション
 設備カルテ
 1つのアカウント運用で複数のシステムを利用。運用の負担軽減とセキュリティ向上

5. “ミニマムに開発しよう” そうは思ってはいるものの...
6. B2Bは競合機能や顧客のユースケースを調べていくうちに、要件が増えやすい ミニマムな アイディア 大きな声のユーザー 様々なユースケース 競合にある機能 この機能までないと、 実運用が難しい
7. その結果、リリースしたものの‧‧‧
8. どうすれば ミニマムに開発にできるか？
9. とにかく⼩さければいい ミニマム ＝ ROIと価値検証が 成⽴する最⼩単位 “良いミニマム” とは
10. 1 2 ROIが⾒合う 価値検証ができる 開発‧保守に対して、⼗分なリターンを得られるか 「提供したい価値」を検証できるサイズか “良いミニマム” を満たす2つの条件
11. 良いミニマムは、ケースバイケース だからプロセスが⼤事！
12. ミニマムな開発をするために プロセスで⼤事なこと 4 つ
13. アウトカム 1 俯瞰
 2 巻き込み
 3 自問自答
 4 ミニマムに開発をする 4 つの要素
14. 俯瞰
 2 巻き込み
 3 自問自答
 4 アウトカム 
 1 ミニマムに開発をする 4 つの要素
15. PM セールス‧CS よくある例：アウトカム⼤きくなる問題 （信頼している分）アウトカムの仮説を、そのまま受け取ってしまう A機能があると、 この業界に売れます！ あのセールス‧CSの⼈が 筋が良いと⾔ってたし
16. こうする！ 
 前提の変化や、全体像を掴み切れていない部分も当然あるので、 アウトカムを⾃分の頭で整理し直す 聞いたこと
 実際
 A機能があれば、この業界に売れる 
 全体像を理解しきれていない 実際はB機能やC機能も必要 A機能がないと、チャーンしそう 
 時間経過 活用フェーズが変わり、実は別の機能が重要 A機能あれば、売上作れます！ 
 協力的な態度 応援したいというマインドから
17. アウトカム 
 1 俯瞰
 2 ミニマムに開発をする 4 つの要素 巻き込み
 3 自問自答
 4
18. ステークホルダー間で「⾃分の思うミニマムライン」が違い、議論が増える よくある例：ミニマムのラインがずれる問題 ここは削って いいですよね？ これないと困ります ここが最低限のUX！ 開発中 デザイン検討中 デザインレビュー中
19. ユーザー ストーリー ユースケース UX の 良 さ 検証したい価値のライン こうする！ 
 価値の全体像を俯瞰してから線引きすると、⽬線が揃う 競合調査やVoCを広めに収集
20. 俯瞰
 2 巻き込み
 3 自問自答
 4 アウトカム 
 1 ミニマムに開発をする 4 つの要素
21. EngとDesは「ソリューション検討」から巻き込むのが効率的 よくある例：実は良いソリューションではない問題 
 
 アウトカム 課題 解決策 ソリュー ション 開発 リリース PMの脳内 • 課題から巻き込んだ⽅がいいとは思いつつ... ◦ EngやDesはデリバリーで忙しい ◦ 顧客解像度が⾼いのは⾃分なので、先に整理しておこう 何が問題か • ソリューションの良い幅が出ない ◦ 「（特に思いつかないので）いいと思います！」 ◦ 「（すでに⾊々考えていると思うので）アグリーです！」
22. 「課題整理」から巻き込むのが効率的（顧客価値‧デリバリーにおいて） よくある例：実は良いソリューションではない問題 アウトカム 課題 解決策 ソリュー ション 開発 リリース 何が良いか • 良いソリューションの幅が出る ◦ 開発⼯数と提供価値の塩梅が良い、ハイコスパ案 ◦ 課題解決の芯を⾷った案 • エンハンスを考慮した設計 巻き込みイメージ • 顧客ヒアリングの同席 • 課題整理ワーク
23. 俯瞰
 2 自問自答
 4 アウトカム 
 1 ミニマムに開発をする 4 つの要素 巻き込み
 3
24. whyとwhatは、チームにもう何回か説明したら途中から省略する この機能を 開発する理由 よくある例：思い込み問題 
 ミニマムになった！ あとは開発するだけ！
25. その機能を 切望しているのは どの会社の誰？ 本当に 今 ？ こうする！ それ、本当に開発しないと いけないんですか？ ⼀度⾃分が良いと思った案でも、考え直すべき 毎回でもチームにwhyとwhatを話し、⾃分が質疑応答に晒される機会を作る
26. ここで終わりではない
27. よくある例：リスクが抽象的なまま問題 
 たしかに！ 対応しないと ミニマム要件をCSと合意する際、 リスクのの観点で、対応した⽅が良いことが増える ユーザーに価値を届けるラストワンマイル PM セールス・CS エッジケースの存在 これだと ユーザーが混乱するかも
28. こうする！ 
 PM セールス・CS 具体で考えれば、リスクを明確化して管理できる 具体で会話すると合意しやすく、開発や顧客コミュニケーションを⼩さく着地しやすい よかった！ じゃ影響範囲は 小さいですね。 データ確認 該当は5社のみ リスク管理 機能開発せず 一旦様子を見る 個別案内はする
29. • 良いミニマムとは：ROIと価値検証が成立する
 • 検討プロセス4つの要素：
 ◦ アウトカムを捉え直す
 ◦ 価値の全体を俯瞰してスコープを切る
 ◦ EngとDesを課題整理から巻き込み
 ◦ 自問自答する（誰今）
 • 合意形成のコツ：リスクを具体化
 まとめ
 AI時代、顧客検証の学習量が重要変数です。
 日々の地味な取り組みも多いですが、一緒にミニマム開発してきましょう💪

30. Thank you!