「老朽化したシステムをどこから手をつければよいか」「外部ベンダーに依頼したいが、何を決めてから発注すればよいかわからない」――システムリアーキテクチャ（アーキテクチャの再設計・刷新）の発注において、こうした悩みを抱える担当者が急増しています。2025年版DX推進指標（経済産業省）では、調査対象企業の約63%が「既存システムの複雑性・老朽化がDXの障壁」と回答しており、システムリアーキテクチャへのニーズは今後さらに高まる見通しです。
しかしリアーキテクチャは、通常のシステム開発と比べてリスクが格段に大きい取り組みです。稼働中のシステムを段階的に刷新しながら事業継続を維持しなければならず、契約形態の選択を誤れば費用超過・スケジュール遅延・責任の押し付け合いへと発展します。本記事では、システムリアーキテクチャの外注・発注方法について、発注前の準備から契約モデルの選択、プロジェクト体制の設計、よくあるトラブルの回避策まで、実務に直結する形で解説します。
本テーマに関する全体ガイドは、以下の記事をご覧ください。
▼全体ガイドの記事
・システムリアーキテクチャの完全ガイド
システムリアーキテクチャの発注方法 — 失敗しないための準備
リアーキテクチャプロジェクトが失敗する最大の原因は、「発注前の準備不足」です。IPA（独立行政法人情報処理推進機構）の調査では、システム再構築プロジェクトの失敗事例の約70%が「要件定義フェーズでの認識齟齬」に起因しているとされています。ベンダーに依頼する前に社内で決めておくべき事項を整理することが、プロジェクト成功の最初の一歩です。
発注前に社内で決めるべき5つの事項
ベンダーへの発注前に、以下の5点を社内で合意しておくことが不可欠です。これらが未決定のまま発注すると、要件変更が頻発し、追加費用と納期遅延を招くリスクが高まります。
①移行の目的とゴール指標の定義
「なぜリアーキテクチャが必要か」を事業的な言葉で明確にします。「デプロイ頻度を現在の月1回から週2回以上に引き上げる」「障害復旧時間（MTTR）を現在の8時間から1時間以内に短縮する」「インフラコストを年間3000万円削減する」など、具体的な数値目標を設定します。目的が曖昧なままだと、ベンダーも適切な提案ができず、完了判定の基準も失われます。
②対象スコープの確定
「どのシステム・どのモジュールを対象とするか」を明確にします。全システムを一括で刷新するのか、特定のマイクロサービス単位で段階的に進めるのかを決定します。スコープが不明確だと、ベンダーは保守的な見積もりを提示せざるを得なくなり、発注金額が肥大化します。「フロントエンドのリアーキテクチャのみ」「認証基盤と決済モジュールを優先」など、優先度付きのスコープ定義が有効です。
③移行アプローチの方針（段階的 vs 一括）
システムリアーキテクチャには大きく「ビッグバン型（一括移行）」と「ストラングラーフィグ型（段階的移行）」があります。現在主流はストラングラーフィグ・パターンで、既存システムを稼働させたまま新アーキテクチャを周辺から少しずつ置き換える手法です。ガートナーの調査では、ストラングラーフィグ型を採用したプロジェクトの成功率は一括型の約2.4倍とされています。どちらのアプローチを取るかによって、契約形態・期間・体制が大きく変わるため、発注前に方針を固めておく必要があります。
④予算とスケジュールの枠組み
予算の上限（概算でも可）とプロジェクト完了の期限（またはマイルストーン）を設定します。リアーキテクチャプロジェクトは長期にわたることが多く、2年以上の期間を要するケースも珍しくありません。「第1フェーズを6ヶ月・予算5000万円で完結させ、成果を見て第2フェーズを判断する」といったフェーズ分割の考え方を最初から導入することで、予算コントロールと意思決定の柔軟性を確保できます。
⑤データ移行と既存システム運用の継続方針
リアーキテクチャ期間中、既存システムはどう運用するか、データベースのスキーマ変更はどのタイミングで行うか、移行期間中のデータ整合性はどう担保するかを事前に検討しておきます。これらは技術的な難易度が高く、ベンダーとの初期協議で必ず論点になるため、社内で基本方針を持っておくことが重要です。
RFP作成とベンダー選定のポイント
リアーキテクチャのRFP（提案依頼書）は、通常のシステム開発とは異なる記載事項が必要です。既存システムの構成情報をどこまで開示するか、どのような移行シナリオを検討しているかを含めて提示することで、ベンダーからより具体的・現実的な提案を引き出せます。
RFPに必ず含めるべき項目：
①現行システムの概要（技術スタック・年齢・規模）、②リアーキテクチャの目的と数値目標、③対象スコープと優先順位、④移行アプローチの方針（段階的/一括）、⑤非機能要件（可用性・性能・セキュリティ）、⑥制約条件（既存インフラ・外部連携先・法規制）、⑦評価基準（技術力・実績・コスト・サポート体制の重み付け）。
ベンダー選定では、単なる開発実績だけでなく「リアーキテクチャ専門の経験」を重視します。マイクロサービス化・クラウドネイティブ移行・モノリス分割などの実績案件数、アーキテクトの資格保有状況（AWS認定ソリューションアーキテクト・Google Cloud Professional Cloud Architectなど）、段階的移行における責任分界点の設計経験を具体的に確認することをおすすめします。
契約モデルの比較と選択（一括請負 vs 準委任 vs MaaS）
システムリアーキテクチャの発注で最も重要な意思決定の一つが「契約モデルの選択」です。誤った契約モデルを選ぶと、プロジェクトが中盤以降に行き詰まるリスクがあります。2025年以降、従来の一括請負・準委任に加え、MaaS（Modernization as a Service）と呼ばれるサブスクリプション型の新しい契約モデルが台頭しており、それぞれの特性を正しく理解した上で選択することが求められます。
3つの契約モデルの特徴と適用場面
各契約モデルの特徴を整理します。
①一括請負型（固定価格契約）
ベンダーが成果物（刷新後のシステム）の完成を約束し、完成に対して報酬を支払う契約形態です。スコープと要件が明確に確定している場合に向いています。発注者にとっては予算が確定する安心感がありますが、要件変更が発生すると追加費用が膨れやすく、ベンダーは利益を守るために品質・スコープを絞る傾向があります。
リアーキテクチャへの適用：要件が固まっている小規模なモジュール単位での刷新や、技術スタックの移行（例：Java EE→Spring Boot）など、変化の少ない部分に限定して使用するのが適切です。全システムを対象とした一括請負は、スコープ外のトラブルリスクが高く、現在では避けるべきとされています。
②準委任型（時間・材料契約）
ベンダーが一定の業務（アーキテクチャ設計・実装・レビュー等）を遂行し、工数に応じた報酬を支払う契約形態です。要件が不確定な段階でも柔軟に開発を進められるため、アジャイル開発との相性が良く、リアーキテクチャプロジェクトで最も多く採用されている形態です。発注者が常にプロジェクトの方向性を制御できる反面、コストのコントロールが難しいというデメリットがあります。
リアーキテクチャへの適用：要件定義・アーキテクチャ設計フェーズ、段階的移行を進めるスプリント型開発、試行錯誤を伴うパフォーマンス改善など、変化が多い局面に適しています。月次で成果を確認しながら継続判断できる形で契約するとリスクを抑えられます。
③MaaS（Modernization as a Service）型
2024年ごろから国内でも普及が進む新しい契約モデルで、システムモダナイゼーション（近代化）をサブスクリプション形式で提供するものです。月額固定費でアーキテクチャ改善・技術的負債の解消・継続的なリファクタリングを行い、発注者は一括の大型投資をせずに継続的な品質向上を実現できます。
リアーキテクチャへの適用：長期にわたる段階的移行（2〜5年規模）を見据えているケース、社内エンジニアとベンダーが継続的に協働するケース、クラウドネイティブへの移行を段階的に進めたいケースに向いています。国内ではまだ対応ベンダーが限られますが、大手SIerやクラウドインテグレーターを中心に提供が広がっています。
フェーズ分割契約のメリットと設計方法
リアーキテクチャプロジェクトで特に有効な手法が「フェーズ分割契約」です。プロジェクト全体を複数のフェーズに分け、各フェーズごとに別契約を締結する方式で、以下のメリットがあります。
フェーズ分割のメリット：
①各フェーズで成果を確認してから次フェーズに進めるため、プロジェクトの方向性修正が容易になる。②フェーズごとにベンダーを変更・追加できるため、競争原理が働きコスト最適化が図れる。③発注者・ベンダー双方にとって過大なコミットメントを避けられるため、健全なパートナーシップが維持しやすい。④会計・予算管理上も年度をまたがる大型投資ではなくフェーズごとの計上が可能になる。
フェーズ分割の設計方法：
一般的なリアーキテクチャプロジェクトのフェーズ設計例として、以下の4段階が参考になります。
フェーズ0（アセスメント・設計：1〜3ヶ月）：現状分析・技術的負債の可視化・移行ロードマップ設計。成果物：アーキテクチャ診断レポート・移行計画書。契約：準委任または固定価格の診断契約。
フェーズ1（コアコンポーネントの刷新：3〜6ヶ月）：認証基盤・APIゲートウェイなど基盤部分の先行移行。成果物：本番稼働する新アーキテクチャの第1弾。契約：準委任（スプリント型）または小規模請負。
フェーズ2〜N（機能単位での段階移行：各3〜6ヶ月）：ストラングラーフィグ・パターンで機能単位を順次移行。契約：準委任またはMaaS型で継続。
フェーズ終了（旧システム廃止）：全機能の移行完了後、旧システムの廃止・データ最終移行・ドキュメント整備。契約：請負（成果物型）が適切。
各フェーズの「ゴール定義（何が完了したらフェーズを終了とするか）」と「継続判断の基準（どの指標が達成されれば次フェーズに進むか）」を最初から設計しておくことが、フェーズ分割契約を有効に機能させる鍵です。
発注から完了までのプロジェクト体制
システムリアーキテクチャプロジェクトの成否は、外部ベンダーの技術力だけでなく、発注者側（社内）の体制構築にも大きく左右されます。「ベンダーに任せきりにした結果、誰も詳細を把握していない状態になった」という失敗は珍しくありません。社内に適切な役割と権限を持つ人材を配置することが、プロジェクト成功の必要条件です。
社内に必要な体制 — アーキテクトとPO/PMの役割
リアーキテクチャプロジェクトにおいて、社内に最低限確保すべき役割は以下の3つです。
①社内アーキテクト（または技術統括者）
ベンダーが提案するアーキテクチャ設計を評価・承認できる技術的判断力を持つ人材です。「このマイクロサービス分割は適切か」「新しいデータベース設計は既存業務要件を満たしているか」などを判断できなければ、ベンダーの提案をそのまま受け入れるしかなくなります。社内にアーキテクトがいない場合は、第三者のアーキテクトをコンサルタントとして活用するか、アーキテクチャレビュー専門のベンダーを別途起用することを検討してください。
なお、日本国内ではアーキテクト人材は需要過多の状態が続いており、フリーランスのアーキテクトを週2〜3日のコンサルティングとして確保するケースも増えています。費用の目安は月額80万〜150万円程度です。
②プロダクトオーナー（PO）
リアーキテクチャの優先順位を事業観点から決定する役割です。「どの機能を先に移行するか」「移行コストと事業継続性のトレードオフをどう判断するか」はビジネス判断であり、技術者だけで決定すべきではありません。POは経営レイヤーに近い立場から意思決定を行い、スプリントごとのバックログ優先付けにも関与します。
③プロジェクトマネージャー（PM）
プロジェクト全体の進捗・リスク・コストを管理し、社内とベンダー間のコミュニケーションを円滑にする役割です。リアーキテクチャプロジェクトでは「過渡期」が長期にわたるため、新旧システムの並行稼働中のリスク管理・マイルストーン管理・ステークホルダーへの報告が特に重要です。PMが社内にいない場合は、ベンダーのPMに依存せず、PMO（プロジェクト管理オフィス）機能を外部コンサルに委託することも選択肢の一つです。
段階的マイルストーンの設計と進捗管理方法
リアーキテクチャプロジェクトは長期にわたるため、進捗を可視化・管理する仕組みが不可欠です。「気づいたら半年経過しているが何が完了したかわからない」という状態を防ぐために、マイルストーンの設計と進捗測定指標を事前に定義しておきましょう。
効果的なマイルストーン設計の原則：
①各マイルストーンは「具体的な成果物」で定義する（「設計完了」ではなく「アーキテクチャ設計書v1.0がレビュー承認済み」のように明確に）。②ビジネス的な価値が確認できるマイルストーンを設ける（「本番トラフィックの10%を新アーキテクチャで処理開始」など）。③各マイルストーンに「合格基準（Definition of Done）」を設定する（応答時間・エラー率・可用性など定量的指標）。
進捗管理で使うべき指標：
技術的な進捗を測る指標として、①移行済みマイクロサービス数／全体数、②新アーキテクチャが処理するトラフィック比率（%）、③テクニカルデット解消件数、④デプロイ頻度（週次）、⑤自動テストカバレッジ率（%）などが有効です。これらをダッシュボード化し、週次の定例レビューで確認する運用を定着させましょう。
過渡期の責任分界点の明確化：
新旧システムの並行稼働期間中は、「どの機能・データが旧システム側にあり、どの範囲が新システムで管理されているか」の責任分界点を常に最新状態で管理することが重要です。障害発生時の対応先（旧システムか新システムか）が不明確だと、復旧に大幅な時間がかかります。フェーズごとに「責任分界点マトリクス」を作成・更新し、社内チームとベンダー双方が常に参照できる状態を維持してください。
発注時の注意点 — よくあるトラブルと回避策
システムリアーキテクチャプロジェクトは複雑性が高く、特有のトラブルが発生しやすい性質を持っています。ここでは、実際のプロジェクトで頻繁に発生するトラブルパターンとその回避策を解説します。
スコープクリープの防止策 — アーキテクチャ適合テストの活用
スコープクリープ（当初想定外の作業が継続的に追加されてプロジェクトが膨張する現象）は、リアーキテクチャプロジェクトで最も頻繁に発生するトラブルの一つです。PMI（プロジェクトマネジメント協会）の調査によると、ITプロジェクトのスコープクリープ発生率は52%に上り、その結果として平均予算超過率は27%とされています。
スコープクリープの主な発生パターン：
①「せっかくだから」型：移行のついでに旧システムになかった機能を追加するよう求められる。②「未定義発見」型：既存システムの調査を進める中で、文書化されていない機能や連携が次々と発見される。③「要件変化」型：プロジェクト中盤以降に業務要件や外部環境が変化し、移行対象の仕様変更が発生する。
有効な防止策①：アーキテクチャ適合テスト（Architecture Fitness Functions）の導入
アーキテクチャ適合テストとは、新アーキテクチャが設計上の原則（制約）を満たしているかを自動テストで継続的に検証する手法です。例えば「マイクロサービスAはマイクロサービスCを直接呼び出してはならない（APIゲートウェイ経由であること）」というアーキテクチャ上のルールを自動テストとして実装し、CIパイプラインで常時チェックします。これにより、「スコープ外の機能追加がアーキテクチャの整合性を崩している」という状況を早期に検出できます。ArchUnit（Java）・NetArchTest（.NET）などのツールを活用すると実装コストを抑えられます。
有効な防止策②：変更管理プロセスの確立
すべてのスコープ変更を「変更要求書」として文書化し、工数・コスト・スケジュールへの影響を見積もった上で、権限者の承認を必須とするプロセスを設けます。「軽微な変更（1日以内の対応）は変更管理不要」という例外を作ると、そこから徐々に積み重なるケースが多いため、例外なく全変更を記録することを推奨します。
有効な防止策③：発注前の「現行システム調査フェーズ」の設置
スコープクリープの「未定義発見」型を防ぐには、本格的な開発契約の前に「現行システム調査フェーズ（アセスメント）」を別契約で実施することが有効です。隠れた機能・外部連携・データ構造を徹底的に洗い出してから本契約のスコープを確定させることで、後からの「実は〇〇機能もあった」というサプライズを減らせます。アセスメントの費用は数百万円が相場ですが、後工程でのスコープクリープによる損失を考えれば十分に元が取れる投資です。
過渡期のリスク管理と責任分界点の設計
新旧システムの並行稼働期間（過渡期）は、リアーキテクチャプロジェクトで最もリスクが高い期間です。以下のようなトラブルが頻繁に発生します。
よくあるトラブル①：データの二重書き込み問題
過渡期には、旧システムと新システムの両方にデータが存在する状態が生じます。どちらが「正」のデータか、更新した場合の同期タイミングはどうするかが不明確だと、データ不整合が発生します。
回避策：Strangler Fig パターンに加えて「データ同期レイヤー」を設計し、どのタイミングでデータの「正源（Source of Truth）」が旧から新に切り替わるかを明確に定義・管理します。
よくあるトラブル②：障害発生時の責任の曖昧さ
並行稼働中に障害が発生した際、「旧システムの問題か新システムの問題か」が判断できず、復旧対応が遅延します。ベンダーと発注者の間で「これは旧システムの問題だからベンダーの責任ではない」という押し付け合いも発生します。
回避策：フェーズごとの「責任分界点定義書」を事前に作成し、どのコンポーネント・機能について誰が責任を持つかを明文化します。また、障害対応フローも旧システム・新システム・データ連携層ごとに分けて定義し、エスカレーションパスを明確にしておきます。
よくあるトラブル③：セキュリティ・コンプライアンスの抜け漏れ
移行作業に集中するあまり、新アーキテクチャのゼロトラスト設計やDevSecOps（開発・セキュリティ・運用の統合）の実装が後回しになるケースがあります。特に、旧システムのセキュリティホールを新システムに引き継いでしまうリスクがあります。
回避策：フェーズ0のアセスメント段階でセキュリティ評価（ペネトレーションテスト・脆弱性診断）を実施し、新アーキテクチャへの移行基準にセキュリティ要件を含めます。CIパイプラインにSAST（静的解析）・DAST（動的解析）ツールを組み込み、セキュリティ検証を継続的に自動化することを契約要件に含めることを推奨します。
よくあるトラブル④：ベンダー依存（ロックイン）の発生
特定のクラウドサービス・独自フレームワーク・プロプライエタリツールへの過度な依存が生じると、将来的なベンダー変更や技術選定の自由度が失われます。
回避策：契約書にソースコードの知的財産権の帰属（発注者への帰属が基本）・ドキュメント納品の義務化・技術選定の合理的な理由開示義務を盛り込みます。特定ベンダーの独自サービスを中核に据えた設計を避け、オープンな標準技術を優先するアーキテクチャ方針を定めておくことも重要です。
まとめ
システムリアーキテクチャの外注・発注を成功させるには、以下の6つのポイントを押さえることが重要です。
①発注前に社内で5つの事項を確定する：移行の目的・スコープ・アプローチ・予算・データ移行方針を明確にしてからベンダーへのRFPを作成する。準備不足のまま発注するとプロジェクト中盤での大幅な方向転換が発生しやすい。
②契約モデルを目的・フェーズに合わせて選ぶ：リアーキテクチャは変化が多いため準委任型またはMaaS型が基本。固定スコープの小規模移行は請負、長期継続的な改善はMaaS型を検討する。フェーズ分割契約を積極的に活用し、各フェーズで成果を確認してから次フェーズに進む。
③社内体制として3つの役割を確保する：アーキテクト（技術判断）・PO（優先順位決定）・PM（進捗・リスク管理）を社内または外部コンサルで確保する。ベンダー任せにすると、完成物を評価・制御できなくなるリスクがある。
④段階的マイルストーンと責任分界点マトリクスを設計する：各マイルストーンを「具体的な成果物と数値基準」で定義し、過渡期の新旧システムの責任範囲を常に最新状態で管理する。これにより障害発生時の混乱を最小化できる。
⑤スコープクリープをプロセスと技術の両面で防ぐ：変更管理プロセスの確立と、アーキテクチャ適合テスト（Architecture Fitness Functions）の自動化により、スコープの肥大化と設計原則の逸脱を早期に検出する。
⑥過渡期のリスクを契約・技術・運用の3層で対策する：データ整合性・責任分界・セキュリティ・ベンダーロックインの各リスクに対し、契約書・アーキテクチャ設計・運用手順の3層で対策を講じる。
システムリアーキテクチャは、適切に進めれば組織のデジタル競争力を根本的に強化できる取り組みです。しかし、準備不足や契約設計の誤りが原因で失敗するプロジェクトも後を絶ちません。発注を検討している場合は、まず社内の課題・目標・体制を整理した上で、リアーキテクチャの実績を持つ専門パートナーに相談することをおすすめします。riplaでは、システムリアーキテクチャの発注前相談から要件定義支援・ベンダー選定サポートまで対応しています。お気軽にご相談ください。
本テーマに関する全体ガイドは、以下の記事をご覧ください。
▼全体ガイドの記事
・システムリアーキテクチャの完全ガイド
株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。