業務システム刷新は、新規開発と違って、現行システムの把握から始まります。まず現行の把握、次に要件とRFPの具体化、最後に移行とベンダー評価と進めると、安全な置き換えを目指せます。
各工程の全体像は、業務システム刷新の完全ガイドもあわせてご覧ください。
▼全体ガイドの記事
・業務システム刷新の完全ガイド
レガシーシステム刷新の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
刷新失敗を回避するアセスメントとAS-IS可視化
業務システム刷新では、要件定義に入る前のアセスメントが成否を左右します。アセスメントは、現行の処理や業務連携を棚卸しして、現状（AS-IS）を客観的に把握する工程です。
アセスメントを飛ばして理想（TO-BE）だけを描くと、現行の処理が新システムから漏れるおそれがあります。稼働後に業務が回らなくなる原因は、技術力の不足よりも現状把握の甘さにある場合が少なくありません。そこで、自社の資産を正確に可視化することが、刷新を進める出発点になります。
ブラックボックス化が要件定義の不足を招く理由
ブラックボックス化は、要件定義の段階で次のような問題を起こします。
- 仕様の不明確さ：長年の運用や改修で仕様書がなく、更新も止まって実態とずれています。設計意図や全体像を説明できる人もいません。
- 要件の判断困難：現行でできることが見えないため、維持する内容と変更する内容を定められません。
たとえば販売管理には、特定の得意先向けの値引きや、月末締めの特殊な集計処理が組み込まれていることがあります。こうした処理が仕様書になく、担当者の記憶だけに残っていると、要件から漏れやすくなります。
ブラックボックス化が進むと、「見えない要件」が増えていきます。漏れた要件が残ったままだと、請求金額の不一致や締め処理の停止といった重大な問題に直結します。
棚卸しでは、ソースコードや設定、運用手順といった現行の資産を洗い出し、業務フローと照らし合わせます。帳票、画面、外部連携も対象に含めます。
そのうえで、実際の処理を文書に復元しておくと、後工程の手戻りを減らせます。つまり、棚卸しに時間と費用をかけることは、刷新を失敗させないための投資です。
アプリ資産の複雑度と依存関係の見える化
大規模システムの現状把握には膨大な工数がかかります。そのため、既存アプリの資産を解析するツールやサービスも活用できます。
- 資産の複雑度：富士通の「ソフトウェア地図」は、複雑さと依存関係を可視化して、刷新の難所や優先順位の把握に役立ちます（出典：富士通）。
- システム間の依存：販売管理は会計と、会計は勤怠の人件費データと連携しています。取引先とは、EDI・APIでもつながっています。
- 見積もりの妥当性：複雑な箇所は移行リスクやテスト工数が膨らみやすく、可視化した情報は、提案の金額を判断する材料になります。
見積もりが安いときは、発注側が可視化の結果と照らし合わせて、難所や必要な工数が提案に反映されているかを確認します。可視化の裏づけがない安値を示すベンダーは、刷新の難所を見落としている可能性があります。
依存関係を一覧にすると、連携先への影響がわかります。また、刷新の範囲をどこで区切るか、段階的な計画をどう立てるかを検討できます。
複雑さと依存関係の情報は、後段のRFPに添付する現行構成の説明資料としても使えます。
要件定義・業務棚卸しの進め方と費用相場
現状を可視化したら、業務棚卸しと一体で要件定義を進めます。発注側は、現行業務を洗い出し、刷新後に残す処理、改善する処理、廃止する処理を決めます。
上流工程に投資するかどうかを判断するため、まず費用相場を把握しておきます。要件定義は発注前の独立した工程として、費用と期間を確保します。要件が固まらないまま開発に入ると、後工程で仕様変更が膨らみます。
要件定義・業務棚卸しの費用相場の目安
外部委託では、費用だけでなく、独立契約による比較機会や成果物の利点も確認しておきます。
- 費用相場：要件定義と業務棚卸しだけなら、200万〜500万円程度が目安です。対象規模や業務の複雑さ、関係部門の数によって幅があります。
- 契約方法：独立契約なら、成果物であるRFPをもとに複数社へ相見積もりを取れます。一括発注だと比較機会が失われ、特定ベンダーへのロックインが起きやすくなります。
- 作業範囲：ヒアリングや帳票・画面の分析、TO-BE業務フローの設計、RFPドラフトのどこまでを含むかを確認します。
要件定義の不足による手戻りは、上流工程の費用を上回ることがあります。実際に、上流で500万円を惜しんだ結果、開発後半に数千万円規模の追加費用が発生した事例もあります。
要件が文書化されていれば、各社の見積もりを同じ前提で比べ、価格と品質を評価できます。一方で、要件定義と設計・開発の線引きが曖昧だと、後から別費用として追加請求される余地が残ります。
会計・勤怠刷新で求められる改正対応の要件
会計と勤怠では対象となる制度が異なるため、業務固有の改正対応を要件に含めておきます。
- 会計刷新：インボイス制度（適格請求書等保存方式）への対応と、電子帳簿保存法に沿った電子取引データの保存・検索要件。
- 勤怠刷新：時間外労働の上限規制、年次有給休暇の取得義務、勤務間インターバルの記録。
特に勤怠管理システムでは、労働関連法制への対応が要件の中核になります。制度への対応を後付けにすると、改修費用がかさみ、施行期限に間に合わないおそれがあります。
労働法制は改正されるため、制度の改正時に設定変更だけで対応できるかどうかも、要件に含めておきます。これは、保守性を確認する観点にもなります。
改正対応の要件は、業務部門と法務・経理部門を交えて定義します。情報システム部門だけで決めると、現場の運用や制度の解釈とずれるおそれがあります。
「いつの時点の制度に準拠するか」「将来の改正にどう備えるか」まで、関係部門で合意しておくと、長期運用を見据えた要件になります。
RFPに盛り込むべき必須項目と移行方式の設計
RFP（提案依頼書）は、要件定義の成果をベンダーに伝える文書です。刷新ではベンダーが現行を見られないため、現状情報の精度が提案の質を左右します。新規開発と異なり、刷新のRFPは現行システム情報の充実度が成否を分けます。
刷新RFPに必須の記載項目チェックリスト
各社から比較しやすく精度の高い提案を得るため、RFPには次の現状・性能・移行の情報を記載します。
- 現行構成：ハードウェア、ミドルウェア、ネットワークに加え、連携先も示した構成図
- 性能要件：同時接続数、処理件数、応答時間に加えて、ピーク時の負荷の条件
- 移行後KPI：処理時間の短縮や運用工数の削減といった定量目標
- 移行範囲：移行の対象とするデータの年数と、マスタ・トランザクションの区分
- 外部連携：EDIやAPI、他システムとのインターフェース仕様
RFPには、刷新に固有の改正対応や保守・運用、移行方式も盛り込みます。具体的には、法令要件や障害対応時間帯、SLAを示します。加えて、運用の引き継ぎと、段階移行か一括移行かの方針も書きます。
現行構成図と外部連携の一覧は、アセスメントで可視化した資産情報を転用できます。
情報が欠けると、ベンダーは想定で見積もることになります。その結果、金額のばらつきや追加費用が生じます。
性能要件とKPIは、各社の提案を同じ条件で比べるために、数値で明記します。「速くしたい」と書くより、現行で3秒かかる検索を1秒以内にするといった形で示すほうが確実です。
数値があれば、各社は達成する構成を提案でき、見積もりの根拠も明確になります。また、移行後のKPIは稼働後の効果検証にも使えるため、投資対効果を説明する材料になります。
段階移行とストラングラーパターンの設計
切り替え方式ごとにリスクと設計方針を押さえたうえで、RFPでベンダーの移行計画を確認します。
- 一括移行：切り替え日にリスクが集中し、不具合が出ると業務が全面的に止まるおそれがあります。
- 段階移行：機能や業務ごとに置き換える方式です。RFPには想定方式と理由を記し、計画を求めます。
- ストラングラーパターン：段階移行の代表的な手法で、現行の周囲に新システムを構築し、トラフィックを機能ごとに新しい側へ振り向けていきます。
RFPでこの方針への対応を問うことで、ベンダーの移行設計力を見極められます。特に、移行方式の設計には、刷新ベンダーの実力が最もよく表れます。
段階移行では、業務によって新旧システムが並んで動く期間が生じます。その間もデータの整合性を保つため、両者の同期を設計します。
RFPでは、並行稼働中のデータ連携方式と、最終切り替え時のダウンタイムの見積もりを求めます。そのうえで、ベンダーが移行リスクを具体化できるかを評価します。
ベンダー評価の観点とデータ移行への備え
RFPを各社に示したあとは、返ってきた提案をどの観点で評価するかが次の関門になります。刷新では、価格の安さだけで選ぶと、移行時に取り返しのつかない事態を招くおそれがあります。
移行設計力や運用体制は、提案書の金額には表れにくい実力です。そのため、ベンダーを選ぶ際に見極めます。データ移行は失敗が起きやすいことから、その備えも発注の段階から織り込みます。
ベンダー評価の5つのチェックポイント
ベンダーの実力を見比べるときは、次の5つを確認します。
- 実績：同業界・同規模の刷新経験があるか
- 段階移行：具体的な移行計画を示せるか
- 停止時間：ダウンタイムを現実的に見積もっているか
- 保守体制：24時間365日の障害対応体制があるか
- 認証：ISO9001・ISO27001等を取得しているか
特に、同業界・同規模の実績と段階移行の設計力を重視します。商習慣や法令対応は業界ごとに異なるため、同業界の刷新実績は要件理解を助け、提案の精度や運用の安心感にもつながります。
移行計画では、「段階的に行う」と書くだけでなく、どの単位でどう切り替えるかまで確認します。
ダウンタイムの見積もりは、業務への影響を大きく左右します。停止が長引くと業務が止まり、機会損失が発生します。また、「ほぼゼロ」とする提案も、根拠がなければ、移行の難しさを軽視している可能性があります。
保守体制と認証は、稼働後の長期運用を任せられるかを判断する材料になります。そのうえで、各観点を総合し、価格とのバランスを見て発注先を決めます。
データ移行の泥臭さに対するRFPでの備え
データ移行は、刷新のなかで最も泥臭く、失敗が起きやすい工程です。そのため、独立した工程として扱い、範囲と方式、役割を発注の段階で定めておきます。
実際に、現行のマスタや取引データを新システムの構造に合わせて移す作業は、見た目以上に困難です。
- データ変換：マスタや取引データを新しい構造へ移します。コード体系や項目が異なるマスタは対応関係を一件ずつ定めるため、想定外の工数がかかりがちです。
- 現場の参画：現場の関与が不足すると、失敗要因の一つになります。移行・廃棄するデータの範囲と、移行後の正しさは、ユーザー部門が確認します。
- RFPの提案項目：対象データの年数やマスタ、マッピングの責任者を明記します。加えて、リハーサルの回数と、移行後の検証方法や担当も書き込みます。
情報システム部門とベンダーだけで進め、現場の確認を後回しにすると、稼働後に過去データが見つからない、金額が合わないといった問題が起きます。
データ移行は、刷新の最終関門です。事前の備えの厚さが、プロジェクト全体の着地を左右します。
まとめ：上流工程の精度が左右する刷新の成否
アセスメントでは、仕様書の欠如やブラックボックス化が要件定義の不足を招きます。そのため、資産の棚卸しと、複雑度・依存関係の可視化が失敗回避の鍵になります。富士通の「ソフトウェア地図」のようなツールを使うと、刷新の難所や優先順位を把握しやすくなります。
要件定義・業務棚卸しは、200万〜500万円程度を目安に、独立した工程として確保します。会計ではインボイス・電子帳簿保存法、勤怠では労働法制の改正対応を、要件に明記します。
RFPには、現行構成や性能要件、KPIを記載します。移行範囲と外部連携も示し、法改正対応や保守運用の要件を書き込みます。移行方式と検証の役割も、明確にしておきます。
ベンダーは、同業界・同規模の実績、段階移行力、ダウンタイムの妥当性で評価します。加えて、24時間365日の保守とISO9001・ISO27001等の認証も確認します。
データ移行では、マスタのマッピングやユーザー部門の参画不足が失敗要因になります。そのため、範囲や検証体制、役割分担を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を創業。