【テンプレート付】在庫管理システムの要件定義｜機能要件・非機能要件チェックリストと進め方

在庫管理システムの要件定義とは

在庫管理システムの要件定義とは、システムに「何を実現させるか（機能要件）」と「どの程度の品質で動かすか（非機能要件）」を、導入前に文書として明確にする工程です。入出庫・ロケーション・ロット/期限・引当・棚卸といった業務機能の要否、性能やセキュリティなどの品質目標、そして基幹システムとの連携範囲を洗い出し、関係者で合意します。

要件定義は単なる「やりたいことリスト」ではなく、製品選定・見積依頼（RFP）・導入・テストのすべての判断基準になるプロジェクトの背骨です。ここが曖昧だと、ベンダーごとに提案の前提がバラバラになり、見積もりも横並びで比較できなくなります。

なぜ要件定義で導入の成否が決まるのか

在庫管理システムの導入が失敗するとき、その原因の多くは「製品が悪かった」ではなく「要件が固まっていなかった」ことにあります。要件が曖昧だと、次のような構造的な問題が起きます。

• 比較ができない — 各社が異なる前提で提案するため、価格も機能も横並びにできない
• 現場と乖離する — 情シス部門だけで要件を決め、現場の運用（ハンディ・棚卸・現品管理）が抜ける
• 追加開発で費用が膨らむ — ロット管理・FEFO出庫・トレーサビリティなど、後から必要と判明した要件が追加開発になる
• データ移行で躓く — 現行の在庫データ・マスタの移行要件を後回しにし、稼働直前に問題が顕在化する

逆に言えば、要件定義の段階でこれらを潰しておけば、製品選定から稼働までの不確実性を大きく減らせます。

要件定義で決める5つの範囲

1. 業務範囲 — 対象拠点・倉庫・取扱品（部品/原材料/仕掛品/製品）と対象業務
2. 機能要件 — 各業務でシステムに実現させる機能
3. 非機能要件 — 性能・可用性・セキュリティ・拡張性など品質に関する要件
4. 連携要件 — 生産管理・販売・購買・会計など他システムとの連携範囲と方式
5. データ移行・運用要件 — 現行データの移行、運用体制、教育、保守

特に在庫管理では、取扱品の特性によって要件が大きく変わります。食品・医薬なら期限管理（FEFO）とトレーサビリティが必須に、電子部品ならロット・シリアル管理が重要に、というように、自社の品目特性を起点に要件を組み立てるのがコツです。

要件定義の進め方：5ステップ

ステップ	内容	アウトプット
① 現状把握（As-Is）	現行の在庫業務・課題・帳簿と現品の差異要因を洗い出す	業務フロー、課題一覧
② あるべき姿（To-Be）	解決したい課題と目指す運用像を定義する	目的・KPI（在庫差異率、欠品率など）
③ 機能要件の整理	チェックリストで必要機能の要否・優先度を決める	機能要件一覧
④ 非機能・連携要件の整理	性能・セキュリティ・連携先を定義する	非機能要件・連携要件一覧
⑤ RFP化・評価基準の作成	要件をRFPにまとめ、評価軸と配点を決める	RFP、評価マトリクス

ポイントは、②で「KPI（測れる目標）」まで落とすことです。「在庫差異率を○%以下に」「欠品による出荷遅延を○件/月以下に」といった数値目標があると、機能の要否判断と導入後の効果測定がぶれません。

機能要件チェックリスト（在庫管理の核心）

在庫管理システムに求める代表的な機能要件です。自社の品目特性に照らして「必須／任意／不要」を判断してください。

大分類	主な要件項目
入出庫管理	入庫/出庫登録、倉庫間・棚間移動、入荷/出荷予定取込、入荷・出荷検品
ロケーション管理	棚番マスタ、フリー/固定ロケーション、ロケーション別在庫照会、最適格納
ロット・期限管理	ロット管理、シリアル管理、賞味/使用期限管理、FEFO出庫、期限アラート
在庫照会・引当	リアルタイム在庫照会、受注/出庫引当、引当順序(FIFO/FEFO)、利用可能在庫(ATP)
棚卸	一斉棚卸、循環棚卸（サイクルカウント）、差異報告、結果の在庫反映
補充・発注	安全在庫、発注点、自動補充提案、ABC分析
在庫評価	評価方法（移動平均/総平均/先入先出/標準原価）、在庫金額照会、滞留在庫抽出
トレーサビリティ	ロットトレース（前後追跡）、入出庫履歴、シリアル追跡
入出力・ハンディ	バーコード/QR/RFID、ハンディ端末、ラベル発行、モバイル/オフライン運用

