在庫管理システムの刷新は、現状分析（アセスメント）、要件定義、RFP作成の順に進めます。この順で進めると、要件の抜け漏れによる手戻りを防ぎやすくなります。
各工程の全体像は、在庫管理システム刷新の完全ガイドで先に確認できます。
▼全体ガイドの記事
・在庫管理システム刷新の完全ガイド
レガシーシステム刷新の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
アセスメント：在庫業務とシステムの現状分析
刷新の最初の工程は、現状（AS-IS）を把握するアセスメントです。仕様書の欠如や引当ロジックのブラックボックス化は、要件定義の不足につながります。
要件定義の不足は、刷新失敗の原因として繰り返し指摘されています。そのため、事前に資産を棚卸しして現状を分析しておくことが、後工程の手戻りを防ぐうえで有効です。
在庫業務の棚卸しと課題の可視化
業務面では、担当者や使うシステム、帳票まで含めて在庫業務を書き出すことが出発点になります。
- 業務の流れ：入荷から返品・棚卸までの処理を順に追う
- 裏作業：Excelや手作業で補う業務を洗い出す
- 定量データ：在庫差異、棚卸工数、欠品や過剰在庫の頻度を集める
処理ごとに誰が、いつ、どの手段で動かしているかまで追うと、担当者の判断に頼っている場所が見えてきます。システムで管理できていない裏作業も、現場の工夫で不足を補っていることがあります。そのため、刷新で解決すべき課題を見極めるには、現場へのヒアリングと実地観察に時間を割きます。
収集した定量データは、刷新の効果目標（KPI）の基準値になります。さらに、稟議で投資対効果を説明する材料や、必須要件と見送る要件を分ける判断材料としても使えます。
現行システムの資産棚卸しと依存関係の整理
システム面では、現行システムがどのように作られ、どこへつながっているかを調べます。資産棚卸しでは、調べた内容を図や仕様書にまとめる作業も伴います。
- 仕様とデータ：項目や引当ロジック、データベース構造を確認する
- 連携関係：他システムへ流れる在庫データと利用項目を追う
- 成果物：現行構成図、データ連携図、引当ロジックの仕様書をまとめる
仕様書が失われている場合は、データベース構造やプログラムを解析して仕様を復元します。富士通が提供する「ソフトウェア地図」のようなツールは、アプリケーション資産の複雑さや依存関係を見える形にします。こうしたツールを使えば、ブラックボックス化したシステムの全体像を効率的に把握できます。
在庫データは、受発注や販売、会計へ流れるほか、WMS（倉庫管理システム）にも渡されます。連携先と利用項目を明らかにしておかないと、刷新の際に連携が壊れ、在庫差異や出荷停止を招くおそれがあります。構成図、連携図、引当ロジックの仕様書がそろっていれば、次の要件定義やRFPの作業も進めやすくなります。
要件定義：在庫管理システム刷新で固めるべき要件
現状を把握したら、目指す姿（TO-BE）を要件として書き出します。在庫管理では、機能、非機能、データ移行の要件を過不足なく整理することが欠かせません。
要件が曖昧なままだと、ベンダーの見積もりがぶれ、後工程で手戻りが生じます。そのため、要件はできる限り具体的に文書にしておきます。
機能要件と非機能要件の整理
在庫管理では、自社固有の引当ルールや繁忙期の稼働条件が、選定と費用を左右します。そのため、機能と運用の両面から要件を整理します。
- 機能要件：必須（Must）と望ましい機能（Want）に分け、自社固有の在庫ルールを定める
- 非機能要件：性能や稼働に関する条件を数値で示す
機能には、入出荷、在庫照会、引当があります。さらに、棚卸、ロケーション管理、受発注連携も含みます。引当ルールに加えて、ロットや賞味期限、シリアル番号の管理要否も明記しておきます。
パッケージ製品を採用する場合は、標準機能で満たせる要件と、追加開発（アドオン）が必要な要件を分けておきます。この区分が、費用見積もりの精度を左右します。
非機能要件は見落とされがちですが、在庫管理では特に大切です。在庫照会の応答速度やピーク時の同時アクセス数、夜間バッチの処理時間を含めます。出荷を止められない時間帯や過去データの保持期間も、数値で定義しておきます。
たとえば、在庫を24時間365日止められないEC事業者や、繁忙期に出荷が集中する小売業では、可用性とピーク性能が選定やコストを左右します。
データ移行要件と在庫マスターの整備
データ移行に失敗すると、在庫差異につながります。そのため、移行要件では対象と手順を先に決めておきます。
- 商品マスター、在庫数量、ロケーション、取引先、引当中データなどを移行対象に定める
- 旧システムと新システムの項目を、データマッピングで対応づける
- 移行時点の在庫数をどう確定し、移行後にどう検証するかを決める
データマッピングは、ERP導入でも難所として知られる作業です。だからこそ、要件定義の段階で移行対象の範囲を決め、在庫差異を防ぐ準備を整えます。
長年運用したシステムには、廃番商品や重複コード、単位の不統一が残っていることがあります。こうしたマスターを整理しないまま移すと、刷新後も在庫精度は上がりません。そこで、マスタークレンジング（データの整理・統一）を移行要件に含めておくと、刷新の効果を得やすくなります。
RFP作成：盛り込むべき項目とベンダーへの伝え方
要件が固まったら、ベンダーに提案を依頼するためのRFP（提案依頼書）を作成します。RFPの内容によって、提案と見積もりの精度が大きく変わるため、盛り込む項目と意図を正確に伝える方法を押さえておきます。
RFPに盛り込むべき必須項目
RFPには、ベンダーが提案を組み立てるのに必要な情報を最低限そろえます。
- 背景と現状：刷新の目的、構成図、データ連携図、業務フロー
- 規模と要件：取扱SKU数・拠点数・1日の入出荷件数、機能・非機能要件
- 移行と目標：データ移行の対象・方針、在庫精度・棚卸工数・欠品率などのKPI
提案の項目として、推奨する刷新手法と構成、概算費用と期間を指定します。さらに、段階移行の進め方、データ移行の方法、保守体制についても回答を求めます。
繁忙期や出荷ピークへの対応も、RFPの中で確認しておきます。在庫業務を止めないカットオーバー計画を問うと、ベンダーの実力を見極める手がかりになります。
評価基準を明示し、項目を網羅しておくと、各社の提案を同じ条件で比べられます。そのため、ベンダー選定の精度も高まります。
ベンダー評価の5つのチェックポイント
集まった提案を客観的に評価するには、明確なチェックポイントが必要です。評価の観点は5点です。
- 同業実績：同業界・同規模の事例から、固有の引当や物流要件への理解を測る
- 段階移行設計力：業務を止めずに切り替える計画を描けるかを確認する
- ダウンタイム見積り：在庫を止められない時間帯への配慮も見る
- 保守体制：出荷ピークやトラブル時の対応力を見る
- 品質/セキュリティ認証：ISO9001・ISO27001で信頼性を確かめる
必要に応じて、24時間365日の対応力も確かめます。
認証は、開発プロセスとデータ保護の信頼性を判断する材料になります。そのうえで、評価シートで点数化し、価格だけでなく総合的に選びます。
評価の観点をRFPの段階で開示しておくと、提案の焦点が定まり、比較もしやすくなります。
要件定義・RFP段階で固めるスケジュールと推進体制
アセスメントや要件、RFPの内容に加えて、スケジュールと推進体制も刷新の成否を左右します。要件定義の段階でこれらを固めておくと、選定後の開発を立ち上げやすくなります。
アセスメントから要件定義にかける期間と費用の目安
現状分析からRFP完成までの期間と費用は、棚卸しの対象範囲や在庫業務の季節差を踏まえて計画します。
- 期間：現状分析から要件定義書・RFP完成まで、おおむね2〜4ヶ月
- 費用：要件定義・業務棚卸しの工程で200万〜500万円
在庫業務は繁忙期と閑散期で実態が異なるため、可能なら両方を観察できる余裕を持たせます。
現状分析を急ぐと、開発の途中で要件の抜け漏れが見つかり、工期とコストが膨らむおそれがあります。一方で、丁寧な棚卸しはベンダーへの説明を助け、提案の精度を高めます。
要件定義は、刷新全体の投資対効果を高める出発点になります。だからこそ、アセスメントと要件定義に十分な期間を確保し、手戻りを防ぐことが大切です。
現場を巻き込む推進体制とPMOの活用
要件定義では、情報システム部門だけでなく、在庫業務の現場部門も巻き込みます。開発の土台として、体制を整えるときは早い段階で担当を決め、それぞれの役割を明確にしておきます。
- 現場部門：倉庫・物流・購買・販売から代表者を参加させる
- 社内推進者：定例で論点を確認し、各部門の役割を定める
- 外部支援：必要に応じ中立的なPMOやコンサルタントを活用する
在庫の流れや裏作業を知る現場が加わらなければ、正確な要件は固まりません。現場の知識を要件に反映させることで、想定した業務とのずれを防げます。
社内に要件定義やRFP作成、ベンダー選定を担える人材が不足する場合は、第三者の支援が有効です。PMOとは、プロジェクト管理を外から支える支援のことです。
第三者が加わると、現状分析の網羅性や評価基準の客観性が高まります。さらに、ベンダーとの交渉でも、対等な立場で向き合う助けになります。そのため、第三者を入れる時期は早い段階で決めておきます。
まとめ
刷新は、アセスメント、要件定義、RFP作成の順に進めます。いずれも現状を把握するところから始まり、事業に直結する刷新を支える工程です。
アセスメントでは、在庫業務を棚卸しして、システム資産と依存関係を見える形にします。要件定義では、機能・非機能・移行の要件を整え、在庫マスターも整備します。
RFPでは必須項目を示したうえで、ベンダーを5つの観点で評価します。評価の観点は、同業実績、段階移行の設計力、ダウンタイム見積り、保守体制、品質/セキュリティ認証です。
要件定義・RFP段階のスケジュールと推進体制は、早い段階で固めておきます。要件定義と業務棚卸しの工程では、200万〜500万円、2〜4ヶ月程度を見込みます。
倉庫・物流・購買・販売などの現場を巻き込み、必要に応じて中立的なPMOやコンサルタントの力も借ります。
現行の引当ロジックやデータ連携は、ブラックボックス化していることがあります。そのため、アセスメントと要件定義の精度が、刷新全体の成否を左右します。
要件が曖昧なまま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を創業。