スケーラビリティとは？将来の利用者増にどこまで備えるかの判断基準

開発会社から「スケーラビリティを考慮した構成にしますか」と確認され、構成の違う見積が 2 パターン出てきました。差額は初期費用で数百万円にのぼります。どちらが正しいのか判断できないまま、比較会議の日が近づいています。社内にインフラの専任者はおらず、相談できる相手もいません。そんな状況で検索にたどり着いた方は少なくないはずです。

この問題が難しいのは、知識が足りないからではありません。将来の利用者数は誰にも正確には読めないのに、「どこまで備えるか」という判断だけは今この見積・契約で確定させなければならないという構造そのものに原因があります。多めに備えれば初期費用が膨らんで稟議が通らず、備えを削れば公開後に遅くなって作り直しになるかもしれません。事業側に「将来どれくらい使われますか」と聞いても、具体的な数字は返ってきません。

この板挟みから抜ける方法は、将来を正確に当てることではありません。「後から足せるもの」と「後から変えると作り直しになるもの」を切り分けて、前者は今決めず、後者だけ今決めるという考え方に切り替えることです。この切り分けができれば、見積の差額が何に対する支払いなのかを説明でき、社内にも根拠を持って説明できるようになります。

本記事では、スケーラビリティとは何かという定義から出発し、スケールアップとスケールアウトの見分け方、「クラウドなら後からいくらでも増やせます」という説明がどこまで成り立つのか、そして将来の利用増にどこまで備えるかを決める 4 つの判断軸、最後に決めた方針を見積・RFP にどう書くかまでを、発注側の立場で順に解説します。

—Free Download / 資料ダウンロード

システム開発の費用を正しく理解するガイドブック――相場・見積チェックリスト・予算策定テンプレート付き

この資料でわかること

発注検討者がシステム開発の費用体系を正しく理解し、「この見積は適正か」「どのくらい予算を確保すれば良いか」を自分で判断できるようになること。

こんな方におすすめです

• システム開発の発注を初めて担当する方
• 複数社の見積もりを比較・評価したい方
• IT投資の社内稟議を通す根拠を固めたい方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

スケーラビリティとは？利用が増えても性能を保てる拡張性のこと

スケーラビリティの意味は「拡張性」｜増やせるだけでは足りない

スケーラビリティ（scalability）とは、利用者数・データ量・処理負荷が増えたときに、性能を保ったままシステムを拡張できる度合いを指します。日本語では「拡張性」と訳され、スケーラビリティが高い状態を「スケーラブル」と表現します。

定義を読むときに注意していただきたいのは、ポイントが「増やせること」ではなく「増やしても遅くならないこと」にあるという点です。利用者が 10 倍になったときにサーバーを 10 台に増やせたとしても、処理が詰まって画面表示に 30 秒かかるなら、そのシステムのスケーラビリティは高いとは言えません。逆に、台数を増やすだけで応答速度が元のまま保たれるなら、スケーラビリティが高いシステムです。

クラウド事業者の解説でも、スケーラビリティは「利用者数・データ量・処理負荷の変化にどれだけ柔軟に対応できるか」という観点で定義されています（さくらのクラウド「スケーラビリティとは？」）。発注の打ち合わせで出てくる「スケーラビリティを確保した構成」という言葉も、この「増えても性能が落ちない状態をつくる」という意味で使われています。

なお、増えるときだけでなく減らせることもスケーラビリティの一部です。キャンペーン期間だけアクセスが跳ね上がり、その後は元に戻るようなシステムでは、増やした分を元に戻せるかどうかが運用費用に直結します。

スケーラビリティが高いシステムの例と、低いシステムで起きること

スケーラビリティが高いシステムの典型は、処理を複数のサーバーで分担できる構成です。たとえば Web サーバーを複数台並べて前段で振り分ける構成、負荷に応じて自動的に台数を増減させるクラウドのオートスケール構成、データを複数のサーバーに分散して保持する分散データベースなどが該当します。いずれも「1 台の限界に全体が縛られない」という共通点があります。

