新規事業のシステムの拡張性｜利用者増への備えはどこまで

新規事業のシステムを作るとき、「利用者が増えても耐えられるように、最初から作っておくべきか」という迷いは、多くの会社に共通しています。この記事では、新規事業のシステムの拡張性について、最初に考えておきたい部分と、事業の手応えを見てからでも間に合う部分の分け方を整理します。備えすぎも備えなさすぎも失敗につながるため、その中間をどう判断するかを具体的に見ていきます。

「拡張性」という言葉が指す3つのこと

「拡張性」は便利な言葉ですが、人によって指しているものが違います。開発会社との会話や社内の議論で食い違いが出やすいので、先に整理しておきます。

1. 負荷への強さ（利用者やデータが増えても動くか）

いちばん一般的な意味です。同時にアクセスする人が増えたり、蓄積されるデータが膨らんだりしても、画面の表示が遅くならず、止まらずに動き続けられるかという観点です。技術の世界ではスケーラビリティと呼ばれることもあります。

対応の方法には大きく2通りあります。1台のサーバーの性能を上げる方法（スケールアップ）と、サーバーの台数を増やして分担させる方法（スケールアウト）です。どちらを選ぶかで、システムの作り方に求められる条件が変わります。

2. 機能の足しやすさ（新しい機能を追加できるか）

事業を進めると、最初は想定していなかった機能が必要になります。料金プランの追加、新しい種類の利用者向けの画面、他のサービスとの連携などです。こうした追加を、既存の部分を壊さずに行えるかどうかが、機能面の拡張性です。

3. 事業の広がりへの対応（地域・商品・組織の拡大に耐えるか）

対象地域の拡大、取り扱う商品の種類の増加、利用する会社や部門の増加といった、事業そのものの広がりに構造が耐えられるかという観点です。たとえば、最初は1つの会社だけが使う想定だったものを、複数の会社が互いのデータを見られない形で使うように変えたい、といったケースです。

この3つは、備えにかかる手間も、後から変えるときの難しさも異なります。「拡張性を考える」と言うときは、どれのことかをまず言葉にしておくと、話が噛み合いやすくなります。

最初から作り込みすぎると起きること

利用者が急に増えて、システムが止まって機会を逃す。この不安から、最初から大規模な利用を前提に設計したくなるのは自然なことです。ただし、新規事業では、最初から備えすぎることにも次のようなリスクがあります。

事業の仮説が確かめられる前に、作る範囲が膨らむ

新規事業の初期段階で最も重要なのは、「この事業は求められているのか」「利用者は想定通りの使い方をするのか」を確かめることです。大規模な利用を前提にすると、構成が複雑になり、開発に時間がかかります。その間、仮説を確かめる機会が後ろにずれていきます。

想定した「増え方」が外れることが多い

事業が育つ方向は、始める前の想定とずれることがあります。利用者の数が増える前に、使われる機能が変わったり、対象とする顧客が変わったりします。備えを想定したのと違う方向に事業が進むと、その備えは使われないまま、システムの複雑さだけが残ります。

構成が複雑になると、変更の速度が落ちる

構成の部品が多いほど、1つの変更に必要な確認と作業が増えます。新規事業では、検証の結果を受けて素早く作り変えられることが強みになります。早い段階で重い構成にすると、この機動力が下がります。

機能の絞り込みについては、MVP開発の機能の絞り方｜最初に作るものと後回しの基準でも整理しています。拡張性の備えも、機能と同じく「最初に作るもの」と「後回しにするもの」に分けて考える対象です。

一方で、備えが少なすぎる場合にも問題があります。次の章で、後から変えにくい部分を見ていきます。

最初に決めておきたい「後から変えにくい部分」

拡張性の備えは、すべてを同じ重さで考える必要はありません。基準にしたいのは、「後から変えるときの大変さ」です。サーバーの台数のように設定で変えられるものは後回しにでき、データの持ち方のように作り直しに近い手間がかかるものは早めに考えておくほうが安全です。

データの持ち方

最も変えにくいのが、データの構造です。システムが動き始めると、利用者の登録情報や取引の履歴などが日々蓄積されます。後から構造を変えるには、すでに入っているデータを新しい形に移し替える作業（データ移行）が必要になり、間違いが許されない分、手間も大きくなります。

最初に考えておきたい点には、たとえば次のようなものがあります。

• 「利用者」「会社」「商品」「注文」など、事業の主役になる情報を、別々のものとして分けて持っているか
• 1人の利用者が複数の会社に所属する、1つの注文に複数の商品が含まれるなど、「1対多」の関係を想定した持ち方になっているか
• 日付や時刻、金額の扱い（タイムゾーン、通貨、税率の変更など）が、将来の変更を受け入れられる形か

