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.1k
【Developers CAREER Boost 2024】顧客価値を中心としたプロダクトエンジニアというキャリア選択
niwatakeru
0
540
【Startup CTO of the Year 2024 / Audience Award】アセンド取締役CTO 丹羽健
niwatakeru
0
9.3k
プロダクトエンジニアの為のトライアルとオンボーディング
niwatakeru
2
1.1k
プロダクトエンジニアを支える組織アーキテクチャ
niwatakeru
4
1.7k
社内 TSKaigi 実施を経た Full Stack TypeScript 強化の道
niwatakeru
2
1.7k
プロダクト開発ゼロイチの分類とロジックス事業がイチに至るまで
niwatakeru
1
530
プロダクトエンジニアとは何者か。
niwatakeru
4
3k
Product Engineer Night 01
niwatakeru
0
1.3k
Other Decks in Technology
See All in Technology
いかにして命令の入れ替わりについて心配するのをやめ、メモリモデルを愛するようになったか(改)
nullpo_head
7
2.5k
Amazon S3 Vectorsは大規模ベクトル検索を低コスト化するサーバーレスなベクトルデータベースだ #jawsugsaga / S3 Vectors As A Serverless Vector Database
quiver
1
140
Foundation Model × VisionKit で実現するローカル OCR
sansantech
PRO
1
330
相互運用可能な学修歴クレデンシャルに向けた標準技術と国際動向
fujie
0
230
dipにおけるSRE変革の軌跡
dip_tech
PRO
1
250
データモデリング通り #2オンライン勉強会 ~方法論の話をしよう~
datayokocho
0
140
僕たちが「開発しやすさ」を求め 模索し続けたアーキテクチャ #アーキテクチャ勉強会_findy
bengo4com
0
2.2k
みんなのSRE 〜チーム全員でのSRE活動にするための4つの取り組み〜
kakehashi
PRO
2
140
o11yツールを乗り換えた話
tak0x00
2
550
LTに影響を受けてテンプレリポジトリを作った話
hol1kgmg
0
340
Amazon Qで2Dゲームを作成してみた
siromi
0
130
2025新卒研修・HTML/CSS #弁護士ドットコム
bengo4com
3
13k
Featured
See All Featured
GraphQLの誤解/rethinking-graphql
sonatard
71
11k
Automating Front-end Workflow
addyosmani
1370
200k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
126
53k
Unsuck your backbone
ammeep
671
58k
How STYLIGHT went responsive
nonsquared
100
5.7k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
131
19k
A designer walks into a library…
pauljervisheath
207
24k
Into the Great Unknown - MozCon
thekraken
40
2k
StorybookのUI Testing Handbookを読んだ
zakiyama
30
6k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
34
3.1k
Become a Pro
speakerdeck
PRO
29
5.5k
Code Review Best Practice
trishagee
69
19k
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