反対に、スケーラビリティが低いシステムでは次のようなことが起こります。

• 利用者が増えるにつれて画面表示が目に見えて遅くなり、業務が滞る
• 月末・期末などの繁忙期だけ処理が詰まり、バッチ処理が業務開始時刻までに終わらない
• 1 台のサーバーの性能を上げる以外に打ち手がなく、そのサーバーが上限に達した時点で改修が必要になる
• 利用部署を増やす計画が、システム側の都合で先送りになる

発注側にとって痛いのは、これらが公開直後ではなく、事業が順調に伸びた後に起きることです。利用が増えること自体は喜ばしい状況なのに、そのタイミングで追加予算と改修期間が必要になります。スケーラビリティを発注時点で検討する理由はここにあります。

可用性・性能との違い｜発注時に別々に確認すべき 3 つの観点

打ち合わせの場では、スケーラビリティと「可用性」「性能」が混ざって議論されがちです。この 3 つは関係はしますが別の観点であり、提案書の中でも別々に確認する必要があります。

混同が起きやすいのは、スケーラビリティと可用性が同じ手段で実現されることがあるためです。サーバーを複数台並べる構成は、負荷を分担する（スケーラビリティ）と同時に、1 台が故障しても残りで処理を続けられる（可用性）という 2 つの効果を持ちます。冗長化・信頼性・高可用性といった語の区別はAerospike の高可用性解説などでも整理されていますが、発注側として押さえておくべきなのは、「同じ構成で両方の効果が得られる場合がある」一方で「可用性のために増やした台数が、必ずしも性能向上につながるわけではない」という点です。

たとえば待機系のサーバーを 1 台用意する構成（普段は使わず、故障時に切り替える）は可用性を高めますが、普段の処理能力は 1 台分のままです。「冗長化しているのでスケーラビリティも確保されています」という説明を受けたときは、増やした台数が常時処理に使われるのか、待機なのかを確認してください。

この記事で以降扱うのは 3 つのうち「スケーラビリティ（拡張性）」です。現在の性能目標と、障害時にどこまで止めてよいかは別の検討項目として、要件上も分けて扱うことをおすすめします。

スケーラビリティの2つの拡張方式｜スケールアップとスケールアウトの違い

スケーラビリティを実現する方式は、大きく 2 つに分かれます。発注側として重要なのは、どちらを選ぶかを自分で決めることではなく、出てきた見積がどちらの前提で組まれているかを読み取れることです。これができると、2 パターンの見積の差額が何に対する支払いなのかが見えてきます。

スケールアップ（垂直スケール）の効き方と上限

スケールアップは、1 台のサーバーの性能そのものを上げる方法です。CPU のコア数を増やす、メモリを増設する、より高速なディスクに替える、といった対応がこれに当たります。垂直スケールとも呼ばれます。

長所は、アプリケーションの作りを変えずに効果が出ることです。プログラムの構造に手を入れる必要がなく、クラウドであればサーバーの種別（インスタンスタイプ）を変更するだけで済む場合もあります。既存システムの性能が足りなくなったときの第一手として選ばれやすい方法です。

短所は 2 つあります。1 つは上限があることです。クラウド事業者が提供する最大スペックに達したら、それ以上は上げられません。もう 1 つは切り替えに停止が必要になる場合があることです。サーバーの構成を変更する際に再起動を伴うため、業務時間中には実施できず、夜間や休日の作業になることが一般的です。

費用の増え方にも癖があります。スペックを上げるほど単価が上がる傾向があり、性能 2 倍のために費用が 2 倍を超えることも珍しくありません。

スケールアウト（水平スケール）の効き方と前提条件

スケールアウトは、同じ役割のサーバーを台数で増やし、処理を分担させる方法です。水平スケールとも呼ばれます。増やしたサーバーに処理を振り分ける役割を担うのがロードバランサーで、スケールアウト構成では必須の構成要素になります。

