第6話 走り始めスタートアップの最小構成 ── 〜50人の現実解

場面

PE 専任チームを置くには、人が足りない。ではどうしているか。

第4話では Uber が4,000人規模の総合内製プラットフォームを作り、第5話では SmartHR・Money Forward・Sansan が数百人規模でドメイン基盤を立ち上げる過程を見た。これらは、いずれも**「リソースが潤沢にある」**前提で動いている。

だが、走り始めスタートアップは違う。エンジニア20人。インフラ専任ゼロ。CTO が片手間で AWS コンソールを触る。プロダクトを2本同時に立ち上げ、認証も決済も顧客サポートも全部 SaaS で凌ぐ。ここに「Platform Engineering をやりましょう」と言っても、人が足りない。

それでも、走り始めスタートアップの公開一次情報を15社分横断すると、はっきりとしたパターンが見える。「PE 専任チームは置かない」が最頻パターンであり、それでも開発者体験を維持する手段が確立されつつある。本章では海外（Tailscale, Resend, Durable, PostHog, Linear, Notion, Plausible, Cal.com）と日本（Cloudbase, Bitkey, カミナシ, smartround, LayerX バクラク, レバテック）の事例から、〜50人規模の現実解を解剖する。

状況：「PE をやらない」が最頻パターンである

走り始めスタートアップが置かれる状況を、典型的な制約から見る。

制約	影響
エンジニア5〜20人	専任チーム化の余裕がない
インフラ専任ゼロ〜1人	Kubernetes 自前運用は不可能
プロダクトの方向性が未定	早すぎる最適化が最大の罠
採用コストが資金繰りに直結	「人を増やす」より「自動化する」
マネージド SaaS の価格が成長コストになる	月数万〜の固定費でも痛い

これらの制約下で、共通して観察できるのが**「使えるものは何でも使って認知負荷を下げる」**というスタンスだ (Cloudbase, ryukez (2024))。

その帰結として、走り始めスタートアップの Platform Engineering は5つのパターンに収束する。順に見ていく。

選択：5つの共通パターン

パターン1：PaaS／Managed Platform 全乗せフェーズが必ずある

走り始めスタートアップは、ほぼ例外なく以下のいずれかに依存して立ち上がる。

プラットフォーム	採用例
Vercel	Cal.com、Durable、Resend (FE)、多数の Next.js 系
Supabase	Resend、E2B、Documenso
Heroku	Plausible、旧みんせつ
Render	みんせつ（Heroku から移行）
Fly.io	多数の個人開発／Phoenix・Elixir 系
AWS ECS Fargate	smartround、LayerX バクラク、カミナシ
GKE（マネージド K8s）	Linear、10X
Cloud Run	Bitkey（標準化対象）

ここで強調したいのは、自前 Kubernetes クラスタを早期に運用している例が、本リサーチでは見つからなかったという事実だ。これは「やってもいいけど現実的ではない」のではなく、意識的に避けられている。

Hacker News の議論では、「EKS を7年運用して、メンテだけで0.5人年食う」「ECS に移ろうとしている」という証言が繰り返し現れる (HN: “You shouldn’t use Kubernetes as a startup”)。Plausible は明確に**「退屈なツールを選び、顧客課題に集中せよ」**という哲学を掲げる (Plausible: Technology choices)。

注目すべき具体例を3つ挙げる。

Durable（エンジニア6名）：Vercel 全乗せ

AI ビジネスビルダーの Durable は、Vercel の機能を端から端まで使い切ることで、エンジニア6名で300万社へのサービス提供と、年間3,600億トークン（1日11億）の処理を支えている (Vercel: 360 billion tokens, 3 million customers, 6 engineers)。

CEO Khan の言葉が要点を突いている：

我々は AI ネイティブアプリ。AWS インフラを組むのではなくエージェントで価値を作るところに集中する。

避けたものも公式に列挙されている：マルチリージョンクラスタ、SSL/カスタムドメイン基盤、DDoS/Bot 防御、自前のオブザーバビリティ、in-house DevOps。「これらをやらない」と決めることそのものが、走り始めスタートアップの PE 判断だ。

