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.1k
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
1.3k
【Developers CAREER Boost 2024】顧客価値を中心としたプロダクトエンジニアというキャリア選択
niwatakeru
0
98
【Startup CTO of the Year 2024 / Audience Award】アセンド取締役CTO 丹羽健
niwatakeru
0
5.5k
プロダクトエンジニアの為のトライアルとオンボーディング
niwatakeru
2
920
プロダクトエンジニアを支える組織アーキテクチャ
niwatakeru
4
1.5k
社内 TSKaigi 実施を経た Full Stack TypeScript 強化の道
niwatakeru
2
1.4k
プロダクト開発ゼロイチの分類とロジックス事業がイチに至るまで
niwatakeru
1
450
プロダクトエンジニアとは何者か。
niwatakeru
4
2.5k
Product Engineer Night 01
niwatakeru
0
1.2k
Other Decks in Technology
See All in Technology
関東Kaggler会LT: 人狼コンペとLLM量子化について
nejumi
3
570
RECRUIT TECH CONFERENCE 2025 プレイベント【高橋】
recruitengineers
PRO
0
150
Building Products in the LLM Era
ymatsuwitter
10
5.4k
地方拠点で エンジニアリングマネージャーってできるの? 〜地方という制約を楽しむオーナーシップとコミュニティ作り〜
1coin
1
220
Nekko Cloud、 これまでとこれから ~学生サークルが作る、 小さなクラウド
logica0419
2
960
運用しているアプリケーションのDBのリプレイスをやってみた
miura55
1
690
リーダブルテストコード 〜メンテナンスしやすい テストコードを作成する方法を考える〜 #DevSumi #DevSumiB / Readable test code
nihonbuson
11
7.1k
7日間でハッキングをはじめる本をはじめてみませんか?_ITエンジニア本大賞2025
nomizone
2
1.8k
人はなぜISUCONに夢中になるのか
kakehashi
PRO
6
1.6k
OpenID Connect for Identity Assurance の概要と翻訳版のご紹介 / 20250219-BizDay17-OIDC4IDA-Intro
oidfj
0
270
白金鉱業Meetup Vol.17_あるデータサイエンティストのデータマネジメントとの向き合い方
brainpadpr
5
700
利用終了したドメイン名の最強終活〜観測環境を育てて、分析・供養している件〜 / The Ultimate End-of-Life Preparation for Discontinued Domain Names
nttcom
2
180
Featured
See All Featured
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
Fireside Chat
paigeccino
34
3.2k
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.6k
Rails Girls Zürich Keynote
gr2m
94
13k
Building a Modern Day E-commerce SEO Strategy
aleyda
38
7.1k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
129
19k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
30
2.2k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
Docker and Python
trallard
44
3.3k
We Have a Design System, Now What?
morganepeng
51
7.4k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
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