長所は、理論上の上限が高いこと、そして稼働中に台数を増やせることです。既存のサーバーを止めずに新しいサーバーを追加できるため、サービスを止めずに処理能力を上げられます。台数が増えるにつれて費用もほぼ比例して増えるため、費用の見通しが立てやすいという利点もあります。

一方で、スケールアウトにはアプリケーションの作りに対する前提条件があります。代表的なものが「サーバーが利用者ごとの状態を自分の中に持たない」という設計です。たとえばログイン情報やアップロードされた一時ファイルを、処理したサーバーのメモリやディスクに保持する作りになっていると、次のアクセスが別のサーバーに振り分けられた瞬間にログインが切れたり、ファイルが見つからなくなったりします。

この前提を満たすには、状態（セッション情報・アップロードファイル等）をサーバーの外に置く設計が必要です。最初からその前提で作るなら追加費用はほとんど発生しませんが、すでに動いているシステムを後から作り変える場合は、相応の改修になります。見積の差額がここに現れていることは少なくありません。

比較表｜上限・停止の要否・費用の増え方で見分ける

2 つの方式を発注側の判断材料として並べると、次のようになります。

見積を読むときは、「将来利用者が増えたときにどちらの方式で対応する前提か」を開発会社に確認してください。スケールアップ前提なら初期費用は抑えられますが、拡張のたびに停止時間が必要で、いずれ上限に当たります。スケールアウト前提なら初期の設計工数が乗りますが、停止なしで伸ばせます。この違いが分かれば、差額は「性能の値段」ではなく「将来の拡張のしやすさに対する前払い」として評価できます。

なお、ロードバランサーの費用目安や導入の必要性の判断については別の記事で扱っています。本記事では個別手段の費用には踏み込まず、判断軸の整理に集中します。

データベースが先に限界を迎えるのはなぜか

スケールアウトの話で見落とされやすいのが、データベースはアプリケーションサーバーほど簡単に台数を増やせないという点です。

アプリケーションサーバーは、同じプログラムを載せた同じ構成のサーバーを並べれば処理を分担できます。しかしデータベースは「データそのもの」を持っているため、単純に台数を増やすと、どのサーバーのデータが正しいのかという問題が生じます。参照（読み取り）だけなら複製を増やして分担できますが、更新（書き込み）を複数台で分担するには、データの分割方針を事前に設計する必要があります。

結果として、利用が増えていったときアプリケーションサーバーをいくら増やしてもデータベースが詰まって全体が遅くなるという状態が起こります。これはスケーラビリティの検討で最も典型的なボトルネックです。

発注側が確認すべきなのは、技術的な実現方法ではなく次の 2 点です。

• 想定する将来の規模で、データベースはスケールアップだけで足りる見込みか
• 足りない場合、データの持ち方を後から変える必要があるのか、最初から変更しておくのか

後者が重要です。データの持ち方や分割方針は、後から変えると影響範囲が広く、実質的な作り直しになりやすい箇所です。この記事の後半で扱う「可逆な判断と不可逆な判断」の切り分けでも、データベースは不可逆側の代表例として登場します。

クラウドのオートスケールで拡張性を高める方法と、その限界

オートスケールとは｜負荷に応じて増減させる仕組み

オートスケールとは、負荷の状況を監視して、サーバーの台数や性能を自動的に増減させる仕組みです。主要なクラウドサービスが標準機能として提供しており、「CPU 使用率が 70% を超えたら 1 台追加する」「30% を下回ったら 1 台減らす」といったルールを設定して運用します。

オートスケールが発注側にとって意味を持つのは、ピークに合わせて常時高性能な構成を持たなくてよくなる点です。たとえば月末 3 日間だけアクセスが 5 倍になる業務システムで、常時 5 倍の構成を維持すれば残り 27 日分は無駄になります。クラウドの従量課金とオートスケールを組み合わせると、増えた分の費用は増えた期間だけ発生します。

スケーラビリティを高める方法として挙げられる手段（サーバー構成の見直し、キャッシュの導入、処理の非同期化、データベースの参照分散など）のなかで、オートスケールは発注時点の追加費用が比較的小さく、効果が分かりやすい選択肢です。ただし、後述のとおり前提条件があります。

