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