業務システムの更改で最もつまずきやすいのが、実は要件定義より手前の「アセスメント（現状分析）」の段階です。長年使ってきた販売管理や会計のシステムは、仕様書が失われていたり、当初の設計意図が分からなくなっていたりと、ブラックボックス化していることが少なくありません。現状を正確に把握しないまま更改を進めると、必要な機能を取りこぼしたり、逆に不要な機能まで引き継いだりして、費用が膨らみ品質も安定しません。
本記事では、業務システム更改のアセスメント・要件定義・RFPについて、現状分析（AS-IS可視化）からRFPに盛り込むべき項目、ベンダー評価の観点までを一次データをもとに体系的に解説します。更改の手法や事例、費用感を含めた全体像を押さえたい方は、あわせて業務システム更改の完全ガイドもご覧ください。本記事では、その完全ガイドの概要から一歩踏み込み、「アセスメント→要件定義→RFP」という発注準備のプロセスに絞って、具体的な項目と評価観点を掘り下げていきます。
▼全体ガイドの記事
・業務システム更改の完全ガイド
更改の出発点となるアセスメント（現状分析）
業務システム更改は、いきなり要件定義やRFP作成から始めるものではありません。その前段にある「アセスメント」で、現行システムの実態を正確に把握することが何より重要です。アセスメントとは、現行システムの機能・データ・依存関係、そして業務の流れ（AS-IS）を棚卸しし、可視化する工程を指します。ここが甘いと、後続のすべての工程が砂上の楼閣になります。
仕様書欠如とブラックボックス化が更改を阻む
更改が失敗する大きな原因のひとつに、現行システムの仕様が分からなくなっている「ブラックボックス化」があります。長く使われてきた販売管理や会計のシステムでは、当時の開発者がすでに退職していたり、改修を重ねるうちに仕様書が実態と乖離していたりすることがよくあります。何がどう動いているか分からないシステムを、正しく更改することはできません。
とくに厄介なのが、業務ルールがプログラムの中に埋め込まれていて、ドキュメント化されていないケースです。たとえば「特定の取引先には独自の締め日を適用する」といったルールが、コードの奥深くにだけ存在することがあります。アセスメントでこうした隠れた仕様を掘り起こさないまま更改すると、本番稼働後に「あの処理ができなくなった」というトラブルが噴出します。
このブラックボックス化こそ、更改における要件定義の不十分さの根本原因です。だからこそ、要件定義の前にアセスメントで現状を徹底的に可視化する必要があります。事前の資産棚卸しと現状分析を省略することは、更改プロジェクトの失敗確率を大きく押し上げる行為だと認識しておくべきです。
可視化を支えるツールとアセスメントの費用感
現状分析を効率化するための支援ツールも登場しています。たとえば富士通が提供する「ソフトウェア地図」は、アプリケーション資産の複雑度や依存関係を可視化するツールで、どのプログラムがどこと結びついているかを地図のように示してくれます。膨大なコードを人手だけで読み解くのは現実的でないため、こうしたツールを活用して複雑度を客観的に把握することが、更改の対象範囲を見極める助けになります。
アセスメントには相応の費用がかかります。一次データによると、要件定義・業務棚卸しのみのフェーズで200万〜500万円が一つの目安とされています。この金額を「更改本体とは別の追加コスト」と捉えて省略しようとする企業もありますが、これは危険な節約です。アセスメントを省いて要件が固まらないまま開発に進むと、手戻りや追加開発でその何倍ものコストが発生しかねません。
アセスメントの費用は、更改全体のリスクを下げるための保険と考えるべきです。現状を正確に把握できていれば、後続の要件定義もRFP作成も精度が上がり、ベンダーから受け取る見積もりの妥当性も判断しやすくなります。最初に現状を可視化する投資が、結果として更改全体の費用対効果を高めるのです。
要件定義で固める項目とRFPに盛り込むべき内容
アセスメントで現状（AS-IS）を可視化したら、次は更改後にどうありたいか（TO-BE）を定める要件定義へと進みます。そして要件定義の内容を、発注先のベンダーに正しく伝えるための文書がRFP（提案依頼書）です。RFPの質が、ベンダーから提案・見積もりを引き出す精度を決めます。本章では、要件定義で固めるべき項目と、RFPに盛り込むべき内容を整理します。
RFPに盛り込むべき必須項目
更改のRFPには、ベンダーが正確に提案・見積もりを行えるよう、現状と要望の両方を具体的に記載する必要があります。一次データに基づくと、RFPに含めるべき代表的な項目は次のとおりです。
・現行システムの構成図（ハードウェア・ソフトウェア・連携先）
・対象業務の範囲と更改の目的・背景
・移行すべきデータの量・形式とデータ移行の方針
・性能要件（処理件数、レスポンス、夜間バッチの所要時間など）
・可用性・セキュリティ要件
・更改後に達成したいKPI（処理時間短縮率、保守費削減額など）
・予算規模・希望スケジュール・保守体制への要望
これらを漏れなく記載することで、ベンダー各社が同じ前提で提案でき、見積もりの比較がしやすくなります。
とくに見落とされがちなのが「移行後のKPI」です。更改では現行機能の再現に意識が向きがちですが、「何をどれだけ改善したいのか」を数値で示しておくと、ベンダーはその達成に向けた提案をしやすくなります。たとえば「夜間バッチの所要時間を現在の半分以下にしたい」と明記すれば、性能を満たすための設計提案を引き出せます。更改を単なる延命でなく改善の機会にするための要件です。
また、現行システムの構成図やデータ移行の方針は、アセスメントの成果物がそのまま土台になります。アセスメントを丁寧に行っていれば、RFPの記載精度も自然と高まります。逆に現状把握が甘いままRFPを書くと、前提が曖昧になり、ベンダーからの見積もりにも大きな幅が出てしまいます。アセスメントと要件定義、RFP作成は地続きの工程なのです。
移行方式とデータ移行を要件として明文化する
更改特有の重要要件が「移行方式」です。販売管理や会計のように日々動いているシステムを止めずに切り替えるには、どのように新システムへ移行するかを事前に決めておく必要があります。全機能を一度に切り替える一括移行（ビッグバン）にするのか、機能や対象を区切って段階的に置き換えるのかを、要件として明記します。後者は影響範囲を限定でき、トラブル時の切り戻しもしやすいため、業務を止めにくい更改で広く採られる方式です。
データ移行の要件も具体的に固めておくべきです。現行システムのデータをどの形式で、どれだけの量、どのタイミングで新システムへ移すのか。文字コードやマスタ定義の違いをどう吸収するのか。こうした点を曖昧にしたままだと、移行の段階で想定外の作業が膨らみます。要件定義の段階で移行データの範囲と方針を明文化し、RFPにも反映しておくことが、後工程の混乱を防ぎます。
さらに、許容できるダウンタイム（システム停止時間）も要件として示しておきます。切り替え作業のためにシステムを止められる時間が何時間あるのかは、移行方式の選択に直結します。たとえば連休中なら長めの停止が許されますが、平日夜間しか止められない場合は段階移行が現実的になります。業務への影響を最小化するためにも、移行方式・データ移行・許容ダウンタイム・移行後KPIをセットで要件化し、ベンダーに明確に伝えることが更改成功の前提になります。
失敗しないベンダー選定の評価観点
RFPを各社に提示して提案を受け取ったら、いよいよベンダー選定です。更改は現行業務を止めずに進める難しいプロジェクトだけに、ベンダーの実力差がそのまま成否に直結します。価格だけで選ぶと、移行設計の甘いベンダーを掴んでしまうリスクがあります。本章では、更改を任せるベンダーを評価するための客観的な観点を整理します。
ベンダー評価の5つのチェックポイント
一次データに基づくと、更改ベンダーを評価する際の客観的なチェックポイントは大きく5つに整理できます。これらを評価項目として点数化し、各社を横並びで比較すると、価格に引きずられない冷静な選定ができます。
(1)同業界・同規模の更改実績があるか
(2)一括ではなく段階的に移行する設計力を持っているか
(3)ダウンタイム（停止時間）を現実的に見積もれているか
(4)24時間365日の保守体制を提供できるか
(5)ISO9001（品質）やISO27001（情報セキュリティ）などの認証を取得しているか
この5点は、いずれも更改特有のリスクに直結する観点です。価格や機能の充実度だけでなく、これらを満たしているかを必ず確認します。
とくに重視したいのが、(1)の同業界・同規模の実績と、(2)の段階移行の設計力です。販売管理や会計の更改は業界特有の商習慣や法制度が絡むため、類似の更改を手がけた経験があるベンダーほど、隠れた要件を先回りして拾えます。また、一括切り替えのリスクを理解し段階移行を提案できるかどうかは、移行設計の成熟度を測るうえで重要な指標になります。
見積もりの妥当性を判断する視点
提案された見積もりの妥当性を判断するには、更改の費用構造を理解しておくことが役立ちます。小〜中規模の単一業務システムの更改では、費用は3,000万〜1.5億円規模になり、そのうちSI費（設計・開発・テストなどの作業費）が60〜75％を占めるのが一般的です。SI費の比率が極端に低い見積もりは、必要な工程が抜けている可能性を疑う材料になります。
また、複数社の見積もりを比較する際は、前提条件が揃っているかを必ず確認します。RFPの記載が曖昧だと、各社が独自に前提を補って見積もるため、単純な金額比較が成り立ちません。アセスメントとRFPで前提をしっかり固めておくことが、見積もりを公正に比較できる土台になります。安すぎる見積もりは、移行やテストの工数を過小に見ている危険信号と捉えるべきです。
最終的なベンダー選定は、価格・実績・体制・認証・移行設計力を総合的に評価して行います。可能であれば、提案内容だけでなく担当者との面談や過去案件の参照先確認を通じて、実際のコミュニケーションのしやすさも見極めておくと安心です。更改は契約して終わりではなく、移行と本番稼働、その後の保守まで続く長い付き合いです。目先の安さではなく、業務を止めずに確実に更改しきれるパートナーかどうかを、客観的な評価観点に沿って見極めることが、失敗を避ける最大の鍵になります。
まとめ
本記事では、業務システム更改のアセスメント・要件定義・RFPについて解説してきました。更改はいきなり要件定義から始めるのではなく、まずアセスメントで現行システムのブラックボックス化を解消し、AS-ISを可視化することが出発点です。富士通の「ソフトウェア地図」のような可視化ツールを活用し、要件定義・業務棚卸しに200万〜500万円規模の投資を惜しまないことが、後続工程の精度を高めます。要件定義では現行構成図・性能要件・移行方式・データ移行・移行後KPIを固め、それらをRFPに漏れなく盛り込むことが重要です。
ベンダー選定では、(1)同業界・同規模の実績、(2)段階移行の設計力、(3)ダウンタイムの見積もり、(4)24時間365日の保守体制、(5)ISO9001・ISO27001などの認証、という5つの観点で各社を客観的に評価します。見積もりはSI費が60〜75％を占める費用構造を踏まえ、前提を揃えたうえで妥当性を判断します。アセスメント・要件定義・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を創業。