SaaSの開発ROIってどうやって考えるの?ラーメンに置き換えて考えてみよう🍜
※あくまで個人的な考え方です🐖
序章 20XX年、世界は“大RaaS時代”
ラーメンを欲する者は店へ行かず、端末を叩く—
そこにはラーメンファンが望んだラーメンが届く、ラーメン as a Service《RaaS》が待っている。
20XX年。自宅キッチンに据え付けられた RaaS(ラーメン as a Service) が、ボタンひとつでラーメンを仕上げるのが当たり前になった。
この世界で頭角を現したのが 統合型豚骨 RaaS《トンジャー》 だ。
濃厚豚骨スープを一本の背骨に、塩ベースのかえしで作る「長浜ラーメン」、豚骨醤油ベースのかえしで作る「二郎系ラーメン」、鶏ガラ醤油ベースで作る「家系ラーメン」などのあらゆる流派を
創業時から継ぎ足しで熟成した濃厚な豚骨スープを基盤に提供する──そんなRaaSプロダクトである。
ところが 20XX 年 4 月、トンジャー開発室で事件が起きる──。
第一章 トッピング開発会議の決裂
からし高菜・溶き卵・キャベチャーのトッピングを作りたい!
トンジャーの PMM ハム 🐖は、ボードの前に 3 枚のカードを貼った。
-
"KARASHI-TAKANA" – 長浜ラーメンに必須の辛子高菜トッピング機能
-
"TOKI-TAMAGO" – 二郎系ユーザー待望の溶き卵オプション機能
-
"KYABE-CHA" – 家系ユーザーが叫ぶキャベツ+チャーシューの肉感ミックス機能
ハム🐖「20XX年の今年はこの3つの機能開発でトンジャーファンを増やしたいです!開発させてください!」
だが CxO 豚太郎🫃 は眉間に皺を寄せる。
豚太郎🫃「今年の開発コストはトンジャーの運用保守でもう決まっておる。高菜で ARR がいくら伸びる?卵で解約率は何%下がる?キャベチャーに関しては意味がわからん――数字を出してくれ」
ハム🐖は沈黙し、無言で目の前にある二郎系ラーメンを啜ることしか出来なかった...(+10kg)
第二章 “機能 ROI”という幻想
その夜、PMMのハム🐖はバーチャル厨房で1人、スープの湯気を眺めながら悟る。
— RaaSなんだから、機能単体ごとに ROI を切り出して投資対効果を説明するなんてのは無理だ...
“機能 ROI”で考えてしまうことで陥る3つの壁
-
機能単体でARRは伸ばせない — ユーザーは“単体機能だけ”を欲しない。業務フローで考えており、機能の掛け算でこそ解決出来るため、機能ROIという考え方では費用対効果を出せない。
-
解約率 / churn改善も機能単体では成せない — 解約減は UIUX改善や日々の機能アップデートによる満足体験の総和。単機能に帰属しない。
-
経営の焦り — とはいえ経営陣や投資家は“投資対効果”を求めるが、旧来の式では霧が深まるばかり。
ハム🐖はホワイトボードを消し、マトリクスを描き始める。
第三章 "PMF軸で考えるROI" へ—9 マスの物語
深夜2時。バーチャル厨房の照明は落ち、引き続き煮立つ豚骨スープの湯気だけが浮かび上がっていた。
ハム🐖は黒マーカーを握り、ホワイトボードに3×3 の方眼を引く。九つの小さな四角は、闇に浮かぶ “未踏の島々” のようだ。
ハム🐖「ここに灯りを点ければ、湯気の中から航路が見えるはず」
トンジャーのPMFセグメント設定
-
縦軸: RaaS 利用段階
① 未利用(アナログ) ② RaaS 他社利用 ③ トンジャー利用
-
横軸: ラーメン流派
(A) 長浜 (B) 二郎系 (C) 家系
A 長浜 | B 二郎系 | C 家系 | |
---|---|---|---|
① 未利用 | ○ | △ | ◎ |
② 他社RaaS利用 | ▲ | × | ○ |
③ トンジャー利用 | △ | × | ▲ |
(◎=Product Market Fit>90%, ○=70%, ▲=50%, △=30%, ×=10%)
トッピング開発とそれによるPMFの向上
トッピング | 影響するセグメント | PMF% Before→After | 理由 |
---|---|---|---|
からし高菜 | ②-A / ③-A | 50→70 / 30→50 | 市場調査によると、競合の長浜系RaaSではからし高菜は当たり前機能。そのためバッティング負けしてる。 |
溶き卵 | ①-B | 30→50 | 二郎系のRaaS市場では「溶き卵」などトッピングを作る機能不足が顕著で、まだアナログラーメン(実店舗に出向く)が主流。二郎系市場でトッピングを作る最初のRaaSになり、PMF%を向上させる。 |
キャベチャー | ③-C | 50→90 | 「チャーシューの小さな家系ラーメンに足りていない肉感を補って欲しい!」と既存ユーザーからフィードバックが多く、ロイヤリティを向上できる。 |
ハム🐖「ROI は PMF% × セグメント規模 でみる!そうすることで、1つの機能開発でも市場を獲得するために必要なマイルストーンだと説明できる!」
ボードに立つ CxO 豚太郎🫃の頬が、ラーメン以外ではじめて緩んだ瞬間だった。
CxO 豚太郎🫃「ゴールは『トッピングの新機能開発でいくら儲かるか』じゃない。 “どの島で旗を立てるか”──セグメントで勝つことだよね」
豚太郎🫃はボードに3つの方針を描いた。
-
PMF スコアリング ―― PMFを数値で測る。そのためにVoCや市場調査といった外部環境の観測によって、各セグメントの定量化が欠かせない。
-
レベル型ロードマップ ―― 別立てで、プロダクトのロードマップ策定が必要。各プロダクト(長浜 / 二郎系 / 家系)が、それぞれのセグメントでいつ “航海可能” になるかを示す。
-
GTM戦略 ―― PMF%が低いセグメント / 高いセグメントごとで事業における戦い方は異なる。そのようなGTM戦略の地図が確かでないと、開発ROIの算出は成り立たない。
まとめ 成熟したSaaSやコンパウンドSaaSにおける開発ROIの考え方
とまあ、ここまでは豚骨の香り漂うフィクションだったわけですが...🐖
成熟したSaaS、特に複数モジュールを束ねるコンパウンド型SaaSでは、単体での"機能ROI"を軸にした投資判断は想像以上に難しいと思っています。
-
機能と成果の非線形性
- モジュールが絡み合い、「この機能=この売上」という単線が引けない。
-
ユーザー体験の複合依存
- UI、サポート、価格、データ統合……トッピングや素材1つで大きく変わらない。味は絡みあって決まる。
-
GTM のタイムラグ
- PMF が完成してから市場に火を点けても遅い。投資効果は“事前の狼煙”で決まる。
-
競合の動的ベンチマーク
- 自社が進化しても競合も進む。ROI は常に相対値で揺れる。
その問題を打破する考え方として、「PMFセグメント×ロードマップ×GTM戦略」 の視点で考えてみるのは1つの手なんじゃないかなと思っています。
例えばジンジャーだと...という話
具体例を出しすぎると僕が考えているプロダクト戦略が筒抜けに...なので少しだけお話しさせていただくと
例えば、昨年末からジンジャーは「画面のリデザイン」に取り組んでいます。
UIUXの改善というのは、投資対効果の出しにくいもので、画面の使いやすさが改善することによって「これだけ売りが立つ」「これだけ解約率が下がる」と定量的に説得材料として準備できないと思っています。
ただ、リデザインによる効果を今回のフレームワークに当てこんで考えると...
-
セグメントで考える:リデザインにより「従業員数の多いアナログ管理からのリプレイス層」や「既にジンジャー勤怠給与は基幹システムとして使っているけど、ペーパーレス化は着手できていない層」へのPMF%を向上することが出来る。
-
ロードマップで見据える:プロダクトロードマップを鑑みた時にリデザインは越えなければいけない壁なので、中長期計画から逆算して今からスタートする。
-
GTM戦略との突き合わせ:競合ベンダーさん含めSaaSはデザインが良いサービスが多いものの、それぞれのセグメントごとでバッティングするベンダーさんも異なるので、リデザインをアピールするセグメントとそうじゃないセグメントはGTM戦略として考える。
-
備考で開発の話:そろそろデザインシステム作らんとデザイナー↔︎PdM↔︎Devの要件のやり取りも煩雑になり開発工数や品質にも影響するので、そういう改善にもなるよ?
(この話は弊社のスーパーデザイナーkadoさんが別で奮闘記を上梓してくれるので、ぜひ見てみてください!)
https://zenn.dev/jinjer_techblog/articles/df3f83c9383cb0
まるで濃厚スープを小鍋で煮詰めるように、深い島を1つずつ制圧する——というストーリーと、セグメントの定量化が成功することで、SaaSにおける開発ROIって考えられたりしないかな?と僕は思っております。
というお話しでした笑
FYI トンジャーみたいなラーメン屋、リアルにあります笑
「ラーメン男盛」
濃厚な豚骨スープを「呼び戻し製法」で仕込んでいて、そのスープを軸に提供する「長浜ラーメン」「二郎系ラーメン」が絶品です🐖
(たまに限定で登場する家系ラーメンやラーショインスパイアもめちゃくちゃ美味しい...)
これまで「長浜ラーメン食べて〜」「二郎系食べて〜」だったんですが、
男盛の登場によって「豚骨を喰らいたい」→「男盛行くか!どれにしよう...」って考え方に変わりました。
まさに、ジンジャーも「労務管理変えて〜」「勤怠管理変えて〜」「タレマネやりて〜」「人的資本して〜」って思って選ばれるのではなく
「人事データまとめたい!管理したい!」って思って、その先の人事業務や課題を解決してくれるような想起をいただけるようになりたいですね...🐖
Discussion