販売管理・在庫管理・顧客管理などの業務システムが老朽化し、「改修コストが年々増加している」「新たな業務ニーズに対応できない」「クラウド化・API連携を進めたい」と感じている企業が急増しています。こうした課題を根本から解決する手段が「リアーキテクチャ（再設計・再構築）」ですが、現行システムの業務ロジックを壊さずに再設計するプロセスは、通常の新規開発より難易度が高く、外注先の選定から発注方法まで、独自のノウハウが求められます。

本記事では、業務システムのリアーキテクチャを外部ベンダーに依頼する際の具体的な発注方法について、発注前の準備からSaaS乗り換えとの比較検討、RFP作成、開発手法の選択、ユーザー受入テスト、契約後のサポート体制まで体系的に解説します。中小〜中堅企業の情報システム担当者・経営者が「今日から使える」実践的な内容に絞って構成しています。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

▼全体ガイドの記事
・業務システムリアーキテクチャの完全ガイド

発注前の準備──業務システム特有の事前作業

業務システムのリアーキテクチャを外注する最大の難所は、「発注前の準備」にあります。新規開発と異なり、リアーキテクチャには「現行システムが何をしているか」を正確にドキュメント化するというステップが不可欠であり、この作業を怠るとベンダーが適切な提案を作れず、見積もりの精度も大幅に下がります。また、業務部門（現場担当者）を早期から巻き込まないと、リアーキテクチャ後のシステムが「使われないシステム」になるリスクが高まります。

リアーキテクチャの発注準備で最初に取り組むべきは、現行の業務フロー図の作成です。多くの中小〜中堅企業では、業務システムの仕様書が存在しないか、存在しても実態と乖離している状態が一般的です。IPA（情報処理推進機構）の調査によると、中堅企業の約60%がシステムの最新仕様書を保有していないと報告されています。

業務フロー図の作成は、IT部門だけで行うのではなく、販売管理なら営業・受注担当者、在庫管理なら倉庫・物流担当者、顧客管理なら営業・カスタマーサポート担当者など、実際にシステムを使っている業務部門の担当者と一緒に行うことが重要です。具体的には、「誰が（役職・担当）」「何のために（目的）」「どのような順序で（フロー）」「どのデータを使って（入力・出力）」業務を行っているかを、付箋やホワイトボードを使ったワークショップ形式でまとめると効果的です。このプロセスを通じて、「実は誰も使っていない機能」「Excelで補完している業務」「部門間で認識がずれているプロセス」が明確になります。

現行システムの棚卸しでは、①使用している機能・使っていない機能の仕分け、②他システム（基幹システム・ECサイト・外部サービス）との連携一覧、③現行システム固有のカスタム業務ロジック（特殊な計算式・承認フロー等）の抽出、④データ量と増加傾向（テーブル件数・年間増加率）の把握を行います。この棚卸し資料は、後のRFP作成の基礎資料になるとともに、ベンダーが「移行リスク」を正確に見積もるための重要なインプットになります。

業務フローの棚卸しが完了したら、次は「リアーキテクチャ後にどのようなシステムを目指すか」というあるべき姿（To-Be）の合意形成を行います。この合意形成を社内で行わずにベンダーに発注してしまうと、開発途中で「そんなシステムになるとは思っていなかった」という部門間の対立が発生し、プロジェクトが迷走するリスクがあります。

あるべき姿の合意形成では、経営層・IT部門・業務部門の三者が一堂に会するキックオフワークショップを設けることを強く推奨します。このワークショップでは、「3年後にこのシステムでどんな業務ができるようになりたいか」という視点でゴールイメージを共有し、①業務効率化（処理時間・入力工数の削減目標）、②データ活用（リアルタイム分析・レポート自動化の範囲）、③拡張性（将来の機能追加・システム連携の方向性）の3軸でKPIを設定します。

さらに重要なのが「優先順位の設定」です。リアーキテクチャの全機能を一度に実現しようとすると、開発期間・コスト・リスクがいずれも膨大になります。「フェーズ1で必ず実現するMust機能」「フェーズ2以降に先送りできるShould機能」「将来的に検討するCould機能」の3段階に分類し、ステークホルダー全員の合意を文書化しておくことが、後の発注ドキュメント作成の基盤になります。

SaaS乗り換え vs 外注リアーキテクチャ──最適解の選び方

業務システムの刷新を検討する際、「既存のSaaSパッケージに乗り換えるか」「スクラッチ（またはマイクロサービス化等）でリアーキテクチャを外注するか」という選択は、プロジェクトの成否を左右する最も重要な意思決定のひとつです。この判断を誤ると、SaaSでは実現できない自社固有の業務ロジックに気づかず多大なカスタマイズコストが発生したり、逆に外注リアーキテクチャを選んで過剰な開発コストをかけたりという失敗が起きます。

