Upgrade to Pro — share decks privately, control downloads, hide ads and more …

プロダクト開発ゼロイチの分類とロジックス事業がイチに至るまで

 プロダクト開発ゼロイチの分類とロジックス事業がイチに至るまで

2024/03/13 Product Engineer Night #3 〜プロダクトの 0→1 開発秘話〜 に登壇した際の資料です。
https://product-engineer.connpass.com/event/311582/

Niwa Takeru

March 13, 2024
Tweet

More Decks by Niwa Takeru

Other Decks in Technology

Transcript

  1. 丹羽 健 Niwa Takeru アセンド株式会社 取締役 CTO 2 自己紹介 2

    1990年生まれ 兵庫県出身 2016年 新卒でSIer NSSOLに入社 飲食業向けSaaS開発に従事 2020年 株式会社グラファーに転職。 行政向けの電子申請SaaSを開発 2021年 アセンド株式会社に取締役CTO就任 物流向け運送管理SaaSを開発 主催 理事 24年5月開催!
  2. 3 会社紹介 3 物流業界の価値最大化 Our Mission アセンドが挑む物流の社会課題 中小企業中心で投資余力がなく デジタル化に取り残された運送業界 2030年に物流の供給力は35%不足

    日本の経済損失は10兆円 一方で運送事業の市場規模は20兆円 SaaSを起点として事業が成り立ち 十分にユニコーンが狙える業界 TAM 20兆円 SAM 2兆円 2024年問題対策として、 政策パッケージが発表 解く意義の大きい社会課題を持ち エンジニアとして最大限の挑戦と 社会的インパクトを起こすこと ができる シリーズA 社員数19名
  3. 4 4 高い開発生産性で 3ヶ月に1度プロダクトをリリース デプロイ頻度 変更リードタイム 5.67 deploys/day 2 hours

    平均修復時間 変更失敗率 24 minutes 2.6 percent 運送業特化 All-in-One SaaS を開発
  4. ゼロイチには複数のフェーズがある • 事業 ◦ 起業からPMFまで • プロダクト ◦ PSF、MVP、製品版リリースまで •

    機能 ◦ 仕様策定からリリースまで 余談)何をイチとするか • 公開して終わりではなく 価値が出て初めてイチと思いたい 6 プロダクト開発のゼロイチを分類してみる 自身が担当するゼロイチのスコープを整理し、 特性を理解した上で効果的なアプローチをとる 6 事業 プロダクト 機能 ゼロ イチ 🚀製品版   リリース 🚀Preview 🚀PSF  (Problem Solution Fit) 🚀PMF  (Product Market Fit) 🚀MVP  (Minimum Viable Product) 🚀GA版  (General Availability) 改善 機 能 機 能 機能 機能 今日の参加者間でゼロイチの認 識を揃えることもサブ目的 🚀起業
  5. バリュープロポジションの確立 • Value Proposition=顧客に提供する独自価値 • 競合事業への優位性 事業として成立する市場規模の開拓 • ニーズの存在だけでなく、 事業として持続可能な成長が遂げられること

    事業戦略 • 会社が持つリソースを最適化した プロダクトロードマップの策定 組織の構築 • プロダクト志向のエンジニア組織文化の構築 • ビジネス組織とプロダクト組織の共同(と採用 事業のゼロイチ 7 7 想定される課題 概要 求めるアウトカム • 起業からPMFまでの期間 • 満足度の高いプロダクトを創ることで はなく、ビジネスとして成立する事業 を創ること • 起業から含めた場合、 資金・組織・顧客がゼロから始まる • Product Market Fit 将来的に事業が成り立つ規模の マーケットセグメントに対して 満足がいくプロダクトを創れた状態 • 参考指標:シリーズA調達、ARR1億
  6. 新しいドメイン知識の獲得 • 顧客・ビジネス組織を巻き込んだ 効果的なドメイン知識のキャッチアップ 顧客ニーズ特定とプロダクトコンセプト • 顧客の本質的な課題の特定 MVPの構築と仮説検証 • 検証に伴走する熱狂的ファンの獲得

    • 高速な仮説検証ができる開発体験 ◦ 最終的に製品提供できる技術的負債の少ない プロダクトコードもあると嬉しい プロダクトのゼロイチ 8 8 概要 求めるアウトカム • 仮説検証を経て製品版リリースまで • 顧客ニーズが不明な状態から Problem Solution Fit し、 MVP等の仮説検証を経て、 実用的なプロダクトを提供すること • 複数の顧客に対しプロダクトを提供し 継続利用されている状態 • 参考指標: 有償提供、製品版リリース 熱狂的なファンの創出 想定される課題
  7. • 仕様策定から一般公開まで • 設定された解くべき課題に対して 仕様・ソリューションを策定・検証し 複数顧客に利用される機能を創ること 機能のゼロイチ 9 9 概要

    求めるアウトカム 顧客の要求分析 • 現場訪問や利用データ分析し調査 • 高い解像度で顧客を理解する 最適な仕様・ソリューションの策定 顧客価値につながるまでの継続的な改善 • 開発機能で顧客課題が解決されること • 参考指標:GA版リリース, 高い利用率 想定される課題
  8. 2周目のゼロイチの存在 10 10 新規事業 速さが求められる2周目 • コンパウンド(複数事業)や マルチプロダクトの展開による 会社の高成長が求められる時代。 •

    1周目の資産を効果的に利用する ◦ 既存の事業・プロダクトの相乗効果 ◦ 構築済みの資産(組織・技術)の活用 ◦ プロダクト開発組織の横展開 • 獲得済みの顧客基盤の活用 • コアデータ活用による新規事業 • 既存事業の利益の再投資 新規プロダクト • 既存顧客へのクロスセル • 既存サービスAPIの利活用 • インフラ基盤やアーキテクチャの踏襲
  9. 11 ゼロイチのまとめ 11 事業 プロダクト 機能 概要 起業からPMF。ビジネス として成立する事業の創出 仮説検証と製品版リリース。

    実用的なプロダクトの提供 仕様策定から一般公開まで。 顧客課題を機能で解決する 求める アウトカム Product Market Fit ex. シリーズA調達、ARR1億 複数顧客への プロダクトの有償提供 顧客課題の解決 ex. 高い利用率、GA 課題 バリュープロポジション確立 一定以上の市場規模の見込 み 高速な仮説検証 新しいドメイン知識の獲得 顧客課題の特定 最適なソリューションの策定 2周目への 資産 顧客基盤、コアデータの蓄積 プロダクトエンジニア組織 技術・アーキテクチャ APIの利活用、インフラ ー
  10. 13 物流業界の課題と未来 13 35 % トラック不足 10兆 円 経済損失 ※2030年の予測値

    コアデータの蓄積 荷物・トラック・ドライバー データを用いた効率的な物流が必要 下記3データを活用した物流の最適化が有効 • 荷物情報 • トラックの空き状況 • ドライバーの勤務状況 一方でデータの標準化・蓄積はされていない 運送管理 SaaS 日本の物流デジタル基盤 デジタル仲介 プラットフォーム事業 モノが届かなくなるという社会課題 荷台の65%が空気という非効率な物流
  11. あらゆるモノを運ぶ物流ゆえに 多様な業務セグメントが存在 • 食品・日用品・農産品・家具・建築材 化学製品・石油製品・自動車部品 • 地場・長距離、定期・スポット 共同配送・通運・多重下請け構造 運送案件の管理=基幹システム データを標準化しSaaSとして提供

    (シングルペインを解決する Light な SaaS ではない) 14 基幹システムをSaaSで提供する 14 情報 通信業 不動産 業 建設業 製造業 サービス 業 物流 金融 保険業 卸売 小売業 物流は日本で最も デジタル化の遅れた産業 デジタル化に取り残され 長らくアナログで最適化された業務
  12. 15 ロジックス事業のゼロイチの挑戦 15 限られたキャッシュとリソース • 基幹システムとして作るものは多い一 方でシード期の資金は少ない • エンジニア4名での開発 高頻度デプロイで不確実性を解消

    機能リリース後に顧客ギャップを埋めることで 初めてアウトカムが実現される。 高頻度にデプロイを実行し顧客検証を素早く繰り返す。 平均復旧時間を縮める施策をすることで仕様的な失敗に 対する安全性を高めることもできる。 多様かつ不透明なセグメント • 運ぶ荷物、運ぶ距離、運び方、荷主 が誰か、近隣の運送会社との力関 係、会社規模、それらの掛け算に よって、ペインが少しずつ違う • いくら開発しても要望が減らない 運送会社の全業務のデジタル化 • 運送事業者の経営改善のために必要な データが欲しいが、全て紙管理 • ホリゾンタルサービスでは運送事業に マッチしきらない事が多く、「全て作 る」決断に 高頻度デプロイで不確実性を解消 機能リリース後に顧客ギャップを埋めることで 初めてアウトカムが実現される。 高頻度にデプロイを実行し顧客検証を素早く繰り返す。 平均復旧時間を縮める施策をすることで仕様的な失敗に 対する安全性を高めることもできる。 運送案件のデータモデルの探求 • 標準的な業務をこちらで規定し、事業 者や業務ごとに個別最適化されたアナ ログ業務から脱却させる • とはいえ、新たな顧客に会う度に、モ デルを改めざるを得ず、苦心
  13. 16 ロジックス事業ゼロイチの歩み ① 16 2020/03 アセンド創業 • CEO, CPO, Engineer

    2名 • 後にCTOとなる丹羽は 副業で参加 • 当時のプロダクト戦略から 大きな変更はない 2020/10 α版プロダクト開発と破棄 • 技術力の低い状態での開発 Python, React by JS • 製品以前の顧客検証版に対し 既に技術的負債が多い状態 • 全コード破棄を決定 2021/05 CTO参画と製品版開発開始 • CTO丹羽が正式入社 • 製品版として 3ヶ月で全てを作り直す。 2021/08 開発生産性の高いArchitecture • フルサイクルで生産性高い 環境を同時に構築 • Full TypeScript 構成 • GitOps, トランクベース開発 • 初期に時間を産む投資をした 2021/08 柔軟なデータモデル設定機能 • 運送案件のデータモデル探求 のため項目を自由に定義でき る負債感の強い機能を開発 • MongoDB にて開発 2021/12 プレシリーズA資金調達 2億円 • 当時の売上はゼロに近いが、 物流業界への解像度・戦略の 高さとプロダクトの充実を背 景に資金調達を実施
  14. 17 ロジックス事業ゼロイチの歩み ② 17 2022/03 プロダクトチームへ 4名 • リードプロダクトエンジニア となる2名の採用。

    • 当初設計した生産性高い環境 カルチャーが機能した。 2022/11 マルチプロダクト展開 • 案件、労務、車両管理の 複数プロダクトを開発・提供 • 基幹システムとしての ニーズの多さ故に開発 2023/05 作りまくる決意 • 多様セグメントで顧客を選べな い状況にあり、効率的な開発を 諦め、ひたすら機能を拡充する ことを決意 • 当時は資金状況は悪化していた 2023/08 データモデル刷新 • 数十社の案件管理から学び 運送データモデルを標準化 • MongoDBからPostgresへ移行 • 3度のリトライ 1年越しのプロジェクト 2023/12 シリーズA資金調達 3億円 • 追加開発なく売れる顧客が 現れてきた • 特定の運行セグメントでPMF • 物流産業を変革するスタート アップとしてGCPから調達 2024/03 現在 プロダクトエンジニア組織化 • 事業計画前倒しでの売上達成 • 再現性高くプロダクト開発力 のあるエンジニア組織化 • 第2の矢となる新規事業開始
  15. プロダクトのゼロイチ 20 20 概要 求めるアウトカム • 仮説検証を経て製品版リリースまで • 顧客ニーズが不明な状態から Problem

    Solution Fit し、 MVP等の仮説検証を経て、 実用的なプロダクトを提供すること • ゼロイチを作るに足る知識の幅広さ ◦ 社内のどこにも知見が無い、ありはするが表に出ていない、 という状態からのスタートが多い。プロダクトを実現するた めに必要な知識の把握と、誰が何に詳しくてどう協力しても らうかをどれだけ早く確立しておくかが構築スピードに大き く影響する。 • 仮説検証のサイクルを上手く回す仕組みの構築 ◦ MVPを定義して作る、まではできても、そこから自然とFB がくるようにはならない。時期を待っているとMVPのまま半 年放置とかもあり得る。 • 価値のデリバリーまでしきること ◦ プロダクトとして顧客に価値が出せるかだけはなく、マー ケ、セールス、オンボーディング、サポートなどのビジネス プロセスの効率性や効果の検証・最適化も必要で、そこから くるプロダクトFBも多い。 ◦ 何をいつキックできるかはプロダクト開発進捗に依存すると ころも多いので、開発途中でも情報を閉じず、社内に対して 常に開いておくこと。 • この時期のプロダクトは品質を犠牲にできる、わけではない ◦ 仮説検証に耐える柔軟性をもたせる必要性がある ◦ 内部品質はもちろん、外部品質も。どれだけ微妙な仕様で も、一度顧客に装着されると変えるのは困難。仕様の負債 化。 ◦ PMFしたらリプレイス、は全く簡単じゃない。足踏みしてい る間にどんどん負債化して事業成長のボトルネックになる • 複数の顧客に対しプロダクトを提供し 継続利用されている状態 • 参考指標: 有償提供、製品版リリース 熱狂的なファンの創出 想定される課題