在庫管理システムの刷新は、現状把握、要件定義、RFP作成、ベンダー選定の順に進めます。この順で進めると、移行後の在庫の不整合を防ぎやすくなります。
各段階で得た情報を、次の段階の材料として引き継ぐことが大切です。全体像は在庫管理システムのモダナイゼーションの完全ガイドもご覧ください。
▼全体ガイドの記事
・在庫管理システムのモダナイゼーションの完全ガイド
レガシーシステム刷新の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
アセスメント：現状（AS-IS）の可視化と在庫システムの棚卸し
要件定義やRFPに入る前に、現行の在庫管理システムの状態（AS-IS）を洗い出します。現行のロジックや連携先、データ量がわからないままでは、新システムの要件を決められません。
アセスメントを省くと、要件の抜けが移行後に表面化し、在庫精度の悪化や業務停止を招きます。そのため、棚卸しの対象を先に明らかにしておきます。
ブラックボックス化した受払・引当ロジックの棚卸し
長く使ってきた在庫管理システムでは、担当者の交代や個別の改修が重なり、受払や引当のロジックがブラックボックス化することがあります。仕様の意図が文書に残らないまま運用だけが続くケースもあります。こうした状態のまま移行すると、従来の挙動が再現されず、現場が混乱します。
棚卸しでは、現場へのヒアリングと実データの突き合わせを行います。仕様書と実際の挙動のずれを確かめ、暗黙知（担当者の経験で覚えている決まり）を文書に書き起こします。
受払・引当ロジックについては、次のルールを実際の伝票の流れに沿って確かめます。
- 払出ルール：先入先出（FIFO）や後入先出
- 引当順序：ロット・賞味期限・ロケーションの考慮
- 欠品時の扱い：引当保留や入荷待ちの処理
近年は、システムの構造を機械的に分析して、現状を見える形にする支援も使われています。たとえば富士通は、ソースコードを解析して、プログラム間の依存関係や複雑度を地図のように示す「ソフトウェア地図」を提供しています（出典：富士通）。在庫システムでも、処理がどこに分散しているか、どこが強く結びついているかが分かれば、刷新の範囲とリスクを見極めやすくなります。
連携I/Fとデータ量の把握
在庫管理システムは、周辺のシステムと連携することで在庫数を保っています。そのため、連携先、インターフェース（I/F）、データのやり取りのタイミングを漏れなく調べます。
連携先には、基幹システム（ERP）やECサイト、受発注システムがあります。物流現場では、倉庫制御システム（WCS）やハンディ端末も連携先になります。把握に漏れがあると、移行後の在庫不整合につながります。
後工程の要件定義やRFPで使えるよう、連携情報を次の観点で一覧にします。
- 連携先と方向：対象システムと受信・送信
- 連携方式：リアルタイムAPI、バッチ、ファイルなど
- 頻度とタイミング：即時、1時間ごと、夜間バッチなど
- データの種類：入出庫実績、在庫数、受注引当、マスタなど
この一覧を表にまとめれば、新システムに必要な連携要件をベンダーに示せます。
データ量も数値で把握します。まず、品目（SKU）数とロケーション数の規模を押さえます。加えて、1日あたりの入出庫トランザクション量と、ピーク時の同時アクセス数も確認します。
受払履歴の蓄積年数と件数も調べます。これらは性能要件とデータ移行要件の根拠になり、曖昧なままでは稼働後の在庫照会の遅れを招きます。
アセスメントには相応の工数がかかり、要件定義や業務棚卸しだけでも、一般に200万〜500万円程度が費用の目安です。
現状把握を軽く見ると、後工程の手戻りがこの金額を上回ることがあります。そのため、アセスメントは刷新全体のリスクを下げる先行投資です。
要件定義：在庫管理モダナイゼーションで定義すべき要件
現状を洗い出したら、機能要件と非機能要件に分けて、新システムの条件を定めます。要件の粒度が粗いと、ベンダーの解釈に委ねる範囲が広がり、見積もりのばらつきや認識のずれにつながります。特に、在庫業務の要件を現場の運用に沿って言葉にできるかが、モダナイゼーションの成否を左右します。
在庫業務に固有の機能要件
機能要件では、実現したい業務処理を具体的に書き出します。入荷から保管まで、ピッキングから出庫までの工程ごとに、必要な機能を洗い出します。在庫業務では、次の論点を定めます。
- ロケーション体系：固定・フリー・ゾーニングの設計方針
- 商品情報：ロット・賞味期限・シリアル番号の管理粒度と追跡要件
- 現場入力：ハンディ端末やRFIDの運用方式
- 棚卸：一斉棚卸・循環棚卸の方式と、現物との差異調整フロー
これらは在庫精度に直接響くため、現場の運用実態に合わせて定めます。
また、引当方式は、FIFO、ロット引当、ロケーション優先などを踏まえて、現行仕様を踏襲するか見直すかを決めます。引当、確保、解放のタイミングも明確にします。
アセスメントで棚卸しした現行ロジックを、あるべき姿（TO-BE）としてどう定めるかが要点です。要件が実態に合わないと、在庫精度が落ち、現場で使われなくなるおそれがあります。
ロケーション体系の再設計は、モダナイゼーションを機に取り組む価値の大きいテーマです。見直さずに移行すると、場当たり的に増えた保管場所や非効率な運用がそのまま残ります。そこで、ピッキング動線と保管効率を考えた再設計の方針を、要件に盛り込みます。
ハンディ端末やRFIDの使い方は、現場の入力の負担と在庫精度のバランスを見て決めます。
性能・移行を含む非機能要件
機能要件と並んで、性能、可用性、移行も欠かせません。在庫管理システムは倉庫の基盤なので、性能が足りないと、現場の作業が止まります。
アセスメントで把握したデータ量を根拠に、性能要件を具体的な数値で定めます。移行要件も非機能要件の一部です。
- 性能指標：照会の応答秒数、夜間バッチ・締め処理の完了時刻、同時ユーザー数・処理数
- 応答条件：セール期ピークに端末100台が同時照会しても、1件2秒以内
- 可用性：稼働率、バックアップ・リカバリ、障害時の在庫データ整合性
- 移行データ：受払履歴の期間、ロケーション・ロット情報、現物と帳簿の差異調整
- 移行時間：セール・決算を避け、倉庫の制約に沿って停止時間の上限を定める
移行後に測る成功KPIの定義
稼働後に刷新の成否を測るKPIを、事前に定めておきます。効果を客観的に判断し、投資の妥当性を説明するためです。
- 指標：在庫精度（帳簿と現物の一致率）、欠品率、棚卸工数、在庫回転率
- 基準値：移行前のベースラインを把握する
- 目標値：在庫精度を現状95%から99%以上へ、現状の月40人日の棚卸工数を半減
- 活用：要件とベンダー依頼に含め、稼働後の効果測定や提案評価に使う
何をもって成功とするかを関係者で合意し、プロジェクトの判断の基準を定めます。
RFPに盛り込むべき項目と書き方
アセスメントと要件定義で得た内容を、発注文書のRFP（提案依頼書）にまとめます。RFPの品質が、ベンダーから得られる提案と見積もりの質を左右します。
記載が曖昧だと各社の前提がずれ、提案がばらついて比べられません。そのため、在庫管理の刷新でRFPに記載する項目と書き方を押さえておきます。
現行システム構成とデータ量の提示
アセスメントで整理した現行の構成とデータ量は、RFPで提案の前提として示します。ベンダーには次の情報を開示します。
- システム構成：サーバー、ミドルウェア、連携先を含む構成図
- 在庫データ量：SKU数、ロケーション数、受払履歴の蓄積件数
- 処理量：1日あたりとピーク時のトランザクション量
- 現行の制約：深夜2時間のバッチ中は照会不可、特定倉庫は別システムで管理
ベンダーは、この構成とデータ量をもとに、移行の規模や必要なリソースを見積もります。制約を伏せたままだと、移行時に想定外の障壁が見つかり、追加費用やスケジュールの遅れにつながります。そのため、現状を正確に示します。
性能要件と移行・連携要件の記載
要件定義で固めた非機能要件は、RFPでも測れる形で明記します。特に、移行と連携の要件は丁寧に記載します。
- 性能：照会の応答秒数、バッチ・締めの完了時刻、同時実行数を数値化
- 実現方法：提案書で説明を求め、性能保証や方式を比べることで障害を防ぐ
- 移行範囲：受払履歴の年数・アーカイブ、ロケーション・ロット情報
- 移行条件：在庫差異の調整、許容停止時間、繁忙期を避ける時期
- 連携：I/F一覧を添付し、各連携の維持・刷新、方式・頻度、全体図を示す
移行計画とダウンタイムの見積もりも、提案に含めてもらいます。
連携先には、基幹システム、ECサイト、受発注システムがあります。さらに、倉庫制御システム（WCS）とハンディ端末も含まれます。
連携の記載に漏れがあると、移行後の在庫不整合につながります。そこで、全体を一枚の図にまとめると、ベンダーの理解と提案の精度が高まります。
移行後KPIと評価条件の明示
RFPでは、移行後に実現したいことと、提案を評価する条件を明らかにします。
- 移行後KPI：在庫精度、欠品率、棚卸工数などの目標値
- 達成提案：目標に貢献する機能・仕組みをベンダーに示してもらう
- 提出内容：概算費用、体制図、移行計画、保守内容とスケジュール
- 評価条件：回答形式と評価観点・配点を示し、提案と評価を効率化する
KPIを共有すれば、発注側とベンダーで成功の定義がそろい、稼働後の評価のずれを防げます。また、同じ形式で回答を得ると、提案を横並びで比べやすくなります。
RFPは、要望を書き出した文書であると同時に、公平な比較と適切な選定を成り立たせるための設計図です。
失敗しないベンダー選定の評価観点
提案が出そろったら、発注先を選びます。倉庫を止められない刷新では、価格だけで選ぶと、移行の段階で深刻なトラブルに直面します。
提案を比べるときは、まず実績と移行設計を見ます。そのうえで、ダウンタイム、保守、認証を確かめます。
実績と移行設計力を見る3つの観点
同じ業界・規模での在庫システムの構築や刷新の実績を確かめます。物流、小売、製造では在庫管理の勘所が異なります。業界特有の要件や落とし穴を理解していると、提案の精度も高まります。
提案書に書かれた実績について、どの課題をどう解決したかを聞きます。どこまで具体的に語れるかは、経験の判断材料になります。自社の状況に応用できるかは、その答えで見極められます。
次に重視するのは、段階移行の設計力です。提案では、次の内容を評価します。
- 業界・規模の実績：自社に近い在庫システムの構築・刷新経験
- 移行の順序：倉庫や機能をどう区切って切り替えるか
- 並行稼働：新旧システム間の在庫データ整合の保ち方
- 切り戻し：問題発生時のロールバック手順
- 停止時間：根拠のあるダウンタイム見積もり
一括で移行するより、倉庫や機能を分けて段階的に移すほうが、リスクを抑えられる場合が多くあります。そこで、具体的な計画を示せるかを確認します。
加えて、ダウンタイム見積もりの精度を確かめます。停止時間と、それを小さくする方法が示されているかを見ます。「最小限」とだけ書かれた提案より、根拠のある見積もりのほうが大切です。
例えば、移行作業を土曜深夜0時から6時間とし、そのうち2時間は在庫照会を止める、といった見積もりがあります。ここまで具体的に示せる提案は、ベンダーの移行経験を見極める材料になります。
保守体制と品質・セキュリティ認証の確認
在庫管理システムは倉庫を支える基盤です。そのため、稼働後を見据えて、保守体制と品質・セキュリティ体制も確かめます。
- 保守：24時間365日の支援、障害時の連絡フロー、復旧目標（SLA）
- 品質認証：ISO9001（品質マネジメント）の取得状況
- セキュリティ認証：ISO/IEC27001（情報セキュリティ）の取得状況
稼働後の運用で、在庫システムの真価が問われます。夜間や休日も業務を止められないため、保守体制は、長く使ううえでの安心に関わります。
認証の有無は、ベンダーの信頼性を測る客観的な指標の一つです。在庫データには、取引先や商品の機微な情報が含まれることもあるため、情報セキュリティの体制を確認しておく必要があります。
実績から認証までの観点を評価シートにまとめ、各社を同じ基準で採点します。こうすると、価格に流されない選定につながります。
まとめ
在庫管理システムの刷新は、アセスメントで現状を把握し、要件定義とRFPで具体化してから、ベンダーを選びます。発注前に情報を整理しておくと、移行後の不整合や性能トラブルを防ぎやすくなります。
アセスメントでは、受払・引当ロジック、連携I/F、データ量を調べます。要件定義では、機能・非機能要件とKPIを定めます。RFPには、現行構成と性能、移行・連携要件を測定可能な形で記載し、KPIも添えます。
ベンダー選定では、実績と段階移行の設計、ダウンタイム、保守と認証を評価します。費用だけでなく、倉庫を止められない制約に対応できるかも確認します。
要件定義や業務棚卸しだけでも、200万〜500万円程度が費用の目安です。前工程に十分な時間と費用をかけておくことが、移行後の損失を防ぐ投資になります。
現状把握とRFPの精度が、倉庫を止められない刷新を成功させる前提です。不安があれば、要件定義や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を創業。