在庫管理システムの更改は、アセスメントで現行システムを把握し、要件定義で要件を数値で示したうえで、RFPを作ってベンダーを評価する順に進めます。この順で進めると、移行漏れや選定後の認識のずれを防ぎやすくなります。
全体像は在庫管理システム更改の完全ガイドもご覧ください。
▼全体ガイドの記事
・在庫管理システム更改の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
アセスメント：現行在庫管理システムのAS-IS可視化
保守期限や周辺機器のサポート終了、業務量の増加を受けて、更改を検討する企業は少なくありません。倉庫や物流現場の在庫管理は事業の中核を担っており、止めずに作り替えるのは簡単ではありません。そのため、稼働中の現場を前提に、新システムの設計より先に現行システムの現状分析（アセスメント）に着手します。
機能、データ、周辺システムや機器との接続を把握しないまま要件定義に入ると、移行時に想定外の問題が起きます。
機能・データ・他システム依存関係の棚卸し
まず現行機能を一覧にし、仕様書にない現場の使い方や他システムとの依存関係も洗い出します。
- 業務機能：入出庫、在庫照会、棚卸、ロケーション、引当、ロット・賞味期限管理
- 利用実態：未使用のまま残る機能と、現場が頼りにしている仕様書にない機能
- システム連携：単独では完結しにくく、販売管理、購買・発注、生産管理、会計、ECサイトとデータをやり取りしている
- データ連携：インターフェース、データの受け渡しの時期、送受信するデータ
連携図を作らないまま更改すると、連携が切れることで欠品や過剰在庫を招くおそれがあります。さらに、富士通の「ソフトウェア地図」のようなツールを使えば、複雑さや依存関係を見える形にでき、ブラックボックス化した現行資産も客観的に把握できます。
仕様書の紛失や現状との食い違いは、更改の現場でよくあります。現行の挙動を文書に組み直せば、手戻りを防げます。特に、ブラックボックスのまま要件定義を進めると、現行で当然できていた処理が新システムから抜け落ちるおそれがあります。
在庫データの品質評価と周辺機器の棚卸し
在庫データの品質と周辺機器は、在庫管理システムの更改に固有の確認事項です。
- マスタデータ：商品、ロケーション、取引先の重複・廃番・表記ゆれ
- 履歴データ：過去何年分を移行するか、移行せずに別途保管するかの方針
- 周辺機器：現場を支えるハンディターミナル、バーコード・RFIDリーダー、ラベルプリンター
- 端末の更新：OSのサポート状況、新システムとの互換性、更新の要否
重複登録や廃番商品の放置、表記ゆれがあるマスタをそのまま移すと、稼働直後から在庫精度が崩れます。そのため、どのデータを整えてから移すか、どこまで移行するかは、アセスメントの段階で見極めます。また、履歴をすべて移すと移行コストと切替時間が増えるため、移行の可否と範囲を早い段階で評価します。
端末のOSやアプリの形式が新システムに合わなければ、現場では業務を続けられません。ソフトウェアだけを刷新しても、非対応のハンディ端末では現場が回りません。そのため、端末の保守状況と更新範囲を確認しておきます。
要件定義：機能要件・非機能要件と移行後KPIの設計
現行と同じ機能の再現に加えて、更改で実現したい業務改善も要件に織り込みます。さらに、在庫管理に必要な機能や性能などの非機能要件、移行後KPIを整理し、要件に優先順位を付けます。
在庫管理に必須の機能要件と非機能要件
機能要件に加えて、見落とすと影響の大きい非機能要件も定めておきます。
- 基本機能：リアルタイム在庫照会、入出庫、棚卸、ロケーション、引当
- 商材別機能：食品・医薬品のロットや期限、多品種小ロットの柔軟なロケーション
- 処理性能：ピーク時の入出庫件数と夜間バッチの完了時間
- 稼働要件：拠点数、同時接続端末数、停止しない可用性
- 優先度：必須（Must）と、あれば望ましい（Want）の区分
機能の粒度は業種や商材によって変わるため、自社の業務に照らして、作り込む範囲に優先順位を付けます。
繁忙期に処理が詰まると出荷が遅れ、顧客への納期にも響きます。そのため、非機能要件は数値で示しておきます。たとえば、ピーク時の1時間あたりの入出庫件数や、同時接続できるハンディ端末数を決めておきます。
すべてを必須にすると、提案が過剰になって費用が膨らむ一方で、必須の線引きが曖昧だと当然の処理ができなくなることもあります。そこで、優先度を明確にしておくと、現実的なコストと品質の釣り合いを取りやすくなります。
移行後KPIの設定とアセスメント費用の目安
改善目標をKPIで数値にしておくと、更改の成果を評価でき、提案の比較にも使えます。
- 在庫精度：理論在庫と実在庫の一致率
- 棚卸工数：年4回の棚卸にかかる工数を半分に減らす目標の例
- 欠品率：現状から1ポイント改善する目標の例
在庫精度を95％から99％へ引き上げる目標の例もあります。目標を先に決めておくと、達成の方法をベンダーに問えます。また、機能の有無だけでなく、自社の目標にどう貢献するかを比べると、選定の精度を高められます。
外部支援によるアセスメントと要件定義の費用は、目安として200万円から500万円程度で、決して小さい額ではありません。工程を省いて見切り発車すると、移行トラブルや要件漏れで、数千万円規模の追加費用が生じることがあります。こうした追加負担と比べると、上流工程への投資は投資対効果が高いといえます。
現状の把握と要件の言語化に十分な人員を割けるかどうかが、更改全体の成否を左右します。
RFP作成とベンダー選定の評価チェックポイント
RFP（提案依頼書）は、要件をベンダーに伝え、提案と見積もりを依頼する文書です。その内容が具体的であるほど、提案の質と選定の精度が高まります。
RFPに盛り込むべき在庫管理固有の項目
提案と見積もりの前提を揃えるため、現状、要件、切替条件をRFPに示します。
- 現状資料：現行システムの構成図と業務フロー
- 移行・性能：データ移行範囲と非機能要件
- 目標・切替：移行後KPIと稼働切替方式
- 端末・保守：周辺機器の更新範囲と稼働後の保守体制
情報が曖昧だと、ベンダーごとに前提が食い違い、見積もりに含まれない作業をめぐって認識のずれが起きます。ハンディ端末などを更新するか流用するかは、台数や機種とともに明記します。そうすれば、現場対応を含む提案につながります。
また、稼働後の保守体制への要望も記しておきます。必要な曜日や時間帯、サポートレベルを示さなければ、各社の前提は揃いません。
全拠点を一括で移すか、拠点や機能ごとに段階を踏んで移すかは、見積もりと計画に大きく影響します。許容できるダウンタイムの上限も示しておくと、在庫を止めない移行設計を提案してもらえます。
ベンダー評価の5つのチェックポイント
価格だけでなく、移行実績と運用・管理体制を含む5つの観点で提案を評価します。
- 同業界・同規模の実績：自社に近い業態での更改経験
- 段階移行の設計力：拠点や機能ごとに置き換える力
- 停止時間の見積もり：在庫を止めないための、並行運用を含めた見込みの精度
- 稼働後の保守体制：障害時に迅速に対応できる体制
- 品質・セキュリティ認証：ISO9001やISO/IEC27001の取得状況
製造業の部品在庫と小売の店舗在庫では商慣習が異なるため、近い規模や業態の実績を確かめておきます。停止できない現場では、類似案件の移行方法や並行運用について質問し、ベンダーが移行リスクをどれだけ理解しているかを見極めます。
24時間365日稼働する現場もあるため、障害時の対応力は事業の継続に関わります。在庫データには取引先情報や仕入価格などが含まれるだけに、認証状況は管理水準を測る材料になります。
各社を採点し、価格と合わせて総合的に比べると、自社に合うパートナーを選びやすくなります。
まとめ
アセスメントでは、機能とデータ、依存関係を棚卸しし、マスタや入出庫履歴の品質と移行の可否を確かめます。また、端末のサポート状況と更新範囲も一覧にします。要件定義では、在庫照会や棚卸の機能、ピーク時の入出庫件数と同時接続台数を、優先度を付けて整理します。
在庫精度、棚卸工数、欠品率のKPIを数値にして、提案の比較に使います。RFPには、現行の構成図と業務フローに加えて、データ移行範囲と性能要件、KPI、切替方式を記します。
端末の更新範囲と保守体制もRFPに明記し、ベンダーは、同業界・同規模の実績と段階移行の設計力で比べます。さらに、停止時間の見積もり、24時間365日の保守体制、ISO9001・ISO/IEC27001などの認証も評価します。
上流工程への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を創業。