スタートアップ運営コストの隠れた負担 – Sugarbug

スタートアップ運営コストの隠れた負担

スタートアップの運営コストが創業初日から段階的に積み重なり、チームが構築よりも調整に多くの時間を費やすようになるまでの過程。

目次

木曜日の午後4時47分、リードエンジニアがSlackチャンネルに一斉通知を送ってきた。月曜日のミーティングで議論したAPIスペックが最終確定されたかどうかを確認したいという。彼は3日間も仮定に基づいて開発を続けていたが、プロダクトリードが火曜日の午後にNotionドキュメントのペイロード構造を変更したことを誰も教えてくれなかった。誰もそのドキュメントを購読していなかった。プロダクトリードは自分がスタンドアップで言及したと本気で思っていた。しかし、そのスタンドアップは18時間も前のことで、エンジニアは子どもが靴下問題でパニックを起こしたために5分遅刻していた。

これは大惨事ではない。誰もクビにならず、何も燃えておらず、3日間の作業がまるごと無駄になったわけでもない。しかし、成長中のスタートアップではこのようなことが常に、目に見えない形で起き続けている。注意を払い始めると、その累積的な重さは本当に驚くほど大きい。

これがどのように起きるのか、段階ごとに見ていこう。

ステージ1：3人の楽園（1〜6か月目）

3人で同じ部屋にいるとき、スタートアップの運営コストはほとんど概念として存在しない。すべての会話が自然と耳に入る。誰かが決定を変えても、自分もその会話にいたか隣接していたから知っている。プロセスがないのは、必要がないからだ。コンテキストは空気のように漂っている。

後になってみんなが懐かしむのはこの時期で、正直、懐かしんで当然だ。これは素晴らしい働き方だ。問題は、人々がこれをシステムと勘違いすることだ。実際には、これは小規模であることの一時的な結果に過ぎない。すべてが1つの部屋に収まるとき、調整はタダだ。しかし調整はもともとタダではなかった – ただ部屋があなたの代わりに仕事をしてくれていただけだ。

そしてここに重要な人間の本性がある。この段階では調整が楽に感じられたため、3人の創業者たちは深く、ほとんど無意識のうちに「プロセスは不要だ」「構造を加えることは官僚的だ」「適切な人材はいつも状況を 把握している はずだ」という信念を持つようになる。この信念が次の2年間、彼らを悩ませることになる。

ステージ2：ぎこちない中間期（7〜14か月目、4〜8人）

4人目を採用し、次に5人目を採用する。デザイナー、2人目のエンジニア、顧客対応担当者かもしれない。しばらくはまだ大丈夫に感じる。Slackチャンネルに4人いることは、3人いることと本質的に変わらないからだ。

しかし、微妙な変化が始まる。全員が参加しないミーティングが出てくる。DMで決定が下される。誰かが2つ目のSlackチャンネルを作る。箇条書き1ページから始まったNotionワークスペースは、今や6つのセクションに47ページを抱えるようになり、プロダクトロードマップが実際にどこにあるかについて誰も合意できなくなっている（おかしなことに、答えは「3つの場所に3つの断片的なバージョンがあり、それぞれが微妙に異なる形で最新でない」だ）。

Timeline

9:00 AM スタンドアップ：デザイナーが創業者からのコピー待ちであることを伝える

9:03 AM 創業者が「昼食までに送る」と言う

10:14 AM 創業者が90分に及ぶ顧客通話に引き込まれる

11:45 AM デザイナーがSlackで創業者に連絡 – 返信なし（まだ通話中）

12:30 PM 創業者が昼食を取り、コピーのことを完全に忘れる

1:15 PM デザイナーは別の作業を始める

3:00 PM 創業者がコピーを思い出し、書いて、Googleドキュメントに入れ、間違ったデザイナーにDMを送る（先週2人目のデザイナーを採用していた）

4:30 PM 元のデザイナーは待ちながらそのまま退勤する

