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