──「経営の選択肢」を持つためのシステム投資
「実は、過去に事業売却を検討したことがあるんです。でも、システムの問題で諦めました。」
中堅企業の経営者の方から、こういうお話を伺うことが少なくありません。
事業ポートフォリオの見直し、選択と集中、ノンコア事業の整理——多くの経営者がそう考えながらも、「うちのシステムでは切り出せない」という現実に阻まれているのが実情です。
事業売却・子会社売却においてシステム分離が長期化する原因は、大きく3つあります。
本記事では、NetSuite認定パートナー（Solution Provider）であるベンチャーネットが、売り手・切り出す側の視点から、システム戦略の要点をお伝えします。
なお、買い手側の経営統合(PMI)については、別記事M&A後のPMI完全ガイド｜「業務統合」でつまずかないためのシステム・データ統合の進め方をご参照ください。
カーブアウトとは何か——売り手側から見た事業切り出しの基本構造
事業売却・カーブアウトの議論を始める前に、用語と基本構造を整理しておきます。
経営者の方にとっては馴染みのある言葉でも、実務担当者と話す際の共通言語として、定義を共有することが大切だからです。
カーブアウト(事業切り出し)の定義
カーブアウトとは、企業の一部事業や子会社を切り出して独立させる行為を指します。「事業売却」「子会社売却」「会社分割」などを包括する概念です。
近年、カーブアウトが注目される背景には、次のような経営課題があります。
- 事業ポートフォリオの最適化
- ノンコア事業の整理と経営資源の集中
- IPO に向けた選択と集中
- 後継者問題・事業承継への対応
事業売却は「会社の縮小」ではなく、「経営戦略の実行手段」として位置づけられるようになってきました。
事業売却プロセスの全体像と登場人物
カーブアウトには、3つの登場人物がいます。
| 登場人物 | 役割 |
|---|---|
| 売り手 | 自社。事業を切り出す側 |
| 買い手 | 取得企業。事業を取得する側 |
| 第三者 | FA(フィナンシャル・アドバイザー)など。仲介・支援 |
そして、プロセスは大まかに次の流れで進みます。
意思決定 → 準備 → マーケティング → デューデリ → 契約 → クロージング
このプロセスの中で「システム分離」が重要になるのは、デューデリから契約・クロージングまでの期間です。買い手から事業の精査を受け、最終的な引き渡しに至るこの局面で、システム面の準備不足が長期化や頓挫の原因になります。
重要な専門用語の整理
事業売却の議論で頻出する用語を、補足しておきます。
| 用語 | 簡潔な定義 |
|---|---|
| デューデリジェンス(DD) | 買い手による事業精査。財務・法務・税務・システム等を多面的に検証 |
| TSA(Transition Service Agreement) | 売却後一定期間、売り手が買い手に業務サービスを提供する暫定契約 |
| クロージング | 事業売却の最終契約締結と引き渡し完了 |
本記事では、これらの用語を文脈に応じて使い分けます。
本記事は「売り手側」の視点で書いています
カーブアウトには売り手側と買い手側の両面があります。
本記事は、事業を切り出す側=売り手側の視点で書いています。具体的には、システム分離・デューデリ対応・TSA設計など、売り手側が直面するシステム面の論点を扱います。
買い手側の経営統合(PMI)については、別記事「M&A後のPMI完全ガイド」で詳しく解説しています。
買い手として M&A 後の業務統合に取り組まれている方は、そちらをご参照ください。
事業売却が頓挫する3つの典型パターン
事業売却そのものは、経営判断の一つです。売る・売らないを決めるのは、経営者である皆さんです。
しかし、いざ「売る」と決めても、システムの問題でその選択肢を失ってしまう——これがカーブアウト現場で繰り返し起きていることです。
ベンチャーネットが支援してきた現場では、事業売却の長期化や頓挫の原因が、驚くほど共通したパターンに集約されることが分かってきました。
ここでは、その3つの典型パターンを共有します。
「自社にも当てはまるかもしれない」と感じる経営者の方は、今すぐの売却予定がなくても、知っておく価値があります。
パターン①:事業部別P/Lが出せない(数字の問題)
よくある兆候
こんな状況に心当たりはありませんか？
- 月次決算では全社の損益しか出てこない。事業部別の損益を出すには、経理が手作業で表計算ソフトを使い、月末から2週間以上かかる
- 「この事業の営業利益はいくらか」と社長が聞いても、即答できる経理担当者がいない
- 共通費(人件費・賃料・本社費用)の按分基準が事業部ごとにあいまいで、本当の事業収益が見えない
なぜ事業売却が頓挫するのか
表面的には「経理が頑張れば出せる」「Excelで集計すれば済む」と思えるこの問題は、実は事業売却の場面で深刻な壁になります。
買い手は事業を買うとき、必ず「事業単独の P/L・B/S」を求めます。過去3〜5年分の数字を、勘定科目レベルで開示する必要があります。
事業部別の数字が出せない構造で運営してきた企業は、ここで初めて「自社の会計の作り方では、事業の価値を証明できない」という現実に直面します。
無理に切り出すと、デューデリで論点が多発し、価格交渉で大幅に不利になります。最悪のケースでは、ディール自体が頓挫します。
つまり、この問題は「経理の頑張り不足」ではなく、会計の設計思想そのものが事業切り出しに対応していないという構造的な問題です。
どう回避するか
事業切り出しの可能性が将来あるなら、会計設計の段階で「事業単独で数字が出せる構造」を整えておくのが理想です。
具体的には、次の3点が要点になります。
- 部門コード(セグメントコード)を勘定科目と連動して設計し、すべての取引に紐付ける
- 共通費の按分基準を事業部ごとに明文化する
- マルチエンティティ対応のERPを使い、子会社・事業部を独立した「Subsidiary(サブシディアリー)」として最初から分けて運営する
NetSuiteは、こうした「事業ポートフォリオを切り分けて運営する」ことを前提に設計されたERPです。
導入時にマスタ設計を正しく組めば、いつでも事業単独の P/L・B/S が即時に出せる状態になります。
ベンチャーネットでは、お客様の事業構造をうかがいながら、「今後5〜10年で起こりうる事業ポートフォリオの変化」を想定したマスタ設計を一緒に組み立てています。
参考リンク:NetSuiteで実現する管理会計の高度化｜中堅・中小企業の経営者が知っておきたい財務会計との違いと実践ステップ
パターン②:基幹システムが全社一体型(システム構造の問題)
基幹システムをどう刷新・統合するかは基幹システムとERPの違い（移行判断）を参照。
よくある兆候
こんな状況に心当たりはありませんか？
- 在庫・受発注・購買のデータベースが全社で1つに統合されていて、事業部単位での切り分けがそもそもできない
- 「この事業の在庫だけ別管理にしたい」と現場が言っても、情シスから「システム上、不可能です」と返ってくる
- ERP を導入した当初は「全社統合」が正解とされ、全データを1つの基盤にまとめた——その設計が今、足枷になっている
なぜ事業売却が頓挫するのか
この問題は、システムが古いから起きるわけではありません。
過去の「全社統合」という設計思想が、今の経営環境に合わなくなった——これが本質です。
2000〜2010年代、多くの中堅企業は「業務を統合してデータを一元管理すること」を目標にERPを導入しました。当時はそれが正解でした。
事業ごとにシステムが分かれていると、全社の数字が出せず、業務効率も悪かったからです。
しかし、その設計思想で構築されたシステムは、いま事業を切り出そうとすると、根本的に対応できません。
具体的には、次の3点が絡み合います。
- マスタデータ(取引先・商品・部門など、業務の基本データ)が全社で共有されており、事業単位で分離できない
- アドオン開発(ERPに付け足した独自プログラム)が事業の境界を越えて絡み合っており、引き剥がすと他の業務が動かなくなる
- 業務プロセスが「全社で1つのワークフロー」になっていて、事業ごとに別の運営にしようとすると、ゼロから組み直しになる
つまり、システムを切り出そうとすると、「事業を売る」のではなく「IT資産をゼロから作り直す」作業が発生します。
これが、カーブアウトを12〜18か月以上の長期戦にしてしまう主要因です(ベンチャーネット支援事例の参考値。実際の期間は事業規模・複雑性によって変動します)。
どう回避するか
ここで重要なのは、「全社統合」と「事業切り出し可能」は両立できるという事実です。
クラウド時代のERPは、論理的に事業を切り分けられる構造(マルチエンティティ対応)を、最初から備えています。
NetSuite では、子会社・事業部などを「Subsidiary(サブシディアリー)」という独立した会計単位として最初から分けて運営できます。
全社のデータを統合的に見ることも、事業ごとに切り分けて見ることも、両方できる構造です。
そして、いざ事業を切り出すときには、Subsidiary 単位でデータを分離して引き渡すことができます。
ベンチャーネットがお客様の導入を支援する際は、最初のマスタ設計の段階で「将来事業を切り出す可能性があるか」を必ず伺います。
可能性があれば、Subsidiary 構造を最初から組み込んで設計します。
切り出さないとしても、複数事業の数字を独立して管理できる構造は、経営判断の精度を上げます。
パターン③:業務プロセスが親会社依存(業務オペレーションの問題)
よくある兆候
こんな状況に心当たりはありませんか？
- 子会社や事業部の経理処理(請求書発行・売掛金管理・支払処理)を、本社の経理部門がまとめて代行している
- 給与計算・人事システム・購買承認などの業務インフラを、親会社のシステムと運用に依存している
- 子会社単独で「契約書を確認する法務」「業務システムを動かす情シス」といった機能を持っておらず、すべて親会社が引き受けている
なぜ事業売却が頓挫するのか
この問題が深刻なのは、システムやデータと違って、「業務を切り分けるとは、人と組織を切り分けること」だからです。
中堅企業の多くは、効率化のために業務を親会社に集約してきました。
子会社ごとに経理・人事・情シスを抱えるのはコストが重いため、本社で集中処理する。これは長年、合理的な選択でした。
しかし、この設計のまま事業を切り出そうとすると、売却後の事業運営に必要な機能がそもそも存在しません。
実務的には、TSA(Transition Service Agreement)という形で、売却後も売り手側が業務代行を続けることになります。
TSA とは、売却後の一定期間、売り手が買い手に業務サービスを提供する暫定契約のことです。
ところが、このTSA期間が長期化すると、次のような問題が発生します。
- 売り手側のリソースが買い手側の業務に拘束され続け、本来の経営にエネルギーを向けられない
- 業務代行の対価をめぐる交渉が複雑化し、関係が悪化する
- 買い手側も、自社統制の業務体制をいつまでも整備できず、PMI(経営統合)が遅れる
業務集約は、平時には効率化として機能します。
しかし、事業切り出しの場面では、その集約が逆に「切り離すべき業務がどこから始まりどこで終わるのか」を不明瞭にする要因になります。
どう回避するか
業務プロセスの集約と切り分けを両立させる方法は、「業務を分離可能な単位で設計しておく」ことです。
具体的には、次の3点が要点になります。
- 各事業の経理処理を、勘定科目と部門コードで完結できる単位に設計する(パターン①と連動)
- 業務ワークフローを Subsidiary 単位で別ルートに分けられる仕組みを持っておく
- 重要な業務マスタ(取引先・契約・人事)を、事業ごとに独立して管理できる構造を採用する
NetSuite は、こうした「同じシステム基盤の中で、業務を事業単位に分離できる構造」を提供します。
本社の経理が一括で処理することも、各事業が独立して処理することも、両方を切り替えられる柔軟性があります。
ベンチャーネットでは、お客様の業務集約の状況を伺いながら、「将来切り出す可能性のある業務」を識別し、TSA 期間を最小化できる業務設計を一緒に組み立てています。
業務の切り出しやすさは、平時の業務効率と必ずしも矛盾しません。正しい設計をすれば、両立できます。
3パターンに共通する構造——「平時の効率化」が「有事の柔軟性」を奪う
ここまで見てきた3つの典型パターンには、共通する構造があります。
過去の経営判断としては、いずれも正解だったということです。
- 全社で会計を統合するのは、経営の見える化のため
- 全社で1つの基幹システムにまとめるのは、データの整合性のため
- 業務を親会社に集約するのは、コスト効率と統制のため
これらはすべて、平時の経営効率を上げるための合理的な選択でした。
ところが、いざ事業を切り出そうとすると、まさにその合理性が足枷になります。「効率化のために統合したもの」を引き剥がす作業に、時間とコストがかかるからです。
つまり、カーブアウトの本質的な難しさは、「過去の合理的な選択を、今の経営環境にどう適応させるか」という、極めて経営判断的な問題なのです。
これは、システム導入の問題というより、経営の柔軟性をシステム設計でどう確保するかという問題です。
では、どんなシステム構造ならこの問題を回避できるのか——次の章では、レガシーERPとクラウドERPの構造的な違いを、売却前提という観点から比較します。
レガシーERP vs クラウドERP——売却前提で見る構造比較
ここまで見てきた3つの失敗パターンは、すべて「ERP の構造設計」に根を持つ問題です。
では、どんなシステム構造ならこれらの問題を回避できるのか——。
レガシーERPとクラウドERPの違いを、事業切り出しという観点から6つの軸で比較します。
比較表:6つの観点で見るレガシーERPとクラウドERPの違い
| 比較軸 | レガシーERP | クラウドERP(NetSuite) |
|---|---|---|
| 会計の切り分け単位 | 全社単一の会計単位 | Subsidiary(独立した会計単位)を複数 |
| データベース構造 | 全社で1つのDB | 論理的に分離可能 |
| マスタデータ管理 | 全社で1つを共有 | Subsidiary 単位で独立管理＋共通並立 |
| 業務ワークフロー | 全社で1つのワークフロー | Subsidiary 単位で別設定可能 |
| アドオン依存度 | アドオン開発が積み上がる | 標準機能でカバー、アドオン最小化 |
| 事業切り出し所要期間(参考値) | 12〜18か月以上 | 3〜6か月 |
所要期間はベンチャーネット支援事例の参考値です。実際の期間は事業規模・複雑性によって変動します。
参考リンク:NetSuite – 基幹システムリプレイスサービス
比較表の読み解き——3つの本質的な違い
この比較表から、3つの本質的な違いが見えてきます。
1. 「全社統合」と「事業分離」が両立できるかどうか
レガシーERPは「全社統合」を目標に設計されたため、事業を分離する発想がそもそも組み込まれていません。
クラウドERPは Subsidiary という概念で、統合と分離を最初から両立させています。
2. アドオン依存度の蓄積構造
レガシーERPでは、業務要件が増えるたびにアドオン開発が積み上がります。10年経つと、誰も全体像を把握できない「ブラックボックス」が出来上がります。
クラウドERPは標準機能の幅が広く、定期的にアップデートされるため、アドオン依存を最小化できます。
3. 切り出し時の所要期間の桁違い
レガシーERPからの切り出しは、実質的にIT資産をゼロから再構築する作業になります。
クラウドERPなら、Subsidiary 単位でデータを分離・引き渡せるため、所要期間が大幅に短縮されます。
事業切り出しの実プロジェクトは、認定パートナーであるベンチャーネットが、お客様と共に設計します。事業構造と切り出し要件を伺った上で、Oracle と最適な実行プランを組み立てます。
では、NetSuite は具体的にどんな機能で、これらの構造的な違いを実現しているのか——次章で見ていきます。
NetSuiteでカーブアウト準備を進める方法
ここからは、NetSuite の具体的な機能を見ていきます。
ただし、機能の網羅的な紹介ではなく、「カーブアウトに対応できる構造」を支える3つの要素に絞ってお伝えします。
Subsidiary構造——複数の事業を「独立した会計単位」で運営する
NetSuite の中核機能の一つが、「Subsidiary(サブシディアリー)」という考え方です。
Subsidiary とは、子会社・事業部などを独立した会計単位として運営する仕組みです。1つの NetSuite アカウントの中に、複数の Subsidiary を持つことができます。
たとえば、本社・国内子会社A・海外子会社B・新規事業C を、それぞれ独立した Subsidiary として運営できます。
各 Subsidiary は、次のような特徴を持ちます。
- 独立した P/L・B/S を持つ
- 独自の通貨・言語・税制度に対応できる
- 業務ワークフローを別ルートで設定できる
- 全社統合の数字も、Subsidiary 単位の数字も、即時に出せる
これは、「全社統合」と「事業分離」を最初から両立させた構造です。
事業を切り出す場面では、その Subsidiary のデータだけを抽出して買い手に引き渡すことができます。
参考リンク:NetSuiteとは？中堅・中小企業の経営者が知っておきたいクラウドERP入門【2026年版】
データ分離——切り出すデータを論理的に切り分ける
事業を切り出すには、その事業のデータ(取引履歴・取引先・在庫・契約など)を、買い手に引き渡せる形で切り分ける必要があります。
レガシーERPでは、全社で1つのデータベースに格納されているため、事業単位での切り分けに大規模な作業が発生します。
NetSuite では、Subsidiary 単位でデータが論理的に分離されています。
切り出し時には、対象 Subsidiary のデータを抽出し、買い手の環境にインポートできる形式で出力します。
これにより、IT 観点での切り出し作業が、ERP の再構築ではなく「データ移行」という標準的な作業に置き換わります。
実際の所要期間や移行手順は、事業の規模・複雑性・対象範囲によって変動します。具体的な計画策定には Oracle およびベンチャーネットによるアセスメントが必要です。
グローバル対応——多通貨・多言語が標準装備という意味
カーブアウト現場で意外に大きな論点になるのが、グローバル対応です。
事業を買い取る側が海外企業の場合、現地法人化や多通貨対応が必要になります。
事業の一部に海外拠点が含まれる場合も、通貨・言語・税制度への対応が課題になります。
NetSuite は、世界 220地域・43,000社以上に導入されているクラウドERPです。190通貨・27言語に標準対応しています(2026年4月時点・Oracle NetSuite 公式数値)。
この標準対応は、事業切り出し時に「買い手の事業環境に合わせた追加開発が不要」という大きな意味を持ちます。
レガシーERPなら、新たな通貨・言語への対応だけで数か月の追加開発になることもあります。
NetSuiteの選択は、ITプロジェクトを超える経営判断
ここまでお伝えしてきた NetSuite の機能は、事業の切り出しをスムーズにする仕組みです。
しかし、本質はもう一段深いところにあります。
カーブアウトは「IT の問題」ではなく、「経営の柔軟性をシステム設計で確保する」という経営判断です。
次章では、その視点を掘り下げていきます。
カーブアウトはITプロジェクトではなく経営プロジェクトである
ここまで読み進めてきた方は、ある違和感に気づいているかもしれません。
カーブアウトの話なのに、「システム」の話ばかりだ——と。
事業売却・子会社売却は、本来は経営戦略の話です。
どの事業を残し、どの事業を切り出すか。どこに経営資源を集中させるか。これらは経営者にしか決められないことです。
ところが、いざ実行段階に入ると、「システム」が経営判断の選択肢そのものを狭めてしまう——これがカーブアウトの現実です。
そして、ベンチャーネットが現場で見てきて分かったことがあります。
多くの企業は、この問題を「システム部門に丸投げ」しようとして、失敗します。
「システム部門に丸投げ」した瞬間、カーブアウトは失敗する
「カーブアウトに向けてシステムを整えておいて」
——経営者がこう言って情シスや経理に丸投げした瞬間、プロジェクトの成功率は大きく下がります。
理由はシンプルです。
カーブアウトの本質は「事業をどう切り出すか」という経営判断であり、その判断をシステム設計に翻訳する作業が必要だからです。
- 「どの事業を、どの単位で、いつ切り出すか」
- 「業務のうち、どこまでを売り手が、どこからを買い手が担うのか」
- 「TSA は何か月で終わらせるのか」
これらは経営判断です。
しかし、システム部門に丸投げすると、こうした経営判断が情シスの想像に委ねられます。
情シスは経営の意思を推測し、「とりあえずシステムを切り分けやすくしておこう」という作業に着手します。
その結果、経営の意思と乖離した仕様で開発が進み、いざ事業を切り出す段になって「想定していた切り出し方ができない」という事態に至ります。
これは情シスの責任ではありません。経営者がシステム設計を経営判断の一部として扱わなかったことが原因です。
経営判断としての3つの問い
カーブアウトをITプロジェクトから経営プロジェクトへと転換するために、経営者が向き合うべき問いが3つあります。
問い1:今後5〜10年の事業ポートフォリオはどうなるか
切り出す可能性のある事業はどれか。逆に、コアとして残す事業はどれか。あるいは、新規事業として育てる領域はどこか。
この問いに答えがなければ、システム設計の方向性は決まりません。
問い2:事業を切り出す場合、どの単位で切り出すか
事業部単位なのか、子会社単位なのか、特定の製品ラインだけか。
切り出しの粒度によって、必要なシステム設計はまったく変わります。
問い3:切り出し後の業務を、誰がどこまで担うのか
TSA で売り手側がどこまで業務を続けるのか。買い手側にどのタイミングで完全移管するのか。
これは契約上の論点ですが、システム設計の前提条件でもあります。
これらの問いは、CFO や情シスだけでは答えられません。
経営者が判断し、経営者が方針を示すことで、初めてシステム設計が経営戦略の一部として機能します。
経営者が当事者になるとき、システム設計は経営戦略になる
ベンチャーネットが NetSuite 導入を支援する際、まず経営者の方と向き合う時間を大切にしています。
技術選定の話よりも先に、「今後の事業ポートフォリオをどう描いていますか」「5年後、いまの会社のかたちをどう変えたいですか」という対話から始めます。
その対話の中で、システム設計の方向性が見えてきます。
カーブアウトは、ITプロジェクトではなく経営プロジェクトです。
経営者が当事者として向き合った瞬間、システム設計は経営戦略を形にする道具になります。
「売れる状態」を維持する経営の発想
ここで、視点をもう一段変えてみます。
これまで「カーブアウトをスムーズに進める」という観点で書いてきましたが、本当に大事なのは、その先にあります。
それは——
売却するかどうかにかかわらず、「いつでも売れる状態」を維持しておくこと自体が、経営の選択肢を広げる
ということです。
カーブアウト準備とは、売却前提の準備ではありません。経営者が事業に対して持つ柔軟性そのものです。
売却する・しないは、後で決められる
中堅企業の経営者の方とお話していると、こんな声を聞きます。
「いまはまだ、売却を具体的に考えているわけじゃない。でも、5年後、10年後はわからない」
これは健全な経営感覚です。
経営環境は変わります。
市場が縮小したり、新しい技術が登場したり、後継者問題が浮上したり——5年後の自社がどんな状況にあるかは、誰にも分かりません。
そんなとき、「売る」という選択肢が手元にあるかどうかは、経営の自由度に大きな差を生みます。
ところが、いざ売ろうとして、システムの問題で売れない——というのが、本記事の冒頭で挙げた典型的な失敗パターンです。
逆に、いつでも切り出せる構造を持っていれば、売却するかしないかは、経営者がそのときの判断で決められることになります。
「準備しておく」と「実行する」は別物です。
準備しておくことに、リスクはありません。リスクがあるのは、準備していないまま選択肢を失うことです。
「売れる状態」が経営にもたらす3つの自由度
「いつでも売れる状態」を持つことは、3つの自由度を経営にもたらします。
自由度1:事業ポートフォリオの組み替え
ノンコア事業を切り出し、コア事業に集中する。
新規事業を立ち上げ、既存事業の一部を整理する。
こうした事業ポートフォリオの組み替えが、経営判断のタイミングで実行できます。
自由度2:経営資源の再配分
切り出した事業のリソース(人材・資金・経営の関心)を、成長領域に振り向けられます。
これは、選択と集中を可能にする基盤です。
自由度3:出口戦略の多様化
事業承継・IPO・MBO・M&A——経営者には複数の出口戦略があります。
「売れる状態」を持っていれば、どの戦略を選ぶかを、経営環境に応じて柔軟に決められます。
これらの自由度は、いずれも「事業を切り分けられる」というシステム基盤があって初めて実現します。
経営の選択肢を持つというシステム投資
NetSuite のような事業切り出しに対応できるERPに投資することは、事業売却の準備に投資することではありません。
それは、経営の選択肢を持つことへの投資です。
売るかもしれないし、売らないかもしれない。
分割するかもしれないし、統合するかもしれない。
コアを変えるかもしれないし、変えないかもしれない。
5年後、10年後の経営判断において、選択肢を持っているか持っていないか——その差を作る投資です。
ベンチャーネットは、お客様のシステム投資を「IT予算」ではなく「経営の自由度を上げるための投資」と位置づけてご支援しています。
実例から見る——「選択と集中」としてのカーブアウト
ここまで読み進めて、こう感じている方もいるかもしれません。
「カーブアウトの話をしているのに、ずいぶんと攻めの経営寄りな論調だな」と。
その通りです。
実際、ベンチャーネットが NetSuite 導入を支援してきた企業の中には、事業切り出しを「攻めの経営戦略の一環」として実行してきた会社があります。
ここでは、2つの実例を通じて、カーブアウトが選択と集中による成長戦略になりうることを見ていきます。
キュリエ様:IPO に向けた事業ポートフォリオの組み替え
株式会社キュリエ様は、プリンター用の互換インクやトナーなど、オフィスサプライの輸入・卸売を主軸に成長してきた企業です。
近年は EC への販売シフトを進め、楽天ショップ・オブ・ザ・イヤーを複数回受賞するなど、オンライン販売の領域でも実績を築かれています。
そして 2024年、新規事業「スマラピ」を立ち上げられました。
従来とは異なる顧客層・商流に踏み出した、事業ポートフォリオ拡張への布石です。
ここで生まれたのが、「コア事業に集中するために、ノンコアの事業部を切り出す」という経営判断です。
具体的には、法人事業部を売却し、生まれたリソース(人材・資金・経営の関心)を新規事業「スマラピ」に集中投入する。
これは IPO を見据えた選択と集中の一環として位置づけられた判断でした。
このとき、システム面での切り出しを可能にしたのが、NetSuite のマルチエンティティ機能です。
事業部ごとに独立した会計単位(Subsidiary)として運営する構造を採用していたため、事業部別の財務データが整理された状態で、デューデリジェンスに臨むことができました。
これは「過去の経営判断としては正しかった全社統合」をやり直すことなく、必要なときに事業を切り分けられる、クラウドERPの構造的なメリットを実証する事例です。
APEX様:レガシーERPからの脱却で「将来の選択肢」を確保
株式会社APEX様は、27年間使用してきた SAP R/3 の保守終了を機に、基幹システムを Oracle NetSuite で全面刷新された企業です。
APEX 様の事例は、必ずしも「目の前の事業売却」が動機だったわけではありません。
むしろ、「将来の事業再編にも柔軟に対応できる体制を整える」という経営判断が背景にありました。
オンプレミス型 SAP の密結合構造から脱却し、NetSuite のマルチエンティティ対応によって、事業単位での独立運用を実現しました。
これにより、現時点で事業の切り出しを計画しているわけではなくても、いつでも切り出せる構造を備えた経営基盤を持つことができます。
これは、前章で述べた「売れる状態を維持すること自体が経営の自由度を上げる」という発想を、実装レベルで体現した事例といえます。
2つの事例に共通する経営観
キュリエ様と APEX 様の2つの事例には、ある共通点があります。
それは、システム投資を「IT予算」ではなく「経営戦略を実現するための投資」と捉えていることです。
キュリエ様は、IPO に向けた選択と集中という経営戦略のために NetSuite を活用しました。
APEX 様は、将来の事業再編に備えるという経営戦略のために NetSuite を活用しました。
どちらの場合も、システムは経営判断の道具です。
「事業ポートフォリオをどう描くか」「将来どんな選択肢を持っておきたいか」
——こうした経営者の問いに対する答えが先にあって、それを実現するためのツールとして NetSuite が選ばれています。
これが、カーブアウトを ITプロジェクトではなく経営プロジェクトとして捉える、ということの実例です。
よくある質問(FAQ)
事業切り出し・カーブアウトに関して、経営者の方から繰り返し寄せられる質問にお答えします。
Q1. 売却を具体的に考えていなくても、本記事を読む意味はありますか？
A1.
はい、むしろ「いまは具体的に考えていない方」にこそ読んでいただきたい内容です。
事業売却・カーブアウトを準備しておくことの本質は、「売却するかどうかを、経営者がそのときの判断で決められるようにしておく」ことにあります。
いざ売ろうとしてシステムの問題で売れない、というのは、経営の選択肢を失うことと同じです。
逆に、いつでも切り出せる構造を備えていれば、売却するかしないかは経営判断のタイミングで決められます。
これは経営の柔軟性を上げる投資です。
Q2. 事業ポートフォリオの見直しは、どのタイミングで考え始めるべきですか？
A2.
明確な「正解のタイミング」はありませんが、システム面の準備は早ければ早いほど経営の柔軟性が上がります。
事業切り出しの準備は、システム導入や会計設計の段階から始まっています。
すでに ERP を運用している企業の場合は、次のリプレイス検討や機能追加のタイミングが見直しの好機です。
これから ERP を選定する企業の場合は、最初からマルチエンティティ対応のクラウドERPを採用しておけば、将来の事業再編にも柔軟に対応できる経営基盤を構築できます。
ベンチャーネットでは、お客様の事業構造をうかがいながら、「今後5〜10年で起こりうる事業ポートフォリオの変化」を想定したシステム設計を一緒に組み立てています。
Q3. NetSuite でカーブアウト準備を進める場合、どれくらいの期間とコストが必要ですか？
A3.
事業規模・組織複雑性・既存システムの状況によって幅がありますが、おおまかな目安をお伝えします。
新規導入の場合
NetSuiteのライセンスは、ミニマム構成・出発点として月20万円〜です。
利用するモジュール・ユーザー数・必要なオプションによって変動し、規模次第では数百万円規模になることもあります。
既存システムからの移行の場合
レガシーERPからの移行は、データ移行と業務プロセスの再設計が必要になるため、6か月〜12か月の期間を見込むケースが一般的です。
最終的な金額の提示は Oracle 営業のみが行います。
概算のお見積りも、認定パートナーであるベンチャーネットを通じて Oracle 営業と共にご対応いたします。
ご検討段階での無料相談から承っていますので、まずはお気軽にお問い合わせください。
Q4. すでに別の ERP や SAP を使っているのですが、移行は可能ですか？
A4.
可能です。
実際、ベンチャーネットがご支援してきた企業の中には、オンプレミス型 SAP や国産ERPからの移行案件も含まれています。
移行プロジェクトのポイントは、既存システムの「業務ロジック」を、NetSuite の標準機能でどこまでカバーできるかを見極めることです。
長年の運用で蓄積された業務カスタマイズを、すべてそのまま NetSuite に持ち込もうとすると、移行コストが大きくなり、クラウドERPの利点も失います。
そのため、移行プロジェクトでは「残す業務ロジック」と「標準機能に合わせる業務ロジック」を経営判断レベルで仕分ける作業が必要です。
これは IT 領域の話というより、業務改革の経営判断に近いものです。
ベンチャーネットでは、お客様の業務を整理しながら、「いつでも切り出せる構造」を備えた次世代の業務基盤を一緒に設計します。
参考リンク:NetSuite – 基幹システムリプレイスサービス
Q5. PMI(買い手側の経営統合)の話とどう違うのですか？
A5.
本記事は 売り手・切り出す側の視点 で書いていますが、カーブアウトには売り手と買い手の両面があります。
簡単に整理すると、次のようになります。
- 本記事(売り手側):事業を切り出す側の準備、システム分離、デューデリ対応、TSA 設計など
- PMI(買い手側):事業を買い取った側の経営統合、業務統合、シナジー創出など
両者は時系列でも論点でも異なります。
買い手側として M&A 後の経営統合に取り組まれる方は、別記事M&A後のPMI完全ガイド｜「業務統合」でつまずかないためのシステム・データ統合の進め方をご参照ください。
なお、ベンチャーネットでは売り手側のカーブアウト支援も、買い手側の PMI 支援も、両方の立場でご相談を承っています。
まとめ:事業の自由度を上げるシステム投資という視点
ここまでお伝えしてきた内容を、3つの要点に整理します。
要点1:カーブアウトが頓挫する原因は、ほとんどがシステムにあります
事業部別P/Lが出せない、基幹システムが全社一体型、業務プロセスが親会社に依存している——これが、本記事で見てきた3パターンです。
いずれも、ベンチャーネットがNetSuite 導入支援の現場で繰り返し見てきた典型的な障害です。
要点2:レガシーERPからクラウドERPへの移行が、構造的な解決策になります
NetSuite のマルチエンティティ対応は、「全社統合」と「事業分離」を両立させた構造を提供します。
これにより、事業切り出しの所要期間が大幅に短縮され、デューデリへの対応も円滑になります。
要点3:これは IT 投資ではなく、経営の自由度を上げる投資です
事業ポートフォリオの組み替え、経営資源の再配分、出口戦略の多様化——これらの経営判断を「いつでも実行できる」状態にしておくこと自体が、経営の柔軟性を高めます。
事業売却は、後ろ向きの経営判断ではありません。
むしろ、経営者が事業に対して持つ柔軟性そのものです。
売る・売らない、組み替える・組み替えない、集中する・拡げる——そのとき、その判断を経営者が自由に行えるかどうかは、普段からのシステム設計に大きく依存しています。
ベンチャーネットは、お客様のシステム投資を「IT予算」ではなく「経営の自由度を上げるための投資」と位置づけて、伴走型でご支援しています。
事業の選択肢を持つこと——それが、いまの経営者に求められている構えだと、私たちは考えています。
ベンチャーネットへのご相談——「経営の選択肢」を整える第一歩を
ここまで読み進めていただき、ありがとうございました。
事業切り出しの検討は、必ずしも「今すぐ売却したい」という段階で始まるものではありません。
むしろ、「将来の選択肢を広く持っておきたい」という経営者の構えから始まります。
ベンチャーネットでは、こうした経営者の構えに寄り添う形で、2つのご相談窓口を用意しています。
事業切り出し・カーブアウトを具体的に検討中の方へ
事業売却・子会社売却に向けたシステム分離の支援サービスです。
デューデリ対応・TSA 設計・データ移行など、カーブアウトプロジェクトを包括的にご支援します。
まずは現状を整理したい・選択肢を広げたい方へ
「具体的な売却予定はないが、将来に備えて準備しておきたい」「いまのERPで本当に対応できるのか確認したい」——そんな段階のご相談も歓迎しています。
私たちは、お客様と対等なパートナーとして、現状の整理から始められる伴走スタイルでご支援しています。
売却を煽ることはありません。一緒に経営の選択肢を考えるところから始めましょう。
あわせて読みたい
- M&A後のPMI完全ガイド｜「業務統合」でつまずかないためのシステム・データ統合の進め方——本記事の裏返しとして、買い手側の経営統合論
- M&Aで高く売れる事業とは？AIで企業価値を磨く中堅・中小企業の経営戦略——売却前の企業価値づくりの観点
- NetSuite×M&A・PMIコンサルティング——M&A 全般のシステムコンサル支援
- NetSuite – 基幹システムリプレイスサービス——レガシーERPからの移行支援
