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

受発注管理システムの刷新は、いきなり開発に着手するものではありません。新しい仕組みをゼロから作る新規開発と違い、刷新は「すでに稼働している現行システム」という前提条件の上に成り立ちます。取引先とのEDI接続、在庫・会計・販売管理といった基幹システムとのつながり、長年積み上がった個別仕様や例外処理など、現行システムが抱える事情を無視して進めれば、移行後にデータ連携が止まる、追加費用が膨らむといった事態を招きかねません。だからこそ刷新では、アセスメント（現状分析）から要件定義、RFP（提案依頼書）の作成、そしてベンダー選定へと至る上流工程の組み立て方が、プロジェクトの成否を大きく分けます。

本記事では、受発注管理システムの刷新における上流工程に的を絞り、各フェーズで「何を調べ、何を決め、誰に何を問うべきか」を順を追って整理します。経済産業省が「2025年の崖」で警鐘を鳴らしたとおり、老朽化したシステムを放置すれば2025年以降に年間最大12兆円規模の経済損失が生じるとされ、刷新はもはや先送りできない経営課題です。とはいえ、上流工程の進め方を体系立てて理解しておけば、刷新は決して無謀な賭けにはなりません。刷新全体の流れや判断材料を俯瞰したい方は、受発注管理システム刷新の完全ガイドもあわせてご覧いただくと、本記事で扱う上流工程を全体像のなかに位置づけやすくなります。

▼全体ガイドの記事
・受発注管理システム刷新の完全ガイド

受発注システム刷新における上流工程の全体像

受発注システムの刷新は、大きく「アセスメント（現状分析）」「要件定義」「RFP作成」「ベンダー選定」という4つの上流工程を経て、ようやく開発や移行の実行段階に進みます。この4工程は独立して存在するのではなく、前の工程の成果物が次の工程の入力になる、いわば一本の流れでつながっています。アセスメントで現状を可視化し、その情報をもとに要件定義であるべき姿を描き、要件定義の内容をRFPに落とし込み、RFPに対する提案でベンダーを比較する。この連続性が崩れると、上流工程全体が機能しなくなります。

受発注システムを刷新する際にこの上流工程が特に重みを持つのは、受発注が「止められない業務」だからです。社内だけで完結する業務システムであれば、多少の不具合が出ても社内で吸収できる余地があります。しかし受発注は取引先との接点であり、システムが止まれば取引そのものが止まり、その影響は自社の外へと波及します。だからこそ、実行段階に入る前の準備を徹底することが、後戻りのできないリスクを抑える唯一の方法になります。本章では、各工程に入る前に、上流工程全体を貫く考え方を整理します。

刷新と新規開発の最大の違いは、「制約の有無」にあります。新規開発であれば、業務要件さえ固まれば比較的自由に設計できます。一方、刷新には現行システムという揺るがせない出発点があり、そこに蓄積された取引先別の仕様やデータ、周辺システムとの連携を引き継ぎながら作り替える必要があります。つまり刷新は、白紙に絵を描く作業ではなく、すでに描かれた絵を傷めずに描き直す作業に近いといえます。

この違いは、上流工程の重心を「要件を考えること」だけでなく「現状を解き明かすこと」へと移します。新規開発なら要件定義から始められますが、刷新ではその前に、現行システムが実際にどう動いているのかを突き止めるアセスメントが欠かせません。現状を把握しないまま要件定義に入ると、現行で当たり前に動いていた処理が新システムから抜け落ち、移行後に「前はできていたのに」という不満が噴出します。刷新の上流工程が新規開発より一段階多いのは、この現状把握の工程が加わるためです。

上流工程を成功させる鍵は、4つの工程を「現状から目標への一本の線」として一貫させることにあります。アセスメントで明らかにした現状（AS-IS）と、要件定義で描く目標（TO-BE）の間に距離があるほど、刷新の難易度と費用は上がります。この距離を正確に測り、無理のない移行のシナリオを描くことが、上流工程の本質的な役割です。距離を測らずに目標だけを高く掲げると、実現性のない計画になりかねません。

