在庫管理システムのモダナイゼーションのアセスメント/要件定義/RFPについて

長年使い続けてきた在庫管理システムを刷新（モダナイゼーション）する際、プロジェクトの成否を最初に大きく左右するのが、アセスメント（現状分析）と要件定義、そしてRFP（提案依頼書）の精度です。「古くなった在庫システムを新しくしたい」という漠然とした依頼のままベンダーへ声をかけると、各社が想定するスコープがばらつき、見積もりの比較そのものが成り立たなくなります。とくに在庫管理システムは、受払や引当のロジックが長年の運用のなかでブラックボックス化しているケースが多く、現状を正しく可視化できていないまま発注すると、移行後に「在庫数が合わない」「想定した照会レスポンスが出ない」といった深刻なトラブルに直結します。

本記事では、在庫管理システムのモダナイゼーションを発注する前段として、アセスメントによる現状（AS-IS）の可視化から、要件定義で固めるべき機能・非機能要件、RFPに盛り込むべき項目とその書き方、そして失敗しないベンダー選定の評価観点までを、倉庫管理（WMS）や在庫業務に固有の論点に寄せて解説します。刷新プロジェクト全体の進め方や手法の全体像を先に把握しておきたい方は、あわせて在庫管理システムのモダナイゼーションの完全ガイドもご覧ください。本記事は、その完全ガイドの内容を発注実務に落とし込み、アセスメントとRFPに具体的に何をどう書くべきかを掘り下げる内容です。

▼全体ガイドの記事
・在庫管理システムのモダナイゼーションの完全ガイド

アセスメント：現状（AS-IS）の可視化と在庫システムの棚卸し

要件定義やRFP作成に着手する前に、まず取り組むべきなのがアセスメント、すなわち現状（AS-IS）の徹底的な可視化です。現行の在庫管理システムがどのようなロジックで動き、どこと連携し、どれだけのデータを抱えているのかを把握しないまま新システムの要件を語ることはできません。アセスメントを省略すると、要件の抜け漏れが移行後に表面化し、在庫精度の悪化や業務停止といった致命的な問題を招きます。ここでは、在庫システムのアセスメントで何をどこまで棚卸しすべきかを整理します。

長く運用されてきた在庫管理システムでは、入出庫に伴う受払ロジックや、受注に対して在庫を割り当てる引当ロジックが、当時の担当者や個別の改修の積み重ねによってブラックボックス化していることが少なくありません。「なぜこの順序で引き当てるのか」「なぜこの条件のときだけ在庫を減らさないのか」といった仕様の意図が、ドキュメントに残っていないまま運用だけが続いているケースが典型です。この状態のまま新システムへ移行すると、業務で当たり前に成立していた挙動が再現されず、現場が混乱します。

アセスメントでは、まずこれらのロジックを業務単位で棚卸しし、暗黙知になっている仕様を明文化することが出発点になります。具体的には、先入先出（FIFO）や後入先出といった払出ルール、ロット・賞味期限・ロケーションを考慮した引当順序、欠品時の引当保留や入荷待ちの扱いなどを、実際の伝票の流れに沿って洗い出します。現場へのヒアリングと実データの突合を併用し、仕様書と現実の挙動のズレを潰していく作業が欠かせません。

こうした可視化の精度を高める手段として、近年はシステムの構造を機械的に分析する支援も活用されています。たとえば富士通は、既存システムのソースコードを解析してプログラム間の依存関係や複雑度を地図のように描き出す「ソフトウェア地図」を提供しており、どの部分が密結合で改修リスクが高いかを俯瞰できます（出典：富士通）。在庫システムにおいても、受払・引当の処理がどのモジュールに分散し、どこと密に絡み合っているのかを可視化できれば、刷新時に切り出すべき範囲とリスクの所在を見極めやすくなります。

