長年使い続けてきた在庫管理システムが、保守期限の到来や周辺機器のサポート終了、業務量の増加に追いつかなくなってきたという理由で、更改（既存システムの更新・置換）を検討し始める企業は少なくありません。倉庫や物流現場の在庫管理は事業の血流そのものであり、止めずに作り替える難しさがあります。とりわけ商品マスタやロケーション、入出庫履歴といったデータが長年の運用で複雑化し、ブラックボックス化しているケースでは、いきなりベンダーに見積もりを依頼しても精度の高い回答は返ってきません。更改を成功させる鍵は、着手前の「現状把握」と「要件の言語化」にあります。
本記事では、在庫管理システム更改における「アセスメント（現状分析）→要件定義→RFP作成→ベンダー選定」という一連のプロセスに焦点を当て、各工程で何を可視化し、どんな項目を盛り込み、どの観点で評価すべきかを実務目線で解説します。更改全体の進め方や費用相場、手法の選択肢まで体系的に把握したい場合は、あわせて在庫管理システム更改の完全ガイドもご覧ください。本記事は、その完全ガイドでは触れきれない「RFPに何を書き、ベンダーをどう見極めるか」という、要件定義とベンダー選定の実務に絞って掘り下げていきます。
▼全体ガイドの記事
・在庫管理システム更改の完全ガイド
アセスメント：現行在庫管理システムのAS-IS可視化
在庫管理システムの更改は、新規開発とは異なり「すでに動いている現場」を前提に進めます。だからこそ、最初に着手すべきは新システムの設計ではなく、現行システムの現状分析、いわゆるアセスメントです。現行システムがどんな機能を持ち、どんなデータを抱え、どの周辺システムや機器とつながっているかを可視化しないまま要件定義に入ると、移行の段階で「想定外」が次々と噴出します。本章では、在庫管理の更改に固有のアセスメント観点を整理します。
機能・データ・他システム依存関係の棚卸し
アセスメントの第一歩は、現行在庫管理システムが担っている機能を洗い出すことです。入出庫の登録、在庫照会、棚卸、ロケーション管理、引当、ロットや賞味期限の管理など、現場で実際に使われている機能を一つずつ棚卸しします。長く使われたシステムほど「誰も使っていないが残っている機能」と「仕様書には書かれていないが現場が頼り切っている機能」が混在しているため、利用実態に踏み込んだ調査が欠かせません。
あわせて重要なのが、他システムとの依存関係の把握です。在庫管理システムは単独で完結することはまれで、販売管理、購買・発注、生産管理、会計、ECサイトの在庫連携など、多くのシステムとデータをやり取りしています。どのインターフェースで、どのタイミングで、どんなデータが流れているかを図にして整理しなければ、更改後に連携が切れて欠品や過剰在庫を招きかねません。近年は富士通の「ソフトウェア地図」のように、システムの複雑度や依存関係を可視化するツールも登場しており、ブラックボックス化した現行資産の構造を客観的に把握する手段として有効です。
仕様書が失われている、あるいは現状と乖離しているという状況は、在庫管理システムの更改現場で頻繁に遭遇します。ブラックボックス化したまま要件定義を進めると、新システムが「現行で当たり前にできていたこと」を取りこぼすリスクが高まります。アセスメントの段階で現行の挙動を文書として再構築しておくことが、後工程の手戻りを防ぐ最大の保険になります。
在庫データの品質評価と周辺機器の棚卸し
在庫管理システムの更改で見落とされがちなのが、データそのものの品質評価です。データは大きく、商品・ロケーション・取引先といったマスタデータと、入出庫履歴に代表されるトランザクションデータに分かれます。マスタデータには重複登録や廃番商品の放置、表記ゆれといった汚れがたまりやすく、これをそのまま新システムへ移行すると、移行直後から在庫精度が崩れます。どのデータをクレンジングし、どこまで移行するかをアセスメントの段階で見極めることが重要です。
トランザクションデータについても、過去何年分の入出庫履歴を移行対象とするか、あるいは新システムでは持ち越さず別途保管するかという方針を決める必要があります。履歴データは量が膨大になりやすく、すべてを移行しようとすると移行コストと稼働切替の所要時間が跳ね上がります。移行可否と移行範囲を早期に評価しておくことが、現実的なスケジュールとコストを描くうえで欠かせません。
もう一つ在庫管理に固有の論点が、周辺機器の棚卸しです。ハンディターミナル、バーコードリーダー、RFIDリーダー、ラベルプリンターといったハードウェアは、在庫管理の現場オペレーションを支える要です。これらの端末のOSがサポート切れになっていないか、新システムが対応するOSやアプリ形式と整合するか、更改にあわせて端末も更新する必要があるかを確認します。ソフトウェアだけを刷新しても、ハンディ端末が新システムに非対応では現場が回りません。機器の保守状況と更新範囲は、必ずアセスメント項目に含めるべきです。
要件定義：機能要件・非機能要件と移行後KPIの設計
アセスメントで現状を可視化したら、次は新しい在庫管理システムに求める要件を定義します。要件定義は「現行と同じことをできるようにする」だけでは不十分で、更改を機にどんな業務改善を実現したいかという目標も織り込みます。本章では、在庫管理に必須の機能要件、見落とすと致命傷になりがちな非機能要件、そして更改の成否を測るための移行後KPIという3つの観点から、要件定義のポイントを整理します。
在庫管理に必須の機能要件と非機能要件
在庫管理システムの機能要件としてまず押さえるべきは、リアルタイムの在庫照会、入出庫処理、棚卸機能、ロケーション管理、引当処理、ロットや賞味期限の管理といった基本機能です。これらは業種や扱う商材によって求められる粒度が変わります。食品や医薬品ではロットや期限の管理が必須ですし、多品種小ロットを扱う現場ではロケーション管理の柔軟さが効率を大きく左右します。自社の業務に照らして、どの機能をどこまで作り込むかを優先順位付けすることが要件定義の核心です。
機能要件以上に軽視されやすいのが非機能要件です。在庫管理システムでは、ピーク時の入出庫件数をさばける性能、夜間バッチ処理を翌朝の業務開始までに終えられる処理時間、拠点数や同時接続するハンディ端末の台数、システムが停止しない可用性などが事業に直結します。たとえば繁忙期の出荷ピークに処理が詰まれば、出荷遅延がそのまま顧客への納期遅れになります。非機能要件は数値で具体的に定義し、「ピーク時に1時間あたり何件の入出庫を処理できること」「ハンディ端末を同時何台まで接続できること」といったレベルまで落とし込むことが重要です。
機能要件と非機能要件を整理する際は、「これは必須（Must）か、あれば望ましい（Want）か」という優先度を明確にしておきます。すべてを必須にしてしまうと、ベンダーの提案が過剰になり費用も膨らみます。逆に必須要件が曖昧だと、稼働後に「在庫管理として当然できると思っていた処理ができない」という事態を招きます。優先度のメリハリこそが、現実的なコストと品質のバランスを取る鍵になります。
移行後KPIの設定とアセスメント費用の目安
要件定義では、更改によって何をどれだけ改善するのかを数値目標として置くことを強くおすすめします。在庫管理であれば、在庫精度（理論在庫と実在庫の一致率）、棚卸にかかる工数、欠品率といった指標が代表的なKPIです。たとえば「在庫精度を95％から99％へ引き上げる」「年4回の棚卸工数を半減する」「欠品率を現状から1ポイント改善する」といった具体的な目標を掲げることで、更改が本当に事業に貢献したかを後から評価できます。
KPIを先に決めておくことには、もう一つ効果があります。ベンダーに対して「このKPIを達成するために、貴社のシステムでどう実現するか」という問いを投げられるようになり、提案の質を比較しやすくなるのです。機能の有無だけでなく、自社の目標達成にどう貢献するかという観点でベンダーを評価できれば、選定の精度は格段に上がります。
なお、ここまで述べたアセスメントと要件定義をコンサルティング会社などの外部支援を受けて実施する場合、費用の目安はおおむね200万円から500万円程度が一般的です。決して小さくない金額ですが、この工程を省いて見切り発車した結果、移行トラブルや要件漏れで数千万円規模の追加費用が発生する事態に比べれば、確実に投資対効果の高い「上流への投資」だといえます。現状把握と要件の言語化に十分なリソースを割くことが、更改全体の成否を左右します。
RFP作成とベンダー選定の評価チェックポイント
アセスメントと要件定義で固めた内容を、ベンダーに提案を依頼するための文書としてまとめたものがRFP（提案依頼書）です。RFPの完成度が、集まる提案の質とその後のベンダー選定の精度を決めます。本章では、在庫管理システムの更改でRFPに盛り込むべき項目と、複数のベンダー提案を見比べる際の評価チェックポイントを整理します。
RFPに盛り込むべき在庫管理固有の項目
RFPには、ベンダーが精度の高い提案と見積もりを行えるだけの情報を盛り込む必要があります。在庫管理システムの更改で特に欠かせないのが、現行システムの構成図、現行の業務フロー、データ移行の範囲、性能などの非機能要件、移行後に達成したいKPI、そして稼働切替の方式です。これらが曖昧なままだと、ベンダーは前提を自社に都合よく解釈して見積もるため、後から「その作業は見積もりに含まれていない」という認識齟齬が生まれます。
在庫管理に固有の項目として、ハンディ端末などの周辺機器の更新範囲を明記することも重要です。新システムの導入にあわせて端末を更新するのか、既存端末を流用するのか、その台数や機種は何かを示すことで、ベンダーは現場対応も含めた現実的な提案ができます。あわせて、稼働後の保守体制への要望も記載しておきます。在庫を扱う現場は土日や夜間も稼働することが多く、どの時間帯にどのレベルのサポートが必要かを伝えておかないと、保守の前提がベンダーごとにバラバラになってしまいます。
稼働切替方式の希望をRFPに記すことも忘れてはいけません。在庫管理システムは止められない業務であるため、全拠点を一度に切り替えるのか、拠点や機能を区切って段階的に移行するのかという方針は、見積もりにもプロジェクト計画にも大きく影響します。自社として許容できるダウンタイムの上限とあわせて伝えることで、ベンダーは在庫を止めない移行設計を具体的に提案できるようになります。
ベンダー評価の5つのチェックポイント
複数のベンダーから提案が集まったら、価格だけで決めずに多面的に評価します。在庫管理システムの更改では、特に次の5つのチェックポイントが有効です。第一に、同業界・同規模の実績です。在庫や物流の領域は業種固有の慣習が多く、製造業の部品在庫と小売の店舗在庫では求められるものが異なります。自社と近い規模・業態での更改実績を持つベンダーは、要件の理解が早く、提案の地に足がついています。
第二に、段階移行の設計力です。在庫を止めずに更改するには、拠点や機能を区切って少しずつ新システムへ置き換える設計力が問われます。第三に、在庫を止めないダウンタイムの見積もり精度です。切替時にどれだけ業務を止める必要があるか、止められない場合にどう並行運用するかを具体的に説明できるベンダーは、移行リスクへの理解が深いといえます。これらは、過去の類似プロジェクトでどう移行したかを質問すれば見極められます。
第四に、稼働後の保守体制です。在庫管理は24時間365日動き続ける現場も多く、障害時に迅速に対応できる体制があるかは事業継続に直結します。第五に、品質・セキュリティの認証です。ISO9001（品質マネジメント）やISO/IEC27001（情報セキュリティ）といった認証の取得状況は、組織としての管理水準を客観的に示す指標になります。在庫データは取引先情報や仕入価格など機密性の高い情報を含むため、セキュリティ面の信頼性は軽視できません。この5つの観点で各社を採点し、価格と総合的に比較することで、自社に最適なパートナーを選び抜けます。
まとめ
本記事では、在庫管理システム更改における「アセスメント→要件定義→RFP→ベンダー選定」という上流工程の進め方を解説してきました。アセスメントでは、機能・データ・他システム依存関係の棚卸しに加え、商品やロケーションといったマスタおよび入出庫履歴の品質と移行可否、ハンディ端末などの周辺機器のサポート状況までを可視化します。要件定義では、在庫照会や棚卸といった機能要件と、ピーク時の入出庫件数や同時接続台数といった非機能要件を優先度付きで整理し、在庫精度・棚卸工数・欠品率といった移行後KPIを数値で設定することが要点でした。
RFPには、現行構成図・業務フロー・データ移行範囲・性能要件・移行後KPI・稼働切替方式に加え、在庫管理に固有のハンディ端末更新範囲や保守体制までを明記します。ベンダー選定では、(1)同業界・同規模の実績、(2)段階移行の設計力、(3)在庫を止めないダウンタイムの見積もり、(4)24時間365日の保守体制、(5)ISO9001やISO/IEC27001などの品質・セキュリティ認証という5つのチェックポイントで多面的に評価することが、最適なパートナー選びにつながります。アセスメントと要件定義に200万円から500万円規模の上流投資を惜しまないことが、結果として更改全体の手戻りとコストを抑えます。
在庫管理システムの更改は、止められない現場を抱えながら作り替える難度の高い取り組みです。だからこそ、現状を正確に可視化し、要件を数値で言語化し、RFPと評価軸を整えるという上流工程の丁寧さが成否を分けます。本記事で整理したプロセスとチェックポイントを、自社の更改計画に照らして活用してください。手法選定や費用相場を含めた全体像を改めて確認したい場合は、完全ガイドもあわせてご覧いただくと、本記事の内容を更改の全工程の中に位置づけやすくなります。
株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。