見落としがちな要件: FEFO出庫（期限の近い順での引当）、循環棚卸、オフライン運用は、デモでは触れられないのに現場で効いてくる項目です。自社で必要なら必ず要件に明記しましょう。

非機能要件で見落としがちなポイント

機能だけに目が向きがちですが、非機能要件こそ稼働後の満足度を左右します。

区分	確認すべき要件（目標値の例）
性能	在庫照会の応答時間（例：2秒以内）、繁忙期のピークトランザクションに耐えるか
可用性	稼働率（例：99.9%）、障害時の復旧目標（RTO/RPO）
拡張性	最大SKU数・拠点/倉庫数、取引量増加への対応
セキュリティ	認証（SSO/MFA）、倉庫・ロール単位の権限、操作・監査ログ
運用保守	バックアップ/リストア、監視、保守時間帯とサポートSLA
移行	現行在庫・マスタ・履歴の移行可否、移行ツール、文字コード対応
コンプライアンス	電子帳簿保存法、内部統制（J-SOX）、業界トレーサビリティ法規

クラウドかオンプレか、繁忙期のピークに性能が耐えるか、権限を倉庫単位で分けられるか——このあたりは契約後に発覚すると致命的なので、要件定義の段階で必ず確認します。

基幹・周辺システムとの連携要件

在庫管理システムは単独では完結しません。どのシステムと、何を、どの方式（API/CSV/EDI）で、どの頻度で連携するかを定義します。

連携先	主な連携内容
生産管理 / MES	製造指図・実績に伴う部品出庫・製品入庫
販売管理 / 受注（EC・EDI）	受注に対する引当・出荷指示
購買 / 発注	発注・入荷予定の取込
会計 / 原価	在庫評価額・受払の仕訳連携
WMS / 物流（TMS）	庫内作業・配送指示
ハンディ / IoT	ハンディ端末・ラベルプリンタ、重量計・センサ

連携は「方向（送信/受信/双方向）」と「頻度（リアルタイム/日次）」まで決めるのがポイントです。ここが曖昧だと見積もりに連携開発費が含まれず、後から大きな追加費用になります。

RFP（提案依頼書）に盛り込むべき項目

要件が固まったら、ベンダーへの提案依頼書（RFP）にまとめます。最低限、次の項目を含めます。

• 案件概要・背景・目的、対象業務範囲、現状の課題
• 想定規模（SKU数・拠点数・ユーザー数・取引量）
• 機能要件・非機能要件・連携要件（チェックリストを別紙添付）
• データ移行要件、提供形態（クラウド/オンプレ）の希望
• スケジュール・予算感、提案書に含めてほしい内容（構成図・見積内訳・実績・体制）
• 評価方法・選定基準、提出期限・問い合わせ先

RFPに評価基準を明記しておくと、各社が要点を押さえた提案をしてくれるため、比較の精度が上がります。

ベンダーを横並び比較する評価マトリクス

複数ベンダーを公平に比較するには、評価項目に重み付けをして加重スコアで比べます。機能適合度・非機能適合度・連携性・コスト（初期＋運用）・導入実績・サポート体制・拡張性・操作性・セキュリティ・導入スピード——これらに重み（合計100%）を割り当て、各社を1〜5で評価して加重スコアを算出します。

こうすると「機能は満点だが定着しにくい」「価格は高いが実績豊富」といったトレードオフを、感覚ではなく数字で意思決定できます。

在庫管理システム導入でよくある失敗と回避策

よくある失敗	原因	回避策
帳簿と現品が合わない	ロケーション・入出庫の運用ルール未整備	棚番マスタとハンディ運用を要件に含め、循環棚卸を設計
現場が使わず形骸化	情シス主導で現場要件が抜けた	要件定義に現場担当を巻き込み、操作性を評価軸に入れる
追加開発で予算超過	ロット/FEFO/連携を後出しで要件化	品目特性から必要機能を先に洗い出し、RFPに明記
稼働直前に移行で躓く	データ移行を後回し	移行対象・方式・時期を要件定義の段階で決める

チェックリストの使い方（テンプレートとして使う）

本記事の機能要件・非機能要件・連携要件・評価マトリクスの各表は、そのまま要件定義の雛形（テンプレート）として使えます。表をコピーして、自社に必要な項目の「要否」「優先度」を記入し、ベンダー回答を並べて比較してください。次の流れが基本です。

1. 各表で自社に必要な項目の要否（必須/任意/不要）と優先度を記入する
2. 不足する自社固有の要件（業種・取扱品の特性）を追記する
3. ベンダーから回答を得たら対応状況（○標準/△設定・追加開発/×不可）を記入する
4. 評価マトリクスで重みと評点を入れ、加重スコアで横並び比較する

※ 記入と加重スコアの自動集計ができるExcelテンプレート（ダウンロード版）は近日公開予定です。