Resend（FE エンジニア2名）：Supabase 全乗せ

開発者向けメール送信 API の Resend は、フロントエンドエンジニア2名がデータベース層も触る体制で立ち上がった。Supabase（Postgres + Auth + Functions）に全面依存し、バックエンド専任を置かない。Year 1 で1,000 paying customers、現在は5,000+ paying customers、登録開発者300,000人超、1日数百万通送信 (Supabase: Resend customer story)。

CEO Zeno Rocha の言：Supabase によりバックエンドを自作せず、メールインフラ本体に集中できた。集中するために、何かを諦める。

Linear・Notion：マネージド DB は最後まで離さない

Linear は Cloud SQL for PostgreSQL を「運用チームなしで TB 級にスケールできた鍵」と Google Cloud 側のケーススタディで明言している (Google Cloud blog)。

Notion は2015〜2020年の5年間、単一 RDS Postgres で動いていた (Notion: sharding-postgres-at-notion)。2021年の TikTok バイラル成長で限界に達し、15論理シャードに分割するまでは。

自前 DB 運用に走る走り始めスタートアップの公開事例は、本リサーチでは発見できなかった。これは偶然ではなく、合理的選択だ。

パターン2：「インフラ専任1人」が現実的な最初のスケール単位

複数の事例で、最初の SRE / インフラ専任は「1人」から始まる。

• smartround：1人目 SRE として2022年5月入社
• LayerX バクラク：SRE グループは「私1人」から始まり4名へ拡大 (LayerX エンジニアブログ, 2025-01)
• Tailscale：インフラチーム3名で運用（2024年11月時点）
• Bitkey：SRE 2名 + ゲリラチーム2名

そして、1人目 SRE の典型的な仕事リストは驚くほど共通している。smartround の事例（Zenn, 2023-04）から汎化したリスト：

graph TD
    A[1人目SRE入社] --> B[古いPaaSからの移行<br/>EB→ECS Fargate / Heroku→Render]
    A --> C[Terraformバージョンアップ<br/>と再構造化]
    A --> D[Secret管理<br/>Parameter Store/Secret Manager]
    A --> E[CI高速化<br/>並列化/shallow clone]
    A --> F[環境差の可視化<br/>Chrome拡張]
    A --> G[DBスキーマドキュメント自動化]
    A --> H[APM/Log管理<br/>Datadog]
    A --> I[外形監視]

    B --> Z[次のフェーズ:<br/>SREチーム化]
    C --> Z
    E --> Z
    H --> Z

この8項目は、形式的には「PE」と呼べる開発者体験改善だが、誰も「PE」とは名乗っていない。SRE が PE 機能を兼ねている、という言い方が一番近い。第5話で見た「日本では SRE → Platform Engineering への組織進化が起こる」という構造の、最初の段階がここだ。

LayerX バクラクの事例では、「私1人」で50+サービスを抱える ECS Fargate 環境を支えていた時期があり、そこから4名体制への拡大過程が公開されている。**1人体制の限界が「複数プロダクトの一斉デプロイ」「サービス間依存の手動解決」**として現れることも、合わせて記録されている (LayerX エンジニアブログ, 2023-12)。

パターン3：「PE 専任チーム」より「兼任 + 標準仕様」

Bitkey、Cloudbase、カミナシいずれも、PE 専任チームは持たない。代わりに**「標準化の道具立て」**を、SRE / ゲリラチーム / 創業期エンジニアが副業的に作っていく。

Bitkey の標準化セット（Speaker Deck）：

• GitHub Actions 集中リポジトリ：再利用可能 workflow / composite action、Google Cloud OIDC、GitHub Apps 経由のトークン発行、Slack/Jira 連携
• Cloud Run 標準化：cloud_run.yaml という独自抽象で、開発者が最小設定でデプロイ
• InnerSource 原則：内製ツールも OSS 同等のドキュメントを揃える
• 社内 RFC/IANA 準拠の標準仕様：ページネーション、エラーハンドリング、ログレベル、デザイントークン

