業務システムのモダナイゼーションは、現状分析から要件定義、RFP、ベンダー選定へと進みます。販売管理や在庫、会計などの基幹業務は、長年の運用で仕様書を失い、ブラックボックス化することがあります。全体像は業務システムのモダナイゼーションの完全ガイドもご覧ください。
把握が浅いまま刷新を進めると、要件漏れや認識違い、炎上、コスト超過を招きます。そこで、RFPと評価軸を明確にして進めると、要件漏れや認識違いによる手戻りを抑えられます。
▼全体ガイドの記事
・業務システムのモダナイゼーションの完全ガイド
レガシーシステム刷新の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
アセスメント（現状分析）の重要性とAS-IS可視化
モダナイゼーションの第一歩は、現行システムのアセスメントです。すでに動いている業務システムの機能を、まず正確に把握します。
現状分析を省いて要件定義に進むと、現行の処理が新システムから抜け落ちるおそれがあります。そのため、稼働後のトラブルを防ぐには、現状を先に可視化しておくことが欠かせません。
資産棚卸しとブラックボックスの可視化
システム資産の棚卸しは、アセスメントの中核です。現行システムを地図のように整理して、刷新の際に見落としやすいブラックボックスを探し出します。
- プログラムと業務：各処理が紐づく業務の対応関係
- 処理とデータ：販売管理の見積から入金消込、商品・得意先マスタまでの流れ
- 機能の利用状況：未使用の機能や、担当者しか知らない処理の有無
ブラックボックスを可視化する手段としては、富士通の「ソフトウェア地図」のようなツールもあります。このツールで、アプリケーション資産の複雑度や依存関係を把握できます。
目視では追いきれない大規模システムでは、こうしたツールが刷新の難しい箇所を客観的に特定する助けになります。また、可視化の精度は、後続の要件定義とコスト見積りにも影響します。
アセスメント・要件定義の先行発注
アセスメントと要件定義は、開発本体から切り離して先に発注するのが定石です。要件定義と業務棚卸しだけであれば、200万〜500万円程度が目安です。
現状と目指す姿を先に固めると、後工程の手戻りを抑えられます。一方で、アセスメントを軽視して大規模な一括契約を急ぐと、浅い把握のまま開発が進み、要件が膨らんでコスト超過を招きます。
単一刷新は3,000万〜1.5億円、周辺を含む中〜大規模の基幹刷新は1.5億〜5億円規模です。それだけの額になるため、アセスメントで数千万円規模の支出のリスクを抑えられます。丁寧に行うと、総コストの抑制にもつながります。
要件定義で押さえるべき観点
刷新失敗の原因には、要件定義の不十分さも指摘されています。AS-ISを可視化したら、刷新後のあるべき姿（TO-BE）を定めます。
要件定義では、現行踏襲と業務改善のバランスを取ることになります。特に、新規開発とは違って、何を残し、何を見直すかを切り分けることが、モダナイゼーションの中心になります。
現行踏襲と業務改善の切り分け
現行踏襲は安全に見えても、無駄や形骸化したルールを引き継ぐおそれがあります。そのため、要件定義では発注側と開発会社が現行処理を一つずつ仕分け、改善の余地を明らかにします。
イオングループの事例のように、刷新と業務プロセスの見直しを一体で進めると、効果が何倍にもなります。
すべてを改善対象にすると、要件が膨らんで破綻するおそれがあります。そこで、変更する範囲と維持する範囲を文書にして関係者が合意し、後の仕様変更による混乱を防ぎます。
- 法令・取引上の必須事項：現行処理を維持するかの確認
- 慣習として残る処理：改善の可否の見極め
- 競争力に関わる業務：販売や在庫を中心とした改善の検討
データ移行と非機能要件の定義
要件定義で見落とされがちなのが、データ移行と非機能要件です。データ移行では、商品・取引先マスタや過去数年分の伝票をどう移すかを決め、新旧の項目を対応させる「データマッピング」も整理します。過去データの移行範囲が曖昧なままだと、移行リハーサルで大量の不整合が起きるおそれがあります。
非機能要件では、性能、可用性、セキュリティ、保守体制などを数値で定めます。切り替え時のダウンタイムにも、目標を置けます。
数値基準があれば、RFPや選定で各社を客観的に比較できます。また、非機能要件は刷新後のKPIとして効果測定にも使えます。
一方で、曖昧なままでは、性能や障害時の復旧に問題が生じ、刷新が評価されないこともあります。数値で合意しておけば、後のトラブルや認識違いを防げます。
- 移行範囲：過去データの対象の明確化
- 性能：月次締めを翌朝6時までに終える目標
- 可用性：切り替え時の停止時間は半日以内
RFP作成とベンダー選定の評価項目
要件が固まったら、ベンダーに提案を依頼するRFP（提案依頼書）を作成します。RFPの内容が不十分だと、提案がばらつき、見積りも比べにくくなります。そこで、要件と評価軸を明確にしておくと、ベンダーの実力を把握でき、選定の精度も高まります。
RFPに盛り込むべき項目
RFPには、刷新範囲や期待する成果をベンダーに伝えるための項目を盛り込みます。
- 背景・要件：目的、現行構成図、機能・非機能要件
- 計画：データ移行方針、想定スケジュール、予算
- 成果と課題：刷新後のKPI、保守費高騰や担当者依存、夜間バッチの遅延
特に現行構成図があると、ベンダーは刷新範囲を把握できます。移行後の目標を示すと、提案の方向性もそろいます。
「保守費を何割削減したい」「月次決算を何日早めたい」といった定量目標があれば、ベンダーは投資対効果を意識した提案をしやすくなります。RFPは、自社の課題意識と期待値をベンダーに共有するための文書です。
ベンダー評価の5つのチェックポイント
ベンダーは、5つの観点で提案を評価します。価格だけでなく、止められない業務を支える実績や移行後の体制も確認します。
- 刷新実績：同業界・同規模の業務システムを手がけた経験
- 段階移行の設計力：ビッグバン以外の移行を設計できるか
- ダウンタイムの見積り：切り替え時の停止時間を現実的に見ているか
- 保守体制：稼働後の24時間365日対応の有無
- 品質・セキュリティ認証：ISO9001やISO27001の取得状況
初期費用よりも、移行設計の堅実さや保守体制のほうが重要な評価要素です。
提案を5つの観点で点数化すると、複数社を同じ基準で比べられます。価格、実績、体制を含めて客観的に選べるため、稟議の場でも根拠を示せます。
上流工程でつまずかないための進め方
アセスメント、要件定義、RFPはつながっていて、前工程の質が次の工程に影響します。どこかを省くと、問題が後工程で表面化します。
そのため、つまずきを避けるには、業務部門を巻き込むことと、決めたことを文書に残すことが有効です。
業務部門を巻き込んだ要件確定
販売・経理・在庫管理の現場にある知識は、情報システム部門やベンダーだけでは拾いきれません。そこで、業務部門（ユーザー部門）の主体的な参加が必要になります。
業務部門の参加が薄いと、「聞いていない」という認識違いが生じます。
現場の参画不足は、パッケージ導入の失敗要因としても指摘されています。上流工程は、技術の作業であると同時に、関係部門の合意を形成していく過程です。部門間で合意しておけば、手戻りを防げます。
- 担当者への聞き取り：例外処理や繁忙期の運用まで含めた確認
- 代表者の参加：業務部門の代表を、プロジェクトメンバーに加える
- 責任者のレビュー：要件の確認と承認への関与
決定事項の文書化と認識の共有
上流工程で決めた内容は文書に残して、関係者間で共有します。一方で、口頭だけの合意は、後のトラブルにつながることがあります。
また、文書化はブラックボックス化の再発防止にも役立ちます。業務ロジックやデータ構造を残しておけば、次の担当者が現状を把握しやすくなります。
記録を残せば、属人化やブラックボックス化に戻るリスクを下げられます。さらに、上流工程で作る文書は、将来のシステムを健全に保つ資産です。
- 決定内容：変更する業務と維持する業務の区分
- 移行範囲：移行対象データの明記
- 上流工程の成果物：現状分析、要件定義書、RFP、ベンダー評価の基準と結果
まとめ
アセスメントで現状を把握し、要件定義で方向を決め、RFPとベンダー選定へ進むのが全体の流れです。RFPに課題とKPIを示しておくと、ベンダーの提案を比べやすくなります。
資産の棚卸しで現状（AS-IS）を可視化し、「ソフトウェア地図」のようなツールも使ってブラックボックスを解きほぐします。要件定義では、現行踏襲と業務改善を切り分けたうえで、データ移行と非機能要件を数値で明確にします。
ベンダー選定では、同業界・同規模の実績と段階移行の設計力を確認し、切り替え時のダウンタイムの見積りも見ます。24時間365日の保守体制や、ISO9001・ISO27001などの品質・セキュリティ認証も評価対象です。5つの観点で、複数社を客観的に比べられます。
要件定義と業務棚卸しだけなら、200万〜500万円程度で先行発注できます。この投資は刷新全体のリスクを抑え、総コストの抑制につながります。
関係部門の合意と判断の文書化は、後工程の手戻りを抑える鍵です。上流工程を丁寧に設計してこそ、刷新の成功につながります。必要に応じて、経験豊富なパートナーと進めます。
▼開発を相談する前に読みたい無料ホワイトペーパー
・レガシーシステム刷新の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。