「クラウドだから無限に伸びる」が成り立たない 3 つのケース

「クラウドなので、後からいくらでも増やせます」という説明を受けることがあります。方向としては正しいのですが、無条件には成り立ちません。成り立たないケースは主に次の 3 つです。

1. アプリケーションが状態をサーバー内に持っている場合

先に触れたとおり、ログイン情報や一時ファイルを処理したサーバー自身が保持する作りだと、台数を増やしても正しく動きません。クラウドの機能としては台数を増やせても、アプリケーションが対応していなければ効果が出ないか、不具合が出ます。これはクラウド側ではなくアプリケーションの設計の問題であり、後から直すには改修が必要です。

2. データベース・外部連携・ライセンスが先に限界に達する場合

アプリケーションサーバーを増やしても、データベースが詰まれば全体が遅くなります。同様に、外部サービスの API（決済・地図・メール配信など）には呼び出し回数の上限が設定されていることがあり、自社側をいくら増やしても上限は超えられません。商用ソフトウェアを使っている場合、ライセンスがサーバー台数やコア数に連動していて、台数を増やすとライセンス費用が跳ね上がることもあります。

3. 増えるのが性能だけでなく月額費用でもある場合

オートスケールは「増やせる」仕組みですが、増えた分は請求されます。想定どおりに利用が伸びた場合はよいのですが、設定を誤って不要に台数が増え続けたり、想定外のアクセス（クローラーや攻撃を含む）で増えたりすると、月額費用が予算を超えます。上限台数の設定と費用の監視・アラートを運用に含めておく必要があります。

この 3 つを押さえると、「クラウドなら大丈夫」という安心材料がどの条件下で成立するのかが分かります。条件が満たせているなら、今は小さく作って後から増やすという判断を根拠を持って選べます。逆に条件が満たせていないなら、そこは後回しにできない箇所です。

開発会社に確認しておきたい質問

打ち合わせでそのまま使える形にしたものが次の 4 問です。いずれも技術的な正解を求める質問ではなく、前提条件が満たされているかを確認する質問です。

1. 「利用者が 3 倍に増えたとき、何を増やすことで性能を保つ想定ですか。サーバー台数ですか、1 台のスペックですか」
2. 「アプリケーションはサーバーを増やすだけで処理を分担できる作りになっていますか。それとも改修が必要ですか」
3. 「データベースは想定規模まで現在の構成で足りますか。足りなくなった場合、何を変える必要がありますか」
4. 「オートスケールを使う場合、上限台数と月額費用の上限はどう設定しますか」

回答を聞くときは、「できます」「可能です」ではなく「何を変えればできるのか」「そのときの費用と期間はどれくらいか」まで確認してください。この回答が、次に説明する判断軸の材料になります。

将来の利用増にどこまで備えるか｜発注時に決める4つの判断軸

ここからが本題です。将来の利用者数は読めませんが、「どこまで備えるか」は 4 つの軸を順に当てはめることで決められます。スケーラビリティは機能要件と非機能要件の違いで言えば非機能要件に属する項目で、機能のように「あるかないか」ではなく「どの程度か」を決める性質のものです。だからこそ、判断の軸が必要になります。

判断軸1 成長シナリオ｜ピーク同時利用者数を3ケースで置く

最初に置くべき数字は、ピーク時の同時利用者数です。累計の登録者数や月間の利用者数ではなく、「同時に使っている人が最も多い瞬間の人数」が、システムの構成を左右します。

これを 1 つの数字で当てようとすると止まってしまうので、3 ケースで置くことをおすすめします。

重要なのは、上振れケースは「構成を決めるための数字」ではなく「確認するための数字」として使うことです。上振れを基準に構成を決めると、次に説明する過剰投資になります。上振れケースは「そのときに何を変えればよいか」を開発会社に確認するためのシナリオとして扱ってください。

事業側が数字を出してくれない場合は、次のような既にある情報から逆算できます。

