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
2.4k
【Developers CAREER Boost 2024】顧客価値を中心としたプロダクトエンジニアというキャリア選択
niwatakeru
0
390
【Startup CTO of the Year 2024 / Audience Award】アセンド取締役CTO 丹羽健
niwatakeru
0
6.4k
プロダクトエンジニアの為のトライアルとオンボーディング
niwatakeru
2
960
プロダクトエンジニアを支える組織アーキテクチャ
niwatakeru
4
1.6k
社内 TSKaigi 実施を経た Full Stack TypeScript 強化の道
niwatakeru
2
1.5k
プロダクト開発ゼロイチの分類とロジックス事業がイチに至るまで
niwatakeru
1
470
プロダクトエンジニアとは何者か。
niwatakeru
4
2.6k
Product Engineer Night 01
niwatakeru
0
1.3k
Other Decks in Technology
See All in Technology
バックエンドエンジニアによるフロントエンドテスト拡充の具体的手法
kinosuke01
1
630
Proxmox VE超入門 〜 無料で作れるご自宅仮想化プラットフォームブックマークする
devops_vtj
0
120
数百台のオンプレミスのサーバーをEKSに移行した話
yukiteraoka
0
640
製造業の会計システムをDDDで開発した話
caddi_eng
3
930
PostgreSQL Unconference #52 pg_tde
nori_shinoda
0
190
Amazon Q Developer 他⽣成AIと⽐較してみた
takano0131
1
120
大規模アジャイル開発のリアル!コミュニケーション×進捗管理×高品質
findy_eventslides
0
420
AWS のポリシー言語 Cedar を活用した高速かつスケーラブルな認可技術の探求 #phperkaigi / PHPerKaigi 2025
ytaka23
7
1.5k
Redefine_Possible
upsider_tech
0
240
ソフトウェアプロジェクトの成功率が上がらない原因-「社会価値を考える」ということ-
ytanaka5569
0
120
Multitenant 23ai の全貌 - 機能・設計・実装・運用からマイクロサービスまで
oracle4engineer
PRO
2
110
ソフトウェア開発におけるインターフェイスという考え方 / PHPerKaigi 2025
k1low
9
3.9k
Featured
See All Featured
The MySQL Ecosystem @ GitHub 2015
samlambert
251
12k
Rails Girls Zürich Keynote
gr2m
94
13k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
Art, The Web, and Tiny UX
lynnandtonic
298
20k
Automating Front-end Workflow
addyosmani
1369
200k
[RailsConf 2023] Rails as a piece of cake
palkan
53
5.4k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
135
33k
GraphQLとの向き合い方2022年版
quramy
45
14k
Facilitating Awesome Meetings
lara
53
6.3k
The Pragmatic Product Professional
lauravandoore
33
6.5k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
A Tale of Four Properties
chriscoyier
158
23k
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