Bitkey の特徴は、トップダウンに PE チームを作るのではなく、Stream-aligned チームの困りごとに応じて SRE / ゲリラチームがボトムアップに提供する設計だ。Cloud Run 標準化の adoption は workhub チームに留まり、横展開しきれていないと自己評価している。これは「強制せず採用される」ことの難しさそのもので、第3話 Paved Road の論点と地続きだ。

カミナシの試行3つ（カミナシ ブログ, 2024-02）も、走り始めスタートアップの試行錯誤として参考になる。

アプローチ	利点	限界
❌ 個人主導：「切って速く動く」	即効性	組織の再現性なし、続かない
△ 学習駆動の協業：式年遷宮型	チームの底上げ	テーマ選定が難しい
○ バックログ統合	標準フローに乗る	「VPC 再設計」のような直接ユーザー価値が見えない項目には適用しづらい

執筆者は前職 freee で SRE 6年経験。それでも「未解決」と明言している。直接ユーザー価値が見えないインフラ作業の優先度付けは、走り始めスタートアップの普遍的な難問だ。

パターン4：OSS／自前ホストの選択肢を絞るのも PE

走り始めスタートアップの PE 判断で、見落とされがちなのが**「サポート対象を絞る」**ことだ。社内 PE と外向き PE が地続きになる、これも小規模スタートアップの特徴。

PostHog：2023年5月、Kubernetes サポートを廃止

47人 / 15チーム / 10カ国の PostHog は、2023年5月に Kubernetes（Helm）サポートを廃止した。維持するのは PostHog Cloud と Docker Compose ベースの “Hobby” デプロイのみ (PostHog: Sunsetting Helm support)。

公式が説明している理由：

• K8s 利用ユーザーは全体の約3.5%
• イベント取り込み、Kafka、ClickHouse、Postgres、Redis、アプリ本体の各層で問題が連発
• 小さなインフラチームが、少数派の K8s ユーザー対応に時間を吸われていた

「PE で複数の運用形態を支援する」という選択は、小規模 OSS スタートアップにとって持続可能でない。集約こそが PE。これは PostHog が公開している重要な学びだ。

Cal.com：2025年、OSS から商用クローズドソースへ

Cal.com は2025年に、コアを商用クローズドソース化し、MIT ライセンスの cal.diy を分離した (Cal.com: Going Closed-Source)。OSS 提供と商用提供の運用負荷を分離する選択であり、これも一種の PE 判断だ。「コアチーム5チーム（Foundation チームを含む）」のうち、Foundation チームがコーディング規約・アーキテクチャパターンを統括し、Vercel cold start を 15s → 2s に短縮するような最適化を主導している (Cal.com: Cold Start Resolution)。

パターン5：「PE をやらない」も明示的選択肢

そして最後に、「PE をやらない」を明示的に選んだ事例がある。

レバテック：基盤システムグループを解散

Platform Engineering Kaigi 2024 で公開された、最も挑発的な事例 (Speaker Deck)。レバテックは基盤システムグループを解散し、エンジニアをドメインチームに再配置。インフラ責務を SRE に集約した。

理由：

• Stream-aligned チームの実課題に PE がフィットしない
• 技術的負債解消が先

「観察と分析の上で、本当に必要になってから始める」「ブームに乗って雇うな」というのが、レバテックの主張だ。第3話で見た Netflix Paved Road の「強制せず誘導する」思想とは別の角度から、そもそも誘導するレイヤを作らないという判断もある、ということを示している。

Cloudbase：「早すぎる最適化」を最大の罠と認識

10人規模の Cloudbase は、執筆者個人が主体となって PE「実践の一部」を取り入れる構成を採る。「組織の各フェーズに応じた PE の役割」を明示的に区別し、初期フェーズ（〜20人）では「使えるものは何でも使って認知負荷を下げる」を原則とする (Cloudbase / ryukez)。

