伝統産業におけるVertical SaaS構築: 「やってはいけないこと」と「既存ワークフローに合うAI開発」

• GrubMarketに買収されたButterの創業者が、2020年からの5年間の経験を整理した文章

パート1 : やってはいけないこと

出発点: パンデミックとデジタル転換の機会

• 2020年のパンデミック期に、食品産業のデジタル転換の可能性を見てButterを設立。
• 発見した問題:
  • シェフたちは依然として手書きの注文書と電話・SMSを使う従来型の方法を好んでいた
  • 卸業者は古い技術（1990年代のERP、Excelでの在庫管理、紙の小切手決済）に依存
    • 顧客注文の入力だけで1日6時間を要した
• ソリューション計画:
  • コアワークフローを捉え、「記録システム」として機能できるオールインワンのクラウドベースERPで中核ワークフローをデジタル化
  • 決済、融資、給与などの金融サービスを統合して顧客価値を最大化（ACV）
  • シェフと卸業者の双方に向けたシームレスなコミュニケーションプロセスを導入し、DoorDashスタイルの注文アプリでプラットフォームのネットワーク効果を創出
    ((ユニコーン企業へ急成長した別の注文アプリChocoの影響を受けた)

しかし失敗

• 当然成功するものだと思っていた（no-brainer）が、私たちは完全に間違っていた

落とし穴1: 技術的複雑性と過度なカスタマイズ

• ERP構築は簡単だと思っていたが、実際には顧客ごとに異なる要求のため開発リソースが枯渇
  • 例: キーボードショートカット、データ入力画面のレイアウト、特定の請求書フォーマット
• 結果: スケーラビリティのないカスタマイズ依存の製品へと変質

落とし穴2: 長い営業サイクル

• ERPシステムの切り替えは複雑で、多くの部門の同意が必要:
  • 顧客企業は現在の不便さがあっても切り替えをためらった
  • レストランの繁忙期には営業機会が限られた
• 結果: 低い成約率（目標値の20〜30%水準）

落とし穴3: 低い支払い意欲と長い収益化までの期間

• 顧客企業の多くは低い利益率（約5%）で運営:
  • QuickBooksに月額80ドルを払っていた顧客にとって、ERPアップグレード費用は負担だった
• 追加のフィンテックや注文アプリ収益も立ち上がりまで長い時間がかかった

落とし穴4: 実験のやりすぎ

• 初期段階で複数の収益モデルとネットワーク効果を同時に試行:
  • 単一の成功事例を確保できていない状態で過度に戦線を拡大
• 結果: チームのバーンアウトと低い反復実験速度

痛みを伴って得た教訓

• Butterを運営しながら大きな誇りを感じた瞬間も多くあった:
  • 午前2時に起きて倉庫で寝泊まりしながら、成功するオンボーディングのために尽力
  • 顧客に愛された、複雑だが直感的なソフトウェアを構築
  • 体系的な導入ガイドを開発
• しかしスケーラブルなベンチャービジネスの構築には失敗
• 教訓1. アイデアを高次の仮説だけに依存しないこと:
  • 倉庫、現場、バックオフィスの担当者と直接対話し、実質的な洞察を得るべき
  • 「真実の探求」を目標に対話し、既存のアイデアを再確認するための会話は避ける
• 教訓2. 成功する製品構築に必要な要素:
  • 問題を深く理解しているユーザーの確保:
    • 現状維持の痛みが変化の摩擦より大きくなければ、誰もシステムを変えない
    • 変化はいくつかの触媒だけでも十分に起こり得る
  • 十分な支払い能力:
    • 顧客にソリューションを負担する財務的余裕がなければ、提供する価値だけでは会社の収益を維持できない
  • 従来より10倍優れた製品体験:
    • 顧客が伝統的であるほど、より劇的な改善が必要
    • 顧客が長年従来方式を維持してきた理由を解決する形でアプローチする
  • シンプルさの重要性:
    • 初期製品はシンプルで導入しやすくあるべき
    • 例: 豪華な日本式ビデを売るのではなく、基本的な配管の問題解決に集中する
• 教訓3. ビジネスモデルとSaaS成功条件:
  • 取引規模と営業サイクル（ディール速度）はバランスしていなければならない。
  • David Sacksの「The Difficulty Ratio」:
    • 高額なACV（Annual Contract Value）と低い取引速度、またはその逆の組み合わせは成立し得る
    • しかしACVが低く取引速度も遅いと失敗の確率が高い
  • Butterの場合:
    • 追加収益源があっても、低い取引速度と低いACVの領域に属していた
    • とくに収益化全体の立ち上がりまで取引速度が非常に遅かった

最後の考え

• 振り返ると、伝統的な慣行と古い技術に依存する業界でVertical SaaSを構築する複雑さを過小評価していた
• デジタルソリューションだけでは導入を促すのに十分ではなかった
• むしろ、従来方式より飛躍的な改善効果を提供しなければならず、
  • 顧客が理解できる形でそれを伝える必要がある。
  • すぐに適しているという印象を与えられなければ、顧客は慣れた従来方式に固執する
• 教訓: 既存ワークフローを尊重しながら実質的な価値を証明するアプローチが成功の鍵

---

パート2: 既存ワークフローによく合うAI開発

出発点: 伝統的な方式との衝突

• 初期の試み:
  • ECを通じて卸業者の注文入力プロセスを近代化することを目標にツールを開発
  • 問題:
    • シェフたちは依然として従来の方式（電話、SMS）を好み、デジタルシステムに容易には適応できなかった
    • 新しいシステムは、既存方式を完全に置き換えるほど十分な価値を提供できなかった
• 顧客の声を聞く:
  • アクティブユーザー、離脱ユーザー、アプリ反対派など多様な顧客層にインタビューを実施
  • アプリ経由の注文は電話・SMS・メールと比べて10倍優れた体験ではないと判断:
    • リアルタイムの商品在庫や配送状況に対する可視性が不足
• 卸業者の苦労を把握:
  • 卸業者は依然として何時間にも及ぶ手作業の注文入力に苦しんでいた
  • AI導入のアイデア:
    • 非構造化データを扱える大規模言語モデル（LLMs）が適していた
    • AIによって複雑な作業の自動化が可能
    • 世界中のデータの約80%が非構造化データである点から、パラダイム転換の可能性を見た
• 戦略転換:
  • サプライヤーやオペレーターに完全なデジタルワークフローを強制しない
  • その代わり、既存プロセスを補完する**AIベースのツール（例: Butter’s AI Order Assistant）**を開発:
    • 既存ワークフローに自然に統合されるよう設計。
    • 技術的に遅れた食品流通業界を近代化できる実用的ソリューションとして位置づけられた。

AIへの転換: 単なる約束ではなく実装へ

• AI成功の鍵:
  • 「より洗練された」製品ではなく、ユーザーの仕事を実際に完了させる製品が必要
  • AI Order Assistant:
    • シェフと卸業者が既存プロセスを変えなくてよい形で設計
    • 既存ワークフローに自然に統合
• 自然言語処理ベースの注文管理:
  • 音声コマンドやテキストメッセージを処理できるAIでプロセスを簡素化
  • 全面システム刷新ではなく追加ツール（add-on）として提供:
    • 迅速に導入可能
    • 従来の「デジタル転換」の複雑な問題を回避
• 顧客オンボーディング過程:
  • メールおよびボイスメールデータをERPと連携し、構造化された購買発注データへ変換
  • シェフの好み（例: 「エビを2箱」）をデジタルシステムに保存:
    • 過去の注文パターンと注文ガイドを活用して製品バリエーションを正確に理解。
    • 例: 「4-6 Tiger Shrimp Frozen」なのか「16-20 EZ Peel Shrimp」なのかをAIが判別
• ユーザーフィードバックの反映:
  • AIモデルに100%の正確性は期待しない:
    • 幅広いUXインタビューを通じて、ユーザーがAI出力を修正できるようにした
    • ERPのショートカットを活用し、キーボード入力だけですべての作業ができるよう設計
  • 結果:
    • 注文処理時間を96%以上短縮
    • バックオフィス担当者を高付加価値業務（品質管理、顧客関係管理）へ転換可能に
• GrubAssistへ拡張:
  • GrubMarketへの買収後、AI Order AssistantをGrubAssistへ拡張
  • 既存ERPシステムに自然言語ベースのビジネスインテリジェンスと分析を提供。
  • 食品業界の既存ワークフローを妨げずにシームレスに統合
• 既存ワークフローとの統合こそがAI成功の鍵。 複雑な切り替えなしに簡単に適用できなければならない。

LLM製品開発で得た教訓

• 技術的限界を考慮した設計:
  • LLMは強力だが、依然として信頼性と速度の面で限界がある。
  • 効果的な設計で限界を補う:
    • 例: レストランや小売業者は注文を翌朝処理するため、バックグラウンド処理によって速度を犠牲にし、より高い推論能力を持つモデルを選べる。
• 速度を優先し、完璧さは後で追う:
  • 初期段階では「完璧なモデル」を探すことに縛られないこと。
  • 市場参入のためにシンプルな技術（例: RAG）を活用:
    • 適切なコンテキストを与えれば、シンプルな方法でも強力に機能する。
    • ベースモデルが改善されれば、AI製品そのものも自動的に進化する。
• 基本を確実に固める:
  • 柔軟な実験環境の提供:
    • モジュラーアーキテクチャを設計し、モデルや機能の差し替えを容易にして高速に反復可能にする。
    • 明確で定量化可能な製品内フィードバックシステムの統合が必要。
• インターフェースが製品の成否を左右する:
  • 「完璧な」モデルがあっても、作業の20%は人間の検証が必要だという前提で設計。
  • インタラクションをシンプルかつ直感的にして、ユーザー参加を維持する:
    • ユーザー検証プロセスを強化すれば、製品改善に重要なデータを確保できる。
• 非構造化知識のキャプチャ:
  • 伝統産業では重要な情報がデジタル化されておらず、人の記憶に依存している。
  • 例: 顧客の好みが営業担当Joeyの頭の中にしかないなら、それを取り込めるインターフェースを構築する。
  • こうした洞察はモデルの差別化を強め、継続的なデータ優位をもたらす。

6. フィードバックループによる精度向上:

• エンジニアリングだけでは限界:
  • ユーザーフィードバックを製品内で直接収集できるシームレスな方法を提供する。
  • フィードバックをチューニングエンジンと結びつけ、より正確で文脈に関連した出力を提供する。

既存システムと協調することが重要

• 現実的な課題:
  • どれほど優れたAIソリューションでも、既存のレガシーERPシステムと統合されなければ意味がない
  • レガシーシステムの置き換えを試みると協業が難しくなる
• 統合戦略:
  • Butterの場合、EDI（電子データ交換）やSFTPファイル交換のような方法でERPと統合する必要があった
  • レガシーシステムは深く根付いており、説得もアーキテクチャ設計も複雑
  • 成功戦略:
    • 既存製品を改善する**追加ツール（add-on）**を提供:
      • 顧客が既存インフラを維持しながらAIの利点を活用できるよう支援
      • 既存ネットワークを強化し、事業者とインフラ提供者の双方にとってAIがプラスに働くことを強調
• 差し迫った状況:
  • AIの専門性は急速に広がっており、動きの遅かった伝統的サービス提供者もAIを導入中
  • 素早く実行し、既存プレイヤーと協力:
    • 正しい戦略と差別化されたアプローチで市場に対応しなければならない
• 新しいソフトウェアアプローチへの警告:
  • 「integrate and surround（統合して包囲する）」方式の新製品:
    • 特定のビジネス領域（例: フィールドセールス）を完全に自己完結型で構築
    • コスト/収益構造を有利に変更
    • こうした動向を理解し、適切なパートナーを選ぶことが重要
• 核心的教訓
  既存システムと協調し、全面的なシステム切り替えなしでも明確な利点と改善点を提供する
  • 低リスク・高リターンの追加ツールとして価値を示し、迅速な導入を促す

未来への洞察

• 伝統産業とAIの接点:
  • 手書き記録や音声データのような非構造化データに依存していた伝統産業が、今やLLM（大規模言語モデル）を通じて現代的な技術ソリューションにアクセス可能になっている
  • Vertical SaaSは、こうした業界で徐々に現実的な選択肢として浮上している
  • AIをあらゆる場所に適用したくなる誘惑はあるが、慎重なアプローチが必要
• AI成功の鍵:
  • 技術そのものではなく、**プロダクトマーケットフィット（Product-Market Fit）**が成功の決定要因
  • AIの進化は可能性を開くが、製品開発の基本原則は変わらない:
    • ユーザーとそのニーズを明確に理解することから始まる
    • 技術はその後についてくる
• 主な教訓:
  • AIは既存プロセスに適合する形で統合されるとき最も効果的
  • 既存のやり方を覆そうとせず、自然に溶け込むように設計する
• 問い:
  • 「誰がこの機会を先に掴むのか？」
  • 手遅れになる前に機会を活かす人が勝つ