詳しくは新規事業のデータ設計｜最初に決めたい5つの持ち方にまとめています。AIを使った設計でどこまで任せられるかは、AI設計でDB設計はどこまで任せる？役割分担の考え方も参考になります。

利用者の区別と権限の考え方

誰がどの情報を見られるか、誰が何を操作できるかという仕組みも、後から変えにくい部分です。最初は「管理者」と「一般の利用者」の2種類だけでも、事業が進むと「会社ごとの管理者」「閲覧だけできる担当者」など、種類が増えるのはよくあることです。

役割を増やせる形で作っておくか、最初から2種類だけを前提に作るかで、後からの手間は大きく変わります。複数の会社が利用する可能性があるなら、「会社ごとにデータを分ける」考え方を最初から入れておくかどうかも、この段階で決めておきたい点です。

外部サービスとの接続の切り分け

決済、メール配信、本人確認、地図、外部のデータ取得など、外部のサービスを使う部分は、システムの本体と切り離して作っておくと、後から入れ替えやすくなります。使うサービスを変えたくなったとき、本体の中に直接組み込んであると、広い範囲を直す必要が出てきます。

決済のように自作と外部利用の選択が大きい領域については、新規事業の決済システム開発｜外部サービスと自作の分け方で整理しています。

個人情報などの扱い方

個人情報や、取り扱いに規制のある情報を扱う事業では、情報の保管場所やアクセスの記録の残し方を、後から追加するのが難しい場合があります。設計の前に確認しておく点は、新規事業の個人情報とシステム設計｜設計前に確認する点で触れています。

設計の考え方の記録

意外に見落とされるのが、「なぜこの作りにしたのか」の記録です。担当者が変わったり、開発会社を変えたりしたときに、構造の意図が分からないと、拡張のたびに調査から始めることになります。設計書の残し方はAI設計書の自動生成は可能？後から困らない残し方、引き継ぎの観点はAI生成コードの保守は可能か｜引き継ぎと改修の確認点が参考になります。

後から足しても間に合いやすい部分と、その見極め方

反対に、利用者が増えてから対応しても、比較的間に合いやすい部分があります。ここは最初から作り込まず、必要になった時点で手を入れるのが現実的です。

サーバーの性能や台数

クラウドのサービスを使っていれば、サーバーの性能を上げたり、台数を増やしたりすることは、設定の変更で行えることが多くなっています。最初は小さな構成で始め、利用状況を見ながら調整する進め方が一般的です。

処理の高速化

画面の表示が遅い、検索に時間がかかるといった問題には、よく使うデータを一時的に保管しておく仕組み（キャッシュ）や、データの検索を速くするための仕組み（インデックス）など、後から追加できる手段があります。どこが遅いのかを計測してから手を入れるほうが、見当で先に作り込むよりも効果的です。

時間のかかる処理の切り出し

大量のメール送信や、レポートの作成のように時間のかかる処理は、利用者を待たせないよう裏側で順番に処理する仕組み（非同期処理）に切り替えることがあります。件数が少ないうちは、画面の中でそのまま処理しても問題になりません。

画面の作り込み

画面の見た目や操作性は、検証の結果を見て変えていく部分です。利用者の反応を見る前に細かく作り込むと、変更のたびに手戻りが出ます。管理画面についても同様で、新規事業の管理画面開発｜最初に作る範囲の見極め方で最初に作る範囲の考え方を整理しています。

見極めの基準：「変えるのに何が必要か」を考える

迷ったときは、次の問いで分けると判断しやすくなります。

• これを後から変えるとき、すでにたまったデータを作り直す必要があるか
• 変更が、利用者に見えない裏側だけで完結するか
• 変更の間、サービスを止める必要があるか

データの作り直しが必要で、利用者への影響が大きいものほど、最初に考えておく側に入ります。設定や追加の作業で済むものは、後回しにできる側です。

利用者数の見立てと、見直しのタイミングの決め方

「どれくらい増える想定で作るか」は、数字で置いておくと議論が具体的になります。ただし、新規事業では正確に予測することはできません。大切なのは、当たる数字を出すことではなく、見直しのきっかけとなる目安をあらかじめ決めておくことです。

段階に分けて仮置きする

たとえば、次のように、段階ごとに想定を仮置きする方法があります。ここに挙げる数字はあくまで考え方を示すための仮の例で、実際の事業の規模に合わせて置き換えて使います。

• 検証期：限られた利用者（数十人から数百人など）で、事業の仮説を確かめる
• 立ち上げ期：公開範囲を広げ、継続して使われるかを見る
• 成長期：利用者が増え、運用や負荷の対策が現実の課題になる