在庫管理システムは単独で動いているわけではなく、多くの周辺システムと連携して在庫の数字を保っています。アセスメントでは、現行システムがどこと、どのようなインターフェース（I/F）で、どのタイミングでデータをやり取りしているのかを網羅的に棚卸しする必要があります。基幹システム（ERP）、ECサイト、受発注システム、物流現場の倉庫制御システム（WCS）、ハンディ端末など、在庫の更新に関わる連携は想像以上に多岐にわたります。これらの連携I/Fを把握し損ねると、移行後に在庫数の不整合が連鎖的に発生します。

連携の棚卸しでは、次のような観点を一覧化しておくと、後工程の要件定義とRFPに直結します。
・連携先システムと連携方向（受信・送信）
・連携方式（リアルタイムAPI連携、バッチ連携、ファイル連携など）
・連携の頻度とタイミング（即時、1時間ごと、夜間バッチなど）
・連携データの種類（入出庫実績、在庫数、受注引当、マスタなど）
これらを表として整理しておくことで、新システムが満たすべき連携要件を漏れなくベンダーへ提示できます。

あわせて、現行システムが扱っているデータ量の把握も欠かせません。在庫の品目（SKU）数、ロケーション数、1日あたりの入出庫トランザクション量、ピーク時の同時アクセス数、そして受払履歴が何年分・何件蓄積されているのかを定量的に押さえます。これらの数値は、新システムに求める性能要件やデータ移行要件の根拠となる重要な前提です。データ量を曖昧にしたまま発注すると、ベンダーは性能を保証できず、稼働後に在庫照会が遅延するといった事態を招きます。

なお、このアセスメントには相応の工数がかかります。一般に、要件定義や業務の棚卸しのみでも200万〜500万円程度の費用がかかるのが目安とされます。アセスメントを軽視して短絡的に進めると、後工程での手戻りがこの金額をはるかに上回るため、現状可視化への投資は刷新全体のリスクを下げる先行投資として位置づけるべきです。

要件定義：在庫管理モダナイゼーションで定義すべき要件

アセスメントで現状を可視化したら、次は要件定義のフェーズです。要件定義では、新しい在庫管理システムが満たすべき条件を、機能要件と非機能要件に分けて具体的に定義していきます。ここで定義の粒度が粗いと、ベンダーの解釈に委ねられる部分が増え、見積もりのばらつきや認識齟齬の原因になります。在庫業務に固有の要件を、現場の運用に即して言語化することが、モダナイゼーション成功の核心です。

機能要件では、在庫管理として実現したい業務処理を具体的に定義します。入荷検品、入庫、保管、ピッキング、出荷検品、出庫といった倉庫業務の一連の流れに沿って、それぞれの工程で必要な機能を洗い出します。とくに在庫の引当方式（FIFO、ロット引当、ロケーション優先など）や、在庫の引当・確保・解放のタイミングは、現行業務の仕様をそのまま踏襲するのか、この機会に見直すのかを明確に決める必要があります。アセスメントで棚卸ししたロジックを、TO-BE（あるべき姿）としてどう定義するかが要件定義の山場です。

在庫管理ならではの機能要件として、次のような論点を漏れなく定義しておくことが重要です。
・ロケーション体系（固定ロケーション、フリーロケーション、ゾーニング）の設計方針
・ロット・賞味期限・シリアル番号の管理粒度とトレーサビリティ要件
・ハンディ端末やRFIDによる現場入力の運用方式
・棚卸（一斉棚卸・循環棚卸）の方式と、現物との差異調整のフロー
これらは在庫精度を直接左右するため、現場の運用実態に即して定義しないと、新システムが現場で使われなくなるリスクがあります。

とくにロケーション体系の再設計は、モダナイゼーションを機に取り組む価値の大きいテーマです。長年の運用で場当たり的に増えたロケーションをそのまま移行すると、新システムでも非効率な保管が温存されます。要件定義の段階で、現状のロケーション運用を見直し、ピッキング動線や保管効率を考慮した体系へ再設計する方針を盛り込んでおくと、刷新の効果を最大化できます。あわせて、ハンディ端末やRFIDをどう活用するかも、現場の入力負荷と在庫精度のバランスを見ながら定義します。