• 対象業務に関わる社員数・部署人数（全社展開時の上限が決まる）
• 既存システムの最大同時ログイン数（過去のログから取得できる場合が多い）
• 現在の業務量（1日あたりの処理件数・伝票枚数・問い合わせ件数など）
• 顧客向けサービスなら、既存の顧客数と利用率の想定

「正確な予測」ではなく「置いた前提」として明示することがポイントです。前提が明示されていれば、後から数字が変わったときに「どの前提が変わったから構成を見直すのか」を説明できます。前提を書かずに合意すると、利用が増えたときに誰の想定外だったのかが決まりません。

判断軸2 遅延・停止の許容度｜誰がどれだけ困るか

同じ「遅くなる」でも、困り方はシステムによってまったく違います。備える強度は、遅延や停止が起きたときに誰がどれだけ困るかで変わります。

次のように整理してみてください。

ここで判断の材料になるのは「許容できる時間」です。「ピーク時に 3 秒以内」「月末処理は翌朝 8 時までに完了」といった形で、誰が何分困るかを時間で表現すると、開発会社と合意しやすくなります。「できるだけ速く」は要件になりません。

また、遅延の影響が大きいシステムでは「遅くなったときに気づける仕組み」（監視とアラート）も併せて検討してください。拡張できる構成にしていても、遅くなっていることに気づかなければ拡張の判断ができません。

判断軸3 後から変えられるか｜可逆な判断と不可逆な判断を分ける

この軸が、過剰投資と手戻りの板挟みから抜ける鍵になります。スケーラビリティに関わる判断は、後から足せるもの（可逆）と後から変えると作り直しに近くなるもの（不可逆）に分かれます。

可逆な判断は、必要になってから実施すれば十分です。サーバーを 2 台から 4 台にする作業は、必要になった時点で数時間から数日で実施できることが多く、そのときに費用を払えば済みます。先に払う理由がありません。

一方で不可逆な判断は、後から変えるとデータの移行作業が発生したり、アプリケーション全体に手を入れることになったりします。特に外部連携の同期／非同期は見落とされやすい箇所です。外部サービスの応答を待ってから処理を進める作り（同期）にしていると、利用が増えたときに外部サービスの遅さがそのまま自社システムの遅さになります。これを後から非同期（いったん受け付けて、後で処理する）に変えるのは、画面の挙動やデータの整合性の扱いを含めた設計変更になります。

したがって、発注時の方針は次の一文に集約できます。

今は小さく作り、不可逆な箇所だけ将来を織り込んでおく。

これが「過剰投資か手戻りか」の二択を崩す第三の選び方です。開発会社への確認も「スケーラビリティを確保してください」ではなく、「標準ケースの規模に達したとき、作り直しが必要になる箇所はどこですか」という形にすると、不可逆な箇所が特定できます。

判断軸4 初期費用と月額費用のどちらが増えるのか

最後の軸は費用の性質です。見積の差額が初期費用に乗っているのか、月額費用に乗っているのかで、判断の性質が変わります。

• 初期費用に乗っている場合: 一度払えば戻ってきません。伸びなかった場合は投資が無駄になります。だからこそ、初期費用の差額は「不可逆な箇所への投資かどうか」で判断してください。不可逆な箇所に備えるための設計費用なら払う価値があり、可逆な箇所（台数など）を先に増やすための費用なら後回しにできます。
• 月額費用に乗っている場合: 伸びなければ止められます。たとえば「ロードバランサーと 2 台構成にすると月額が上がる」という差額は、利用が想定どおり伸びなかった場合に構成を縮小すれば支出を止められます。判断の重さは初期費用より軽いと考えてよいでしょう。

見積比較の場では、総額ではなく初期費用の差額・月額費用の差額をそれぞれ出してもらうことをおすすめします。そのうえで初期費用の差額について「これは何に対する費用か」を聞き、不可逆な箇所への設計投資なのか、可逆な箇所の先払いなのかを切り分けてください。

4軸チェック表｜「今決めること」と「後回しにすること」の仕分け

