SaaS組織づくりとスケーリング

SaaSスケーリング——ARR1億から10億への組織・採用・エンジニアリング体制

「スタートアップを殺すのは失敗ではなく、成功を消化できないことだ」という格言があります。PMFを確認し、資金調達に成功したSaaSが次に直面する最大の難問は「スケーリング」です。プロダクトが売れ始めると、組織・採用・エンジニアリング・カスタマーサクセス・財務管理のすべてが急速に複雑化します。このレッスンでは、ARR1億円から10億円への成長フェーズで必要な組織設計・採用戦略・プロダクト-エンジニアリング体制を体系的に学びます。

---

スケーリングロードマップ

SaaSスケーリングロードマップ — ARR 1億→10億 組織・採用・体制

ARR1億から10億への道のりは、「プロダクト最優先の小チーム」から「専門分業した拡張組織」への変態です。各フェーズで必要な組織構造・優先採用・KPIが異なります。フェーズを誤って早期に大組織を作ると、スタートアップの機動力が失われます。逆に遅すぎると、成長速度についていけずにオペレーションが崩壊します。

---

組織設計の原則

創業期の組織設計（ARR 1億〜3億）

この段階の組織設計の鉄則は「フラットで機動的に」です。階層を作ると意思決定が遅くなり、顧客フィードバックへの反応速度が落ちます。

2 Pizza Rule（アマゾンのベゾスが提唱）: チームサイズは2枚のピザで食べられる人数（6〜8名）を超えないようにします。それ以上になると会議コストとコミュニケーションコストが指数関数的に増加します。

機能別組織の構造

• ◆Engineering（プロダクト開発）
• ◆Sales（獲得）
• ◆Customer Success（継続・拡張）
• ◆G&A（総務・財務）

この段階では各機能の人数は1〜3名程度で、創業者が複数の機能を兼任していることも多いです。

成長期の組織設計（ARR 3億〜5億）

ARR 3億を超えると「チームが10名を超え、創業者が全員を把握できなくなる」転換点が来ます。ここでは**スクワッド制（チーム制）**への移行が有効です。

スクワッドとは、特定の顧客セグメントや製品エリアに特化した小チームで、エンジニア・PM・デザイナー・CSが1チームに集約されています。各スクワッドがEnd-to-Endで意思決定できる権限を持つことで、創業者のボトルネックを解消します。

スケール期の組織設計（ARR 5億〜10億+）

ARR 5億を超えると、組織はプロダクトライン別または顧客セグメント別の事業部制（BU制）へ移行することが多いです。各BUが独自のP&L（損益）を持ち、疑似的な会社として機能します。

💡 組織設計の失敗パターン: 「優秀なエンジニアをマネージャーに昇進させる」は最も多い失敗パターンです。エンジニアとしての優秀さとマネジメント適性は別のスキルです。Individual Contributorとして評価・報酬を高める「デュアルキャリアパス」を設計することで、優秀な技術者をマネージャーに無理やりしなくて済みます。

---

採用戦略——フェーズ別優先ポジション

採用の鉄則：「カルチャーフィット」より「ミッションフィット」

スタートアップの採用で最も高くつく間違いは「カルチャーフィット」という曖昧な基準で採用することです。これは多様性を失い、同質なチームを生む温床になります。代わりに「ミッションフィット（なぜこの会社で働きたいか）」と「スキルフィット（この段階で必要なスキルを持っているか）」の2軸で評価します。

フェーズ別の優先採用ポジション

採用プロセスのベストプラクティス

スコアカード採用: ポジションごとに「必須スキル3つ・歓迎スキル3つ・カルチャー観点3つ」を事前に定義し、全候補者を同じ基準で評価します。面接官の主観や「なんとなく好き」での採用を防ぎます。

ワークサンプルテスト: 実際の仕事に近い課題を候補者に解いてもらい、成果物で評価します。エンジニアならコーディング課題、PMならプロダクト改善提案、CSMなら模擬顧客対応などです。

⚠️ 採用の速度と質のトレードオフ: 「急いで採用して、問題があれば解雇すれば良い」という考えはカルチャーを壊します。1人の不適切な採用の影響は、その人のパフォーマンス問題だけでなく、チームの士気・既存メンバーの離職・採用コストとして波及します。採用基準を下げるくらいなら「ポジションを空けておく」勇気が必要です。