SaaS乗り換えが有効なのは、以下のような状況です。①業務フローが業界標準に近く、自社固有の複雑なカスタムロジックが少ない場合。②ユーザー数・取引量が安定しており、急激な拡張が見込まれない場合。③初期投資を抑えてスピーディに稼働させることを優先する場合。④IT人材が社内に少なく、保守・運用を自社で担いたくない場合。

一方、外注リアーキテクチャが適しているのは以下のケースです。①業界・自社固有の複雑な業務ロジック（特殊な原価計算・複数拠点の在庫引当ロジック等）がある場合。②既存の他システム（EDIシステム・ECプラットフォーム・外部倉庫システム等）との密な連携が必要な場合。③長期的な自社データ管理・分析活用を重視する場合。④SaaSの月額コストを5年間積算すると自社開発コストを超える場合（目安として月額SaaS費用×60カ月 > 自社開発一時費用の場合は要検討）。

近年増えているのが「SaaSの標準機能をベースに、自社固有の業務ロジック部分だけをカスタム開発で補完する」ハイブリッドアプローチです。たとえば、顧客管理の基本機能はSalesforceやkintoneを活用しつつ、自社の特殊な見積もり計算ロジックや承認フローだけをAPI連携で外注開発するという形態です。このアプローチにより、SaaSの迅速な導入メリットを享受しながら、自社固有の業務要件にも対応できます。

ハイブリッドアプローチを採用する場合の発注上の注意点は、「SaaS側の制約（カスタマイズ可能な範囲・APIの呼び出し制限等）」と「カスタム開発側の要件」を同時にベンダーに開示し、整合性のある設計提案を求めることです。SaaS側の制約を把握しないままカスタム開発の要件を固めると、後で「SaaSのAPIでは実現できない」という問題が発覚し、大幅な設計変更につながります。発注前にSaaSベンダーのパートナー認定を受けた開発会社を選定すると、この問題を最小化できます。

業務部門を巻き込んだRFP作成方法

業務システムのリアーキテクチャにおけるRFPは、IT部門だけで作成してはなりません。現場で実際にシステムを使う業務部門の担当者が要件の「一次情報源」であり、彼らを巻き込まないRFPは、実業務から乖離した要件定義になるリスクがあります。「IT部門主導で作ったシステムが現場に受け入れられなかった」という失敗事例は、まさにこの段階での巻き込み不足が原因です。

業務システムリアーキテクチャのRFPには、通常の新規開発のRFPに加えて、以下の項目を必ず含める必要があります。

①現行システムの概要情報：稼働年数・開発言語・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のテストケース設計にあたっては、以下の観点を網羅することが推奨されます。①正常系シナリオ（最も頻度が高い標準的な業務処理）、②例外系シナリオ（在庫不足・与信オーバー・返品処理等の例外業務）、③月次・年次処理（月次集計・棚卸し・年度更新等の定期処理）、④データ移行の整合性確認（移行後の残高・在庫数が現行システムと一致するか）、⑤他システムとの連携テスト（会計システム・ECサイト等との連携が正しく動作するか）。テストケースの網羅性を高めるために、業務フロー図（発注前準備で作成したもの）をベースにテストシナリオを洗い出すアプローチが効果的です。

UATに業務部門を巻き込む最大の障壁は「通常業務が忙しくてUATに時間を割けない」という問題です。これを解決するには、発注時の段階でUAT期間（通常2〜4週間）を業務カレンダーに確保させ、各業務部門からUATリーダー（担当者）をアサインすることを契約前の合意事項として定めておくことが重要です。

UATの進め方として効果的なのは、「ウォークスルー方式」です。最初の1週間はIT担当者がUAT担当者に操作手順を実演して見せ（Walk）、2週間目は担当者自身が操作してIT担当者が補助し（Talk）、3週間目以降は担当者が単独で操作できることを確認する（Run）という段階的な習熟プロセスを設けます。これにより、テストの完了と同時に現場担当者の習熟度も高められ、本番稼働後のサポートコストを大幅に削減できます。UAT中に発見されたバグや仕様変更要望は「不具合管理表」で一元管理し、週次でベンダーと発注側が優先度を協議して対応方針を決定する体制を設けましょう。

契約後のサポート体制の確認──運用・保守フェーズへの引き継ぎ

業務システムのリアーキテクチャは、本番稼働で終わりではありません。稼働後の運用・保守フェーズをどのような体制で行うかは、発注段階から明確にしておく必要があります。多くの企業が「開発ベンダーにそのまま保守も任せる」という判断をしますが、保守体制の品質・コスト・解除条件についての確認が不十分なまま契約を締結し、後で問題が発生するケースが少なくありません。

開発ベンダーと保守・運用契約を締結する際には、以下の項目を必ず確認・明文化してください。

①障害対応のSLA（サービスレベル合意）：「重大障害（基幹業務が停止する障害）は2時間以内に初動対応」「軽微な不具合は翌営業日以内に回答」など、障害レベルと対応時間を数値で定義します。「対応します」という曖昧な約束は、後のトラブルの原因になります。

