購買管理システム更改のアセスメント/要件定義/RFPについて

長年使い続けてきた購買管理システムの更改を検討する際、プロジェクトの成否を最初に左右するのが「アセスメント（現状分析）」と「要件定義」、そしてベンダーへ提示する「RFP（提案依頼書）」の質です。購買・調達システムの更改は、新規に業務システムをゼロから構築するのとは異なり、すでに発注・承認・検収・支払といった業務が日々回っている既存システムを更新・置換する取り組みです。EOL（製品サポート終了）やインボイス制度・電子帳簿保存法への対応、基幹・会計連携の老朽化といった契機で更改に踏み切る企業は多いものの、現行の仕様を正確に把握できていなければ、新しい購買システムの要件を固めることすらできません。経済産業省が指摘する「2025年の崖」では、レガシーシステムを放置した場合に大きな経済損失が生じるリスクが警告されており、購買・調達領域の更改も待ったなしの経営課題となっています。

一方で、購買管理システムの更改プロジェクトが頓挫する大きな原因は、現行システムのアドオンや個別改修がブラックボックス化していたり、サプライヤマスタや単価マスタのデータ品質が把握できていなかったりして、要件定義が不十分なまま発注へ進んでしまうことにあります。本記事では、購買管理システム更改のアセスメント・要件定義・RFP作成に絞り込み、現行購買フローの棚卸しの進め方、RFPに盛り込むべき項目、そして失敗しないベンダー選定の評価観点までを、購買・調達の実務目線で整理します。更改全体の流れや前提を体系的に押さえたい方は、あわせて購買管理システム更改の完全ガイドもご覧ください。本記事はその完全ガイドの内容を発注実務に落とし込み、RFPに何をどの粒度で書くべきかを掘り下げる位置づけです。

▼全体ガイドの記事
・購買管理システム更改の完全ガイド

購買管理システム更改におけるアセスメント（現状分析・AS-IS可視化）

購買管理システムの更改を成功させるうえで、最初の関門となるのがアセスメント、すなわち現状分析です。更改の対象となる既存の購買システムが、どのような業務フローを支え、どんなマスタを持ち、基幹や会計とどう連携しているのかを正確に把握できなければ、更改後の姿を設計することはできません。新規構築と決定的に異なるのは、すでに調達業務が回っている資産を扱う点にあります。現行の処理を取りこぼせば、更改後に「以前は処理できていた発注パターンが通らない」「特定サプライヤへの支払が止まる」といった事態を招きます。ここでは、更改の出発点となる現行購買フローの棚卸しとAS-IS可視化の進め方を整理します。

アセスメントの中核となるのが、現行購買フローの棚卸しです。具体的には、発注・承認・検収・支払という一連の調達プロセスが、どの部門でどの画面・帳票を使い、どんな承認ルートで処理されているのかを網羅的に洗い出します。あわせて、サプライヤマスタと単価マスタのデータ品質を調査することが欠かせません。重複登録や古い取引先、契約単価と実績単価の乖離といった汚れがマスタに残ったまま更改を進めると、新システムに不正確なデータを引き継ぐことになり、稼働後の混乱を招きます。

もう一つ重要なのが、外部システムとの連携インターフェースの整理です。購買システムは、会計システムへの支払データ連携、基幹システムとの在庫・原価連携、そしてサプライヤとのEDI（電子データ交換）など、多くのインターフェースを抱えているのが一般的です。これらのインタフェース一覧を作成し、どのデータがどの方向に流れているのかを可視化しておかなければ、更改時にどこかの連携が抜け落ち、業務が止まる危険があります。現行構成の依存関係を整理することは、更改範囲を見極める前提条件となります。

さらに、長年の運用で積み上がったアドオンや個別改修の洗い出しも欠かせません。標準機能では足りない部分を個別開発で補ってきた結果、その仕様が誰にも正確に説明できないブラックボックスと化しているケースは少なくありません。日本情報システム・ユーザー協会（JUAS）の調査でも、約7割の企業が基幹システムのレガシー化を課題として挙げており、購買システムも例外ではありません。アドオンの棚卸しは、更改後にどの機能を標準で吸収し、どの機能を改めて作り込むかを判断する材料になります。

