基幹システム/ERPリアーキテクチャでは、モノリシックな基幹システムを、業務のドメイン境界に沿ってマイクロサービスに分け直します。その前にPoC（概念実証）やプロトタイプで、分解後の構造が実際に運用できるかを確かめます。
移行アプローチの選び方は、モダナイゼーションの記事で扱っています。その記事は、リホスト、リプラットフォーム、リファクタリング、リビルド、リプレースの5つの手法を横断して扱う総論です。同じ基幹システム/ERPでも、刷新は経営層の投資判断、更改は保守契約やハードウェアリースの満了、リニューアルは画面と操作性を主軸に据えた記事です。
これに対して本記事は、リファクタリングとリビルドをさらに一段深掘りした、IT部門やアーキテクト、エンジニア向けの技術記事です。
このテーマの全体像は、次の記事で確認できます。
▼全体ガイドの記事
・基幹システム/ERPリアーキテクチャの完全ガイド
- リアーキテクチャの概要と、PoCが欠かせない理由
- ドメイン境界の妥当性検証（EventStormingとDDD）
- API設計のプロトタイピングと契約テストの進め方
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
基幹システム/ERPリアーキテクチャの概要と、アーキテクチャ検証PoCが不可欠な理由
リアーキテクチャは、既存の基幹システムの構造そのものを作り直す取り組みで、モノリスからマイクロサービスへの分解、DDD、API-first設計、クラウドネイティブのパターンが中心になります。
基幹システムの構造をマイクロサービスに分解して本番で稼働させると、日々の業務処理がその構造に依存します。そのため、後から境界を切り直すのは現実的に難しくなります。だからこそ、実装に着手する前の技術検証が、プロジェクト全体の成否を分けます。
モダナイゼーション・刷新のPoCとの違い（機能検証と基盤検証）
モダナイゼーションにおけるPoCは、選んだ移行アプローチが技術的に成り立つかを、サンドボックス環境での試験導入で確かめるのが中心です。刷新におけるPoCは、経営層の投資決裁を後押しする稟議材料としての側面が強く出ます。
本記事が扱うリアーキテクチャのPoCは、機能が動くかより、インフラと運用基盤が分散システムとして機能するかを技術的に検証することが主な目的です。コンテナ基盤やCI/CD、APIゲートウェイや分散トレーシングなどが期待どおりに連携し、開発者がインフラ維持に時間を取られず、サービスを独立してデプロイできるかを確かめます。この基盤検証が、他のPoCとの最大の違いです。
「動くか」より「運用できるか」を検証する考え方
従来のシステム開発におけるPoCは、多くの場合「この機能は技術的に実現できるか」という合否の判定が中心です。リアーキテクチャのPoCでは、個々の機能の実現性に加えて、ドメインをまたぐサービス群が長く安定して運用できる基盤になっているかを見ます。
境界の切り方を誤ったまま実装を進めると、複数のサービスが密結合した「分散モノリス」に陥り、開発速度がかえって落ちてしまいます。そのため、着手前にこうした構造上のリスクを洗い出すことが、リアーキテクチャのPoCの本質的な役割です。
ドメイン境界の妥当性検証（EventStormingとDDD）
アーキテクチャ検証の中で最も重要な工程が、ドメイン境界の妥当性検証です。ここで境界を誤ると、その後の実装工程のすべてに影響が及びます。
EventStormingワークショップによる境界づけられたコンテキストの定義
ドメイン境界の妥当性検証は、ドメインの専門家とエンジニアが一緒にビジネスプロセスを描く、EventStormingワークショップから始めます。会計や販売など各部門の業務担当者を集め、受注確定、出荷指示、請求確定といった業務イベントが、どの部門の責任範囲に属するかを付箋やホワイトボードで一覧にします。
この過程で、境界づけられたコンテキストと、部門を横断して誤解なく通じる共通言語（ユビキタス言語）を確立します。技術者だけで机上検討した境界は実際の業務フローとズレていることが少なくないため、業務担当者を巻き込んだ検証が欠かせません。
3〜5のコアドメインに絞った初期設計とデータ管理パターンの検証
境界を洗い出したら、最初からすべてを細かく分解せず、まず3〜5つのコアビジネスドメインに絞って初期設計を行います。あわせて、サービスごとにデータベースを分けるDatabase-per-Serviceを前提に、顧客や商品、従業員などのマスタデータをどう扱うかも検証します。
マスタデータの扱いには、イベントで他のサービスにデータを複製する方式と、共有の参照データサービス経由でAPIから取得する方式があります。どちらが自社の業務特性に合うかを小規模に試作して比べておくと、後工程での大規模なデータ不整合を防ぐ備えになります。
API設計のプロトタイピングと契約テスト
ドメイン境界が固まったら、サービス間の通信仕様を、コードを書く前に「契約」として定義し、プロトタイピングに進みます。
API-firstアプローチとモックサーバーによる並行開発
API-firstでは、OpenAPIやProtocol Buffersといった仕様を使い、APIの契約を「単一の信頼できる情報源」として最初に定義します。そのうえで、PrismやMockoonでモックサーバーを作っておけば、バックエンドの実装を待たずに、フロントエンドや他のサービスのチームが開発とテストを進められます。
基幹システム/ERPは、会計や生産など複数のチームが同時並行で開発に関わるケースが多いものです。そのため、モックサーバーを介して並行開発できる仕組みを整えられるかどうかが、実装フェーズ全体の日程短縮に直結します。
契約テストによるインターフェース検証
複数のサービスが独立して開発・デプロイされる環境では、あるサービスの変更が、別のサービスを意図せず壊してしまうリスクが常にあります。これを防ぐため、PactやSpring Cloud ContractをCIパイプラインに組み込み、互換性を損なう破壊的変更を自動で検査する契約テストを、PoCの段階から導入しておくことが推奨されます。
プロトタイプの段階で契約テストの運用フローを検証しておけば、本開発に入ってからサービス間の連携不具合に悩まされるリスクを大きく減らせます。
ストラングラーフィグパターンの最初のパイロットモジュール選定
「ビッグバン」を避け、ストラングラーフィグパターンで段階的に移行する場合、最初のターゲットの選び方がPoCの締めくくりとなる判断になります。
選定基準（垂直スライス・境界づけられたコンテキスト）
パイロットモジュールは、アプリケーション全体から「機能的な垂直スライス」か「1つの境界づけられたコンテキスト」を切り出して選びます。基幹システム/ERPでは、他のドメインとの依存が比較的少なく、業務インパクトを検証しやすいドメイン（在庫照会や見積管理など）を最初の対象にするケースがよく見られます。
一方で、会計は税務処理と密接に絡み、失敗が許されないドメインです。いきなり最初の対象に選ぶと、検証中のトラブルが経営リスクに直結しかねないため、リスクとリターンのバランスを踏まえて選ぶことが重要です。
最初の四半期の成功シグナルと次段階への判断
パイロットモジュールを選んだら、まず既存のモノリスと並行して新しいマイクロサービスを構築します。古いコードはフォールバックとして残し、トラフィックを新しいサービスへ少しずつ振り分けていきます。
最初の四半期（約3ヶ月）以内に、APIとサービスへの明確な分解、CI/CDパイプラインの自動化、旧システムの機能を損なわない独立稼働の3点が達成できていれば、プロジェクトは正しい軌道に乗っていると判断できます。そのうえで、次のドメインへ同じプロセスを反復していけます。
逆に、これらのシグナルが確認できない場合は、本開発への移行を急がず、境界の切り直しやインフラ整備をやり直す判断も検討すべきです。
PoC・プロトタイプの期間・費用感と実務ポイント
アーキテクチャ検証のPoCは、本開発に比べれば小規模な工程です。それでも一定の期間と費用がかかるため、事前に相場感を把握しておくことが、予算計画とよくある失敗の回避につながります。
期間3〜6ヶ月・費用感の目安とROIの捉え方
アーキテクチャ検証のPoC・パイロットフェーズは、期間3〜6ヶ月が目安です。費用は複雑さによって変わりますが、10万〜50万ドル（約1,500万〜7,500万円）の予算を見込んでおく必要があります。
この段階のROIは0%から-100%で、純粋なコストとして捉えるべきフェーズです。財務的なリターンは期待できず、インフラ構築とドメイン境界・API設計の妥当性検証に予算を投じる期間になります。
ただし、この3〜6ヶ月で技術基盤とパイロットモジュールの成功を証明できれば、MVPフェーズ（6〜12ヶ月でROI10〜30%）、本番フェーズ（12〜18ヶ月でROI50〜150%）へ進むための強い土台になります。経営層には、この期間を「その後の投資回収を確実にするための必要な準備期間」として説明することが大切です。
よくある失敗（過剰分解・境界誤り・検証範囲の偏り）
PoC段階でよくある失敗の一つは、最初から細かく分解しすぎることです。3〜5のコアドメインという規模を無視して10以上のサービスに一気に分けると、検証すべき組み合わせが爆発的に増え、期間内に妥当性を確かめきれなくなります。
もう一つの失敗は、技術者だけで境界を決め、業務担当者の検証を経ないまま実装に進んでしまうことです。EventStormingを省くと、後工程で「業務の実態と境界がズレていた」という致命的な手戻りにつながりかねません。
また、検証対象を1つのドメインだけに絞りすぎると、他のドメインとの連携パターンを見落としたまま次の段階に進んでしまいます。そのため、代表的な連携シナリオを最低限カバーする検証範囲を確保することが、PoCを形だけのものに終わらせないための実務ポイントです。
まとめ
ここまで、基幹システム/ERPリアーキテクチャのPoCで、アーキテクチャを実装前に検証する進め方を見てきました。ドメイン境界はEventStormingとDDDで、API設計はプロトタイピングと契約テストで確かめ、最初に切り出すモジュールは影響を検証しやすいものから選びます。
期間は3〜6ヶ月、費用は約1,500万〜7,500万円が目安です。この段階のROIは0%〜-100%となる純粋なコストとして捉える必要があります。
移行アプローチの選び方は基幹システム/ERPのモダナイゼーションの記事に、経営層の稟議材料としての活用は基幹システム/ERP刷新の記事に譲ります。特に重要なのは、業務担当者を巻き込んだドメイン境界の検証と、最初の四半期の成功シグナルの確認です。DDD・API設計・分散システム運用の実績が豊富なパートナーに、早めに相談することをお勧めします。
▼全体ガイドの記事
・基幹システム/ERPリアーキテクチャの完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。