新規事業は既存システムと切り離して作る理由と進め方
既存事業を持つ会社が新規事業を始めるとき、「今ある基幹システムや会員基盤の上に作れば早いのではないか」という考えが自然に出てきます。この記事では、新規事業のシステムを既存システムと切り離して作る理由と、切り離したあとの「つなぎ方」の考え方を整理します。切り離すか載せるかを判断するための目安も紹介します。
「切り離す」とは何を分けることか
「新規事業 既存システム 切り離し」と聞くと、既存システムと一切関わらない状態を想像する方もいるかもしれません。実際には、分けるものと分けないものを、最初に決めることを指します。
分ける対象は、大きく4つあります。
- 開発とリリースの単位：新規事業側の変更が、既存システムのリリース作業や検証に引きずられない状態にする
- データベース：新規事業で扱う情報を、既存のデータとは別の場所に保存する
- 画面と認証：ログインや画面の作りを、既存サービスとは別に持つ
- 意思決定の流れ：新規事業の仕様変更や中止を、既存システムの管理ルールとは別に判断できるようにする
一方で、最初から無理に分けなくてよいものもあります。たとえば請求や在庫の最終的な突き合わせなどは、事業が育ってから連携を考えても遅くありません。大切なのは「最初は独立して動かし、つなぐのは確かめてから」という順番です。
既存システムに載せると起きやすいこと
切り離しの利点は、載せた場合の困りごとを見ると分かりやすくなります。新規事業のシステムを既存システムの上や内部に作ると、次のような問題が起きやすくなります。
変更の影響範囲が読みにくい
長く使われてきた既存システムは、機能どうしが複雑に結びついていることがあります。経済産業省の「DXレポート」でも、老朽化・複雑化・ブラックボックス化した既存システム（いわゆるレガシーシステム）が、新しい取り組みの足かせになりうる点が指摘されています。
新しい機能を一つ足すだけでも、既存の機能への影響を調べる作業が必要になります。新規事業では仕様を頻繁に変えたいのに、変更のたびに影響調査が発生すると、動きが鈍くなります。
リリースのリズムが合わない
既存事業のシステムは、止まらないこと、間違えないことが最優先です。そのため、リリースの時期や承認の手順が厳格に決まっていることが多くなります。
新規事業は逆です。小さく出して反応を見て、すぐ直すことが求められます。リズムの違う二つを同じ仕組みに載せると、どちらかが無理をすることになります。
仕様が固まらない開発と相性が悪い
新規事業の初期は、誰に何を提供するかが仮説の段階です。既存システムの設計ルールや命名規則、データ構造に合わせようとすると、仮説が変わるたびに大きな作り直しになりがちです。仮説検証が目的の段階で、本番級の整合性を求められる状況は、負担が大きくなります。
やめにくくなる
既存システムに深く組み込んだ機能は、事業をやめると決めたときに取り外す作業が大きくなります。取り外しの手間が心配で、判断が先送りになることもあります。撤退の基準を考えるうえでも、独立していることは意味があります。詳しくは「新規事業の撤退判断｜プロトタイプで「やめる」と決める基準」で整理しています。
切り離して作る5つの理由
ここからは、切り離しを選ぶ理由を5つに分けて見ていきます。
1. 検証の速度を保てる
新規事業で最初に大切なのは、完成度よりも「確かめるまでの速さ」です。既存システムの制約や調整から離れると、必要な機能だけを短い期間で作り、利用者の反応を見られます。
最初に作る範囲の絞り方は、「MVP開発の機能の絞り方｜最初に作るものと後回しの基準」が参考になります。MVP（Minimum Viable Product）とは、仮説を確かめるために必要な最小限の機能を備えた製品のことです。切り離しは、この最小限の範囲を守りやすくします。
2. 既存事業への影響を抑えられる
新規事業のシステムに不具合が出たとき、既存事業まで止まってしまうと、会社として大きな損失になります。独立した環境で動かしていれば、問題が起きても影響範囲は新規事業側に収まります。
特に、外部のユーザーに公開する新サービスでは、負荷の急増や想定外の使われ方が起こりえます。既存の基幹業務と同じ土台を共有していないことは、安全面でも安心材料になります。セキュリティ面の考え方は「AI生成コードのセキュリティ｜確認点と人の役割」でも触れています。
3. 仕様変更と撤退の判断がしやすい
切り離されていれば、仕様を大きく変えても、既存システムの担当部署との調整は限られます。検証の結果、方向転換が必要になったときも動きやすくなります。
撤退する場合も、新規事業のシステムだけを止めれば済みます。「やめるときの手間」が小さいと、判断に迷う時間も短くなります。小さく作って確かめる投資判断の進め方は、「新規事業の開発は小さく作って確かめる投資判断の進め方」で説明しています。
4. 技術の選び方に自由度が生まれる
既存システムが古い言語や特定の環境で作られている場合、新規事業もそれに合わせると、選べる技術が狭くなります。切り離せば、新規事業の目的に合った構成を選べます。
たとえば、画面の作りやすさ、外部サービスとの連携のしやすさ、AIを使った開発の進めやすさなどを基準に決められます。AIを使った開発の特徴は「AI駆動開発のメリットとデメリット｜向く開発と注意点」にまとめています。
ただし、自由度が高いぶん、あとで保守する人が困らない構成にしておく視点も必要です。引き継ぎの観点は「AI生成コードの保守は可能か｜引き継ぎと改修の確認点」が参考になります。
5. 事業としての数字が見えやすくなる
既存システムと一体にすると、新規事業にかかった開発の手間や運用の負担、利用状況が、既存事業の数字に混ざってしまいます。切り離しておけば、新規事業単体の利用状況や運用の負担を測りやすくなります。
何を指標にするかは、先に決めておくと判断が楽になります。「MVP検証の指標を先に決める方法｜判断基準の作り方」も併せて確認してみてください。
切り離しても起きやすい失敗
切り離せば何でもうまくいく、というわけではありません。切り離したあとに起きやすい失敗も知っておく必要があります。
二重管理が負担になる
顧客情報や商品情報を、既存側と新規側の両方で手入力していると、すぐに運用が苦しくなります。切り離した状態で事業を始めても、検証の期間が長くなるほど、二重管理の手間は大きくなります。
対策として、検証期間を区切っておくことが考えられます。「この期間は手作業で補い、この指標を満たしたら連携を設計する」と決めておくと、手間が増え続けることを避けられます。
将来つなぐときの作り直しが大きくなる
完全に別物として作ると、事業が育って連携したくなったときに、データの形式がそろわず苦労することがあります。次の点を、最初から意識しておくと後が楽になります。
- 顧客や取引先を識別する項目（ID）の考え方を、既存側と矛盾しないようにしておく
- データの項目名や意味を、既存側と食い違わせすぎない
- 外部とやり取りする窓口（API）を用意する前提で設計する
API（Application Programming Interface）とは、システムどうしがデータや機能をやり取りするための窓口のことです。最初は使わなくても、「あとで窓口を付けられる作り」にしておくことが、切り離しの失敗を減らします。
新規事業として育たず、既存の延長になる
既存システムと切り離しても、既存の承認手順や社内ルールをそのまま持ち込むと、速さが戻ってしまいます。技術的に切り離すだけでなく、判断する人と判断の基準も切り分けることが大切です。経営陣と現場で判断の速度が違うことから生じるすれ違いについては、「新規事業で経営陣と現場がすれ違う原因は進め方のズレ」で触れています。
切り離すか、載せるかの判断の目安
すべての新規事業で切り離しが正解とは限りません。判断の目安を、次のように整理できます。
切り離しを優先しやすいケース
- 新規事業の顧客や商品が、既存事業とは大きく異なる
- 仕様が固まっておらず、頻繁に変わる見込みがある
- 既存システムの変更手順が重く、短い周期のリリースが難しい
- 失敗したときに既存事業へ影響を出せない
- 事業の成否を、単独の数字で判断したい
- システム自体が事業の中核になる（サービスそのものがシステムである）
既存システムに載せることを考えやすいケース
- 既存の顧客に、既存サービスの追加機能として提供する
- 既存の在庫・会員・請求の情報を使うことが前提で、独立では成り立たない
- 事業モデルがすでに確かで、仕様が安定している
- 既存システムが十分に整理されていて、変更の影響範囲が把握できている
迷う場合は、「最初の検証に必要なのは何か」から考えます。既存データの利用が検証の核心なら、読み取り専用で参照する形など、部分的な接続を検討します。そうでなければ、まず独立して作り、必要になった連携を後から足すほうが、判断を誤りにくくなります。
認証・決済は別の考え方もある
ログインや決済のように、自社で作る必然性が低い部分は、外部のサービスを使う選択肢もあります。既存の認証基盤を共有するか、外部サービスを使うか、新規で作るかは、利用者の体験と運用の負担で変わります。分け方の考え方は「新規事業の決済システム開発｜外部サービスと自作の分け方」で整理しています。
切り離した新規事業を、どう進めるか
切り離すと決めたあとの進め方も、整理しておきます。
最初に「連携しないこと」を決める
新規事業の初期は、既存システムとの連携を最小限にします。連携が必要に見える場面でも、手作業や簡易な代替手段で検証できないかを先に考えます。連携の開発は、事業の見込みが確かめられてからでも遅くありません。
動くものを見ながら判断する
企画書や仕様書だけでは、新規事業の価値は伝わりにくいものです。動くプロトタイプを先に作り、関係者が実物を見ながら判断すると、認識のズレを早い段階で減らせます。プロトタイプとMVPの違いは「プロトタイプとMVP・モックの違いを整理｜新規事業の使い分け」で説明しています。
切り離しは、プロトタイプ作りとも相性が良い考え方です。既存システムの制約を受けないため、確かめたいことに集中して作れます。稟議や決裁の場面でも、動く実物は判断材料になります。「稟議を通すシステム開発｜プロトタイプの使い方」も参考になります。
内製か外注かを決める
切り離した新規事業のシステムは、既存システムの担当チームとは別の体制で作ることが多くなります。社内にエンジニアがいない場合や、既存チームの手が空かない場合は、外部に依頼する選択肢もあります。判断軸は「内製と外注どちらがいい？新規事業システムの判断軸」にまとめています。
外注する場合は、作ったシステムの権利や、あとで自社が引き継げるかを、契約前に確認しておくことが欠かせません。「システム開発の著作権帰属は誰のもの？契約前の確認点」が参考になります。
作って終わりにしない
切り離して作ったシステムは、検証の結果に合わせて育てていく前提で考えます。機能を足す、直す、必要になった時点で既存システムとつなぐ、といった変更を続けられる体制が必要です。この考え方は「システムは納品後の改善で育てる｜新規事業の考え方」で詳しく扱っています。
まとめ
既存事業を持つ会社が新規事業のシステムを切り離して作る理由は、次の5つに整理できます。
- 検証の速度を保てる
- 既存事業への影響を抑えられる
- 仕様変更と撤退の判断がしやすい
- 技術の選び方に自由度が生まれる
- 新規事業単体の数字が見えやすくなる
一方で、切り離しは二重管理や、将来つなぐときの作り直しといった課題も生みます。そのため「最初は独立して作り、連携は確かめてから足す」という順番と、検証期間の区切り、あとで窓口を付けられる設計が大切になります。
既存システムに載せるべきか迷うときは、「最初の検証に何が必要か」「失敗したときに既存事業へ何が起きるか」の2点から考えると、判断がしやすくなります。
JustFitは、株式会社LEGAREAが運営する完全オーダーメイドの受託開発サービスで、構想をもとに約1ヶ月で動くプロトタイプを先に開発し、実物を見てから契約を判断できる進め方をとっています。システムが事業そのものになるような新規事業を得意としており、既存システムとどう距離を取るかを含めた相談にも対応しています。詳しくはJustFitのサービス紹介をご覧ください。