購買管理システムの更改では、法制度への対応状況の確認がアセスメントの重要な論点になります。インボイス制度（適格請求書等保存方式）に対応するには、受領した請求書が適格請求書の要件を満たしているかを判定し、登録番号を保持する仕組みが必要です。また電子帳簿保存法への対応では、取引関係書類を要件に沿って電子保存できているかが問われます。現行システムがこれらにどこまで対応しているのか、暫定的な手作業で凌いでいる箇所はどこかを棚卸しすることで、更改で解消すべき課題が明確になります。

こうした棚卸しを人手だけで進めるのは、長年改修を重ねたシステムほど困難です。そこで活用されるのが、アプリケーション資産を機械的に解析して可視化するツールです。たとえば富士通が提供する「ソフトウェア地図」は、アプリケーション資産の複雑度や依存関係を地図のように可視化し、どこにリスクが集中しているかを俯瞰できるようにする支援ツールです（出典：富士通）。購買システムのように個別改修が積み重なった資産では、こうしたツールを用いることで、目視では追い切れないプログラム間の依存構造を客観的なデータとして把握でき、更改範囲の優先順位づけに役立てられます。

アセスメントから要件定義にかけての工程は、更改の本体開発に入る前の準備段階にあたります。この段階だけを切り出して外部の専門会社に依頼する場合、業務の棚卸しと要件定義のみで200万〜500万円程度が一つの目安とされます。本体の更改費用に比べれば一部分に見えるかもしれませんが、ここでの分析の質が後工程の見積り精度を決めるため、相応の投資が必要な工程です。この費用を惜しんで現状分析を省略すると、本体開発の途中で想定外の仕様やマスタの不整合が次々と判明し、追加要件や手戻りでコストもスケジュールも膨らみます。RFPを出す前にこの段階を独立して進め、確かな現状理解のうえで発注に臨むことをお勧めします。

更改後のKPIと機能・非機能・データ移行の要件定義

アセスメントで現行購買フローが可視化できたら、次はその情報をもとに要件を固めていきます。購買管理システムの更改では、更改後に何を実現したいのかという目標と、それを支える機能要件・非機能要件、そして既存データをどう引き継ぐかというデータ移行要件を、抜け漏れなく定義することが重要です。ここでは、更改後のKPIを起点に、購買・調達文脈で押さえるべき要件を整理します。要件が曖昧なまま発注に進むと、ベンダー各社の提案がバラバラの前提で作られ、横並びの比較ができなくなります。

要件定義の出発点は、更改後に達成したいKPIを明確にすることです。購買管理システムであれば、発注リードタイムの短縮、請求照合（マッチング）の自動化率、支出の可視化といった指標が代表的です。「処理にかかる工数を何割減らしたいのか」「請求照合の自動化率を何パーセントまで高めたいのか」といった数値目標を示すことで、更改の成否を客観的に評価できるようになります。KPIが曖昧なまま発注すると、「新しいシステムは動くが、期待した効率化は得られなかった」という結果に陥りがちです。

このKPIを実現するために、購買特有の機能要件を具体的に定義します。代表的なものとしては、発注書・検収・請求書の三者を突き合わせて支払の妥当性を担保する3-way match（三点照合）、部門や金額に応じて自動で経路が変わる承認ワークフロー、サプライヤとオンラインで注文や納期回答をやり取りするWeb-EDI、そしてインボイス制度に対応した適格請求書の処理などが挙げられます。これらの機能をどの粒度で求めるのかを、現行業務との対応づけとともに整理することが、更改後の業務効率を左右します。

機能要件を定義する際は、現行のアドオンで実現していた処理を、更改後の標準機能でどこまで吸収できるかを見極める視点が欠かせません。標準機能に合わせて業務を見直せる部分は見直し、どうしても譲れない購買ルールだけを個別要件として残すことで、更改の難度とコストを抑えられます。アセスメントで洗い出したアドオン一覧を、機能要件の検討材料として活用することが、過剰な作り込みを避ける鍵になります。

