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