そして、この一本の線を発注先のベンダーへ正確に伝える橋渡しがRFPであり、伝わった内容にどれだけ的確に応えられるかでベンダーを選ぶのがベンダー選定です。つまり上流工程とは、自社の内側で現状と目標を整理する前半（アセスメント・要件定義）と、それを外部のパートナーへ手渡す後半（RFP・ベンダー選定）に分けて捉えると理解しやすくなります。次章以降で、この4工程を順に掘り下げていきます。

アセスメントで現行受発注システムの実態を測る

上流工程の出発点となるのがアセスメント、すなわち現行受発注システムの実態を測る現状分析です。アセスメントのゴールは、刷新の対象範囲と難易度を、感覚ではなくデータで示せる状態にすることにあります。長く使われてきた受発注システムは、増改築を重ねた建物のように、当初の設計から大きく姿を変えていることが多く、その全体像を誰も正確には説明できないという状態に陥りがちです。この「わからない」を「わかる」に変えるのがアセスメントの役割です。

受発注システムのアセスメントでは、システムそのものの構造だけでなく、取引先との連携や周辺システムとのインターフェース、そして移行対象となるデータまでを視野に入れる必要があります。特に受発注は外部との接点が多いため、自社内で完結する評価では不十分です。本章では、アプリケーション資産の複雑度をどう測るか、そして取引先連携やデータ移行対象をどう見極めるかという二つの観点を取り上げます。

現行受発注システムの実態を測るうえで最も難しいのが、長年の運用でブラックボックス化したアプリケーション資産の評価です。設計書が更新されないまま改修だけが繰り返された結果、ソースコードだけが唯一の正しい仕様になっている、という現場は少なくありません。こうした状態を客観的に捉える手法として、富士通が提供する「ソフトウェア地図」のように、ソースコードを解析してプログラムの複雑度や相互の依存関係を地図のように可視化するアプローチが活用されています（出典：富士通）。どの処理が突出して複雑なのか、どの部分が多くの機能から参照される要になっているのかを俯瞰できれば、刷新時にどこから手をつけ、どこに最も注意を払うべきかが見えてきます。

受発注システムの場合、画面から見える受注入力や照会だけでなく、夜間に動く受注確定バッチや、取引先データの自動取り込み、在庫引当の裏側のロジックなど、表に出ない処理が複雑度の塊になっていることがよくあります。複雑度を地図として捉えることで、こうした見えにくい部分のリスクを早い段階で炙り出せます。属人的な勘に頼っていた「あの処理は触ると怖い」という感覚を、定量的なデータへと置き換えること。これが、刷新計画の精度を支える土台になります。

受発注システム特有のアセスメント論点が、取引先との連携をどこまで把握できているかです。EDIによる受発注データの送受信、在庫システムへの引当依頼、会計システムへの売上計上連携など、受発注は数多くのインターフェースを抱えています。これらのインターフェースについて、相手先・データ項目・連携方式・連携タイミングを一覧として棚卸しし、どこに依存関係が集中しているかを見極めます。この依存関係の地図を持たずに刷新を進めると、ある処理を変えた途端に別の連携が止まる、といった連鎖的なトラブルを引き起こします。

もう一つ、アセスメントの段階で見極めておきたいのが、新システムへ引き継ぐ移行対象データの範囲です。受発注データには、過去の受注履歴、商品マスタ、取引先マスタなどが含まれますが、その全てをそのまま移すのが正解とは限りません。廃番になった商品コードや、長期間取引のない取引先、表記の揺れた重複データなどが蓄積している場合、移行対象を絞り込み、移行前に整える計画をこの段階で立てておくことが重要です。何を残し、何を捨て、何を整えてから移すのか。移行対象データの特定は、後の要件定義とRFPで「移行範囲」を明示するための前提になります。

要件定義で刷新後の受発注業務を具体化する

