← エピソード一覧に戻る Episode 136 Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
0:00 / 0:00
スクリプト
Chapter 1 オープニング ― 裏で人が動くことは失敗なのか
タカシ
皆さんこんにちは、タカシです。今日は SaaS 立ち上げで誤解されやすい手動運用を扱います。実は有名 SaaS の初期には、裏で創業者がレポートを書いたり、設定を代わりに入れたりしていた例が珍しくないんです。
ミカ
ミカです。えっ、それって『まだ SaaS になっていない』ってことじゃないんですか。システムで自動化できていないなら、むしろプロダクトが弱いサインにも聞こえるんですが、その見方は早計なんでしょうか。
タカシ
早計ですね。初期の手動運用は、未熟さの証拠というより、顧客価値が生まれる流れを体で覚えるための観測装置です。問題は手で回していること自体ではなく、そこから何を学び、いつ仕組み化するかが曖昧なことなんです。
ミカ
なるほど、舞台で言うと本番前のリハーサルを、観客を入れながらやっている感じですね。裏方の動きまで含めて『どうすれば価値が届くか』を確かめる期間だと考えると、かなり見え方が変わります。
タカシ
その理解でいいです。今日は、手動運用の基本的な考え方、Vanta と UserLeap と Superhuman の具体例、そして手で回すことが受託化に落ちる危険まで、経営判断として順番に見ていきましょう。
Chapter 2 基本 ― 手動運用は学習装置であって美談ではない
タカシ
Paul Graham は、後で自動化する処理を最初は手で回し、その筋肉記憶から何を作るべきか学べると述べています。SaaS でも、導入設定や初回レポート作成のような工程は、まず人が担ったほうが顧客の詰まりを早くつかめます。
ミカ
でも、それって『実は人が頑張っていました』という危うい状態とも隣り合わせですよね。どこからが健全な学習で、どこからが単なるごまかしなのか、その境目が気になります。
タカシ
境目は三つあります。反復される作業か、経済合理性があるか、そしてログ化されているかです。毎回似た条件で発生し、価格や将来の粗利に耐え、さらに時間や詰まりを記録しているなら、それは立派な学習資産になります。
ミカ
逆に言うと、案件ごとに別のことを頼まれて、その場しのぎで全部受けていると危ないわけですね。売上が立っているようで、実態はコンサル受託や便利屋に近づいてしまう、と。
タカシ
その通りです。SaaStr の Steve Newman も、初期に手で回すのは有効だが、どの作業が時間を食い始めたかを見張らないと、少しずつ何かを落とし始めて大問題になると言っています。美談化せず、計測することが前提なんです。
Chapter 3 事例 ― Vanta と UserLeap は何を手で回したのか
タカシ
Vanta の初期は象徴的です。ソフトウェアを書く前に、まず Segment 向けの SOC 2 ギャップ分析をスプレッドシートで作りました。さらに最初のソフト版も簡単なフォームだけで、裏ではチームが情報を集め、翌日にレポートを書いていたそうです。
ミカ
かなり手作りですね。でも、その段階で売れたからこそ、『どの統制は共通化できるか』『どこはまだ人の判断が要るか』が見えたわけか。いきなり完成版を作っていたら、外していた可能性も高そうです。
タカシ
まさにそこです。手動運用の価値は、顧客が払うかどうかだけでなく、どの工程が標準化できるかを見極めることにあります。Vanta は同じ型を別の会社にも当てられると分かったから、初めて『ここは SaaS にできる』と確信できました。
ミカ
他にも、手で回したからこそ本当に必要な機能が見えた例ってありますか。初期 SaaS だと、管理画面を頑張って作りたくなる誘惑がかなり強そうなので、その反例を知りたいです。
タカシ
UserLeap が良い例です。最初は SDK と生データを見る場所だけ作り、アンケートの停止や出し分け、分析は Ryan Glasgow 自身が手で実施しました。2,000 件の回答を読んで示唆まで返したから、先に作るべきなのは配信機能より分析価値だと分かったんです。
Chapter 4 深掘り ― Superhuman は人手を自動化の前提知識にした
タカシ
Superhuman も手動運用を徹底しました。Gaurav Vohra は初期に何百人もの顧客を自ら 1 対 1 でオンボーディングし、その後は数十人規模の専門チームへ広げています。かなり重い運用ですが、ここで『最初の一歩』を徹底的に観察したわけです。
ミカ
正直、そこまでやると非効率に見えます。でも、メールみたいに日常頻度が高いプロダクトだと、最初の数分でつまずいた理由を会話から拾える価値は大きそうです。分析ツールだけでは見えない部分ですよね。
タカシ
その通りです。Superhuman は後にセルフサーブを強化しますが、初期の人手で得た学びをプロダクトに移したから精度が高かった。つまり手動運用は『いつまでも続ける前提の作業』ではなく、『自動化の設計図を集める期間限定の投資』なんです。
ミカ
では経営者は、いつ『もう十分学んだ、ここは作ろう』と判断すればいいんでしょう。手で回すほど学びは増えるけれど、創業者の時間は有限ですし、やめ時を逃すのもかなり怖いです。
タカシ
目安は、同じ作業が繰り返し出て、条件分岐が読め、しかも創業者時間を食い始めた時です。例えば週に何回発生するか、1 件あたり何分かかるか、顧客成果にどう効くかを見て、作る・採る・やめるの三択で判断するとブレません。
Chapter 5 失敗パターンとクロージング ― 手作業を資産に変えるには
タカシ
よくある失敗は三つです。手作業を記録せずに美談化すること、顧客ごとに別の特注対応を増やして受託化すること、そしてやめ時を決めずに創業者依存を固定してしまうことです。どれも『学習手段』を『構造的な負債』に変えてしまいます。
ミカ
創業者が『まだ自分で回せるから大丈夫』と思っていたら、ある日まとめて破綻する絵が見えますね。しかも本人ほど、その負荷が少しずつ増えていることに気づきにくい。これはかなり危ない落とし穴だと思います。
タカシ
だから実務では、最初の 10 社前後で手で回した工程を必ず記録し、学習のための作業と単なる特注作業を分けることです。そして同じ作業が何回出たら自動化するか、誰の時間を何割超えたら採用するかを先に決めておくと強いですね。
ミカ
今日の話を聞くと、手動運用は『恥ずかしい暫定対応』ではなく、『顧客価値の地図を描く期間限定の現場仕事』なんですね。手で回した内容をきちんと記録できれば、あとで作るべきものもかなりシャープになりそうです。
タカシ
その通りです。SaaS 立ち上げでは、自動化を急ぐより先に、顧客が価値に届く流れを自分たちで再現できることが大切です。皆さんの事業でも、いま手で支えている工程が『学び』なのか『負債』なのか、ぜひ一度棚卸ししてみてください。