このタイムラインで誰も無能でも不注意でもない。一人ひとりが、すべての段階で合理的な行動を取った。創業者は重要な顧客通話に出た！デザイナーは待ちぼうけになる代わりに別の作業に移った！これらはすべて正しい個人の判断だが、集合的に悲惨な結果を生んだ。これこそが要点だ – スタートアップの運営コストは悪い人によって引き起こされるのではなく、成長した調整メカニズムを超えたシステムの中で動く良い人によって引き起こされる。

ステージ3：プロセスパニック（15〜22か月目、9〜15人）

ここが費用がかさむ段階であり、人間の本性という悪役が本当に中心的な役割を担う段階だ。9〜10人目あたりで、痛みが無視できなくなるからだ。物事が落ちこぼれ始める。大きな問題ではないこともあるが（いや、時には大きな問題もある）、見落とされたハンドオフ、重複した作業、古い情報、そして共有ドキュメントが存在して実際に共有されていれば学べたはずのことを互いに伝えるためだけに開かれるミーティングが、常に降り注いでいる。

この数字は、ほとんどの創業者の予想より本当に悪い。AsanaのAnatomy of Workレポートは、平均的なナレッジワーカーの1日の58%が「仕事のための仕事」 – 調整、ステータスの追いかけ、情報の検索、ツール間の切り替え – に費やされていることを明らかにした。MicrosoftのWork Trend Indexはほぼ同じ57%という結果だった。Clockwiseのエンジニアリング特化データでさえ、エンジニアが週9.7時間をミーティングだけに費やしていることを発見した。

10–20人規模のスタートアップの場合、控えめに見積もっても労働時間の25–45%が純粋な調整コストに消えている。それが実際にいくらの金額になるかは、チームがどこにいるかで完全に変わる：

要点

スタートアップの運営コストは人員数に比例して増加しない。人と人の関係と情報フローの数に比例して増加する。つまり、調整コストを積極的に削減しなければ、採用するたびに問題が不均衡に悪化する。悪役はツールでも、プロセスでも、組織図でもない – 3人で機能したことが15人でも機能すると思い込む、まったく自然な人間の傾向だ。

これらのブレンドコストには、基本給に加えて福利厚生と雇用主負担の税金が含まれている。「30%」の列は25–45%の中間値だ – そして自分に正直になれば、あなたのチームはおそらく高い方に近い。控えめな見積もりでも、サンフランシスコの12人のスタートアップは、製品開発ではなく調整に年間約$860,000を燃やしている。シュトゥットガルトでは約€350,000。東京では約3,300万円。絶対額は異なるが、バーンレートのうち「人が他の人に自分のやっていることを伝える（実際にやるのではなく）」ことに費やされる割合は、地域を問わず驚くほど一貫している。

そして次に何が起きるか – なぜなら毎回起きるから：誰か（たいていは創業者、時には新しく採用された運用担当者）がチームにプロセスが必要だと宣言する。意図は良い！実行も時には良い！しかし根本的な問題は、18か月間「プロセスは不要だ」というアイデンティティを築いてきたチームにプロセスを加えることは、まるで全員が自分たちは耐火性があると信じている家にスプリンクラーシステムを設置するようなものだ。

ステータスフィールドが埋められない。スコープが変わってもチケットが更新されない。重要な会話がDMで行われ、チャンネルにクロスポストされない。これは何かを妨害しているからではない – 注意力に限りがある人間であり、3人の楽園の時代に築いた深く染み込んだ習慣があるからだ。そしてその習慣こそが、15人の会社を崩壊させるものだ。

スタートアップ運営コストの複利計算

この数字は多くの人の予想よりも悪い。スタートアップが成長しているとき、運営コストは線形には複利しないからだ。

8人で、調整コストが中程度の20% – チーム全体で一人当たり月約32時間、合計256人時だとしよう。煩わしいが、管理できる – スタートアップなのだから、頑張って吸収できる。

そこで1四半期で4人を採用する。12人になった。しかし調整コストは人員数に比例して線形に増加するのではなく、コミュニケーション経路の数に比例して増加する。おおよそn(n-1)/2だ。8人から12人になると、コミュニケーション経路は28から66に増え、2倍以上になる。一人当たりのオーバーヘッドは20%にとどまらず、研究が一貫して示すように、この規模では30–35%に跳ね上がる。調整すべき人が増え、監視すべきチャンネルが増え、参加すべきミーティングが増え、善意の情報損失の機会が増えるからだ。