②問い合わせ窓口と担当者の固定：業務システムの問い合わせには「システムの問題か」「操作ミスか」「業務フローの問題か」の切り分けが必要です。開発内容を熟知した担当者が窓口対応できる体制か、担当者が頻繁に交代しないかを確認します。中小企業向けのシステム保守では、担当者が頻繁に変わって「ナレッジの引き継ぎができていない」というケースが多いため、担当者固定の条件を契約書に明記することを推奨します。

③法改正・セキュリティパッチ対応の範囲：税制改正（消費税率変更・インボイス制度対応等）や個人情報保護法改正への対応が保守費用に含まれるか、別途費用が発生するかを明確にします。インボイス制度や電帳法（電子帳簿保存法）への対応は、業務システムにとって頻繁に発生する法改正対応の代表例です。

④月額保守費用の内訳と変更条件：月額保守費用に含まれるサービス範囲（監視・バックアップ・パッチ適用・問い合わせ対応等）と、含まれない追加作業（機能追加・大規模改修等）の区分を明確にします。また、保守費用の値上げ条件（いつ・どの程度まで値上げできるか）を契約書に定めることで、不意の費用増加を防ぎます。

業務システムのリアーキテクチャを外注すると、「ベンダー依存（ベンダーロックイン）」のリスクが生まれます。開発したベンダー以外には保守・改修ができない状態になると、ベンダーとの関係が悪化した際や、ベンダーが廃業・撤退した際に深刻な問題が生じます。このリスクを低減するためには、発注段階から「ナレッジ移転」の仕組みを契約に組み込んでおくことが重要です。

具体的には、①システム設計書・API仕様書・データベース設計書などのドキュメント一式を成果物として納品させることを契約書に明記する、②ソースコードのリポジトリへのアクセス権（GitHub/GitLab等）を発注側が保有することを条件にする、③運用手順書・障害対応マニュアルを本番稼働前に納品させる、④保守担当者向けのシステム説明会（引き継ぎドキュメントの解説）を契約に含める、という4点を必ず盛り込んでください。これらを怠ると、保守ベンダーを変更する際に「ドキュメントがなく、開発者に聞かないと何もわからない」という状態に陥り、移行コストが膨大になります。ドキュメントの完成基準（何の資料が・どの程度の詳細さで・いつまでに）を検収条件として契約書に明記することが、最も確実な対策です。

まとめ

業務システムのリアーキテクチャを外注で成功させるためには、発注前の準備・SaaSとの比較検討・RFP作成・開発手法の選択・UAT設計・保守体制の確認という6つのフェーズを、それぞれ業務部門を巻き込みながら丁寧に進めることが不可欠です。本記事で解説したポイントを以下に整理します。

①発注前準備：業務フロー図の作成と「あるべき姿」の合意形成を社内で行ってからベンダーに発注する。現行システムの棚卸し（機能・データ・連携一覧）は必須の事前作業であり、これがRFPの品質を決める。

②SaaS vs 外注の判断：自社固有の業務ロジックの有無・5年間のTCO（総保有コスト）比較・IT保守体制の有無を軸に判断する。ハイブリッドアプローチ（SaaS＋カスタム開発）も有効な選択肢として検討する。

③RFP作成：業務部門との3回のワークショップを経て、現行システム情報・As-Is/To-Beマッピング・移行制約・非機能要件を具体的な数値で記述する。業務部門の合意を文書化することが後の変更管理の基盤になる。

④開発手法の選択：会計連携・法令対応が多い業務システムはウォーターフォールが基本。要件定義・基本設計をウォーターフォールで固め、機能開発をアジャイルで進めるハイブリッドが実務的に最も有効な選択肢である。

⑤UAT設計：業務シナリオベースのテストケースを設計し、UATリーダーのアサインと期間の確保を発注段階で合意する。「Walk→Talk→Run」の段階的習熟プロセスを設けることで、テスト完了と同時に現場担当者の習熟度を高める。

⑥保守体制の確認：障害対応SLA・法改正対応の範囲・保守費用の内訳を契約書に明記する。ドキュメント一式・ソースコードリポジトリの権限・引き継ぎ手順書の納品を検収条件に含めることでベンダー依存リスクを低減する。

業務システムのリアーキテクチャは、適切に進めれば業務効率の飛躍的な向上・データ活用の基盤強化・将来の事業拡張への対応力という大きなリターンをもたらします。本記事のポイントを参考に、発注プロセス全体を主体的にコントロールし、プロジェクトの成功確率を高めてください。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

▼全体ガイドの記事
・業務システムリアーキテクチャの完全ガイド

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また「Boxシリーズ」による、受発注管理・在庫管理・配送管理・業務システム・生成AI・SaaS・マッチングサイト・EC・アプリ・LINEミニアプリなどの標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」を活用することで、低コスト・短期間でのスクラッチ開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。