業務システムのモダナイゼーションを成功させられるかどうかは、刷新作業に入る前の「アセスメント・要件定義・RFP（提案依頼書）」の段階でほぼ決まると言っても過言ではありません。販売管理や在庫、会計といった基幹業務は、長年の運用で仕様書が失われていたりブラックボックス化していたりすることが多く、現状を正しく把握しないまま刷新に着手すると、要件の漏れや認識違いから炎上やコスト超過を招きます。実際、刷新失敗の大きな原因として「要件定義の不十分さ」が共通して指摘されています。
本記事では、業務システムのモダナイゼーションにおけるアセスメント（現状分析）から要件定義、そしてRFP作成・ベンダー選定までの流れを、盛り込むべき項目と評価観点に絞って具体的に解説します。全体像を体系的に整理した業務システムのモダナイゼーションの完全ガイドもあわせてご覧いただくと、各工程の位置づけが理解しやすくなります。本記事は、その完全ガイドより一段深く、AS-IS可視化の手法やRFPの記載項目、ベンダー評価のチェックポイントといった実務に踏み込む内容です。
▼全体ガイドの記事
・業務システムのモダナイゼーションの完全ガイド
アセスメント（現状分析）の重要性とAS-IS可視化
モダナイゼーションの第一歩は、現行システムの現状を可視化するアセスメントです。新規開発であれば「これから作りたいもの」を定義すればよいのですが、刷新では「すでに動いている業務システムが何をしているか」を正確に把握することが出発点になります。ここを飛ばして要件定義に進むと、現行で当たり前に動いていた処理が新システムで抜け落ち、稼働後にトラブルが発生します。
資産棚卸しとブラックボックスの可視化
アセスメントの中核となるのが、システム資産の棚卸しです。どのプログラムがどの業務に紐づき、どのデータを参照しているのかを洗い出し、現行システムの全体像を地図のように整理します。販売管理であれば、見積から受注、出荷、請求、入金消込までの一連の処理と、そこで使われる商品マスタや得意先マスタの関係を可視化していきます。この作業によって、使われていない機能（リタイア候補）や、特定の担当者しか把握していない処理が明らかになります。
ブラックボックス化の可視化を支援するツールも登場しています。たとえば富士通が提供する「ソフトウェア地図」は、アプリケーション資産の複雑度や依存関係を可視化し、どの部分がどれだけ絡み合っているかを把握しやすくするものです。こうしたツールを活用すれば、目視では追いきれない大規模な業務システムでも、刷新の難易度が高い箇所を客観的に特定できます。可視化の精度が、後続の要件定義とコスト見積りの精度を直接左右します。
アセスメント・要件定義を切り出して発注する
アセスメントと要件定義は、刷新全体の中でも特に重要な工程であるため、本体の開発契約とは切り離して先行発注するのが定石です。要件定義・業務棚卸しのみであれば、費用の目安は200万〜500万円程度です。ここで現状と目指す姿を固めてから本格的な刷新の見積りを取ることで、後工程での手戻りや想定外コストを大きく減らせます。
この段階を軽視して、いきなり大規模な一括契約を結んでしまうと、現状把握が浅いまま開発が進み、途中で要件が膨らんでコストが膨張するという典型的な失敗パターンに陥ります。アセスメントへの投資は、刷新全体の数千万円規模の支出に対するリスク保険のようなものであり、ここを丁寧に行うことが結果的に総コストを抑えることにつながります。単一の業務システム刷新であれば全体で3,000万〜1.5億円、基幹に周辺を含む中〜大規模では1.5億〜5億円規模に達することを踏まえれば、上流に数百万円を投じて全体像を固める意義は明らかです。
要件定義で押さえるべき観点
アセスメントで現状（AS-IS）を可視化したら、次は刷新後のあるべき姿（TO-BE）を定義する要件定義に進みます。モダナイゼーションの要件定義は、新規開発と異なり「現行踏襲」と「業務改善」のバランスを取ることが難しいポイントになります。何を変えずに残し、何を見直すかを明確に切り分けることが重要です。
現行踏襲と業務改善の切り分け
業務システムの刷新では、現行の業務をそのまま新システムに移す「現行踏襲」が安全に見える一方で、長年蓄積された無駄や形骸化したルールまで引き継いでしまう危険があります。要件定義では、現行処理を一つずつ「これは法令・取引上必須か」「単なる慣習で残っているだけか」と仕分けし、改善の余地がある部分を明確にします。イオングループの事例のように、刷新を業務プロセスの見直しと一体で進めることで、効果が何倍にもなります。
一方で、すべてを改善対象にすると要件が際限なく膨らみ、プロジェクトが破綻します。会計や勤怠のように法令で定まった処理は現行踏襲を基本とし、販売や在庫のように競争力に関わる業務は改善を検討する、といった優先順位づけが現実的です。要件定義の段階で「変えるもの」と「変えないもの」を文書として確定させ、関係部門の合意を取っておくことが、後の仕様変更による混乱を防ぎます。
データ移行と非機能要件の定義
業務システム刷新の要件定義で見落とされがちなのが、データ移行と非機能要件です。商品マスタや取引先マスタ、過去数年分の伝票データをどう新システムに移すかは、刷新の中でも最も泥臭く、失敗しやすい領域です。新旧でデータ項目の持ち方が異なる「データマッピング」の整理や、移行対象とする過去データの範囲を要件として明確にしておく必要があります。これを曖昧にすると、移行リハーサルの段階で大量の不整合が噴出します。
非機能要件としては、性能（夜間バッチの処理時間や画面応答速度）、可用性（許容できるダウンタイム）、セキュリティ、保守体制などを数値で定義します。たとえば「月次締め処理を翌朝6時までに完了させる」「切り替え時のダウンタイムは半日以内」といった具体的な目標値を設定することで、後続のRFPやベンダー選定で各社を客観的に比較できるようになります。これらの非機能要件は、刷新後のKPIとしてそのまま効果測定にも使えます。逆に、非機能要件を曖昧なまま進めると、稼働後に「想定より遅い」「障害時に復旧できない」といった事態が起き、せっかくの刷新が評価されないことにもなりかねません。数値で合意しておくことが、後のトラブルと認識違いを防ぐ最大の備えになります。
RFP作成とベンダー選定の評価項目
要件が固まったら、それをベンダーに提示して提案を募るためのRFP（提案依頼書）を作成します。RFPの完成度が低いと、各社の提案がばらつき、見積りも比較できなくなります。逆に要件と評価軸を明確にしたRFPは、ベンダーの実力を正確に引き出し、選定の精度を高めます。ここではRFPに盛り込むべき項目と、ベンダー評価のチェックポイントを整理します。
RFPに盛り込むべき項目
RFPに盛り込むべき主な項目は、プロジェクトの背景・目的、現行システムの構成図、機能要件と非機能要件、データ移行の方針、想定スケジュールと予算、そして刷新後に達成したいKPIです。特に業務システムのモダナイゼーションでは、現行構成図と移行後のKPIを明示することが重要になります。現行構成を示すことでベンダーは刷新範囲を正確に把握でき、KPIを示すことで提案の方向性がそろうためです。
あわせて、現状で抱えている課題（保守費の高騰、特定担当者への依存、夜間バッチの遅延など）と、刷新で実現したい姿を具体的に記載します。「保守費を何割削減したい」「月次決算を何日早めたい」といった定量目標を提示できれば、ベンダーは投資対効果を意識した提案を行いやすくなります。RFPは単なる仕様の羅列ではなく、自社の課題意識と期待値をベンダーと共有するためのコミュニケーション文書だと捉えることが大切です。
ベンダー評価の5つのチェックポイント
ベンダーを客観的に評価するための観点として、次の5つが有効です。第一に、同業界・同規模の業務システム刷新実績があるか。第二に、ビッグバンではなく段階移行を設計できる力があるか。第三に、切り替え時のダウンタイムを現実的に見積もれているか。第四に、稼働後の24時間365日の保守体制を持つか。第五に、ISO9001やISO27001といった品質・セキュリティ認証を取得しているか、という観点です。
これらのチェックポイントは、価格の安さだけでベンダーを選ぶことの危険を避けるための軸でもあります。販売・会計・在庫といった止められない業務を扱う以上、移行設計の堅実さや保守体制の手厚さは、初期費用以上に重要な評価要素です。提案内容を5つの観点で点数化し、複数社を同じ基準で比較することで、稟議でも説明しやすい客観的な選定が可能になります。価格・実績・体制を総合して判断する姿勢が、刷新成功への第一歩です。
上流工程でつまずかないための進め方
アセスメント・要件定義・RFPという上流工程は、それぞれが独立しているのではなく、前の工程の質が次の工程に直結する連鎖関係にあります。どこか一つでも手を抜くと、後工程で取り返しのつかない問題が顕在化します。ここでは、上流工程でつまずかないための実務上の進め方を、関係者の巻き込みと文書化の観点から整理します。
業務部門を巻き込んだ要件確定
上流工程でもっとも重要なのが、業務部門（ユーザー部門）の主体的な参画です。販売や経理、在庫管理の現場でしか把握していない業務知識は、情報システム部門やベンダーだけでは拾いきれません。要件定義の段階で、実際にシステムを使う担当者にヒアリングを重ね、例外処理や繁忙期の運用まで含めて洗い出すことが、稼働後の「これができない」を防ぎます。現場の参画不足は、パッケージ導入の失敗要因としても繰り返し指摘されています。
業務部門を巻き込むには、要件定義を情報システム部門だけの作業にせず、業務部門の代表者をプロジェクトメンバーに正式に位置づけることが効果的です。各業務の責任者が要件のレビューと承認に関与する体制を作れば、後から「聞いていない」という認識違いが起きにくくなります。上流工程は技術作業である以上に、関係部門の合意形成プロセスだと捉えることが、手戻りを防ぐ最大のポイントです。
決定事項を文書化して認識を揃える
上流工程で固めた内容は、必ず文書として残し、関係者間で共有することが欠かせません。現状分析の結果、要件定義書、RFP、そしてベンダー評価の基準と結果は、すべて文書化しておくことで、プロジェクトが進む中での認識のズレを防げます。特に「変えるもの」「変えないもの」「移行対象とするデータの範囲」といった判断は、口頭の合意だけでは後にトラブルの火種になります。
文書化のもう一つの意義は、ブラックボックス化の再発を防ぐことにあります。今回の刷新で苦労して可視化した業務ロジックやデータ構造を文書として残しておけば、次の世代の担当者が現状を把握しやすくなり、再び属人化・ブラックボックス化に陥るリスクを下げられます。上流工程の成果物は、刷新プロジェクトのためだけでなく、将来にわたって業務システムを健全に保つための資産になるのです。
まとめ
本記事では、業務システムのモダナイゼーションにおけるアセスメント・要件定義・RFPの進め方を解説しました。出発点となるのは資産棚卸しによる現状（AS-IS）の可視化であり、「ソフトウェア地図」のようなツールも活用しながらブラックボックスを解きほぐすことが重要です。要件定義では現行踏襲と業務改善を切り分け、データ移行と非機能要件を数値で明確にします。そのうえで、現行構成図・KPI・課題を盛り込んだRFPを作成し、ベンダーから精度の高い提案を引き出します。
ベンダー選定では、同業界・同規模の実績、段階移行の設計力、ダウンタイム見積り、24時間365日の保守体制、品質・セキュリティ認証という5つのチェックポイントで複数社を客観的に比較することが有効です。要件定義・業務棚卸しのみであれば200万〜500万円程度で先行発注でき、この投資が刷新全体のリスクを大きく抑えます。アセスメントから要件定義、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を創業。