4 つの軸を 1 枚にまとめると次のようになります。見積比較の会議資料にそのまま転記できる形にしています。

この表が埋まれば、「どこまで備えるか」は決まったことになります。残っているのは、決めた内容を発注文書に落とす作業です。

—Free Download / 資料ダウンロード

システム開発の費用を正しく理解するガイドブック――相場・見積チェックリスト・予算策定テンプレート付き

この資料でわかること

発注検討者がシステム開発の費用体系を正しく理解し、「この見積は適正か」「どのくらい予算を確保すれば良いか」を自分で判断できるようになること。

こんな方におすすめです

• システム開発の発注を初めて担当する方
• 複数社の見積もりを比較・評価したい方
• IT投資の社内稟議を通す根拠を固めたい方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

スケーラビリティを非機能要件として見積・RFPに書く方法

非機能要件のどこに書くか｜「性能・拡張性」の位置づけ

スケーラビリティは非機能要件の一部として扱われます。IPA（情報処理推進機構）が公開している「非機能要求グレード」では、非機能要求が 6 つの大項目（可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジー）に整理されており、拡張性は「性能・拡張性」の中に位置づけられています（IPA「システム構築の上流工程強化（非機能要求グレード）」）。

このうち拡張性に直接対応するのが「B.3 リソース拡張性」という中項目で、CPU 拡張性・メモリ拡張性・ディスク拡張性・ネットワーク・サーバ処理能力増強といった小項目に分かれています。各項目は「現在の利用率」と「どこまで拡張できる余地があるか」の 2 つの観点で、レベルを段階的に定義する作りになっています（NTT DATA Tech「非機能要求グレードの歩き方 Vol.3 オンライン編-B3リソース拡張性」）。

ただし、この粒度は要件定義を担当する開発側・インフラ担当者向けのものです。発注側が最初からこの項目をすべて埋める必要はありません。発注側が担うべきなのは、「どこまで拡張できる必要があるか」の前提となる数値を提示することです。CPU 利用率を何%に抑えるか、ディスクを何倍まで増やせるようにするかといった設計判断は、提示した数値をもとに開発側が決める領域です。

発注側が数値で書くべき5項目

発注側が実際に書ける粒度に絞ると、次の 5 項目になります。先に作成した 4 軸チェック表の内容を、そのまま項目に対応させられます。

5 番目の「拡張に許容できる所要時間」は見落とされやすいものの、構成を大きく左右する項目です。「数日かかってよい」のであればスケールアップでの対応が選択肢に入り、初期費用を抑えられます。「数分以内に自動で対応してほしい」のであればオートスケール前提の構成が必要になり、設計工数が乗ります。この 1 項目で見積が変わるため、必ず明記してください。

なお、発注側が数値を提示することには実務上の意味があります。発注者向けの解説でも、最初からデータ量や利用者数の増加を示していれば、性能が出なかった場合の責任の所在が変わる点が指摘されています（発注ラウンジ「機能要件とは？システムの品質向上にかかわる非機能要件との違い」）。「普通に使える程度で」と口頭で合意した場合、遅くなったときに何が約束されていたのかを示す材料がありません。数値で書くことは、開発会社を縛るためではなく、双方が同じ前提を共有するための作業です。

RFP・要件定義書への記載例

記載例を示します。業務システムを想定した書き方です。

性能・拡張性に関する要件（拡張性）

1. 想定ピーク同時利用者数は、稼働開始時 50 名、1 年後 150 名、3 年後 300 名とする。この数値は対象部署 420 名のうち利用率 70% を上限として算出した想定値であり、確定値ではない。
2. 利用者数の年間増加率は 40% を想定する。
3. 保持データは年間約 50GB 増加し、保存期間は 5 年間（計 250GB）とする。
4. 月末 3 営業日は平常時の 4 倍のアクセスを想定する。
5. 性能不足が判明した場合、5 営業日以内にリソース増強が可能な構成とすること。
6. 上記 3 年後の規模に達した場合に、アプリケーションまたはデータ構造の変更が必要となる箇所がある場合は、提案時に明記すること。
7. 稼働開始時点では上記 1 の稼働開始時規模に対応する構成とし、増強は段階的に行う方針とする。

