リアーキテクチャの外注は、発注前の準備からSaaSとの比較、RFP作成、開発手法、UAT、保守体制まで、6段階で条件を固めます。
現行の業務ロジックを壊さずに再設計するのは新規開発より難しく、外注先の選定から発注方法まで独自の進め方が要ります。全体像は次の記事で解説しています。
▼全体ガイドの記事
・業務システムリアーキテクチャの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
発注前の準備──業務システム特有の事前作業
業務システムのリアーキテクチャを外注するうえで最も難しいのは、発注前の準備です。新規開発と異なり、現行システムが何をしているかを正確にドキュメント化する作業が欠かせません。この作業を怠ると、ベンダーは適切な提案を作れず、見積もりの精度も大きく下がります。
また、業務部門（現場担当者）を早期から巻き込まないと、リアーキテクチャ後のシステムが「使われないシステム」になるリスクが高まります。そこで、業務の流れ、現行システムの中身、目指す姿の3点を、関係者と一緒に整理しておきます。
- 業務フローの整理：現場担当者と現行業務を図にして、実態を関係者で共有する。
- 現行システムの棚卸し：機能・連携・固有ロジック・データ量の一覧をつくる。
- あるべき姿の合意：経営層・IT部門・業務部門で優先順位を決め、文書に残す。
業務フロー図の作成と現行システムの棚卸し
リアーキテクチャの発注準備では、現行の業務フロー図の作成から始めます。中小〜中堅企業では、業務システムの仕様書が存在しないか、存在しても実態と乖離しているのが一般的です。実際、IPA（情報処理推進機構）の調査では、中堅企業の約60%がシステムの最新仕様書を保有していないと報告されています。
業務フロー図は、IT部門だけでなく、システムを使う業務部門の担当者と一緒に作ります。たとえば、販売管理なら営業・受注担当者、在庫管理なら倉庫・物流担当者、顧客管理なら営業・カスタマーサポート担当者が対象です。付箋やホワイトボードを使い、「誰が（役職・担当）」「何のために（目的）」「どのような順序で（フロー）」「どのデータを使って（入力・出力）」業務を行っているかを書き出します。
この作業で、誰も使っていない機能やExcelによる補完、部門間のずれが見えてきます。
現行システムの棚卸しでは、次の3つを整理します。
- 機能と連携：使っている機能と使っていない機能を仕分け、基幹システム・ECサイト・外部サービスとの連携を一覧にする。
- 固有の業務ロジック：特殊な計算式・承認フロー等、自社独自の処理を抜き出す。
- データ量と増加傾向：テーブル件数と年間増加率。
この棚卸し資料は、後のRFP作成の基礎になり、ベンダーが移行リスクを正確に見積もる材料にもなります。
「あるべき姿」の合意形成と優先順位の設定
業務フローの棚卸しが終わったら、次に「リアーキテクチャ後にどのようなシステムを目指すか」というあるべき姿（To-Be）の合意に進みます。この合意を社内で済ませずにベンダーへ発注すると、開発途中で「そんなシステムになるとは思っていなかった」という部門間の対立が起き、プロジェクトが迷走するリスクがあります。
あるべき姿の合意では、経営層・IT部門・業務部門が集まるキックオフワークショップを設けることを強くすすめます。そこでは「3年後にどんな業務ができるようになりたいか」という視点でゴールを共有します。そのうえで、業務効率化（処理時間・入力工数の削減目標）、データ活用（リアルタイム分析・レポート自動化の範囲）、拡張性（将来の機能追加・システム連携の方向性）の3つの観点でKPIを設定します。
さらに重要なのが優先順位の設定で、全機能を一度に実現しようとすると、開発期間もコストもリスクも膨大になります。そこで、「フェーズ1で必ず実現するMust機能」「フェーズ2以降に先送りできるShould機能」「将来的に検討するCould機能」の3段階に分け、全員の合意を文書に残します。その文書は、後の発注ドキュメント作成の基盤にもなります。
SaaS乗り換え vs 外注リアーキテクチャ──最適解の選び方
業務システムの刷新では、既存のSaaSパッケージに乗り換えるか、スクラッチ（またはマイクロサービス化等）でリアーキテクチャを外注するかを選ぶ必要があります。この選択は、プロジェクトの成否を左右する重要な意思決定のひとつです。
判断を誤ると、SaaSでは実現できない自社固有の業務ロジックに後から気づき、多大なカスタマイズコストが発生することがあります。逆に、外注リアーキテクチャを選んで過剰な開発コストをかけてしまう失敗も起きます。
SaaS乗り換えが向いているケース・外注リアーキテクチャが向いているケース
SaaS乗り換えが有効なのは、業務フローが業界標準に近く自社固有の複雑なカスタムロジックが少ない場合や、ユーザー数・取引量が安定して急な拡張が見込まれない場合です。さらに、初期投資を抑えて早く稼働させることを優先する場合や、社内のIT人材が少なく保守・運用を自社で担いたくない場合にも向いています。
一方、外注リアーキテクチャが向いているのは、業界特有や自社固有の複雑な業務ロジック（特殊な原価計算・複数拠点の在庫引当ロジック等）がある場合です。また、既存の他システム（EDIシステム・ECプラットフォーム・外部倉庫システム等）と密に連携する場合や、長期的な自社データ管理・分析活用を重視する場合にも向いています。
加えて、SaaSの月額コストを5年間積算すると自社開発コストを超える場合も該当します（目安として月額SaaS費用×60カ月 > 自社開発一時費用の場合は要検討）。
ハイブリッドアプローチ（SaaS＋カスタム開発）の活用
近年増えているのが、SaaSの標準機能をベースに、自社固有の業務ロジックだけをカスタム開発で補完するハイブリッドアプローチです。たとえば、顧客管理の基本機能はSalesforceやkintoneを活用しつつ、特殊な見積もり計算や承認フローだけをAPI連携で外注開発する形態です。
このアプローチなら、SaaSの迅速な導入を生かしつつ、自社固有の業務要件にも対応できます。発注時の注意点は、「SaaS側の制約（カスタマイズ可能な範囲・APIの呼び出し制限等）」と「カスタム開発側の要件」を同時にベンダーへ開示し、整合性のある設計提案を求めることです。
SaaS側の制約を把握しないままカスタム開発の要件を固めると、後から「SaaSのAPIでは実現できない」という問題が見つかり、大幅な設計変更につながります。そこで、発注前にSaaSベンダーのパートナー認定を受けた開発会社を選ぶと、この問題を最小化できます。
業務部門を巻き込んだRFP作成方法
業務システムのリアーキテクチャのRFPは、IT部門だけで作ってはいけません。現場で実際にシステムを使う業務部門の担当者が要件の「一次情報源」であり、彼らを巻き込まないRFPは、実業務から離れた要件定義になるリスクがあります。
実際、「IT部門主導で作ったシステムが現場に受け入れられなかった」という失敗事例も、この段階での巻き込み不足が原因です。
リアーキテクチャ特有のRFP記載項目
業務システムのリアーキテクチャのRFPには、新規開発のRFPに加えて、次の4項目を必ず含めます。①現行システムの概要情報：稼働年数、開発言語、DBの種類、サーバー環境（オンプレ/クラウド）、ユーザー数、主要機能と連携システムの一覧です。これを開示することで、ベンダーは移行リスクと移行工数を正確に見積もれます。
②移行対象データの情報：主要テーブルのレコード件数、データ品質（重複・欠損・文字コードの問題等）、移行方式（一括か段階的か）を示します。データ量と品質はコストを大きく左右するため、「データ品質調査」を事前に行い、ベンダーに共有するのが推奨されます。
③移行期間中の運用制約：並行稼働の期間、切り替え時の業務停止の許容時間（例：深夜0時〜5時まで最大5時間）、段階的移行の優先業務の順序です。業務を止めない移行は、リアーキテクチャ特有の課題です。
④As-Is/To-Beの対応表：現行機能と新機能の対応を一覧にした表です。「現行のA機能は新システムのB機能に相当し、C機能は廃止する」と整理すると、ベンダーが開発スコープを把握できます。
業務部門との要件ヒアリングワークショップの進め方
業務部門からRFPに必要な情報を引き出すには、アンケートより対面かオンラインのワークショップが効果的です。第1回（現状把握）：付箋に「困っていること」「Excelで補完している業務」「エラーや問い合わせが多い点」を書いてもらい、課題を見えるようにします。その不満を共有すると、リアーキテクチャへの当事者意識が生まれます。
第2回（あるべき姿の設計）：「新しいシステムでどんな業務ができるようになりたいか」を部門ごとにKPI（数値目標）で表現してもらいます。たとえば「受注入力時間を現在の10分から2分に短縮」「在庫照会をリアルタイムで行えるようにする」「月次レポートを自動生成して手作業をゼロにする」など、具体的な数値目標を引き出すことが大切です。
第3回（優先順位の確定）：収集した要件をMust/Should/Couldに分類し、部門間の優先順位を経営層の判断も交えて決めます。この合意を文書に残すと、後の変更管理で「なぜこの優先順位にしたか」という判断の根拠が明確になります。
アジャイル vs ウォーターフォール──業務システムリアーキテクチャの開発手法選択
業務システムのリアーキテクチャでは、開発手法の選択がプロジェクトのリスク管理に直接影響します。そのため、「アジャイルのほうがモダンだから」「ウォーターフォールのほうが安心だから」といった感覚で決めず、プロジェクトの特性に基づいて選ぶことが求められます。
ウォーターフォールが適しているケース
ウォーターフォール開発が適しているのは、次の条件がそろっている場合です。まず、要件が安定していて、開発途中で大きな変更が想定されないことです。さらに、規制・法令（会計基準・個人情報保護法等）に基づく処理が多く、仕様の事前確定が必要なケースにも当てはまります。
一括データ移行を行い、特定の日付に本番稼働させる必要がある場合（例：期末に合わせたシステム切り替え）も向いています。また、予算とスケジュールを固定して経営層に報告する必要がある場合にも該当します。
特に販売管理・会計連携機能を含む業務システムでは、仕様変更が会計数値の整合性に影響します。そのため、ウォーターフォールで要件を固めてから開発するほうが、リスクが低い傾向があります。
アジャイルが適しているケース・ハイブリッド手法の活用
アジャイル開発が適しているのは、リアーキテクチャの対象範囲が広く段階的にリリースして現場の反応を取り込みたい場合や、マイクロサービス化・API化で機能単位にリリースできる構成を採る場合です。さらに、業務部門のデジタルリテラシーが高く、スプリントレビューに積極的に参加できる体制がある場合にも向いています。
ただし、アジャイル開発を外注すると準委任契約が基本になり、コストの管理が難しくなる点に注意が必要です。そのため、実務的には、要件定義と基本設計をウォーターフォールで固め、機能開発をアジャイルで進めるハイブリッドが最も向いています。
中でも、データ移行設計と移行テストはウォーターフォールで厳密に行い、UI/UX改善や追加機能はアジャイルで柔軟に進める分担が効果的です。発注時には、どのフェーズをどの手法で進めるかを明示し、契約形態（請負・準委任）をフェーズごとに使い分ける方法をRFPに含めます。
ユーザー受入テスト（UAT）の設計と業務部門の巻き込み方
ユーザー受入テスト（UAT：User Acceptance Test）は、業務システムのリアーキテクチャで最も重要な品質保証の工程です。ベンダーの単体テストや結合テストが「仕様どおりに動くか」を確かめるのに対し、UATは「現場の業務が実際にシステム上で行えるか」を業務担当者が見極めるテストです。
UATを省略したり形骸化させたりすると、稼働後に「画面の操作が現場の業務フローと合っていない」「データが正しく移行されていない」といったトラブルが頻発します。
UATのテストケース設計──業務シナリオベースのアプローチ
UATのテストケースは、業務シナリオのテストとして設計することが大切です。たとえば在庫管理システムなら、「営業担当者が受注を入力→在庫引き当て→出荷指示→在庫数量の更新→請求書の発行」という一連の業務を通しで確かめるシナリオテストを組みます。
テストケースは、正常系シナリオ（最も頻度が高い標準的な業務）、例外系シナリオ（在庫不足・与信オーバー・返品処理等の例外業務）、月次・年次処理（月次集計・棚卸し・年度更新等の定期処理）の3つを網羅します。
残りの2つは、データ移行の整合性（移行後の残高・在庫数が現行と一致するか）と、他システムとの連携（会計システム・ECサイト等）の動作です。さらに、発注前に作った業務フロー図をもとにテストシナリオを洗い出すと効果的です。
業務部門をUATに巻き込むための仕組みづくり
UATに業務部門を巻き込む最大の障壁は、通常業務が忙しくてUATに時間を割けないことです。そこで、発注時点でUAT期間（通常2〜4週間）を業務カレンダーに確保し、各業務部門からUATリーダー（担当者）を出すことを契約前の合意事項にしておくことが大切です。
効果的なのは「ウォークスルー方式」です。最初の1週間はIT担当者が操作手順を実演し（Walk）、2週間目は担当者自身が操作してIT担当者が補助し（Talk）、3週間目以降は担当者が単独で操作できることを確認します（Run）。これにより、テストの完了と同時に現場担当者の習熟度も高まり、本番稼働後のサポートコストを大幅に削減できます。
UAT中に見つかったバグや仕様変更の要望は、「不具合管理表」にまとめて管理します。そして、週次でベンダーと発注側が優先度を協議し、対応方針を決める体制を設けましょう。
契約後のサポート体制の確認──運用・保守フェーズへの引き継ぎ
業務システムのリアーキテクチャは、本番稼働で終わりではありません。稼働後の運用・保守を、どの体制で担うかは発注段階から明確にしておく必要があります。
多くの企業は、開発ベンダーにそのまま保守も任せる判断をします。しかし、保守体制の品質・コスト・解除条件の確認が不十分なまま契約し、後で問題が起きるケースは少なくありません。
保守・運用契約で確認すべき必須項目
保守・運用契約では、次の4項目を明文化します。①障害対応のSLA（サービスレベル合意）：「重大障害（基幹業務が停止する障害）は2時間以内に初動対応」「軽微な不具合は翌営業日以内に回答」など、障害レベルと対応時間を数値で定めます。「対応します」という曖昧な約束は、後のトラブルの原因になります。
②問い合わせ窓口と担当者の固定：問い合わせが「システムの問題か、操作ミスか、業務フローの問題か」のどれかを切り分けられる担当者が窓口に固定されるか、開発内容を熟知した担当者が窓口対応できる体制かを確認します。担当者が頻繁に変わると引き継ぎが途切れやすいため、担当者の固定を契約書に明記することを推奨します。
③法改正・セキュリティパッチ対応の範囲：税制改正（消費税率変更・インボイス制度対応等）や個人情報保護法改正への対応が、保守費用に含まれるか、別途費用が発生するかを明確にします。④月額保守費用の内訳と変更条件：月額費用に含まれる範囲（監視・バックアップ・パッチ適用・問い合わせ対応等）と、追加作業（機能追加・大規模改修等）の区分を明確にします。値上げの条件も定めると、不意の費用増加を防げます。
ベンダー依存リスクの低減とナレッジ移転の仕組み
業務システムを外注すると、開発したベンダーでなければ保守・改修できない「ベンダー依存（ベンダーロックイン）」のリスクが生まれます。ベンダーとの関係が悪化したときや、廃業・撤退したときに、深刻な問題になります。そこで、このリスクを下げるには、発注段階からナレッジ移転の仕組みを契約に組み込むことが重要です。
具体的には、設計書・API仕様書・DB設計書などの一式を納品させるとともに、ソースコードのリポジトリ（GitHub/GitLab等）へのアクセス権を発注側が持つ条件にします。さらに、運用手順書と障害対応マニュアルを本番稼働前に納品させ、保守担当者向けのシステム説明会を契約に含めます。
これを怠ると、保守ベンダーを変える際に「ドキュメントがなく、開発者に聞かないと何もわからない」状態に陥り、移行コストが膨大になります。そのため、ドキュメントの完成基準（何の資料が・どの程度の詳細さで・いつまでに）を検収条件として契約書に明記することが、最も確実な対策です。
まとめ
業務システムのリアーキテクチャを外注で成功させるには、発注前の準備、SaaSとの比較、RFP作成、開発手法の選択、UAT設計、保守体制の確認の6つを、業務部門を巻き込みながら丁寧に進めることが欠かせません。各段階の要点は、次のとおりです。
①発注前準備：業務フロー図の作成と「あるべき姿」の合意を社内で済ませてから、ベンダーに発注します。現行システムの機能・データ・連携を一覧にする作業は必須で、RFPの品質を左右します。
②SaaS vs 外注の判断：自社固有の業務ロジックの有無、5年間のTCO（総保有コスト）の比較、IT保守体制の有無で判断します。ハイブリッド（SaaS＋カスタム開発）も有効な選択肢として検討します。
③RFP作成：業務部門との3回のワークショップを経て、現行システム情報、As-Is/To-Beマッピング、移行制約、非機能要件を具体的な数値で書きます。業務部門の合意を文書にしておくと、後の変更管理の基盤になります。
④開発手法の選択：会計連携や法令対応が多い業務システムは、ウォーターフォールが基本です。要件定義と基本設計をウォーターフォールで固め、機能開発をアジャイルで進めるハイブリッドが、実務上有効な選択肢です。
⑤UAT設計：業務シナリオベースのテストケースを作り、UATリーダーの配置と期間の確保を発注段階で合意します。「Walk→Talk→Run」の段階的な習熟を取り入れると、テストの完了と同時に現場の習熟度も高まります。
⑥保守体制の確認：障害対応SLA、法改正対応の範囲、保守費用の内訳を契約書に明記します。ドキュメント一式、ソースコードのリポジトリの権限、引き継ぎ手順書の納品を検収条件に含め、ベンダー依存のリスクを下げます。
業務システムのリアーキテクチャは、適切に進めれば業務効率の飛躍的な向上、データ活用の基盤強化、将来の事業拡張への対応力といった大きなリターンをもたらします。本記事のポイントを参考に、発注プロセス全体を主体的にコントロールして、プロジェクトの成功確率を高めてください。
▼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を創業。