機能要件と並んで重要なのが、性能や可用性、移行に関する非機能要件です。在庫管理システムは倉庫の稼働を支える基盤であり、性能が不足すると現場の作業が止まります。アセスメントで把握したデータ量を根拠に、具体的な数値で性能要件を定義します。たとえば、在庫照会のレスポンスタイム（何秒以内に在庫数を返すか）、夜間の棚卸バッチや締め処理の完了時間（何時までに終わらせる必要があるか）、ピーク時の同時実行ユーザー数や同時トランザクション数といった指標です。

これらの非機能要件は、数値の根拠を示して定義することが肝心です。「在庫照会は速く」では要件になりません。「セール期のピーク時に、ハンディ端末100台が同時に在庫照会を行っても、1件あたり2秒以内に応答すること」というように、業務シーンと具体的な数値をセットで定義します。倉庫は止められないという前提に立てば、可用性（稼働率）やバックアップ・リカバリの要件、障害時の在庫データの整合性確保の方針も、非機能要件として明確に盛り込んでおくべきです。

移行に関する要件も、非機能要件の重要な一部です。在庫データの移行は、単にデータをコピーするだけでは済みません。受払履歴をどこまで遡って移行するのか、ロケーションやロット情報の移行範囲をどう定めるのか、移行時点での現物在庫と帳簿在庫の差異をどう調整するのかを、要件として明確にします。さらに、繁忙期（セールや決算）を避けた移行ウィンドウの設計や、許容できるダウンタイムの上限も、倉庫を止められない制約のなかで現実的に定義する必要があります。

要件定義では、新システムが稼働した後に「刷新が成功したかどうか」を測る指標、すなわちKPIを事前に定義しておくことが重要です。KPIを決めずに進めると、稼働後に効果を客観的に判断できず、投資の妥当性を説明できなくなります。在庫管理のモダナイゼーションでは、在庫精度（帳簿と現物の一致率）、欠品率、棚卸にかかる工数、在庫回転率といった指標が代表的なKPIになります。これらを移行前のベースラインとともに定義します。

KPIは、現状値と目標値をセットで定めるのが鉄則です。たとえば「在庫精度を現状の95%から99%以上へ」「棚卸工数を現状の月40人日から半減へ」というように、改善の方向性と達成基準を数値で示します。こうしたKPIを要件定義に組み込んでおくと、ベンダーへの依頼内容が明確になるだけでなく、稼働後の効果測定や、ベンダーの提案を評価する際の判断軸にもなります。何をもって成功とするかを、関係者の合意のもとで言語化しておくことが、プロジェクトの軸を定めます。

RFPに盛り込むべき項目と書き方

アセスメントと要件定義の成果を、ベンダーに発注するための文書としてまとめたものがRFP（提案依頼書）です。RFPの品質が、各社から引き出せる提案と見積もりの質を決めます。記載が曖昧だと、ベンダーは前提を補って提案するため、各社の提案がばらつき、横並びの比較ができなくなります。ここでは、在庫管理システムのモダナイゼーションのRFPに、どのような項目をどう書くべきかを整理します。

RFPの土台となるのが、現行システムの構成とデータ量の開示です。アセスメントで整理した内容を、ベンダーが提案の前提として読み解ける形で提示します。具体的には、現行システムの構成図（サーバ構成、ミドルウェア、連携先を含む全体像）、扱っている在庫データ量（SKU数、ロケーション数、受払履歴の蓄積件数）、そして1日あたりおよびピーク時のトランザクション量を記載します。これらを示すことで、ベンダーは移行規模と必要なリソースを正確に見積もれます。

