Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
BtoB SaaS開発における Minimum Viable Product への勘所
Search
Niwa Takeru
December 06, 2023
Technology
1
1.3k
BtoB SaaS開発における Minimum Viable Product への勘所
https://product-engineer.connpass.com/event/301502/
Niwa Takeru
December 06, 2023
Tweet
Share
More Decks by Niwa Takeru
See All by Niwa Takeru
【Developers Summit 2025】プロダクトエンジニアから学ぶ、 ユーザーにより高い価値を届ける技術
niwatakeru
2
6.3k
【Developers CAREER Boost 2024】顧客価値を中心としたプロダクトエンジニアというキャリア選択
niwatakeru
0
560
【Startup CTO of the Year 2024 / Audience Award】アセンド取締役CTO 丹羽健
niwatakeru
0
9.4k
プロダクトエンジニアの為のトライアルとオンボーディング
niwatakeru
2
1.1k
プロダクトエンジニアを支える組織アーキテクチャ
niwatakeru
4
1.8k
社内 TSKaigi 実施を経た Full Stack TypeScript 強化の道
niwatakeru
2
1.8k
プロダクト開発ゼロイチの分類とロジックス事業がイチに至るまで
niwatakeru
1
540
プロダクトエンジニアとは何者か。
niwatakeru
4
3.1k
Product Engineer Night 01
niwatakeru
0
1.4k
Other Decks in Technology
See All in Technology
5年目から始める Vue3 サイト改善 #frontendo
tacck
PRO
3
150
実運用で考える PGO
kworkdev
PRO
0
130
まだ間に合う! StrandsとBedrock AgentCoreでAIエージェント構築に入門しよう
minorun365
PRO
11
830
Obsidian応用活用術
onikun94
0
330
退屈なことはDevinにやらせよう〜〜Devin APIを使ったVisual Regression Testの自動追加〜
kawamataryo
4
1.4k
自作JSエンジンに推しプロポーザルを実装したい!
sajikix
1
130
2025年になってもまだMySQLが好き
yoku0825
8
3.7k
役割は変わっても、変わらないもの 〜スクラムマスターからEMへの転身で学んだ信頼構築の本質〜 / How to build trust
shinop
0
160
BPaaSにおける人と協働する前提のAIエージェント-AWS登壇資料
kentarofujii
0
110
生成AI時代のデータ基盤
shibuiwilliam
4
2.9k
Browser
recruitengineers
PRO
8
2.3k
衝突して強くなる! BLUE GIANTと アジャイルチームの共通点とは ― いきいきと活気に満ちたグルーヴあるチームを作るコツ ― / BLUE GIANT and Agile Teams
naitosatoshi
0
300
Featured
See All Featured
Faster Mobile Websites
deanohume
309
31k
Git: the NoSQL Database
bkeepers
PRO
431
66k
Mobile First: as difficult as doing things right
swwweet
224
9.9k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
252
21k
The Cult of Friendly URLs
andyhume
79
6.6k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
11
1.1k
Build The Right Thing And Hit Your Dates
maggiecrowley
37
2.8k
Thoughts on Productivity
jonyablonski
69
4.8k
jQuery: Nuts, Bolts and Bling
dougneiner
64
7.9k
Automating Front-end Workflow
addyosmani
1370
200k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.6k
Transcript
【Product Engineer Night #1】 BtoB SaaS開発における Minimum Viable Product への勘所
取締役CTO 丹羽健
2 自己紹介 2 1990年生まれ 兵庫県出身 2016年 新卒でSIer NSSOLに入社 飲食業向けSaaS開発に従事 2020年
株式会社グラファーに転職。 行政向けの電子申請SaaSを開発 2021年 アセンド株式会社に取締役CTO就任 物流向け運送管理SaaSを開発 丹羽 健 Niwa Takeru アセンド株式会社 取締役 CTO TSKaigi運営理事
3 3 12/06 Press Release!!
4 会社紹介 4 物流業界の価値最大化 Our Mission アセンドが挑む物流の社会課題 中小企業中心で投資余力がなく デジタル化に取り残された運送業界 2030年に物流の供給力は35%不足
日本の経済損失は10兆円 一方で運送事業の市場規模は20兆円 SaaSを起点として事業が成り立ち 十分にユニコーンが狙える業界 TAM 20兆円 SAM 2兆円 2024年問題対策として、 政策パッケージが発表 解く意義の大きい社会課題を持ち エンジニアとして最大限の挑戦と 社会的インパクトを起こすこと ができる シリーズA 社員数16名
5 5
6 6 BtoB SaaS開発における MVPへの勘所 BtoB SaaS開発における MVPへの勘所
業務で扱うアプリのMVPを開発 • エリック・リースのLean Startupを モデルにMVP開発をトライしたが 想定と全く異なる • Mockを提供して顧客に当てても 実際に業務運用に載せると 解像度の異なる課題が続出
(toCのスマホオーダーは検証精度は高かった) • MVPと言えど業務に乗る最低限が遠い 7 これまで開発してきたMVP達 7 飲食店向け注文管理 SaaS • スマートフォンオーダー • キッチンモニター 行政向け電子申請 SaaS • 申請の職権訂正機能 物流向け運送管理 SaaS • 運送案件管理および入力UI • 配車表(4回作り直し) • 請求書の自動作成機能 • 車両の原価管理機能 業務アプリケーションにおいては MVPの扱い方は全く異なるのかもしれない
Product Market Fit まで 少ない投資と開発期間 で 実際の市場・顧客から学ぶ形 で 検証してから作り込み、 拡大させようとする考え方
8 MVPの役割を改めて捉える 新規事業、新サービスなど 何らかの新しいアイデアを より効率よく より顧客にフィット した形で価値を生み出すこと 8 MVPで目指すこと MVPとは 以下の2点にフォーカスをおき、 MVPを開発する方針とした • 最低限であることよりも、利用可能であること • アイデアを試すことよりも、顧客が受け入れられること 仮説 IDEA プロト タイプ CODE データ DATA 構築 Build 学習 Learn 検証 Measure
toC はまだ世にない価値の追求が多く 顧客数も多様で部分最適でも事業が成立 (確かにEric Ries はtoC向けの紹介が中心であった…) 9 BtoB SaaS 開発における
MVP 9 新機能プロダクトに付加価値があること 大前提として業務が成立すること • 業務面 ◦ コアバリューの付加価値 ◦ 運用可能性 • テクノロジー面(また別の機会で) ◦ システム設計の筋の良さ ◦ UI/UXのユーザビリティ 業務管理アプリは既存業務の代替を前提 業務を再設計してSaaSに置き換え 効率化・付加価値向上を提供する。 故に顧客のペインは自明なことが多い toB の性質 toB で立証すべきこと toC との違い
10 MVPで立証する2つのポイント 10 付加価値 コアバリューとなる機能 顧客が「この機能がいいんだよね〜」と判 断できる状態にする 運用可能性 コア機能に辿り着くための機能群 運用・認知負荷を極力上げずにスムーズに
業務に組み込める形を見つける 障害となる事項 • 業務は一人業務では完結せず 多くの関係者で成り立ち 前段階の業務も多くある • MVPの検証先でも 細かい必須業務要件がある 障害となる事項 • スクラッチではなくSaaSである 標準化した機能としての置き換え • 既存業務の複雑性がある上に 再設計した業務での適用する難易度 • この複雑性の上で 世にない新しい価値を作る
11 MVPで立証する2つのポイント 11 付加価値 コアバリューとなる機能 顧客が「この機能がいいんだよね〜」と判 断できる状態にする 運用可能性 コア機能に辿り着くための機能群 運用・認知負荷を極力上げずにスムーズに
業務に組み込める形を見つける 障害となる事項 • 業務は一人業務では完結せず 多くの関係者で成り立ち 前段階の業務も多くある • MVPの検証先でも 細かい必須業務要件がある 障害となる事項 • スクラッチではなくSaaSである 標準化した機能としての置き換え • 既存業務の複雑性がある上に 再設計した業務での適用する難易度 • この複雑性の上で 世にない新しい価値を作る やはり作らねばならないところは 作らねばならない!!
12 最低限とするためのアプローチ 12 ゼロから要件を精査する すべての機能要求を洗い出してから 要件を吟味することは難しい。 全から削るよりも、ゼロから積み上げる。 生産性・高頻度デプロイでカバー 検証開始後に顧客ギャップを埋めることで 初めてアウトカムが実現される。
高頻度にデプロイを実行し顧客検証を素早 く繰り返す。 ドメインへのディープダイブ エンジニア自身の中でイマジナリー顧客を 再現することで 顧客に当てずとも感覚的に 業務が回るスコープを判断できるように (→やっぱりドメインへの理解が一番大切) イテレーション テクノロジー ドメイン UXデザイン
None