機能要件と並んで重要なのが、性能・可用性・セキュリティといった非機能要件です。購買システムは月末や期末の処理が集中する時期に負荷が高まるため、ピーク時の同時接続数や請求照合バッチの許容処理時間を性能要件として明示する必要があります。可用性については、支払業務が止まると取引先への支払遅延に直結するため、求める稼働率や障害時の復旧目標時間を定義します。セキュリティでは、取引単価や支払情報という機密性の高いデータを扱う以上、アクセス権限の制御や監査ログの要件を明確にすることが求められます。

そして、購買システムの更改で特に難所となるのがデータ移行要件です。引き継ぐべき対象としては、サプライヤマスタ、単価マスタ、そして未検収の発注（未検収PO）が代表的です。とりわけ未検収POは、発注済みだがまだ検収が終わっていない取引であり、更改のタイミングで宙に浮くと、検収や支払が処理できなくなる恐れがあります。どの時点のデータを、どのような形式で、どこまで移行するのかを要件として定義しておくことが、稼働後の業務停止を防ぐうえで欠かせません。

データ移行要件を固める際は、アセスメントで把握したマスタのデータ品質を踏まえ、移行前にどこまでクレンジング（データの整理・修正）を行うかも併せて決めておきます。汚れたマスタをそのまま移行すれば、新システムでも同じ問題を抱え込むことになります。一方で、すべてを完璧に整えてから移行しようとすると工数が膨らむため、どの範囲を移行前に整え、どの範囲を移行後に運用で修正するかの線引きを要件として明文化することが、現実的な移行計画につながります。

RFPに盛り込む項目とベンダー選定の評価観点

アセスメントと要件定義で固めた内容は、最終的にRFP（提案依頼書）へ落とし込み、ベンダー各社に提案を求めることになります。RFPは、各社に同じ前提で提案を作ってもらうための共通の物差しです。記載が曖昧だと、各社の提案がバラバラの前提で作られ、横並びの比較ができなくなります。ここでは、購買管理システム更改のRFPに盛り込むべき項目と、提案を評価する際のベンダー選定の観点を整理します。

購買管理システム更改のRFPでは、ベンダーが現行システムを知らない状態で提案を作るため、現状情報の解像度がそのまま提案の精度に直結します。RFPに盛り込むべき代表的な項目を整理すると、次のとおりです。

・現行システムの構成図（ハードウェア・ミドルウェア・基幹／会計連携やEDIを含む全体図）
・移行対象範囲（更改する機能と、現行のまま据え置く機能の線引き）
・性能要件（月末・期末の同時接続数、請求照合バッチの許容処理時間など）
・移行後のKPI（発注リードタイム短縮、請求照合自動化率、支出可視化などの数値目標）
・データ移行方針（サプライヤ／単価マスタ、未検収POの引き継ぎ範囲）
・サポート体制（稼働後に求める保守・運用のサポート水準）
・移行方式（段階移行やストラングラーパターンなど想定する進め方）
・概算費用・期間（投資可能な金額の幅と希望する完了時期）

これらをRFPに明記することで、ベンダー各社が同じ前提に立って提案を作成でき、見積りの比較可能性が担保されます（出典：富士通）。

とくに現行構成図と移行対象範囲は、購買システム更改に固有の重要項目です。会計・基幹との連携やEDIをどこまで更改の対象に含めるのかが曖昧だと、ベンダーごとにスコープの解釈が割れ、見積りが大きくぶれます。アセスメントで可視化した連携一覧やマスタの状況を、RFPの中で具体的な図表として提示することが、提案の質を引き上げる鍵となります。あわせて、段階移行を前提とするのか、一度に切り替えるビッグバン方式を許容するのかという移行方式の方針も、RFPに明示しておくべき論点です。

RFPを各社に提示し、提案が出そろったら、いよいよベンダーの選定です。購買管理システムの更改は、基幹や会計と密接に連携する既存資産を扱う難度の高いプロジェクトであるため、価格や提案書の見栄えだけで選ぶのは危険です。客観的な判断をするために、次の5つのチェックポイントを軸にすると比較がしやすくなります。