現行構成の提示で見落とされがちなのが、現行システムの制約や課題の明記です。「現行は深夜2時間のバッチで在庫を確定しており、この時間帯は照会できない」「特定の倉庫だけ別システムで管理している」といった、現状の制約や例外を正直に開示することが、現実的な提案を引き出す鍵になります。良く見せようとして制約を伏せると、移行段階で想定外の障壁が露見し、追加費用やスケジュール遅延の原因になります。

要件定義で固めた非機能要件は、RFPでも測定可能な形で明記します。性能要件としては、在庫照会のレスポンス目標、棚卸バッチや締め処理の完了時間、ピーク時の同時実行性能を、具体的な数値とともに記載します。ベンダーには、これらの性能をどう実現するのかを提案書で説明してもらうよう求めます。数値で要件を示すことで、性能保証の有無や実現方式を各社で比較でき、稼働後の性能トラブルを未然に防げます。

移行要件と連携要件は、在庫管理のRFPでとくに丁寧に記載すべき項目です。移行要件としては、データ移行の対象範囲を明示します。
・受払履歴の移行範囲（何年分を移行するか、アーカイブ扱いとするか）
・ロケーション情報・ロット情報の移行方針
・移行時の現物在庫と帳簿在庫の差異調整の進め方
・許容ダウンタイムと、繁忙期を避けた移行ウィンドウの制約
これらを条件として提示し、ベンダーには移行計画とダウンタイムの見積もりを提案に含めるよう求めます。

連携要件では、アセスメントで棚卸しした連携I/Fの一覧をRFPに添付し、新システムが各連携を維持・刷新できることを提案の前提として示します。基幹システム、ECサイト、受発注システム、物流現場の倉庫制御システム（WCS）、ハンディ端末との連携について、連携方式と頻度を明記します。在庫の数字は複数システムが連携して保たれているため、連携要件の記載漏れは移行後の在庫不整合に直結します。連携の全体像を一枚の図にまとめて提示すると、ベンダーの理解と提案の精度が高まります。

RFPには、要件定義で定めた移行後のKPIも明記します。在庫精度、欠品率、棚卸工数といった目標値を示すことで、ベンダーは何を実現すべきかを正確に理解でき、その達成に向けた提案を組み立てられます。KPIをRFPに盛り込むことは、発注側とベンダーの間で「成功の定義」を共有する効果があり、稼働後の評価をめぐる認識のずれを防ぎます。目標KPIに対して、ベンダーがどのような機能や仕組みで貢献できるかを提案に含めてもらうとよいでしょう。

あわせて、RFPには提案の評価条件やスケジュール、提出してほしい項目（概算費用、体制図、移行計画、保守内容など）も明記しておきます。各社に同じフォーマットで回答してもらうことで、提案を横並びで比較しやすくなります。評価の観点や配点を事前に示しておくと、ベンダーは重視すべきポイントを押さえた提案を行いやすくなり、発注側も評価作業を効率化できます。RFPは単なる要望リストではなく、公平な比較と適切な選定を成立させるための設計図だと捉えることが大切です。

失敗しないベンダー選定の評価観点

RFPに対してベンダーから提案を受け取ったら、いよいよ発注先を選定する段階です。在庫管理システムのモダナイゼーションは、倉庫を止められないという厳しい制約のなかで行うため、価格だけでベンダーを選ぶと、移行段階で深刻なトラブルに直面します。ここでは、提案を比較・評価する際に押さえるべき観点を、具体的なチェックポイントとして整理します。

まず確認したいのが、自社と同じ業界・同じ規模での在庫システム構築・刷新の実績です。物流、小売、製造といった業種ごとに、在庫管理の勘所は大きく異なります。同業界・同規模の実績を持つベンダーは、業務特有の要件や落とし穴を理解しており、提案の精度も高くなります。提案書に記載された実績について、どのような課題をどう解決したのかを具体的にヒアリングし、自社の状況にどこまで通用するかを見極めましょう。