検証期の備えは、「後から変えにくい部分」だけで十分な場合が多くあります。クローズドな形で公開範囲を絞る進め方は、新規事業のクローズドβ｜進め方と公開範囲の決め方で触れています。

見直しのきっかけを数字で決める

次の段階に進む前に、どの状態になったら構成を見直すのかを決めておきます。たとえば次のような項目です。

• 画面の表示にかかる時間が、あらかじめ決めた目安を超えるようになった
• 同時に利用する人数が、現在の構成で想定した上限に近づいた
• データの件数が増え、検索や集計に時間がかかるようになった
• 運用の手作業が増え、担当者の負担が目に見えて大きくなった

こうした目安を、事業の指標と合わせて置いておくと、「そろそろ備える時期だ」という判断を感覚ではなく数字で行えます。事業側の指標の決め方はMVP検証の指標を先に決める方法｜判断基準の作り方が参考になります。

負荷の確認は、増える前に試しておく

公開範囲を広げる前には、想定する人数が同時に使ったときの動きを、あらかじめ試しておく方法があります（負荷試験）。実際に利用者が増えてから問題に気づくより、事前に限界の目安を知っておくほうが、対応の時間を確保できます。ここでも、最初から大規模な試験を行う必要はなく、次の段階に進む前に実施する、という位置づけで十分です。

開発会社に相談するときに伝えたいこと・確認したいこと

拡張性の判断は、開発会社と一緒に行うことになります。互いの認識がずれないよう、相談の場では次のような点を共有しておくと進めやすくなります。

伝えておきたいこと

• 事業の段階（検証期か、すでに利用者がいるか）
• 利用者の増え方についての仮の見立てと、その根拠の弱さ（まだ分からない部分）
• 複数の会社や拠点に広げる可能性があるか
• 扱う情報の種類（個人情報や決済情報を含むか）
• 将来つなぎたい外部サービスや、既存の社内システムの有無

確認しておきたいこと

• 「後から変えにくい部分」として、どこを最初に押さえる想定か
• 後回しにする部分と、そのときに必要になる作業の見立て
• 利用者が増えたとき、どの指標を見て、どの段階で見直すのか
• 設計の考え方が、後から読める形で残されるか
• 将来、別の担当者や別の会社が引き継げる状態か

既存の社内システムとの関係については、新規事業は既存システムと切り離して作る理由と進め方が参考になります。また、MVPを作った後に本格的な開発へ進むとき、どこを引き継ぎ、どこを見直すかはMVPから本開発は作り直し？引き継げる部分と見直す点で整理しています。最初に備えた部分が適切であれば、作り直しの範囲を小さく抑えやすくなります。

開発の全体像の中に置く

拡張性は、一度決めて終わりではなく、事業の成長に合わせて見直していくものです。プロトタイプの後の1年をどう進めるかは新規事業の開発ロードマップの描き方｜プロトタイプ後の1年に、納品後の育て方はシステムは納品後の改善で育てる｜新規事業の考え方にまとめています。あわせて見ておくと、備えを段階で考える感覚がつかみやすくなります。

まとめ

新規事業のシステムの拡張性について、要点を整理します。

• 「拡張性」には、負荷への強さ、機能の足しやすさ、事業の広がりへの対応という3つの意味があり、どれを指すかを先に言葉にしておくと議論が噛み合いやすくなる
• 最初から大規模な利用を前提に作り込むと、検証の開始が遅れ、想定が外れたときに複雑さだけが残る
• 最初に考えておきたいのは、データの持ち方、権限の考え方、外部サービスとの切り分け、個人情報の扱い、設計の記録といった「後から変えにくい部分」
• サーバーの台数、処理の高速化、時間のかかる処理の切り出し、画面の作り込みなどは、必要になってから手を入れても間に合いやすい
• 利用者数は段階ごとに仮置きし、見直しのきっかけとなる目安を数字で決めておく

判断の基準は、「後から変えるときに、すでにたまったデータの作り直しが必要か」「利用者への影響が大きいか」です。大きいものは最初に、小さいものは必要になった時点で、という分け方をすると、事業の検証を早く進めながら、成長したときの手戻りも抑えられます。

私たちJustFitは、構想をもとに約1ヶ月で動くプロトタイプを先に開発し、実物を見てから契約するかを判断していただく進め方をとっています。納品後も、システムの維持や不具合修正に加え、毎月ひとつの機能追加まで対応する伴走型の技術支援です。仕様が固まっていない段階でも相談できますので、利用者が増えたときの備えをどこまで考えるかで迷われたときは、JustFitのサービス紹介もご覧ください。