「スコープの肥大化」「プロダクト方針が固まる前の早すぎる最適化」を最大の罠として警戒する姿勢は、走り始めスタートアップの PE 議論で頻繁に見落とされる視点だ。

なぜ：5パターンを貫く論理

5パターンを貫く論理を、3つに整理する。

論理1：認知負荷の最小化が、機能開発速度に直結する

走り始めスタートアップでは、プロダクト機能の開発速度こそが事業の生命線だ。インフラ・運用に1割でも余計な認知負荷が乗ると、機能開発が遅れる。マネージド SaaS は割高に見えても、機能開発に注げる時間を増やすための投資として正当化される。

Plausible が言う「退屈なツールを選び、顧客課題に集中せよ」は、この論理の最も端的な表現だ。

論理2：「形式化される前の実践」が走り始めの実態

公開情報のギャップとして、「自社製 IDP（Backstage 等）を走り始めスタートアップで導入した」事例は、本リサーチでは未発見だった。「最初の Platform Engineer を雇った瞬間の意思決定プロセス」を一次情報で書いている小規模スタートアップも見つかっていない。

これは「ない」のではなく、「形式化される前のもの・人に紐づく実践」だから記事化されにくい、と読むべきだろう。Bitkey、smartround、カミナシのように、SRE / インフラ専任が個別に語っている事例があるだけだ。

論理3：「やる／やらない」を経営判断にする

走り始めスタートアップの PE は、技術判断ではなく経営判断だ。

graph LR
    Q[PEを始めるべきか?]
    Q --> S1{Stream-aligned<br/>チームの困りごとは<br/>PEで解けるか?}
    S1 -->|Yes| S2{陣容を割けるか?}
    S1 -->|No| END1[PEを始めない]
    S2 -->|Yes| S3{プロダクト方針は<br/>安定したか?}
    S2 -->|No| END2[兼任で先に試す]
    S3 -->|Yes| START[専任化を検討]
    S3 -->|No| END3[早すぎる最適化を警戒]

Bitkey の「専任チームを置くより、SRE がついでにやる」、レバテックの「Stream-aligned チームの困りごとが、PE で解けるかを問う」、Cloudbase の「組織の各フェーズに応じた PE の役割」──いずれも、経営判断としての PEを語っている。

「最初の Platform Engineer を雇うタイミング」の相場感

公開一次情報を集約すると、以下の相場感が浮かぶ（断定ではなく公開事例の集約値）。

エンジニア規模	典型的な体制	代表事例
〜10人	PE 専任なし。創業エンジニア／CTO が PaaS で立てて回す	Cloudbase、Resend (FE2人)、Durable (6人)
10〜20人 ＆ プロダクト2本以上	1人目 SRE／インフラ専任が登場。PE 的活動はこの1人が兼任	smartround、LayerX バクラク（初期）、Tailscale（インフラ3人）
30〜50人	SRE チーム化（2〜4名）、PE 的活動は SRE の中で標準化	Bitkey（SRE 2人＋ゲリラ2人）、LayerX バクラク（4人体制）、PostHog（47人）
PE 専任チーム化	走り始めスタートアップではほぼ存在しない	（第5話で見た数百人規模事例に到達してから）

業界一般言説として、複数の調査・ベンダー記事を集約すると次のような数字も見られる：

• 最初の DevOps エンジニアを雇う目安：エンジニア5〜10人
• Developer : DevOps の理想比：3:1 〜 5:1
• 専任チーム化の閾値：10人を超えてから
• 最初の Platform Engineer を雇う目安：Series C 以降（DevOps より遅い）

「PE 専任は DevOps よりさらに遅い」というのが、現時点での集約された相場観だ。これは、PE が DevOps より高度な活動だから遅いのではなく、「兼任で十分な期間が長い」から後回しにできる、という理解の方が正確だろう。

示唆：あなたの会社が走り始めなら

5パターンと相場感から、自社判断のための問いが3つ抽出できる。

1. PaaS 全乗せフェーズを、いつまで延ばせるか？

   • Vercel・Render・Cloud Run・ECS Fargate のどれかで凌げるなら、そのまま延ばす。マルチリージョン要件、特殊なネットワーク、コスト圧で初めて自前構築を検討する。

