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

購買管理システムの刷新を進めるとき、開発そのものよりも難しいのが、その前段で作り上げる「ドキュメント」の質をどう担保するかという問題です。アセスメントの報告書、要件定義書、RFP（提案依頼書）といった上流工程の成果物は、刷新プロジェクト全体の設計図にあたります。ここに抜けや曖昧さがあると、発注・検収・支払といった基幹業務が止まりかねない刷新で、後工程の手戻りや追加費用が一気に膨らみます。逆に言えば、何を盛り込み、どの項目を点検すれば抜けがないのかを最初に押さえておけば、刷新の成否は大きく安定します。

本記事では、購買・調達領域のシステム刷新について、アセスメント・要件定義・RFPの各工程で「実際に作る成果物」と「点検すべきチェック項目」に踏み込んで整理します。富士通の「ソフトウェア地図」による複雑度の可視化、要件定義のみで200万〜500万円という費用相場、RFP記載項目やベンダー評価の客観基準といった一次情報を、購買固有のチェックリストに落とし込んでご紹介します。手法の全体像や費用感を体系的に押さえたい場合は、購買管理システム刷新の完全ガイドもあわせてご覧いただくと、本記事の上流工程を全体像の中で位置づけやすくなります。ここでは、その完全ガイドでは触れきれない「成果物とチェック項目の具体」に焦点を絞ってお伝えします。

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

購買管理システム刷新のアセスメント：現行資産と業務の棚卸しで何を可視化するか

刷新プロジェクトの入り口にあたるアセスメントは、「何を可視化し、どの項目を点検対象にするか」を決める工程です。ここで作る成果物は、現状診断レポートと資産一覧であり、後続の要件定義やRFPはこの診断結果を土台に組み立てられます。購買・調達の刷新では、一般的なシステム資産の棚卸しに加えて、調達現場ならではの点検項目を漏らさないことが重要になります。本章では、アセスメントで主役となる点検リストの考え方を整理します。

購買アセスメントは、診断項目をあらかじめリスト化しておくことで、抜け漏れを防ぎながら効率的に進められます。漠然と「現状を調べる」のではなく、点検すべき観点を先に決めておくことが診断の質を左右します。購買・調達の刷新で最低限点検しておきたい項目は、業務・データ・連携・統制の4つの軸に整理できます。

具体的な点検項目を挙げると、次のとおりです。

・野良購買の量：システム外でExcelや紙により処理されている発注がどれだけあるか
・サプライヤーマスタの汚れ：表記ゆれによる取引先の重複登録や休眠データの残存
・例外承認の実態：規程外の特急発注や事後承認がどの頻度で発生しているか
・基幹連携インターフェース：ERPや会計システムとのデータ受け渡し方式と更新頻度
・帳票・保存の現状：発注書や検収書が紙か電子か、保存方法が制度に適合しているか

これらを点検結果として一覧化することで、刷新の対象範囲と移行の難所が浮かび上がります。

とりわけ野良購買と例外承認は、診断の精度を大きく左右する項目です。システムに乗っていない購買は、現行システムの画面を眺めるだけでは見えてきません。購買部門・経理部門・現場の発注担当者へのヒアリングを通じて、「正規の手順から外れた処理」がどこにどれだけ潜んでいるかを掘り起こすことが、後の要件定義の精度を決めます。点検リストは、このヒアリングの抜け漏れを防ぐ羅針盤として機能します。

業務面の点検と並行して取り組みたいのが、現行アプリケーション資産の技術的な診断です。ヒアリングだけでは把握しきれない、プログラム同士の絡み合いやブラックボックス化の度合いは、可視化ツールを使うことで客観的なデータとして残せます。富士通が提供する「ソフトウェア地図」は、アプリケーション資産の複雑度やプログラム間の依存関係を地図のように描き出し、どこが手を入れにくいかを一目で示してくれるツールです。

購買管理システムは、発注・検収・支払・在庫・会計といった機能が密に連携しているため、ある機能に手を入れると思わぬ箇所へ影響が波及しやすい構造を抱えています。依存関係をデータ化しておけば、刷新を段階的に進める際の「切り出し単位」を、勘ではなく根拠に基づいて決められます。アセスメントの成果物として、この複雑度マップを残しておくことが、後のRFPで段階移行方針を語る際の裏付けにもなります。