(1) 同業界・同規模の購買・基幹更改実績があるか。自社と近い業界や規模で購買・調達システムを更改した経験があれば、固有の調達ルールや法対応の落とし穴への理解が期待できます。
(2) 段階移行（ストラングラーパターン）の設計力があるか。新旧システムを並行稼働させながら機能を少しずつ移す設計は、業務を止めずに更改を進める鍵となります。
(3) ダウンタイム（切替時の停止時間）の見積り精度が高いか。支払や検収が止まる時間を具体的に試算できるベンダーは、移行の段取りを現実的に描けている証拠です。
(4) 24時間365日の保守体制を備えているか。購買・支払業務は止まると取引先との関係に直結するため、運用フェーズのサポート水準が重要になります。
(5) ISO9001やISO27001などの品質・セキュリティ認証を取得しているか。取引単価や支払情報を扱う以上、組織としての品質管理と情報セキュリティの裏づけが欠かせません。

これら5つの観点は、いずれも提案の見栄えでは測れない実力を映し出すものです。とくに段階移行の設計力とダウンタイムの見積り精度は、購買システム更改特有の難所に直結するため、重点的に確認することをお勧めします。一度にすべてを切り替えるビッグバン方式は、切替時の影響範囲が大きく、問題が起きたときの後戻りが難しいという特徴があります。これに対し、機能を分割して順次置き換える段階移行は、影響を局所化しながら進められるため、業務を止めにくいという利点があります。各観点に重みづけをして点数化すれば、複数社を定量的に比較できる選定シートが作れます。

最終的な選定では、価格の安さだけで判断しないことが何より重要です。購買管理システムの更改は、安価な提案に飛びついた結果、移行に失敗して支払業務が混乱し、かえって高くつくケースが後を絶ちません。5つのチェックポイントで一定の水準を満たしたうえで、総保有コストや更改後の運用負荷まで含めて総合的に判断する姿勢が、失敗しないベンダー選定につながります。RFPの段階で各観点に関する情報をベンダーから引き出す問いを用意しておけば、抽象的なアピールではなく具体的な事例や試算で各社を横並びに評価できます。

まとめ

本記事では、購買管理システム更改のアセスメント・要件定義・RFP作成に絞り込み、更改を発注実務に落とし込む際の要点を整理してきました。まず、更改失敗の大きな原因がアドオンのブラックボックス化やマスタのデータ品質の見落としにあることを踏まえ、現行購買フロー（発注・承認・検収・支払）の棚卸し、サプライヤ／単価マスタの品質調査、EDI・基幹・会計連携の整理、そしてインボイス制度や電子帳簿保存法の対応状況確認を徹底することの重要性を確認しました。富士通の「ソフトウェア地図」のような可視化ツールを活用し、棚卸し・要件定義フェーズに200万〜500万円程度の投資を惜しまないことが、後工程のリスクを前倒しで潰す鍵になります。

続いて、要件定義では更改後のKPI（発注リードタイム短縮、請求照合自動化率、支出可視化）を起点に、3-way matchや承認ワークフロー、Web-EDI、適格請求書処理といった機能要件、性能・可用性・セキュリティの非機能要件、そしてサプライヤ／単価マスタや未検収POのデータ移行要件を具体的に固めることが重要だと述べました。RFPには、現行構成図・移行対象範囲・性能要件・移行後KPI・サポート体制・移行方式・概算費用と期間を盛り込み、ベンダー各社が同じ前提で提案できるようにします。ベンダー選定では、同業界・同規模の更改実績、段階移行（ストラングラーパターン）の設計力、ダウンタイムの見積り精度、24時間365日の保守体制、ISO9001やISO27001などの認証という5つのチェックポイントで客観的に比較する姿勢が失敗を防ぎます。

2025年の崖が警告するように、レガシー化した購買・調達システムの更改はもはや先送りできない経営課題です。だからこそ、焦って発注に走るのではなく、現状分析という土台を固めたうえで、ビッグバンを避けた段階移行を前提に、質の高いRFPと客観的なベンダー評価をもって臨むことが、更改成功への確実な近道となります。アセスメントから要件定義、RFP、ベンダー選定までの一連の流れを丁寧に積み上げることが、購買管理システム更改を成功へ導く出発点です。

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。