6 番目と 7 番目が、判断軸 3（可逆／不可逆）と判断軸 4（費用）を文書化した部分です。6 番目があると、提案の段階で不可逆な箇所が洗い出されます。7 番目があると、「初期から最大構成を組む提案」と「段階的に増強する提案」が混在して比較できなくなる事態を避けられます。

数値が確定していない場合は、上の例のように想定値であることと算出の根拠を併記してください。確定値として書いてしまうと、後から前提が変わったときに契約上の扱いが曖昧になります。

見積比較時に確認する項目

提案と見積が出てきたら、次の項目を揃えて比較します。

• 拡張方式: 将来の増強はスケールアップ前提か、スケールアウト前提か
• 稼働開始時の構成が対応する規模: 何名の同時利用までを想定した構成か
• 標準ケース到達時に必要な追加作業: 台数追加だけか、改修を含むか
• 不可逆な箇所の有無: 3 年後規模で作り直しが必要になる箇所として何が挙げられているか
• 増強にかかる所要時間と停止時間: 稼働中に実施できるか、停止が必要か
• 初期費用の差額の内訳: 設計費用か、機器・ライセンスの先行購入か
• 月額費用の差額と縮小可能性: 伸びなかった場合に下げられるか
• 性能の確認方法: 稼働前に負荷をかけて確認するのか、しないのか

最後の項目は、次に説明する失敗パターンに直結します。構成の話だけで合意すると、見積に性能確認の工数が含まれているかどうかが曖昧になりがちです。

スケーラビリティ要件でよくある3つの失敗

ここまでの判断軸を飛ばすと、具体的にどうなるのでしょうか。発注側が実際に陥りやすい型を 3 つに絞って整理します。

要件を数値にせず「普通に使える程度」で合意する

最も多いのが、拡張性について何も書かずに契約してしまうケースです。打ち合わせでは「問題なく使えるようにしてください」「将来は全社展開も考えています」といった会話が交わされますが、文書には何も残りません。

このとき何が起きるかというと、公開後に遅くなったときに、誰の想定外だったのかが決まらないという状態になります。開発会社は「ご提示の要件にはなかった規模です」と言い、発注側は「将来展開する話はしていました」と言います。どちらも嘘ではないため、追加費用の負担について合意形成に時間がかかります。

これは判断軸1（成長シナリオ）を飛ばしたことで起きる失敗です。回避策は、数値を当てることではなく、保守・標準・上振れの 3 ケースを前提として明示し、「標準ケースを前提に構成を組む」と文書に書くことです。前提が書かれていれば、前提が変わったときの扱いも議論できます。

上振れケースだけで構成を決めて初期費用が膨らむ

逆の失敗もあります。「将来 10 倍になるかもしれない」という話から出発して、最初から大規模構成の見積を作ってしまうケースです。

この場合、2 つの形で損失が出ます。1 つは、初期費用が膨らんで稟議が通らず、プロジェクト自体が止まることです。もう 1 つは、通ったものの利用が想定どおり伸びず、使われない性能に初期費用を払った状態になることです。初期費用は戻ってこないため、後者は取り返せません。

これは判断軸3（可逆／不可逆）と判断軸4（費用の性質）を飛ばしたことで起きる失敗です。回避策は、上振れケースを「構成を決める数字」ではなく「そのとき何を変える必要があるかを確認する数字」として使うことです。そして初期費用の差額について、不可逆な箇所への設計投資なのか、可逆な箇所の先払いなのかを必ず切り分けてください。先払いであれば後回しにできます。

拡張できる構成にしたが検証していない

3 つ目は、構成の話だけで終わってしまうケースです。「スケールアウトできる構成にしました」という提案を受け入れ、実際に増やしたときに性能が伸びるかどうかは確認しないまま本番を迎えます。

