【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 ● 配車表（４回作り直し） ● 請求書の自動作成機能 ● 車両の原価管理機能 業務アプリケーションにおいては MVPの扱い方は全く異なるのかもしれない

Product Market Fit まで 少ない投資と開発期間 で 実際の市場・顧客から学ぶ形 で 検証してから作り込み、 拡大させようとする考え方 8 MVPの役割を改めて捉える 新規事業、新サービスなど 何らかの新しいアイデアを より効率よく より顧客にフィット した形で価値を生み出すこと 8 MVPで目指すこと MVPとは 以下の２点にフォーカスをおき、 MVPを開発する方針とした ● 最低限であることよりも、利用可能であること ● アイデアを試すことよりも、顧客が受け入れられること 仮説 IDEA プロト タイプ CODE データ DATA 構築 Build 学習 Learn 検証 Measure

toC はまだ世にない価値の追求が多く 顧客数も多様で部分最適でも事業が成立 （確かにEric Ries はtoC向けの紹介が中心であった…） 9 BtoB SaaS 開発における MVP 9 新機能プロダクトに付加価値があること 大前提として業務が成立すること ● 業務面 ○ コアバリューの付加価値 ○ 運用可能性 ● テクノロジー面（また別の機会で） ○ システム設計の筋の良さ ○ UI/UXのユーザビリティ 業務管理アプリは既存業務の代替を前提 業務を再設計してSaaSに置き換え 効率化・付加価値向上を提供する。 故に顧客のペインは自明なことが多い toB の性質 toB で立証すべきこと toC との違い

10 MVPで立証する２つのポイント 10 付加価値 コアバリューとなる機能 顧客が「この機能がいいんだよね〜」と判 断できる状態にする 運用可能性 コア機能に辿り着くための機能群 運用・認知負荷を極力上げずにスムーズに 業務に組み込める形を見つける 障害となる事項 ● 業務は一人業務では完結せず 多くの関係者で成り立ち 前段階の業務も多くある ● MVPの検証先でも 細かい必須業務要件がある 障害となる事項 ● スクラッチではなくSaaSである 標準化した機能としての置き換え ● 既存業務の複雑性がある上に 再設計した業務での適用する難易度 ● この複雑性の上で 世にない新しい価値を作る

11 MVPで立証する２つのポイント 11 付加価値 コアバリューとなる機能 顧客が「この機能がいいんだよね〜」と判 断できる状態にする 運用可能性 コア機能に辿り着くための機能群 運用・認知負荷を極力上げずにスムーズに 業務に組み込める形を見つける 障害となる事項 ● 業務は一人業務では完結せず 多くの関係者で成り立ち 前段階の業務も多くある ● MVPの検証先でも 細かい必須業務要件がある 障害となる事項 ● スクラッチではなくSaaSである 標準化した機能としての置き換え ● 既存業務の複雑性がある上に 再設計した業務での適用する難易度 ● この複雑性の上で 世にない新しい価値を作る やはり作らねばならないところは 作らねばならない！！

12 最低限とするためのアプローチ 12 ゼロから要件を精査する すべての機能要求を洗い出してから 要件を吟味することは難しい。 全から削るよりも、ゼロから積み上げる。 生産性・高頻度デプロイでカバー 検証開始後に顧客ギャップを埋めることで 初めてアウトカムが実現される。 高頻度にデプロイを実行し顧客検証を素早 く繰り返す。 ドメインへのディープダイブ エンジニア自身の中でイマジナリー顧客を 再現することで 顧客に当てずとも感覚的に 業務が回るスコープを判断できるように （→やっぱりドメインへの理解が一番大切） イテレーション テクノロジー ドメイン UXデザイン

No content