アセスメントで現状を測り終えたら、要件定義のフェーズに進みます。要件定義は、刷新後の受発注業務が「どう変わり、どんな水準を満たすべきか」を文書として確定させる工程です。経済産業省も刷新失敗の主因として要件定義の不十分さを挙げており、この工程の精度が、後続の開発費用や品質を直接左右します。刷新の要件定義では、現行の不満を解消することと、刷新後に達成したい目標を掲げることの両方をバランスよく盛り込むことが求められます。

費用の観点でも、要件定義は軽視できません。現状分析や業務棚卸しを含む要件定義のみを外部に委託する場合、対象範囲によるものの、おおむね200万円から500万円程度が一つの相場とされています。開発本体に比べれば一見大きな出費に見えますが、ここで要件を固め切れずに開発へ進むと、手戻りによる追加費用がそれをはるかに上回ります。本章では、刷新後の目標値をどう定めるか、そして連携・性能・締め処理といった条件をどう数値で示すかを見ていきます。

要件定義の核となるのが、刷新後にどんな受発注業務を実現したいかというTO-BE要件です。現行業務に潜む手作業、二重入力、紙やExcelによる運用といった非効率を洗い出し、新システムでどこまで自動化・標準化するのかを決めます。ここで大切なのは、現行業務をそのまま新システムに移し替えないことです。古い業務の形をそのまま引き継げば、「速くなっただけの旧来業務」で刷新が終わってしまい、刷新本来の狙いである業務の変革を取り逃がします。

あわせて、刷新の成果を測る物差しとして、刷新後のKPIを数値で掲げます。受注入力にかかる時間、受注ミスや欠品の発生率、在庫引当の精度、月次締め処理に要する時間など、刷新によって改善したい指標を、現行の数値とセットで定義します。改善後の目標値だけでなく現状の数値も併記することで、刷新がどれだけの効果を生むのかが具体的になり、ベンダーへの要求も明確になります。目標を数字で語れるかどうかが、要件定義の質を測る一つの基準だといえます。

受発注システムは単体では完結せず、在庫・会計・販売管理といった基幹システムや、EDIを介した取引先システムと密に結びついています。要件定義では、これらの連携要件を取引先別・システム別に細かく定義する必要があります。取引先ごとに異なるEDIフォーマットや通信手順を新システムでどう吸収するのか、在庫システムへの引当依頼や会計システムへの売上計上をどの方式とタイミングで行うのか。アセスメントで棚卸ししたインターフェースを一つずつ要件へ落とし込むことで、移行後の連携停止という最悪の事態を防ぎます。

機能面と並んで重要なのが非機能要件です。受発注は事業の根幹であり、性能と可用性の要件を具体的な数値で定めなければなりません。ピーク受注時に何件の同時処理をさばけるべきか、夜間バッチを何時までに完了させる必要があるか、そして月次や日次の締め処理において、業務を止められる時間がどこまで許容されるのかを明確にします。受発注では締め処理のタイミングが事業のリズムと直結するため、締め処理中にどの程度のシステム停止が許されるのかという許容時間の定義は、特に丁寧に行うべき論点です。これらの非機能要件は、次のRFPでベンダーへ提示し、提案を比較する評価軸にもなります。

RFP作成とベンダー選定で刷新パートナーを見極める

アセスメントと要件定義で自社の内側を固めたら、上流工程の後半は、それを外部のパートナーへ手渡すフェーズに移ります。要件定義で整理した内容を発注先へ正確に伝える文書がRFP（提案依頼書）であり、RFPに対する各社の提案を比較して刷新パートナーを決めるのがベンダー選定です。RFPの作り込みが甘いと、各ベンダーが独自の前提で提案を組み立て、内容がばらばらになって横並びの比較ができなくなります。逆に、現状の制約と刷新後の目標を漏れなく伝えられれば、精度の高い見積りと提案を引き出せます。

受発注システムの刷新では、RFPに盛り込む情報と、提案を評価する観点の両方を、受発注業務の特性に合わせて設計することが求められます。本章では、RFPに必ず含めたい項目と、提案を見極めるための具体的な確認ポイントを整理します。