拡張できる構成になっていても、想定どおり性能が伸びるとは限りません。データベースが先に詰まる、外部 API の上限に当たる、設定値が意図どおりになっていない、といった理由で、台数を増やしても効果が出ないことがあります。そしてこれらは本番で負荷がかかった瞬間に初めて分かります。

これを避ける手段が負荷テストです。想定するピーク負荷をかけて、応答時間が要件を満たすか、台数を増やしたときに性能が伸びるかを稼働前に確認します。発注側として確認すべきなのは次の 3 点です。

• 見積に負荷テストの工数が含まれているか
• どの規模（同時利用者数）で、どの画面・処理を対象に実施するか
• 要件を満たさなかった場合、誰がどう対応するか

これは判断軸2（許容度）で定めた時間が実際に守られるかを確認しないことで起きる失敗です。「ピーク時 3 秒以内」と要件に書いたのであれば、それを確認する工程まで含めて合意してください。

まとめ｜今決めることと、後から決めてよいこと

スケーラビリティとは、利用者数・データ量・処理負荷が増えたときに、性能を保ったまま拡張できる度合いです。「増やせること」ではなく「増やしても遅くならないこと」が要点であり、可用性（止まらないこと）や現在の性能（速いこと）とは別の観点として、提案書でも分けて確認する必要があります。

将来の利用増にどこまで備えるかは、4 つの判断軸で決められます。ピーク同時利用者数を保守・標準・上振れの 3 ケースで置き（成長シナリオ）、遅延・停止で誰がどれだけ困るかを時間で表現し（許容度）、後から足せる箇所と後から変えると作り直しになる箇所を切り分け（可逆／不可逆）、差額が初期費用か月額費用かで判断の重さを変えます（費用の性質）。この 4 つを埋めれば、「どこまで備えるか」は決まります。

そして結論は 1 文で表せます。今は小さく作り、不可逆な箇所だけ将来を織り込んでおく。 サーバー台数やオートスケールの設定値は必要になってから足せる可逆な判断であり、先に払う理由はありません。一方でデータの持ち方、状態をどこに置くか、外部連携を同期前提にするかどうかは、後から変えると作り直しに近くなる不可逆な判断です。ここにだけ今の検討時間と予算を使ってください。

次に取る行動は 3 ステップです。

1. 成長シナリオを 3 ケース置く: ピーク同時利用者数を保守・標準・上振れで書き出し、算出の根拠（対象部署の人数・既存システムのログ・現在の業務量）も併記する
2. 不可逆な箇所を開発会社に確認する: 「標準ケースの規模に達したとき、作り直しが必要になる箇所はどこですか」と質問し、挙がった箇所だけを今の検討対象にする
3. 5 項目を要件に書く: ピーク同時利用者数、年間増加率、保持データ量と保存期間、ピーク倍率、拡張に許容できる所要時間を、想定値であることと根拠を添えて文書化する

この 3 ステップが済めば、見積の差額が何に対する支払いなのかを自分の言葉で説明できる状態になります。判断を文書に残しておけば、前提が変わったときにも「どの前提が変わったから構成を見直すのか」という形で議論を進められます。

関連情報

システム開発の発注・要件定義の進め方をまとめたお役立ち資料をご用意しています。要件の整理や発注前の確認事項を体系的に押さえたい方は、お役立ち資料の一覧をご覧ください。

拡張性をどこまで要件に織り込むべきか判断に迷われている場合は、お問い合わせフォームからご相談いただけます。要件の整理段階からのご相談も承っています。

—Free Download / 資料ダウンロード

システム開発の費用を正しく理解するガイドブック――相場・見積チェックリスト・予算策定テンプレート付き

この資料でわかること

発注検討者がシステム開発の費用体系を正しく理解し、「この見積は適正か」「どのくらい予算を確保すれば良いか」を自分で判断できるようになること。

こんな方におすすめです

• システム開発の発注を初めて担当する方
• 複数社の見積もりを比較・評価したい方
• IT投資の社内稟議を通す根拠を固めたい方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。