つまり今や12人×一人当たり月約50時間の調整コストで、600人時 – 8人だったときの2倍以上だ。チームはわずか50%しか増えていないのに。そして月600時間は、実質的にフルタイムのエンジニア約3.5人分が、本来構築すべきものを構築するのではなく、チームの調整に費やしていることを意味する。

この記事が響き、Sugarbugのナレッジグラフがチームのコーディネーションコストをどのように削減できるかを見たいなら、早期アクセスに登録する – 5〜30人規模のチームに展開中で、実際の環境的認識がどのようなものか見ていただけることを楽しみにしています。

実際に効果があること（そして効果がないこと）

多くのチームの本能 – 優れたプロジェクト管理ツールを購入する、運用担当者を採用する、ミーティングを増やす – は間違いではないが、不完全だ。症状（人々が何が起きているか知らない）を治療しているが、原因（情報が十数個のツールに断片化されており、誰もそれを手動で統合する余裕がない）には対処していない。

実際に効果があると分かったのは、環境的な認識のコストを下げることだ。すでに使っているツール全体で何が起きているかを – LinearをチェックしてからGitHub、Slack、Notion、カレンダー、またSlackへという手順なしに – 楽に把握できれば、調整コストの大部分は蒸発する。なぜなら、ほとんどの見落としタスクの根本原因は人々が気にしないからではなく、知らなかったからだ。

これが、透明性を持って言えば、Sugarbugが解決するために作られた問題だ。チームがすでに使っているツールにAPIで接続し、それらのツールが生成するすべてのシグナルからナレッジグラフを構築する。そのため、エンジニアが古いスペックに基づいて開発しているとき、火曜日にNotionドキュメントでスペックが変更されたという事実は、誰かがスタンドアップで言及することを思い出すかどうかに依存するのではなく、システムが実際に浮かび上がらせるものになる。ツールやプロセスを置き換えるのではなく、すべてのツール間の情報フローを誰かの記憶と注意力に依存しないようにしようとしている。

本当の悪役はあなた（具体的には、あなたの習慣）

人間の本性というフレームに戻りたい。これがこの記事全体で最も重要なポイントだと思うからだ。スタートアップの運営コストが速度を圧迫し始めると、外部に責任を求める誘惑が生じる – ツールが悪い、プロセスが壊れている、組織構造が悪い。そしてそれが事実のこともある！しかしより多くの場合、根本的な問題は、チームの人々がその瞬間に自然で合理的で効率的と感じることを正確にしており、それらの個々の合理的な判断の集合的な結果が、調整に25%の能力を費やす組織だということだ。

解決策は人々を人間であることで責めることではない。解決策は、全員が完璧な記憶と無限の注意力を持つことを必要とせずに、適切な情報を適切な人に届けるシステムを構築することだ。

よくある質問

スタートアップのオペレーショナルオーバーヘッドとは何ですか？

スタートアップのオペレーショナルオーバーヘッドとは、チームが構築ではなく調整に費やす時間・エネルギー・費用の合計です。複数の人が同じことに取り組むための税金であり、チームが拡大するにつれてほとんどの創業者の予想より速く増大します。

Sugarbugはどのようにしてスタートアップのオペレーショナルオーバーヘッドを削減しますか？

SugarbugはAPIでチームがすでに使っているツールに接続し、それらのツールが生成するすべてのシグナルから生きたナレッジグラフを構築します。ツールを置き換えるのではなく、それらを通じて流れる重要なシグナルが失われないようにします。

チームのどの規模でオペレーショナルオーバーヘッドが深刻な問題になりますか？

ほとんどのチームは8〜12人あたりで本当の痛みを感じ始めます。オーバーヘッドはその閾値以前から積み重なっていました – ただ気づくほど痛くなかっただけです。

Sugarbugはプロジェクト管理ツールの代替になりますか？

いいえ、それは設計上のことです。Sugarbugは既存のスタックの横に置かれてそこから読み込み、ツール間の情報を結びつけるナレッジグラフを構築します。各ツールの役割を補完します。