2. 1人目 SRE / インフラ専任を雇うトリガーは何か？

   • プロダクト2本以上、エンジニア10〜20人、CTO の片手間で AWS が回らなくなった瞬間が、smartround・LayerX バクラクの相場感。
   • 雇った1人には、上記の8項目（PaaS 移行、Terraform、CI 高速化、Datadog 等）を期待値として共有する。

3. 「PE をやらない」の明示的判断ができているか？

   • レバテック・Cloudbase のように、「いつ始めるか」を経営判断として明示する。ブームに乗って始めると、第10話で扱うアンチパターン（Field of Dreams、誰も使わない Backstage）に直結する。

まとめ

パターン	内容	代表事例
1	PaaS 全乗せフェーズが必ずある	Durable, Resend, Linear, Notion
2	1人目 SRE が現実的な最初のスケール単位	smartround, LayerX バクラク, Tailscale
3	PE 専任より兼任 + 標準仕様	Bitkey, Cloudbase, カミナシ
4	OSS／自前ホストの選択肢を絞る	PostHog, Cal.com
5	「PE をやらない」も明示的選択肢	レバテック

走り始めスタートアップの Platform Engineering は、**「PE をやる」より「PE をやらない判断を含めた、最小構成を保つ」**ことに本質がある。マネージド SaaS への意図的依存、1人目 SRE の典型業務、兼任 + 標準仕様、サポート範囲の意図的縮小、そして「PE をやらない」の明示的判断──これら5つはすべて、認知負荷の最小化と機能開発速度の最大化という同じ論理に貫かれている。

そして、本章で見た事例は、第7話「中規模成長期の選択」につながる。1人目 SRE → SRE チーム化 → Platform Engineering 的活動の標準化 → Platform チームの専任化──このフェーズ移行を、10X、LayerX バクラク、カケハシ、freee、Visional の事例から詳細に追っていく。50人を越えたあたりで何が起きるのか、なぜ既存の SRE では足りなくなるのか。次の章で解きほぐす。

---

問い：あなたの会社の今のフェーズ（〜10人 / 10〜20人 / 30〜50人）で、「PE をやらない」と意識的に決めることが、機能開発速度の確保にどれだけ寄与するだろうか。「やる」より「やらない」の判断の方が、難しくはないだろうか。

---

参考文献

海外事例

• How Tailscale’s infrastructure team stays small (2024-11)
• The magic of small engineering teams - PostHog
• Sunsetting Kubernetes support for PostHog (2023-05)
• PostHog Handbook - Small teams
• Plausible: Technology choices
• Cal.com: Cold Start Resolution Blog
• Cal.com: Going Closed-Source - Technical Changes Behind Cal.diy
• How we built multi-region support for Linear
• Linear uses Google Cloud databases - Google Cloud Blog
• Building and scaling Notion’s data lake
• Herding elephants: lessons learned from sharding Postgres at Notion
• Vercel: 360 billion tokens, 3 million customers, 6 engineers (Durable)
• Supabase: Resend customer story

日本事例

• スタートアップでもPlatform Engineeringがしたい！Part 1 - Cloudbase / ryukez
• スタートアップにおける Platform Engineering の片鱗 - Bitkey
• 専任チームが存在しないカミナシでどうやってインフラの改善を進めているのか？
• スタートアップの1人目SREが入社後にやってきたこと - smartround
• 転生 SRE マネージャー サバイバル・ガイド - LayerX エンジニアブログ (2025-01)
• バクラクの爆速開発を支えるDevOpsチームの「のびしろ」 - LayerX (2023)
• いつPlatform Engineeringを始めるべきか？レバテックのケース - Platform Engineering Kaigi 2024
• みんせつ事例（CI/CD Conference 2023） - Think IT

コミュニティ議論

• Hacker News: You shouldn’t use Kubernetes as a startup
• Hacker News: Is Kubernetes still a big no-no for early stages in 2025?

＋ － ⟳ ✕