こうしたアセスメントは、それ自体を独立した工程として外部に委託することもできます。要件定義・業務棚卸しのみで200万〜500万円程度が費用相場の目安とされています。決して安くはありませんが、この診断を省いて要件が曖昧なまま開発へ進むと、後工程での手戻りや追加費用がはるかに大きく膨らみます。上流の診断への投資は、総コストを抑えるための先行投資と捉えるのが妥当です。

要件定義で固めるべき購買刷新のTO-BE要件

アセスメントで現状を診断したら、次は刷新後の姿を定義する要件定義です。ここで作る要件定義書は、ベンダーに渡すRFPの土台になる中核ドキュメントであり、その品質が後続の提案や見積もりの精度を直接左右します。要件定義の成果物を堅牢にするコツは、要件を「機能要件」「非機能要件」「制度要件」の3つの引き出しに整理し、それぞれで漏れがないか点検することです。本章では、購買刷新のTO-BE要件を3分類で固める考え方を整理します。

まず固めるべきは、システムが「何をするか」を定める機能要件です。購買管理システムであれば、発注・検収・三点照合（発注書・納品書・請求書の突合）・支払処理・マスタ管理といった業務機能が中核になります。アセスメントで洗い出した野良購買や例外承認を、新システムでどこまで取り込み、どう標準化するかを機能要件として言語化していきます。ここを曖昧にすると、稼働後に現場が使わないシステムになりかねません。

一方で見落とされがちなのが、「どの程度の品質で動くか」を定める非機能要件です。発注や支払を扱う購買システムでは、性能と可用性が事業継続に直結します。要件定義書には、次のような非機能要件を具体的な数値で書き込んでおくことが望まれます。

・性能：月次締めの集中時に何件の発注・検収を何秒以内で処理するか
・可用性：許容できる停止時間と、障害時の切り戻し手順
・移行後KPI：発注リードタイムや支出可視化率など、達成すべき数値目標
・拡張性：取引先や拠点の増加にどこまで耐えられるか

これらを数値で明示しておくことで、ベンダー各社の提案を同じ物差しで比較できるようになります。

とくに移行後KPIは、要件定義を単なる仕様書から「成果を測る契約」へと格上げする要素です。発注リードタイムを何割短縮するのか、支出可視化率を何パーセントまで高めるのかをあらかじめ定めておけば、刷新後の達成度を客観的に評価でき、ベンダーとの認識合わせもぶれません。機能の網羅性に気を取られて非機能要件の数値化を後回しにすると、稼働後に「思ったより遅い」といった評価のずれを招きます。

機能・非機能と並ぶ第三の引き出しが、法制度への適合を定める制度要件です。購買・調達は、発注書や請求書といった証憑を大量に扱うため、税務・会計に関わる制度の影響を真正面から受けます。要件定義の段階でこれを織り込んでおかないと、稼働後に大規模な改修が発生し、刷新の効果が削がれてしまいます。

購買刷新で押さえるべき制度要件の中心は、電子帳簿保存法とインボイス制度への対応です。電子帳簿保存法に沿えば、電子取引で受け取った発注書や請求書を、改ざん防止や検索性の要件を満たす形で電子保存する仕組みが求められます。インボイス制度への対応では、適格請求書の記載事項を正しく処理し、税区分ごとに正確な仕入税額控除を行える仕様が必要になります。これらを「対応する」と一言で済ませず、保存方法や処理フローのレベルまで要件定義書に落とし込むことが肝心です。

制度要件をこの段階で固めておく利点は、後追いの個別改修を避けられることだけではありません。刷新は、属人化した承認ルールや帳票の扱いを制度に合わせて一気に標準化できる、またとない機会でもあります。なお、要件定義書は次工程のRFPの土台になるため、この3分類で要件を明確に言語化できているほど、ベンダーへ正確な前提を伝えられ、提案の精度も高まります。要件定義の品質が、その後のベンダー選定の質をそのまま決めると言っても過言ではありません。

RFPに盛り込むべき項目とベンダー評価の客観基準

要件定義の成果を、ベンダーへの提案依頼書（RFP）という形に仕立て、提案を客観的に評価するのがこの工程です。RFPは、各ベンダーから的確な提案を引き出し、複数社を同じ条件で比較するための共通の物差しになります。記載が薄ければ提案も薄くなり、選定の精度は下がります。本章では、RFPに盛り込むべき項目と、提案を見極めるベンダー評価の客観基準を整理します。

