Ch5 03: ソフトウェアの前にバン#

Curbeeの創業者たちは、モバイルカーリペアのテクノロジープラットフォームを構築したかった。ビジョンはあった――アプリでボタンをタップすれば、技術者があなたの家の前まで来て、あなたが家の中でコーヒーを飲んでいる間に車を修理してくれる。自動車修理版Uber。ピッチ資料は洗練されていた。ワイヤーフレームは描かれていた。技術スタックは計画済みだった。

そして彼らは、シリコンバレーのほとんどの創業者が異端と呼ぶようなことをした。ノートパソコンを閉じて、バンを一台買ったのだ。

最初の数ヶ月間、Curbeeは手動のサービスビジネスとして運営された。アプリなし。プラットフォームなし。ソフトウェアなし。あるのはバンと技術者と電話だけ。顧客は電話かテキストで連絡してきた。誰かが顧客の場所まで車を走らせた。修理が行われた。支払いは基本的な請求ツールで処理された。

テック系スタートアップのどの基準で見ても、笑えるほど原始的だった。しかし同時に、彼らにできた最も賢い選択だった。

バンのフェーズが彼らに教えたこと――どれだけプロダクト設計、顧客リサーチ、競合分析をしても決して得られなかったであろう教訓がここにある。

教訓1：現場で対応できる修理と、できない修理。 当初のビジョンでは、どんな修理でも顧客の場所で行えると想定していた。現実は違った。リフトが必要な作業もあった。バンに収まらない専門機器が必要なものもあった。屋外作業には天候の影響を受けやすすぎるものもあった。数百件の手動ジョブを経て、チームはモバイルで対応可能なものとそうでないものの正確な地図を手にした――これがサービスメニューの骨格となった。

教訓2：顧客が本当に重視していること。 創業者たちは価格が最も重要だと思っていた。違った。顧客が気にしていたのは時間だった――具体的には、ショップまで車を運転し、車を預け、帰りの足を確保し、折り返しの電話を待ち、また車を取りに戻るために費やすはずだった数時間を消し去ることだった。その時間の節約にはプレミアムを払う価値があった。この洞察が価格モデルを「ショップより安い」から「4時間を節約してくれるからショップ以上の価値がある」へと一変させた。

教訓3：本当のボトルネックはどこに隠れているか。 制約となっていたのは修理そのものではなく、部品のロジスティクスだった。技術者はブレーキパッドを45分で交換できた。しかし、適切なパッドを適切なバンに適切なタイミングで届けるのに丸一日かかることもあった。バンのフェーズはこのボトルネックを容赦なく浮き彫りにし、テクノロジープラットフォームが最初に解決すべき問題となった。

教訓4：実世界のエッジケースとはどんなものか。 技術者が到着したとき顧客が不在だった。車が狭いガレージに詰め込まれていた。修理中にもっと厄介な2つ目の問題が見つかった。技術者に向かって吠え続ける犬がいた。これらはすべてバンのフェーズで発生し、そのすべてがプラットフォームの例外処理ロジックを形作った。

数ヶ月間、数百件の完了ジョブを経て、チームは自分たちのビジネスを隅々まで理解していた。スプレッドシートからではなく。アンケートからではなく。自分たちの手で仕事をすることで。

そして今――このタイミングになって初めて――ソフトウェアの開発に着手した。

出来上がったプロダクトは、初日に作っていたら生まれたであろうものとはまったく違っていた。サービスメニューは理論的なカバー範囲ではなく、実世界での実現可能性によって切り出されていた。スケジューリングアルゴリズムは移動時間、部品の在庫状況、作業の複雑さを考慮していた――現場で理解した変数だ。顧客コミュニケーションのフローは、創業者たちが想像した質問ではなく、顧客が実際にした質問を先回りして対応していた。価格モデルは市場調査の推測ではなく、実際の取引から得た支払い意欲のデータに基づいていた。

ソフトウェアは無駄がなく、焦点が定まり、正確だった――すべての機能が、バンのフェーズで浮かび上がった問いへの答えだったからだ。

これが、私が会社から会社へと見てきた成功パターンだ――まずサービス、次にプロダクト、そしてプラットフォーム。

