既存のWebアプリやモバイルアプリが成長とともに技術的負債を抱え、「新機能を追加するたびにバグが増える」「インフラコストが急増している」「採用したエンジニアがコードを理解できない」といった課題を感じている担当者は少なくありません。そうした状況を打開するのが「アプリリアーキテクチャ（再設計・再構築）」の外注です。
しかしリアーキテクチャは通常の新規開発とは異なり、既存ユーザーへの影響を最小化しながら段階的に移行する難易度の高いプロジェクトです。本記事では、アプリリアーキテクチャをベンダーに発注・外注する際の全体フローから、準備すべきドキュメント、契約設計の注意点、段階的リリース計画の組み込み方まで、実務に即した方法論を詳しく解説します。
本テーマに関する全体ガイドは、以下の記事をご覧ください。
▼全体ガイドの記事
・アプリリアーキテクチャの完全ガイド
発注前に必ず行うべき準備作業
リアーキテクチャの外注を成功させるためには、発注前の準備が通常の新規開発以上に重要です。現状のシステムを正確に把握し、ベンダーに伝えられる状態にしておくことが、提案の質と開発精度を大きく左右します。
現在のアーキテクチャ図の作成と技術スタックの棚卸し
ベンダーへの最初の依頼資料として最も重要なのが、現在のシステムアーキテクチャ図です。フロントエンド・バックエンド・データベース・インフラ（クラウド・オンプレミス）の構成を可視化し、サービス間の依存関係を明示します。Webアプリであれば「フロントエンド（React/Vue等）→ APIサーバー（Node.js/Ruby on Rails等）→ DB（PostgreSQL/MySQL等）」のように、モバイルアプリであれば「iOS/Androidクライアント→ BFFレイヤー→ マイクロサービス群→ データストア」のような形で整理します。
技術スタックの棚卸しでは、以下の項目を一覧化しておきましょう。フレームワーク・ライブラリのバージョン（特にEOLに近いものはリアーキテクチャの優先度が上がります）、外部API・SaaSの依存関係、デプロイ方法（CI/CDパイプラインの有無）、テストコードのカバレッジ（多くのレガシーアプリはカバレッジが10〜20%未満であることが多い）、ドキュメントの整備状況です。
実際には、数年運用されたアプリでは「ドキュメントが存在しない」「当初の設計者が退職している」「本番のみに存在する設定がある」といったケースが珍しくありません。こうした「負債の実態」を正直にベンダーへ開示することが、現実的なスコープと費用見積もりにつながります。技術スタックの棚卸しに要する工数は、規模にもよりますが一般的に1〜2週間程度を見込んでください。
パフォーマンス要件の定量化とSLA定義
リアーキテクチャの目的の一つがパフォーマンス改善である場合、要件を定量的に定義することが契約上のトラブル回避に直結します。「速くする」「スケールさせる」という曖昧な表現ではなく、以下のような具体的なSLA（サービスレベル合意）を発注仕様書に明記します。
応答時間の目標値：APIのP95レイテンシを500ms以下（現状は平均2秒）、ページの初期表示をLCP（Largest Contentful Paint）2.5秒以下など、計測基準を含めて明示します。同時接続数・スループット：ピーク時の同時接続数1,000セッションを処理できること、1秒あたりのリクエスト処理数（RPS）が500以上を維持することなど。可用性：月間稼働率99.9%（ダウンタイム月43分以内）、計画メンテナンス時間の上限を規定します。スケーラビリティ：ユーザー数が現状の3倍になった際も追加インフラコストを○○円以内に抑える、オートスケーリング対応を必須とするなど。
これらのSLAをベンダーと合意した上で、本番リリース前の負荷テスト（Apache JMeter、k6、Locustなどのツールを使用）での検証を契約に組み込みます。負荷テストのシナリオ・合格基準・実施方法を事前に合意しておくことで、「要件を満たしているか否か」の検収判断を客観的に行えます。
リアーキテクチャ外注の全体フローと発注ステップ
リアーキテクチャの外注プロセスは、通常の新規開発と比べて「現状分析」「移行計画」に多くの工数がかかる点が特徴です。段階的に進めることでリスクを低減しながら、確実に移行を完了させることができます。
発注の6ステップ詳細（現状分析→RFP→選定→契約→移行→検収）
ステップ1：現状分析フェーズ（発注前）
前述のアーキテクチャ図・技術スタック棚卸し・パフォーマンス計測を実施します。現状の問題点（技術的負債の種類と量）、リアーキテクチャの目的（パフォーマンス改善・スケーラビリティ確保・開発速度向上・コスト削減等）、優先度の高い移行領域を明確化します。この段階で「すべてを一度に作り直す（Big Bang型）」か「段階的に移行する（Strangler Fig型）」かのアプローチも社内で方針決定しておきます。
ステップ2：RFP（提案依頼書）の作成
現状システムの詳細資料（アーキテクチャ図・技術スタック一覧・既知の問題点）を添付した上で、目標アーキテクチャのイメージ、スケジュール感（リアーキテクチャ完了の期限）、予算の目安、成果物要件（ソースコード・APIドキュメント・テストコード等）をRFPに明記します。リアーキテクチャ特有の項目として、移行中の既存サービス継続要件も必ず記載します。
ステップ3：ベンダー選定
3〜5社から提案を受け、技術力・移行実績・コミュニケーション能力・保守体制を総合評価します。リアーキテクチャは既存コードの深い理解が必要なため、「コードリーディングの品質」を評価軸に加えることを推奨します。提案書だけでなく、技術的なディスカッション（技術選定の理由・移行リスクの考え方）を通じてベンダーの実力を見極めましょう。
ステップ4：契約締結
後述する「リリース後の保守体制」を含む契約設計を行います。契約形態（請負型・準委任型のハイブリッドが多い）、知的財産権の帰属、移行期間中のSLA、検収基準を明確化します。
ステップ5：段階的移行の実施
フィーチャーフラグ等を活用した段階的なリリースで進めます。移行フェーズごとに中間チェックポイントを設け、品質と進捗を確認します。
ステップ6：最終検収とハンドオーバー
SLAで定めたパフォーマンス要件の充足確認（負荷テスト結果）、APIドキュメント・テストコードの成果物チェック、移行後の安定稼働確認（通常1〜2週間の監視期間）を経て検収完了とします。
リアーキテクチャ専門ベンダーの選定ポイント
リアーキテクチャを得意とするベンダーを見分けるためのチェックポイントを紹介します。
実績の質：「○件のリアーキテクチャ実績がある」だけでなく、「モノリスからマイクロサービスへの移行」「Railsアプリのモジュラーモノリス化」「レガシーAndroidアプリのKotlin化」など、具体的な技術スタックと課題に近い実績があるかを確認します。
移行アプローチの論理性：「Big Bang型（一気に全部作り直す）」は停止が難しいサービスには不向きであることを理解しているか、「Strangler Fig（ストラングラー・フィッグ）パターン」などの段階移行手法を提案できるかを評価します。Strangler Figパターンは、Martin Fowlerが提唱した移行パターンで、新旧システムを並行稼働させながら機能を段階的に移行する手法であり、サービスを停止せずにリアーキテクチャを進める際の標準的アプローチです。
テスト戦略への理解：テストコードが乏しいレガシーアプリに対して、移行前にどのようにテストを整備するか（E2Eテストを先に書いてリグレッションを防ぐなど）を具体的に説明できるベンダーは信頼できます。
リリース後の保守体制を含む契約設計の重要ポイント
リアーキテクチャプロジェクトにおける契約設計で見落とされがちなのが「移行完了後の保守体制」です。新しいアーキテクチャが本番稼働し始めた直後は、隠れていた問題が表面化しやすく、迅速な対応体制が不可欠です。
移行後の瑕疵担保・保守契約の設計
リアーキテクチャの開発契約と保守契約を分けて設計することが基本ですが、両者を連動させた設計が重要です。具体的には以下の点を契約に盛り込みます。
瑕疵担保期間と保証範囲：民法改正（2020年）以降、「瑕疵担保」から「契約不適合責任」に変わりましたが、実務上は「検収後○ヶ月以内に発見されたバグは無償対応」という形で契約します。リアーキテクチャでは複雑な移行に起因するバグが検収後に発覚するケースが多いため、一般的な6ヶ月ではなく12ヶ月の瑕疵担保期間を設けることを推奨します。
移行後の緊急対応SLA：リリース後3ヶ月間は「重大障害（P1）の初回応答1時間以内・解決4時間以内」「軽微なバグ（P3）の対応1週間以内」といった対応時間を契約に明示します。障害対応の連絡手段（Slack/メール/電話）と担当者も確定しておきます。
モニタリング・ログ管理の引き継ぎ：Datadog・New Relic・AWS CloudWatchなどの監視ツールの設定、アラートルール、ダッシュボードを成果物として明示し、社内チームへのハンドオーバーを契約に含めます。「運用できる状態で引き渡す」ことを明文化することが重要です。
請負型・準委任型のハイブリッド契約設計
リアーキテクチャは「要件が途中で変わりやすい」「現状調査の結果次第でスコープが変動する」という特性があるため、フェーズによって契約形態を使い分けるハイブリッド型が適しています。
現状分析・設計フェーズ（準委任型）：既存コードの分析、移行計画の策定は「結果」ではなく「作業」に対して報酬を支払う準委任契約が適しています。月額固定制（例：月100万円×2ヶ月）でエンジニアをアサインし、分析と移行設計に集中してもらいます。
移行実装フェーズ（請負型）：設計が固まったコンポーネントから順次、請負契約でマイルストーンごとに契約します。「認証モジュールの移行完了：○○万円」「決済APIの刷新完了：○○万円」のように機能単位で区切ることで、成果に対してコストを支払う透明性が生まれます。
保守フェーズ（月額準委任型）：本番リリース後は月額の保守契約（SLAを定めた準委任型）に切り替えます。保守範囲（バグ修正のみか、小規模な機能追加も含むか）、月間対応工数の上限、超過時の追加費用についても明記します。
フィーチャーフラグを活用した段階的リリース計画の発注仕様への組み込み方
サービスを停止せずにリアーキテクチャを進める際に最も有効な技術手法が「フィーチャーフラグ（Feature Flag / Feature Toggle）」です。フィーチャーフラグとは、コードの変更をデプロイしたままにしながら、機能のオン/オフをリアルタイムに切り替えられる仕組みです。
フィーチャーフラグの発注仕様書への記載方法
フィーチャーフラグを使った段階的リリースを発注仕様に組み込む際は、以下の要件を明記します。
フィーチャーフラグ管理基盤の要件：LaunchDarkly・Unleash・AWS AppConfig等のフィーチャーフラグ管理ツール（または自社実装）を使用すること、フラグのオン/オフをコードデプロイなしに変更できること、ユーザーセグメント（内部ユーザー・ベータユーザー・全ユーザー）ごとにフラグを切り替えられること、フラグの変更履歴が記録されることを要件化します。
カナリアリリース計画の仕様化：「新APIを最初は全トラフィックの1%に向け、問題がなければ10%→50%→100%と段階的に拡大する」という具体的な展開計画と、各ステージのロールアウト判断基準（エラーレート○%以下・P95レイテンシ○ms以下等）を発注仕様書に記載します。Netflix、Amazon、Facebookなどのテック企業が採用するカナリアリリースは、リアーキテクチャのリスクを大幅に低減する標準的手法です。
ロールバック手順の明文化：問題が発生した際に旧システムへ即座に切り戻せるロールバック手順と所要時間（目標：5分以内）を成果物の一部として定義します。フィーチャーフラグによるロールバックは、コードの再デプロイなしに実行できるため、インシデント時の影響時間を最小化できます。
段階的移行フェーズの設計と発注スコープの区切り方
リアーキテクチャの発注スコープを「全体を一括」ではなく「フェーズ分割」することで、ベンダーへのリスク移転と発注者側のコントロール性を両立できます。一般的なフェーズ分割の例を示します。
フェーズ1（基盤整備・3〜4ヶ月）：テストコードの整備（カバレッジを最低60%まで引き上げる）、CI/CDパイプラインの構築、モニタリング基盤の整備、フィーチャーフラグ基盤の導入を行います。このフェーズは次のフェーズの品質を担保する土台であり、省略すると後工程のリスクが著しく高まります。
フェーズ2（コアモジュールの移行・4〜6ヶ月）：ビジネスへの影響が大きいコアモジュール（認証・課金・ユーザー管理等）から優先的に移行します。各モジュールを独立したデプロイ単位として分割し、フィーチャーフラグで新旧を切り替えながら本番投入します。
フェーズ3（残余モジュールの移行・3〜4ヶ月）：優先度の低い機能を順次移行し、旧システムのコードを削除します。旧システムのインフラを停止することでコスト削減効果が実現します。
UI変更を伴う場合のUXテスト計画の組み込み方
リアーキテクチャに伴いユーザーインタフェースも刷新する場合、UXの品質を発注仕様に組み込むことが非常に重要です。技術的な動作は正常でも、UIの変更によってユーザーが操作方法を見失い、離脱率が急上昇するリスクがあります。実際に、大手ECサイトがリニューアル後に売上が10〜20%低下するケースは珍しくありません。
UXテスト要件の発注仕様書への記載方法
UXテストを発注仕様に含める際の具体的な記載例を紹介します。
ユーザビリティテストの実施要件：リリース前に実際のユーザー（または代表的なユーザー属性に近い被験者）5〜8名を対象にしたユーザビリティテストを実施すること、主要タスク（例：商品購入フロー・プロフィール変更・パスワードリセット）のタスク完了率と所要時間を計測・記録すること、NPS（Net Promoter Score）または SUS（System Usability Scale）スコアを移行前後で比較することを成果物要件として規定します。
A/Bテスト計画の組み込み：フィーチャーフラグの仕組みを活用して、新UIと旧UIを一定割合のユーザーに並行して提供するA/Bテストを実施します。判断基準となるメトリクス（クリック率・コンバージョン率・エラー発生率）と判断期間（2週間以上）を事前に合意しておくことで、客観的なデータに基づいた移行判断が可能になります。
アクセシビリティ要件：WCAG 2.1 AA準拠をUX要件として明示します。スクリーンリーダー対応・キーボード操作対応・色コントラスト比（4.5:1以上）を検収基準に含めることで、リアーキテクチャ後のアクセシビリティ品質を担保します。
モバイルアプリ特有のリアーキテクチャ発注における注意点
モバイルアプリ（iOS/Android）のリアーキテクチャは、Webアプリとは異なる固有の課題があります。
アプリストアの審査期間：iOS App StoreはAppleの審査が1〜7日程度かかるため、Webアプリのような即時ロールバックができません。審査リスクを考慮したリリース計画と、フィーチャーフラグによるサーバーサイド制御（アプリ更新なしで機能を切り替える）の仕組みを発注仕様に含めることが重要です。
旧バージョンの並行サポート：モバイルアプリはユーザーがアップデートしないケースが多く、旧バージョンのAPIとの後方互換性維持期間（例：リリースから6ヶ月間）を発注仕様に明記します。強制アップデートを促す画面のUI実装も成果物として定義します。
デバイスフラグメンテーション：Androidはメーカー・OSバージョンの多様性が高く、テストデバイスマトリクス（最低10機種・OSバージョン3世代以上）と自動化テスト（Espresso/XCUITest等）の実施を要件化します。Firebase Test Lab等を使ったクラウドデバイステストの実施も検討します。
成果物要件：APIドキュメント・テストコードの定義方法
リアーキテクチャ後の長期的な保守性を確保するために、ソースコードだけでなく「ドキュメント」と「テストコード」を成果物として明示的に定義することが重要です。これらを発注仕様に含めることで、後継ベンダーへの引き継ぎや社内エンジニアによる内製化への移行がスムーズになります。
APIドキュメントの成果物要件の定義
APIドキュメントは、リアーキテクチャ後に社内チームや後継ベンダーがシステムを理解・維持するために欠かせない資産です。発注仕様書には以下の要件を明記します。
OpenAPI（Swagger）仕様書：全APIエンドポイントをOpenAPI 3.0以上の形式で記述すること、リクエスト/レスポンスのスキーマ・認証方式・エラーコードを網羅すること、SwaggerUI等で閲覧可能な形式で提供することを成果物要件とします。APIドキュメントはコードと同期して更新される仕組み（コードファーストのドキュメント生成ツール等）を採用することも要件化できます。
アーキテクチャドキュメント：移行後のシステム全体構成図（コンポーネント図・シーケンス図・ERD）、技術的意思決定の記録（ADR: Architecture Decision Record）、環境構成（開発・ステージング・本番）とデプロイ手順書を成果物として定義します。これらは引き継ぎ時の「なぜこの設計にしたか」を後から理解するために不可欠です。
運用手順書：障害発生時のRunbook（障害種別ごとの対応手順）、定期メンテナンス手順（DBバックアップ・証明書更新等）、スケーリング手順（手動・自動スケーリングのトリガーと操作方法）を成果物に含めます。
テストコードの品質要件と成果物定義
テストコードは「資産」として発注仕様に明示することで、ベンダーが後から付け足すのではなく、開発と並行して作成する文化を醸成できます。
テストカバレッジの定量要件：ユニットテストのライン/ブランチカバレッジ80%以上（ビジネスロジック層は90%以上）、統合テストで主要なAPIエンドポイントを100%カバーすること、E2E（エンドツーエンド）テストで主要ユーザーフロー（購入・登録・ログイン等）を網羅することを検収基準に含めます。カバレッジレポートをCI/CDパイプラインで自動生成し、レポートを成果物として提出することを義務化します。
テストの自動化要件：テストがCI/CDパイプライン（GitHub Actions・GitLab CI等）に統合されており、プルリクエストごとに自動実行されること、テスト実行時間がユニットテスト10分以内・E2Eテスト30分以内であること（開発速度維持のため）を発注仕様に含めます。また、テストが「読みやすく・保守しやすい」コードで書かれているかを検収時にコードレビューで確認します。
パフォーマンステストの成果物：負荷テストのシナリオファイル（k6・JMeter等）、負荷テスト結果レポート（ピーク時のスループット・レイテンシ分布・エラー率）、ボトルネック特定と改善の記録を成果物として定義します。これらのシナリオファイルは、将来的に自社で負荷テストを再実施する際の資産となります。
リアーキテクチャ外注の費用相場とコスト最適化
アプリリアーキテクチャの外注費用は、システムの規模・複雑度・移行期間によって大きく異なります。あくまで目安として以下の相場感を参考にしてください。
規模別の費用相場と内訳
小規模リアーキテクチャ（500〜1,500万円）：ユーザー数1万人未満・機能数20以下の小規模Webアプリの技術スタック刷新（例：PHP5系からLaravelへの移行、JQueryからReactへのフロントエンド置き換え）が対象です。期間は3〜6ヶ月が目安。テスト整備・CI/CD構築を含みます。
中規模リアーキテクチャ（1,500〜5,000万円）：ユーザー数1〜10万人程度・機能数50〜100のWebアプリまたはモバイルアプリのアーキテクチャ刷新（例：モノリスからモジュラーモノリスへの移行、APIの全面刷新）が対象です。期間は6〜12ヶ月が目安。フィーチャーフラグ基盤・パフォーマンステスト・ドキュメント整備を含みます。
大規模リアーキテクチャ（5,000万円〜）：ユーザー数10万人超・複雑な業務ロジックを持つシステムのマイクロサービス化・クラウドネイティブ化が対象です。期間は12〜24ヶ月が目安。複数チームの並行開発体制が必要となります。海外のSaaS企業事例では、大規模リアーキテクチャに2〜3年・数十億円を投じるケースも珍しくありません。
コスト最適化のための発注設計テクニック
リアーキテクチャの外注コストを適切にコントロールするための実践的な方法を紹介します。
スコープの優先度付けと段階発注：全機能を一度に発注せず、ビジネスインパクトが高い領域から優先的に移行し、効果を検証しながら次のフェーズに進む方法です。フェーズ1の完了後に予算承認を得るプロセスにすることで、ROIを確認しながら投資を継続できます。
社内エンジニアとの分業：現状分析・テスト作成・ドキュメント整備を社内エンジニアが担当し、コアの移行実装をベンダーに依頼する分業体制にすることで、外注コストを30〜50%削減できるケースがあります。ただし、社内エンジニアの工数確保と役割分担を事前に明確化しておくことが前提です。
マネージドサービスの積極活用：フィーチャーフラグ管理（LaunchDarkly等）・モニタリング（Datadog等）・CI/CD（GitHub Actions等）はマネージドサービスを活用することで、ベンダーの実装工数を削減できます。初期費用はかかりますが、長期的なTCO（総所有コスト）を下げる効果があります。
リアーキテクチャ外注でよくある失敗パターンと対策
リアーキテクチャプロジェクトは、通常の開発プロジェクトと比べて失敗リスクが高い傾向があります。業界調査によると、大規模なシステム刷新プロジェクトの約30〜40%が期待通りに完了しないとされています。代表的な失敗パターンとその対策を理解しておくことが、発注者として重要です。
Big Bang型移行への固執と「第2システム効果」
最もよくある失敗が「すべてを一度に作り直す」Big Bang型移行への固執です。「古いシステムを全部捨てて1から作れば綺麗になる」という判断は、エンジニアリング的には誤りではありませんが、ビジネスリスクが非常に高い選択です。
「第2システム効果」（Frederick Brooksが「人月の神話」で指摘した概念）として知られるように、「1から作り直した新システム」は往々にして当初の見積もりの2〜3倍の期間・コストがかかり、リリース時点で旧システムの機能を完全に再現できていないケースが多くあります。旧システムには「暗黙の仕様」「エッジケースへの対応」「長年の改善」が積み重なっており、これらを再発見しながら作り直す難易度は想定以上に高いのです。
対策：前述のStrangler Figパターンによる段階移行を基本とし、Big Bang型を選択する場合は相応の理由（例：旧システムのライセンスが切れる・セキュリティ上の理由で即時廃棄が必要）がある場合に限定します。発注RFPにもこの方針を明記してベンダーに段階移行アプローチを求めます。
スコープの無制限拡大（スコープクリープ）と発注者側の管理責任
リアーキテクチャ中に「ついでにこの機能も追加しよう」「新しいアーキテクチャに合わせてUI全面刷新もやってほしい」とスコープが膨らむスコープクリープは、期間・コストの超過の主因です。リアーキテクチャ中の機能追加は、移行中のシステムの複雑性を倍増させ、ベンダーの混乱を招きます。
対策：契約書にスコープ変更手続き（Change Request Process）を明文化します。スコープ変更は書面で申請→ベンダーが影響範囲と追加費用を見積もり→発注者が承認→追加契約締結というフローを確立します。「リアーキテクチャ完了後に機能追加フェーズを設ける」という原則を社内でも徹底することが重要です。
リアーキテクチャの外注を成功させるためには、発注者自身が「プロジェクトオーナー」として主体的に関与し、明確な意思決定を迅速に行う体制を整えることが何より重要です。ベンダー任せにするのではなく、週次のステータスレビュー・月次のアーキテクチャレビューを実施し、技術的な判断にも積極的に参加することが、期待通りのリアーキテクチャ完成への近道です。
本テーマに関する全体ガイドは、以下の記事をご覧ください。
▼全体ガイドの記事
・アプリリアーキテクチャの完全ガイド
株式会社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を創業。