「初日から完璧なスケーラビリティ」という指示にどう向き合うか

状況

新規プロジェクトのキックオフミーティングで、非エンジニアの事業責任者からこう言われることがあります。

「このサービス、将来100万人使うかもしれないので、最初から完璧にスケールする設計にしておいてください」

悪意はまったくなく、むしろ事業への期待と野心の表れです。将来の成功を見据えているからこその発言であり、担当者としては「将来困らないようにしてほしい」という誠実な願いを言っているだけです。

しかし、エンジニアの立場からすると、これは危険な指示でもあります。「完璧なスケーラビリティ」を初日から設計しようとすると、まだ誰も使っていないサービスのために、存在しない負荷を想定した複雑なアーキテクチャ（マイクロサービス分割、分散キャッシュ、マルチリージョン構成など）を組むことになりがちです。結果として、リリースが半年遅れ、肝心の「ユーザーに使われるかどうか」を確かめる前に予算と時間を使い果たす、というのはよくある失敗パターンです。

ここで「それは無理です」「オーバーエンジニアリングです」とだけ返すと、相手には「このエンジニアは慎重すぎる」「成長を軽視している」というメッセージとして伝わってしまいます。必要なのは、相手の意図（将来への不安）を認めつつ、現実的な進め方に翻訳することです。

たとえ

これは「開店前のラーメン屋」に似ています。

まだ1杯も売れていない新しいラーメン屋を開くときに、「将棋、いつか1日1000人来るかもしれないから、最初から1000人分の厨房設備と、1000人が並べる待合スペースを作っておこう」と考える店主はいません。

もしそうしたら、開店資金のほとんどを「まだ来ていない1000人」のための設備に使ってしまい、肝心の「今日来る10人のお客さんに美味しいラーメンを出す」ための準備ができなくなります。しかも、1000人来る店の厨房レイアウトは、10人向けの厨房とは全く違う形になるため、実際に1000人来るようになった頃には、最初に作った設備は使い物にならず、結局作り直すことになるかもしれません。

実際の優れた店主がやることは逆です。まずは小さい厨房で美味しい一杯を出すことに全力を注ぎ、お客さんが増えてきたら「2台目のコンロを増やす」「隣の店舗を借りて席を増やす」というように、実際の行列の長さに合わせて段階的に拡張していきます。重要なのは、最初の設計が「後から拡張できる構造になっているか」という点であり、「最初から1000人分の設備があるか」ではありません。

スケーラビリティも同じで、「将来大きくなれる余地を残した作り」にすることと、「今から巨大な負荷に対応する作り」にすることは、似ているようで全く別の話です。

提案の型

1. 受け取り（意図を認める）

「将来ユーザーが増えたときに困らないようにしたい、というご心配はまさにその通りだと思います。サービスが伸び悩んで困るより、嬉しい悲鳴で困りたいですよね」

ここで相手の不安や期待を否定しないことが重要です。相手は「スケーラビリティ」という技術用語を使っていますが、本音は「将来の成功を潰したくない」という事業的な懸念です。

2. たとえ（翻訳する）

「これは新しいラーメン屋の開店準備に似ています。まだ1杯も売れていないうちから1000人分の厨房を用意すると、今日の10人のお客さんへの対応が後回しになってしまいます。それに、実際に行列ができる頃には、お客さんの動き方（注文の仕方、滞在時間など）が想定と違っていて、最初に作った1000人用の設備がそのまま使えないことも多いんです」

3. 言い換え（技術的な論点に翻訳する）

「なので目指すべきは『最初から1000人に対応できる設計』ではなく、『今はシンプルに作りつつ、必要になったときにスムーズに拡張できる作り』だと考えています。具体的には、データベースやサーバーを後から分割・増強しやすい構成にしておく、というアプローチです」

4. 段階案（実行可能な代替案を示す）

「進め方としては、こういう段階を考えています。

• 第1段階（リリース時）: シンプルな構成で、まずユーザーに使ってもらえる状態を最速で作る
• 第2段階（初期の成長期）: 実際のアクセス状況・使われ方のデータを見ながら、ボトルネックになっている部分だけを強化する
• 第3段階（本格的なスケール期）: 実際に『1000人規模が見えてきた』段階で、その負荷特性に合わせた本格的な分散構成に作り直す

こうすることで、『今日のお客さん』への対応を後回しにせず、かつ将来の拡張にも備えられます」

ミーティングで使える一文

「最初から1000人分の厨房を作るより、まず美味しい一杯を10人に出せる形にして、行列ができ始めたらコンロを増やす形で進めませんか。どちらも『将来の成功に備える』という目的は同じです」

例外（このたとえを使わない／肯定すべきケース）

このたとえが当てはまらない、むしろ最初から高いスケーラビリティを検討すべきケースもあります。

• バイラル施策や大規模広告出稿など、アクセス急増のタイミングが事前に確定している場合：「開店日にテレビで紹介される」と分かっているなら、最初から相応の厨房を用意すべきです。これは推測ではなく確定した前提なので、段階的拡張の議論自体が不要になります。
• 後からの拡張がほぼ不可能な領域（データの永続化方式、認証の基盤、APIの外部公開仕様など）：厨房の広さは後から変えられますが、「お店の立地」や「メニューの根本的な提供方式」は後から変えにくいものです。同様に、データ設計や外部契約など、後戻りのコストが極端に高い部分については、最初にある程度の余裕を持たせておくべきです。
• 既にPMFしており、成長曲線が明確に見えている場合：ゼロから始めるラーメン屋ではなく、すでに繁盛している2号店を出す状況では、1号店のデータに基づいて最初から相応の規模で設計するのは合理的です。

こうした場合は「段階的に進めましょう」ではなく、「その前提なら、最初から備えるべき部分ですね。どの部分を手厚くするか整理しましょう」と肯定的に受け止めるべきです。

まとめ表