RFPという成果物の役割は、ベンダーが正確に提案するための前提を、過不足なく伝えることにあります。刷新案件では、現行システムの状態と刷新後の到達点を具体的に示すことがとりわけ重要です。要件定義書で固めた内容を、ベンダーが読み解きやすい形へ再構成していくイメージで作り込みます。

RFPに記載しておきたい中心的な項目は、次のように整理できます。

・現行構成図：アセスメントで作成したAS-IS全体像と連携先の一覧
・性能要件：同時利用者数や処理件数、レスポンスの目標値
・移行後KPI：発注リードタイムや支出可視化率など達成すべき数値
・段階移行方針：どの機能から先行稼働させ、どう新旧を並行させるか
・データ移行の範囲：サプライヤーマスタや過去取引データの扱い

これらを具体的に記すほど、提案の精度と各社の比較可能性が高まります。

購買管理システムのRFPでは、ここに購買固有の前提を加えることが差別化の決め手になります。三点照合の自動化範囲、ERP・会計との連携方式（API連携かファイル連携か、リアルタイムかバッチか）、電子帳簿保存法・インボイス制度への対応方法を、要件として明示しておきます。とくに段階移行方針は、発注や支払を止められない購買システムでは欠かせない記載項目です。発注機能から先行させ、検収・支払を後続で移すといった現実的な移行像を示せるかどうかが、提案の質に表れます。

提案が出そろったら、金額の安さだけで判断せず、客観的な観点に沿って各社を採点します。提示金額の低さに引きずられて選ぶと、刷新の途中で実装力やサポート体制の不足が露呈し、プロジェクトが立ち行かなくなる恐れがあります。刷新案件で共通して有効な評価観点は、次の5つに集約できます。

採点表に落とし込みたい5観点は以下のとおりです。

・同業種・同規模の実績：似た業種や企業規模での刷新経験があるか
・段階移行の設計力：新旧を並行させながら安全に移す設計を描けるか
・ダウンタイムの見積り：切り替え時の停止時間を具体的な数値で提示できるか
・24時間365日の保守体制：稼働後のサポート体制が整っているか
・ISO9001／27001等の認証：品質と情報セキュリティの客観的な裏付けがあるか

これら5観点を各社で採点すれば、提案の良し悪しを感覚に頼らず横並びで判断できます。

購買管理システムの場合は、この5観点に「購買業務への習熟度」を補助線として加えると、見極めの精度がさらに上がります。三点照合や予算統制、サプライヤーポータルといった購買特有の機能を、過去にどこまで実装してきたか。制度対応を「対応可能」と抽象的に述べるだけか、保存要件や適格請求書の処理方法まで踏み込んで提示できるか。提案書の抽象度そのものが、ベンダーの実装力を映す鏡になります。アセスメントから要件定義、RFPへと丁寧に成果物を積み上げてきた企業ほど、こうした提案の差を読み取る目も確かなものになっているはずです。

まとめ

本記事では、購買管理システム刷新のアセスメント・要件定義・RFPについて、各工程で作る成果物と点検すべきチェック項目に焦点を当てて解説してきました。アセスメントでは、野良購買・サプライヤーマスタの汚れ・例外承認・基幹連携・帳票保存という購買固有の点検項目をリスト化し、富士通の「ソフトウェア地図」で複雑度と依存関係をデータ化します。要件定義では、機能要件・非機能要件・制度要件という3つの引き出しでTO-BE要件を固め、移行後KPIや電子帳簿保存法・インボイス対応を数値とフローのレベルまで言語化することが要点でした。

RFPでは、現行構成図・性能要件・移行後KPI・段階移行方針・データ移行範囲を成果物として整え、購買固有の前提を明記します。ベンダー評価では、同業種同規模の実績、段階移行の設計力、ダウンタイム見積り、24時間365日の保守体制、ISO9001／27001認証という5観点を採点表に落とし込み、購買業務への習熟度を補助線として加えます。要件定義・業務棚卸しのみでも200万〜500万円が相場ですが、この上流工程の成果物を堅牢に作り込むことこそが、刷新全体の手戻りを抑える最善の手立てになります。

自社の購買管理システム刷新を検討する際は、まず本記事のチェック項目を手元のたたき台として使い、アセスメント・要件定義・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を創業。