ステージ1：手動サービス。 あなた自身がプロダクトだ。サービスを手作業で提供する。すべてを学ぶ――何がうまくいき、何が壊れ、顧客が何を気に入り、何を許容し、何で離れていくか。売上は雇える人数に制限されるが、学びに制限はない。

ステージ2：ソフトウェアプロダクト。 検証済みのサービスをテクノロジーに落とし込む。ソフトウェアは新しいプロセスを発明するのではなく、実証済みのプロセスをデジタル化する。顧客はチームではなくプロダクトとやり取りする。売上はヘッドカウントではなくユーザー数に比例してスケールする。限界費用はゼロに向かう。

ステージ3：プラットフォーム。 テクノロジーを第三者に開放する。他の技術者、他のプロバイダー、他のビジネスがあなたのレールの上で稼働する。あなたはインフラとなる。売上は自社の事業だけでなく、エコシステム全体に比例してスケールする。

各ステージはその前のステージの上に成り立っている。手動サービスが叩き込む理解なしに、優れたプロダクトは作れない。信頼を勝ち取った実証済みプロダクトなしに、優れたプラットフォームは作れない。

ステージ1を飛ばす創業者――いきなりプロダクト開発に飛び込む創業者――は、技術的には印象的だが商業的には漂流するものを出荷しがちだ。顧客が抱えていない問題を解決する。機能しないワークフローを自動化する。検証されていないモデルをスケールさせる。

バンのフェーズが生み出すもう一つの資産がある。そしてそれが最も価値があるかもしれない――データだ。

あらゆる手動サービスのやり取りが情報を生み出す。どの修理が依頼されたか。実際の問題は何だったか（顧客の説明とは異なることが多い）。どれくらい時間がかかったか。どの部品が消費されたか。何がうまくいかなかったか。その後、顧客は何と言ったか。

このデータが数百件のジョブにわたって蓄積されると、テクノロジープラットフォームの学習セットとなる。スケジューリングアルゴリズムは実際の作業時間で訓練される。診断の提案は実際の問題解決パターンによって形作られる。顧客コミュニケーションのテンプレートは実際のフィードバックで磨かれる。

ソフトウェアを先に立ち上げ、後からこのデータを集めようとする競合他社は、上り坂を戦うことになる。彼らのデータセットは薄く、偏りがあり（未検証のプロダクトを試す意欲のある顧客からのみ）、ハンズオンサービス中の人間の観察から生まれる深みが欠けている。

Curbeeのデータ上の優位性は、優れたテクノロジーから生まれたのではない。何ヶ月もの間、レンチを手に顧客の自宅前で車を修理することから生まれたのだ。

ガイダンス#

テクノロジーを活用したサービスを構築するなら、テクノロジーではなくサービスから始めることを検討しよう。

最低3ヶ月間、サービスを手動で提供する。 「ベータテスト」としてではなく、本物のビジネスとして。本物の価格を請求する。本物の顧客にサービスを提供する。本物の売上を計上する。手動フェーズはリハーサルではない。それこそがビジネスなのだ。
すべてを記録する。 あらゆるやり取りの詳細なログを残す――何が依頼されたか、何が提供されたか、どれくらい時間がかかったか、何が壊れたか、顧客が何と言ったか。このログがプロダクトの仕様書だ。会議室で作成できたどんなものよりも正確だろう。
ボトルネックを見つける。 50件から100件の手動のやり取りを経れば、最大の制約がどこにあるか分かるだろう。最初のテクノロジーは、プロセス全体をデジタル化するためではなく、その特定の制約を打ち砕くために構築しよう。
テクノロジーを段階的に拡大する。 自動化は一度に一機能ずつ追加し、常に手動データに導かれるようにする。スケジューリング、次にコミュニケーション、次に決済、次に診断。追加するものはすべて、投機的な機能リクエストではなく、実際の問題への答えであるべきだ。

ソフトウェアの前にバンが来る。アルゴリズムの前にレンチが来る。そして、自分の手で仕事をすることで築いた理解――それこそが、どんな競合にもコピーできない資産なのだ。