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.2k
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
3.2k
【Developers CAREER Boost 2024】顧客価値を中心としたプロダクトエンジニアというキャリア選択
niwatakeru
0
480
【Startup CTO of the Year 2024 / Audience Award】アセンド取締役CTO 丹羽健
niwatakeru
0
8k
プロダクトエンジニアの為のトライアルとオンボーディング
niwatakeru
2
1k
プロダクトエンジニアを支える組織アーキテクチャ
niwatakeru
4
1.7k
社内 TSKaigi 実施を経た Full Stack TypeScript 強化の道
niwatakeru
2
1.6k
プロダクト開発ゼロイチの分類とロジックス事業がイチに至るまで
niwatakeru
1
510
プロダクトエンジニアとは何者か。
niwatakeru
4
2.8k
Product Engineer Night 01
niwatakeru
0
1.3k
Other Decks in Technology
See All in Technology
LT:組込み屋さんのオシロが壊れた!
windy_pon
0
270
型がない世界に生まれ落ちて 〜TypeScript運用進化の歴史〜
narihara
1
200
SmartHRの複数のチームにおけるMCPサーバーの活用事例と課題
yukisnow1823
2
1.1k
Rebase エンジニアリング組織の現状とこれから
rebase_engineering
0
130
スプリントゴールで価値を駆動しよう
takufujii
3
1.6k
Roo Codeにすべてを委ねるためのルール運用
pharma_x_tech
1
180
大事なのは、AIの精度だけじゃない!〜1円のズレも許されない経理領域とAI〜
jun_nemoto
10
5k
他チームへ越境したら、生データ提供ソリューションのクエリ費用95%削減へ繋がった話 / Cross-Team Impact: 95% Off Raw Data Query Costs
yamamotoyuta
0
170
人とAIとの共創を夢見た2か月 #共創AIミートアップ / Co-Creation with Keito-chan
kondoyuko
1
650
令和トラベルQAのAI活用
seigaitakahiro
0
480
Data Hubグループ 紹介資料
sansan33
PRO
0
1.7k
Introduction to Sansan, inc / Sansan Global Development Center, Inc.
sansan33
PRO
0
2.6k
Featured
See All Featured
How STYLIGHT went responsive
nonsquared
100
5.6k
The Invisible Side of Design
smashingmag
299
50k
StorybookのUI Testing Handbookを読んだ
zakiyama
30
5.8k
Why You Should Never Use an ORM
jnunemaker
PRO
56
9.4k
A designer walks into a library…
pauljervisheath
205
24k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
34
2.3k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.9k
Bash Introduction
62gerente
614
210k
Building Better People: How to give real-time feedback that sticks.
wjessup
368
19k
The Power of CSS Pseudo Elements
geoffreycrofte
76
5.8k
Building Flexible Design Systems
yeseniaperezcruz
329
39k
Documentation Writing (for coders)
carmenintech
71
4.8k
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