← エピソード一覧に戻る Episode 174 Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
0:00 / 0:00
スクリプト
Chapter 1 オープニング ― 売れる瞬間に壊れないための余白
タカシ
皆さんこんにちは、タカシです。今日は SaaS 開発のアーキテクチャランウェイを取り上げます。分かりやすく言うと、次の成長で必要になる機能や負荷増に対して、大改修なしで走れるよう先回りで敷いておく技術の滑走路ですね。
ミカ
ミカです。ランウェイって資金繰りの話でよく聞きますけど、開発にもあるんですね。つまり、今の商談は取れても、次の大口顧客や急な利用増に耐える余白がなければ、売れた瞬間に詰まる、みたいな話ですか。
タカシ
その理解で合っています。前回の技術的負債が『過去の近道のツケ』なら、今回は『未来の成長のためにどこまで先回りするか』です。SaaS では、機能を作る力だけでなく、増える顧客を同じ基盤で安全にさばけるかが経営力になります。
ミカ
なるほど。備えが足りないと苦しいのは分かるんですけど、逆に先回りしすぎると過剰設計にもなりそうです。今日は、そのちょうどいい線引きを経営者目線でつかみたいです。
Chapter 2 原則 ― ランウェイは大設計ではなく近い将来への備え
タカシ
Scaled Agile は、アーキテクチャランウェイを『近い将来の機能を、過度な再設計や遅延なしに実装するための既存コードや技術基盤』と定義しています。全部を先に決めることではなく、次の数四半期を詰まらせない最低限の準備なんです。
ミカ
つまり『いつか世界一になる前提の豪華な設計』ではなくて、『次の商談や次の負荷に耐えるための現実的な余白』なんですね。場当たり実装も危ないけど、夢のアーキテクチャを作り込むのも違うと。
タカシ
まさにそこです。SAFe も、場当たりの emergent design だけでは標準不在、属人化、セキュリティや安定性の問題が起きると指摘しています。一方で BDUF、つまり大規模な先回り設計にも寄りすぎない。このバランスが runway の本質です。
ミカ
SaaS だと、その余白ってサーバー台数の話だけじゃなさそうですね。顧客ごとの負荷差、オンボーディング、課金、運用の見え方まで揃っていないと、増えた瞬間に人手が爆発しそうです。
タカシ
その通りです。AWS は SaaS を技術実装ではなく事業戦略だと整理しています。だから runway は DB やキューだけでなく、共通のオンボーディング、テナント単位のメトリクス、同じバージョンを一斉運用できる control plane まで含めて考える必要があります。
Chapter 3 具体例 ― Shopify、Slack、GitLabがどう先回りしたか
ミカ
この話、理屈では分かるんですけど、実際に強い SaaS 企業はどんな runway を敷いてきたんでしょう。『先に備える』が、どのくらい具体的な意思決定なのか知りたいです。
タカシ
まず Shopify です。2015 年には、より大きい DB サーバーを買い続けるやり方が限界に達し、シャーディングへ進みました。その後は podded architecture へ広げ、リクエストやジョブを shop 単位で分け、ある pod の障害が他へ波及しにくい構造を整えています。
ミカ
でも Shopify って、いきなり全部を細かいサービスに分けたわけじゃないんですよね。『モノリスを水平スケールするのが当時の負荷への最速解だった』とも言っていて、そこが現実的で面白いです。
タカシ
そうなんです。runway は複雑化そのものではありません。次に効く制約へ最短で効く設計を選ぶことです。Shopify は『今の成長には monolith の水平分割が最も速い』と判断し、その後に必要な分だけ pod や境界を厚くしていったわけです。
タカシ
Slack も分かりやすいです。Vitess 導入を進め、2020 年時点で 99 パーセント採用、2.3 million QPS を処理する状態まで持っていきました。そして 2020 年 3 月、わずか 1 週間でクエリレートが 50 パーセント増えたとき、resharding で busiest keyspace を水平拡張できました。
ミカ
1 週間で 50 パーセント増は、かなり怖いですね。もし負荷が来てから設計を考え始めていたら、大口顧客ほど先に落としていたかもしれない。runway って、売上チャンスを取り切るための保険でもあるんですね。
タカシ
GitLab も同じです。2022 年に単一 PostgreSQL を `main` と `ci` に分割し、DB 容量が roughly 2x 伸びる見込みを示しました。しかも大事なのは、複数 DB 向け migration や loose foreign keys などの道具を先に整え、開発速度を落とさないようにしたことです。
ミカ
基盤刷新だけで満足しないのが大事なんですね。分けたはいいけど、開発チームが毎回つまずくなら、それは runway じゃなくて新しい渋滞ですもんね。
Chapter 4 失敗パターン ― 早すぎる複雑化と、遅すぎる計測
ミカ
逆に、アーキテクチャランウェイで失敗しやすい会社には、どんな共通点があるんでしょう。創業期だと『先回りしないと不安』と『まだ早い』が混ざって、判断がぶれやすそうです。
タカシ
典型例は四つあります。将来不安だけで分散化に走る、データ面だけ拡張して運用面を後回しにする、変更を支えるツールなしに基盤だけ刷新する、そして runway の不足を事故が起きるまで測らない。この四つです。
ミカ
特に二つ目は SaaS っぽいですね。専用環境を作れば安心に見えるけど、オンボーディングや監視や課金が個別運用のままだと、受注のたびに人が増える。売上が増えるほど粗利が落ちる構造になりそうです。
タカシ
AWS も、分離スタック型の SaaS でも全顧客を同じバージョン、同じ onboarding、同じ運用体験で扱うことが重要だと述べています。つまり data plane を分けても、control plane は一つで回る形を崩すべきではないんです。
ミカ
あと、計測なしも危険ですね。『まだ落ちてないから大丈夫』で判断していると、季節要因や大型顧客の利用開始みたいな一発で詰まる。これは経営判断というより、ほぼ祈りに近いです。
タカシ
その通りです。AWS も、今の段階に合うスケーリング方式を選び、メトリクスで有効性を検証し続けろと述べています。見るべきは CPU だけではなく、テナント別 p95、DB 接続余力、デプロイ時間、環境追加日数など、事業成長に直結する指標ですね。
Chapter 5 クロージング ― 次の制約を一段早く外す
ミカ
今日の話を聞くと、アーキテクチャランウェイって『未来のための贅沢』じゃなくて、『次の受注と次の改善速度を守る現実的な投資』なんですね。備えすぎず、でも詰まる直前まで放置もしない、と。
タカシ
はい。経営者が明日からできることは三つです。次の 6 から 12 カ月で起こる成長イベントを書き出すこと、アーキテクチャ判断ごとに『まだ早い条件』と『着手トリガー』を置くこと、そして基盤投資には必ず移行ツールや観測基盤をセットで付けることです。
ミカ
滑走路って、長ければいいわけじゃなくて、次の離陸に足りる長さを見誤らないことなんですね。皆さんの SaaS でも、次の大型案件や負荷増を止める制約がどこか、ぜひ一度棚卸ししてみてください。今回もありがとうございました。