---

プロダクト-エンジニアリング体制

PMとエンジニアの役割分担

スケールフェーズで最も摩擦が生まれやすいのがPM（プロダクトマネージャー）とエンジニアの関係です。PMはビジネス要件と顧客ニーズを定義し、エンジニアはその実装方法を決定します。PMが実装方法を指示する「スペック提示型」はエンジニアの自律性を奪い、品質とモチベーションを下げます。

推奨フレームワーク: 「問題は詳細に、ソリューションは余白を持たせて」 PM → 「顧客がオンボーディング完了までに離脱する問題を解決したい（目標: 7日以内完了率80%）」 エンジニア → 「それを達成するための最適な実装方法を自分たちで決める」

プロダクト組織のKPI設計

エンジニアリング組織のスケーリング

エンジニア採用の「Hiring Bar（採用基準）」を下げない: エンジニアリングチームが30名を超えると、1名の採用基準の低下が組織全体の技術力低下に繋がります。採用バーを維持するために、採用決定には「必ず1名以上の現シニアエンジニアが賛成票を投じる」というルールを設けることが有効です。

技術的負債の管理: スケール期には「今すぐリリースする」プレッシャーが高まり、技術的負債が蓄積しやすくなります。Sprint全体の20%を技術的負債の返済に充てるルールを定め、債務が雪だるま式に増えないよう管理します。

---

カスタマーサクセス（CS）のスケーリング

CS体制のフェーズ別設計

初期は創業者・営業が兼任していたCSを、ARR 1億超えのタイミングで専任化します。CSのKPIは「チャーン防止」だけでなく「拡張収益（Net Expansion）の創出」も含まれます。

CSチームのセグメント別設計

• ◆ハイタッチ（High Touch）: ACV $50K以上の大口顧客。CSMが1対5〜10の比率で担当。定期QBR（四半期ビジネスレビュー）を実施
• ◆ミッドタッチ（Mid Touch）: ACV $10K〜$50K。CSMが1対20〜50の比率。月次メール＋アラートベースの介入
• ◆テックタッチ（Tech Touch）: ACV $10K未満のSMB。CSMは介入せず、自動化されたメール・プロダクトメッセージのみ

チャーン防止のためのヘルススコア

ヘルススコアは顧客がチャーンするリスクを数値化したものです。以下の指標を組み合わせてスコアを算出します。

💡 チャーンの早期検知: チャーンは契約終了の1〜2ヶ月前に「ヘルスサインの急落」として現れます。チャーンアラートが出た顧客には72時間以内にCSMがアクションを起こすSLAを設けることで、チャーン率を大幅に改善できます。Gainsightなどのツールを使えばこのプロセスを自動化できます。

---

ARR10億到達のためのチェックリスト

---

🏋️実践ワーク

以下のワークを実施してください。

1. ◆フェーズ診断: 自社のARRを確認し、現在どのスケーリングフェーズ（Phase 1/2/3）にいるかを特定する。そのフェーズで「最も緊急度の高いボトルネック」を組織・採用・プロダクト・CSの4軸で1つずつ挙げる
2. ◆採用スコアカード作成: 次に採用予定のポジション1つを選び、必須スキル3つ・歓迎スキル3つ・ミッションフィット評価基準3つを含む採用スコアカードを作成する
3. ◆ヘルススコア設計: 自社プロダクトの顧客に対して、ログイン頻度・機能利用率・サポート状況・支払状況の4軸でヘルススコアを算出するスプレッドシートを設計する
4. ◆スクワッド設計: 現在または目標とするフェーズでのスクワッド構成を設計する。各スクワッドの「担当領域・チーム構成・OKR（目標と主要成果指標）」を書き出す

📝まとめ

SaaSのスケーリングは「良いプロダクトが自動的に組織を成長させる」のではなく、フェーズごとに意図的な組織設計・採用・体制構築が必要です。ARR 1億から3億は機動力重視のフラット組織、3億から5億はスクワッド制への移行、5億以上は事業部制と専門Cレベルの確立というロードマップが機能します。採用では基準を下げず、CSではヘルススコアで先手を打ち、エンジニアリングでは技術的負債を意識的に管理する。スケールの壁を越えるのは、優れたプロダクトを持つことと同じくらい、優れた組織を設計する経営者としての意思決定の質にかかっています。