次に重視すべきは、段階移行の設計力です。在庫システムの刷新は、一度にすべてを切り替える一括移行よりも、倉庫や機能を分けて段階的に移行する設計のほうがリスクを抑えられる場合が多くあります。提案書を読み解く際は、次の点を確認します。
・どのような順序で、何を区切って移行する計画か
・移行期間中、新旧システムをどう並行稼働させ、在庫データの整合をどう保つか
・問題が起きた場合の切り戻し（ロールバック）の手順
段階移行を具体的な計画として描けているベンダーは、現実のリスクを理解していると判断できます。

3つ目は、ダウンタイム見積もりの精度です。倉庫は止められないという前提に立てば、移行時にどれだけシステムを停止するのか、その時間をどう最小化するのかは、選定の決定的な判断材料になります。「ダウンタイムは最小限に抑えます」といった曖昧な表現にとどまるベンダーではなく、「移行作業は土曜深夜0時から6時間、うち在庫照会の停止は2時間」というように、根拠を伴って具体的に見積もれるベンダーを選ぶべきです。ダウンタイムを具体化できることは、移行を実際に成功させてきた経験の表れでもあります。

残る2つのチェックポイントは、稼働後を見据えた評価観点です。1つは、保守体制の確認です。在庫管理システムは、倉庫が稼働している限り止められない基盤であり、夜間や休日に障害が起きても在庫業務を止めるわけにはいきません。24時間365日の保守・サポート体制が整っているか、障害発生時の連絡フローと復旧目標（SLA）が明確かを確認します。稼働後の運用フェーズこそ、在庫システムの真価が問われる局面であり、保守体制の手厚さは長期的な安心に直結します。

もう1つは、品質・セキュリティに関する第三者認証の有無です。ISO9001（品質マネジメント）やISO/IEC27001（情報セキュリティ）といった認証を取得しているベンダーは、開発・運用のプロセスが標準化され、一定の品質とセキュリティ水準が担保されていると判断できます。在庫データには、取引先や商品の機微な情報が含まれることも多く、情報セキュリティ体制は軽視できません。認証の有無は、ベンダーの信頼性を客観的に測る一つの指標になります。

ここまでの評価観点を整理すると、ベンダー選定では次の5つのチェックポイントを軸に比較するとよいでしょう。
・同業界・同規模（物流・小売・製造）での在庫システム実績
・段階移行を具体的に描ける設計力
・倉庫を止められない前提でのダウンタイム見積もりの精度
・24時間365日の保守・サポート体制
・ISO9001・ISO/IEC27001などの品質・セキュリティ認証
これらを評価シートに落とし込み、各社を同じ基準で採点すれば、価格に流されない合理的な選定ができます。

まとめ

本記事では、在庫管理システムのモダナイゼーションにおけるアセスメント・要件定義・RFP・ベンダー評価について解説してきました。アセスメントでは、ブラックボックス化した受払・引当ロジックや連携I/F、データ量を棚卸しし、現状（AS-IS）を正確に可視化することが出発点となります。要件定義では、在庫業務に固有の機能要件と、性能・移行を含む非機能要件、そして移行後のKPIを具体的な数値で定義します。RFPには現行構成・性能要件・移行/連携要件・KPIを測定可能な形で記載し、ベンダー評価では実績・段階移行の設計力・ダウンタイム見積もり・保守体制・認証の5観点で比較することが、失敗を避ける要諦です。

在庫管理システムの刷新で最も重要なのは、発注前のアセスメントと要件定義に十分な時間と費用をかけることです。要件定義や業務棚卸しのみでも200万〜500万円程度の費用がかかりますが、この前工程を丁寧に行うことが、移行後の在庫不整合や性能トラブルといった、はるかに大きな損失を防ぐ最善の投資になります。倉庫を止められないという制約のなかで刷新を成功させるには、現状の正確な把握とRFPの精度こそが、すべての土台になります。

在庫管理システムのモダナイゼーションは、現状の可視化から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を創業。