受発注システム刷新のRFPには、まずアセスメントで可視化した現行構成図を添付します。サーバー構成、利用しているソフトウェアやデータベース、取引先とのEDI接続状況、周辺システムとのインターフェース一覧といった現状を共有することで、ベンダーは刷新の難易度を正しく見積もれます。あわせて、要件定義で定めた性能要件と移行後KPIを明記し、「動くシステム」ではなく「成果を出すシステム」を前提に提案を求めます。さらに、ビッグバン方式か段階移行か、あるいはストラングラーのように既存を少しずつ置き換える漸進的な方式かといった移行方式の方針と、切り替え時に許容できるダウンタイムの見積りも示します。

これらに加えて、見落とされがちなのがスコープの境界線です。今回の刷新でどこまでを対象とし、どこからを対象外とするのか、その境界を明確にしておかないと、提案ごとに前提がずれて比較が成り立ちません。たとえば、周辺の在庫システムの改修まで含むのか、データ移行はどちらの責任範囲なのか、取引先へのEDI切り替え調整は誰が担うのか。こうした境界をRFPで言語化することで、各社の提案が同じ土俵に乗り、見積りの差が「本当の実力差」として浮かび上がります。スコープの境界を曖昧にしたRFPは、後の追加費用や責任範囲をめぐるトラブルの火種になります。

RFPへの提案が出そろったら、いよいよベンダー選定です。受発注システムの刷新は難易度が高く、価格の安さだけで選ぶと移行の途中で頓挫しかねません。提案を評価する際は、次の5つの確認ポイントを総合的に見ることをおすすめします。一つ目は、自社と同じ業界・同規模の刷新実績があるかどうかです。受発注は業界ごとに商習慣やEDIの仕組みが大きく異なるため、近い領域での経験を持つベンダーほど勘所を押さえた提案ができます。二つ目は、段階移行を設計できる力があるかです。一気に切り替えるリスクの大きい受発注システムでは、機能やデータを分割しながら安全に移していく設計力が問われます。

三つ目は、ダウンタイムの見積りが具体的かどうかです。切り替え時にどれだけシステムを止める必要があり、その間の業務をどう回すのかまで踏み込んだ提案は、移行の現実を理解している証拠になります。四つ目は、24時間365日の保守体制を備えているかです。受発注はトラブルが取引に直結するため、夜間や休日も含めて、障害発生からどれだけの時間で対応を開始してくれるのかを確認します。五つ目は、ISO9001（品質マネジメント）やISO27001（情報セキュリティマネジメント）といった第三者認証の有無です。受発注データには取引先の機密情報が含まれるため、組織として品質とセキュリティの管理体制を備えているかは欠かせない判断材料になります。この5点、すなわち同業界・同規模の実績、段階移行の設計力、ダウンタイム見積りの具体性、24時間365日の保守体制、品質・セキュリティ認証を総合して評価することで、刷新を任せられるパートナーを見極められます。

まとめ：上流工程の設計が受発注システム刷新を左右する

本記事では、受発注管理システムの刷新における上流工程を、「全体像の把握」「アセスメント」「要件定義」「RFP作成とベンダー選定」という流れに沿って解説しました。刷新は新規開発と異なり、現行システムという制約の上で進むため、アセスメントで現状を測ることが出発点になります。富士通の「ソフトウェア地図」のような手法でアプリ資産の複雑度・依存関係を可視化し、取引先連携や移行対象データを特定したうえで、要件定義へとつなぎます。要件定義ではTO-BE要件と刷新後KPIを数値で掲げ、EDI・基幹連携や締め処理の許容時間といった非機能要件を固めます。そしてRFPには現行構成図・性能要件・移行後KPI・移行方式・ダウンタイム見積り・スコープの境界を盛り込み、5つの確認ポイントでベンダーを評価します。

これらの上流工程を一本の線として一貫させることが、刷新成功の条件です。経済産業省が「2025年の崖」で最大年間12兆円規模の損失リスクを示し、その主因を要件定義の不十分さやシステムのブラックボックス化に求めているとおり、上流工程の甘さこそが刷新失敗の最大の要因です。要件定義のみでも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を創業。