ただし、kintoneにアプリを作れば自動的に在庫が正しくなるわけではありません。在庫数をいつ確定するのか、入庫・出庫・返品・調整をどの単位で記録するのか、どの担当者が承認するのかを決めてから設計する必要があります。標準機能で足りない処理をプラグインで補う場合も、追加するほど管理対象や更新確認が増える点に注意が必要です。
この記事では、kintoneで在庫管理を始める手順、基本的なアプリ構成、バーコードや集計に使えるプラグインの考え方、向いている企業と限界を整理します。小規模な試行から始める方法と、将来の拠点増加や外部連携まで見据えて判断するポイントを、現場で使う担当者と導入を決める責任者の両方に向けて解説します。
この記事で分かること
- kintoneを在庫管理に使うメリットと、事前に決めるべき在庫の定義
- 商品マスタ、入出庫履歴、倉庫・ロケーションを分けるアプリ構成
- kintoneで在庫管理アプリを作る手順と、権限・通知の設計方法
- バーコード、ルックアップ、集計、帳票などを補うプラグインの選び方
- kintoneが向いている企業と、専用システムや個別開発を検討すべきケース
- 試行導入から本番運用へ移すときのデータ移行、教育、改善の進め方
kintoneが在庫管理に使われる理由
業務に合わせて項目を変更しやすい
市販の在庫管理システムでは、最初から用意された項目や画面に業務を合わせることがあります。kintoneはアプリのフィールドを追加・変更しやすく、自社で使う商品コード、単位、仕入先、保管場所、担当部署などを登録できます。まず必要な範囲に絞って作成し、運用しながら入力項目や一覧を見直せる点が特徴です。
柔軟さを活かすには、自由に項目を増やすのではなく、項目の目的を説明できる状態にします。「備考」だけに情報を集めると、あとで検索や集計ができません。入庫理由、出庫先、ロット、期限、承認状態など、後から判断に使う情報は独立したフィールドにし、入力形式も選択肢や数値に制限します。
ブラウザから同じデータを確認できる
kintoneのアプリは、パソコンの場所ごとにファイルを配布する方法と比べ、同じデータを参照する運用を作りやすくなります。倉庫担当者が入出庫を登録し、購買担当者が発注点を確認し、管理者が棚卸しの差異を承認するというように、役割ごとの作業を分けられます。拠点が増えた場合も、共有範囲や権限を設計することで情報を集約しやすくなります。
一方で、画面を開ける人が多いほど権限設計が重要です。誰でも在庫数を編集できる状態では、入力ミスを防げず、履歴の信頼性も下がります。登録、確認、承認、マスタ変更の権限を分け、実棚を数える人と在庫を確定する人を必要に応じて分けます。
通知やプロセスを業務に組み込みやすい
発注点を下回った商品を知らせる、棚卸しの確認を依頼する、入庫登録後に購買担当へ通知するなど、手作業での連絡を減らす仕組みを検討できます。通知条件を作るときは、すべての更新で通知するのではなく、対応が必要な状態になったときに限定します。通知が多すぎると見落とされるため、誰が何を確認し、いつ対応を完了するかまで決めることが大切です。
kintoneの在庫管理アプリを設計する
商品マスタアプリに登録する情報
商品マスタアプリには、商品コード、商品名、カテゴリ、単位、標準仕入先、保管場所、発注点、在庫管理の対象かどうかを登録します。商品コードは重複しない値にし、商品名だけで入出庫を紐付けないようにします。商品名の変更や表記ゆれがあっても、コードを基準に履歴を追えるようにするためです。
単位は特に慎重に決めます。箱で入荷して個で出庫する商品なら、換算数をどこで管理するかを明確にしなければなりません。商品ごとに換算率を持たせる方法もありますが、例外が多い場合は、入出庫時の単位と換算後の数量を別々に記録すると検証しやすくなります。廃番や取扱停止のフラグも用意しておくと、過去履歴を残したまま新規入力だけを制限できます。
入出庫履歴アプリで事実を記録する
在庫数を一つの数値欄へ直接入力する設計では、いつ何が変わったかを追跡できません。入庫、出庫、返品、移動、棚卸し調整などの事実を、入出庫履歴アプリへ一件ずつ登録します。主なフィールドは、処理日時、商品コード、処理区分、数量、単位、倉庫、ロケーション、伝票番号、担当者、備考です。登録時点の情報と承認後の確定情報を区別する項目も必要になります。
現在庫は履歴を集計して表示する考え方が基本です。入庫をプラス、出庫をマイナスとして合算する設計なら計算しやすくなりますが、現場が意味を誤解する可能性があります。画面には「入庫数量」「出庫数量」「調整数量」を分けて表示し、集計ルールを手順書に明記します。マイナス在庫を許可するか、登録時に警告するか、出荷を止めるかも、商品や業務ごとに決めます。
倉庫・ロケーションを別の情報として扱う
倉庫が一つの間は商品マスタに保管場所を持たせるだけでも運用できます。しかし、棚番や複数拠点を扱うなら、倉庫・ロケーションの情報を独立させた方が変更に対応しやすくなります。同じ商品が複数の棚に分かれる場合は、商品とロケーションの組み合わせで在庫を集計します。拠点間移動は、出庫と入庫を別々に登録するのか、一つの移動伝票で管理するのかを決めます。
| アプリ | 主な役割 | 設計時の注意点 |
|---|---|---|
| 商品マスタ | 商品コード、名称、単位、発注点を管理 | コードの重複と単位の混在を防ぐ |
| 入出庫履歴 | 入庫、出庫、返品、調整の事実を記録 | 処理区分、日時、担当者、伝票を残す |
| 倉庫・ロケーション | 拠点、棚番、保管場所を管理 | 移動前後と利用停止場所を区別する |
| 棚卸し | 実棚数、帳簿数、差異、承認を管理 | 数えた人と確定した人を記録する |
kintoneで在庫管理を作る手順
先に業務の流れと在庫の定義を整理する
アプリを作り始める前に、商品の受注、仕入れ、入荷、検品、保管、出荷、返品、廃棄、棚卸しの流れを並べます。各場面で在庫が増減するのか、仮の数量として扱うのか、確定の条件は何かを確認します。受注しただけで引当在庫が変わる企業もあれば、出荷確定時だけ減らす企業もあります。画面の項目名が同じでも意味が異なるため、現場で使う言葉をそのまま要件に反映します。
現状のExcelや紙の台帳を見ながら、入力者、入力のタイミング、チェック者、後工程で使う帳票を洗い出します。入力を一度に減らそうとして必要な履歴まで省くと、後から原因調査ができません。逆に、誰も参照しない項目をすべて移すと、入力負担が増えます。最初の対象業務を入庫と出庫に絞るなど、試行範囲を決めることが成功しやすい進め方です。
アプリとフィールドを段階的に作成する
最初から複雑な連携を実装するのではなく、商品マスタと入出庫履歴を作り、数件の実データで入力と集計を確認します。ルックアップで商品名や単位を取得すると、コード入力時の転記を減らせます。ただし、マスタの変更が履歴へ自動反映されるかどうかは設計と設定によって異なるため、過去データの表示が変わってよいのかを確認します。
一覧画面は、すべてを一つに詰め込まず、用途別に用意します。入庫担当向けの「当日処理」、管理者向けの「発注点未満」、棚卸し向けの「差異あり」など、判断に必要な列だけを並べます。検索条件に商品コード、倉庫、処理区分、期間を用意すると、履歴の確認や問い合わせへの対応が早くなります。
権限、プロセス、履歴の扱いを決める
商品マスタを変更できる人、入出庫を登録できる人、調整を承認できる人を分けます。登録後に訂正できる期間や、確定後は変更申請にするルールも必要です。棚卸しで差異が出たとき、数値を上書きせず、差異の理由と承認を記録する運用にすると、後から追跡できます。
権限を細かく設定しすぎると、現場が入力できず、結局Excelへ戻ることがあります。実際の担当者の交代や休暇も含め、誰が代替できるかを確認します。ログを残すだけでなく、ログを誰がどの頻度で見るのかを運用に組み込むことが重要です。
在庫管理で検討されるkintoneプラグイン
バーコードやQRコードの入力を補助する
商品コードを手入力すると、桁の誤りや似たコードの選択ミスが起きます。バーコードやQRコードを読み取り、商品を呼び出すプラグインを使えば、入出庫や棚卸しの入力を簡略化できる場合があります。導入前に、使う端末のカメラ性能、ラベルの印刷品質、通信できない場所の有無、同じ商品に複数のコードがあるかを確認します。
読み取れることだけを確認して終わらせず、誤読したときに訂正できる画面を用意します。連続スキャンで数量を加算する方式では、同じ商品を二重に読んだ場合の取り消しが必要です。箱と個のコードを混在させる場合は、数量換算のルールと表示を現場で検証します。
ルックアップや関連レコードの入力を整える
標準機能で対応できる範囲でも、商品コードを選んだ後に関連する情報を表示したい、入出庫の明細を一覧で確認したいという要望が出ます。プラグインを使う場合は、標準機能との違い、設定の保存場所、ライセンス更新、kintoneの仕様変更への対応を確認します。プラグインを追加するほど画面の動作や障害時の切り分けが複雑になるため、目的を一つずつ明確にします。
集計、帳票、通知を補う
在庫を商品別・倉庫別に集計したい、棚卸し表を印刷したい、発注依頼書を出力したいという場合に、集計や帳票を補助するプラグインを検討します。帳票の見た目を整えることに集中すると、元データの抽出条件が曖昧になります。帳票に出した時点、対象期間、在庫の定義、出力者を明確にし、同じ条件で再出力できるようにします。
プラグインの選定では、無料か有料かだけでなく、提供元のサポート、導入後の更新、データの取り出し方法を確認します。試用できる場合は、実際の商品コードと棚卸しの手順で試します。業務上不可欠な処理を一社のプラグインだけに依存する場合は、停止時の代替手順も用意します。
kintone在庫管理の限界と注意点
複雑な引当や製造工程は設計が難しくなる
単純な入庫・出庫・棚卸しであれば、アプリと集計の組み合わせで始めやすい一方、受注引当、複数段階の承認、ロット追跡、期限管理、返品検品、セット品の分解、製造の所要量計算などが重なると設計は複雑になります。どの処理を一つのアプリに置き、どの処理を別アプリや連携先に任せるかを決めなければなりません。
製造業で原材料、仕掛品、完成品を同時に管理する場合は、在庫数だけでなく、製造指図、工程、歩留まり、入庫予定を扱う必要があります。製造に必要な機能は、製造業向け在庫管理システムの選び方で整理している観点も参考にし、自社の業務がkintoneのアプリ構成で無理なく表現できるかを確認します。
大量データやリアルタイム連携では事前検証が必要
履歴を長期間すべて保存し、複数拠点から高頻度で更新し、販売・会計・生産システムと連携する場合は、データ量、処理回数、検索速度、連携の失敗時の扱いを検証します。登録が成功したように見えても連携先に届いていない、同じ伝票が二重に取り込まれるといった事態に備え、連携IDとエラーの再処理方法を定義します。
バーコード端末を倉庫の奥で使うなど、通信が不安定な環境では、入力を一時保存できるか、通信復旧後にどの順番で送るかを確認します。通信状態に左右される業務を無理に一つの画面へ集約すると、現場が作業を止めることがあります。紙や一時ファイルを使う場合の戻し方まで含めて、例外時の手順を作ります。
プラグインが増えるほど保守の責任が増える
プラグインは短期間で機能を補える一方、提供元のサポート条件やライセンスに影響されます。担当者が変わったときに設定を再現できるよう、導入目的、設定値、契約情報、更新日、障害時の連絡先を一覧にします。アプリを改修する前に、どのプラグインがどのフィールドや画面に関係するかを調べます。
kintoneを使うかどうかは、機能の数だけで決めません。在庫の定義、業務の頻度、現場の入力負担、将来の連携を並べ、標準機能・プラグイン・別システムの役割を分けることが大切です。
kintoneでの在庫管理が向いている企業
まず業務を整理しながら小さく始めたい企業
商品数や拠点数が限定され、現在はExcelや紙で運用しているものの、入力や確認の手間を減らしたい企業には、kintoneが候補になります。いきなり全社の在庫を移すのではなく、一つの倉庫や商品群に対象を絞り、入出庫と棚卸しを試します。現場の意見を聞きながら項目や一覧を変えられるため、要件が固まっていない段階でも検証しやすくなります。
部門間で同じ情報を共有したい企業
倉庫、購買、営業、管理部門がそれぞれ別の表を持ち、在庫確認のたびに照合している企業も対象になります。商品コードと更新ルールを統一し、誰が見ても同じ現在庫と履歴を確認できる状態を作ることが目的です。店舗間移動や拠点別の在庫を見える化したい場合は、小売・複数店舗向け在庫管理システムの機能も要件整理に役立ちます。
自社で改善を続けられる体制がある企業
アプリの管理者を置き、現場から出た変更要望を整理し、テストしてから反映できる企業は、kintoneの柔軟さを活かしやすくなります。外部へ開発を依頼する場合も、業務側に判断できる担当者がいると、入力項目の追加が目的から外れにくくなります。管理者が不在のまま導入すると、作成者しか変更できない状態になり、別の属人化を招くため注意が必要です。
kintone以外の方法を検討したい企業
高度な在庫引当や基幹連携が最初から必要な企業
受注と出荷を秒単位で連動させる、複数モールの在庫を同時に更新する、製造計画と原材料を連動させるなど、最初から高度な連携が必要な場合は、専用システムや個別開発を含めて比較します。kintoneを連携の中心にできる場合もありますが、処理の正本、データの更新順、障害時の復旧を詳細に設計しなければなりません。
ECや複数チャネルの受注を扱う場合は、EC在庫管理で複数モールと倉庫在庫を連携する方法も確認し、必要な受注・在庫・出荷データの流れを洗い出します。kintoneのアプリだけで要件を満たそうとせず、既存の販売管理や倉庫システムとの境界を決めることが、二重管理を防ぐポイントです。
現場に入力端末や通信環境を用意できない企業
倉庫に端末を置けない、通信できない場所で作業する、担当者がシステム入力に時間を割けないという場合は、先に作業方法を見直します。導入後も紙へ記録して後でまとめて入力するなら、リアルタイムで見られるという利点が薄れます。端末、ネットワーク、ラベル、入力時間、教育を含めた運用設計を行い、kintoneが現場の負担を増やさないかを試します。
導入を進める手順
現状データを整理して試行範囲を決める
商品コードの重複、単位の違い、廃番商品、過去履歴の欠落を確認し、移行するデータと参照用に残すデータを分けます。すべてを一度にきれいにしようとすると開始が遅れるため、試行対象の商品と期間を定めます。入力後にどの帳票や確認作業へ使うかを決めると、必要なフィールドを絞り込めます。
一つの業務でパイロット運用を行う
一つの倉庫、一つの商品群、一つの入出庫業務など、結果を確認しやすい範囲でパイロットを行います。実際に棚卸しを実施し、帳簿数と実棚数の差異、入力にかかった時間、修正の回数、通知の見落としを記録します。テスト用データだけでは分からない、例外商品や返品処理も少数含めて確認します。
教育と改善のルールを整える
操作方法だけでなく、どの時点で登録するか、誤入力をどう訂正するか、在庫を確定するのは誰かを手順書にします。変更要望はすぐにアプリへ反映せず、目的、影響する帳票、権限、テスト方法を整理してから管理者が判断します。月次で差異と未処理通知を確認し、不要な項目や通知を減らすことも定着につながります。
kintone在庫管理を導入する前の確認項目
- 在庫数が増減する処理と、確定するタイミングを説明できるか
- 商品コード、単位、倉庫、ロケーションのマスタを管理する担当者がいるか
- 入出庫、返品、移動、棚卸し調整の履歴を残せるか
- 登録、承認、マスタ変更、帳票出力の権限を分けられるか
- バーコード端末、通信、ラベル、入力教育を用意できるか
- プラグインの更新、契約、障害時の代替手順を管理できるか
- データ量と外部連携を検証し、将来の拡張範囲を決めているか
よくある質問
kintoneの標準機能だけで在庫管理を始められますか？
商品マスタと入出庫履歴を登録し、一覧や集計で現在庫を確認するところから始めることはできます。バーコード読み取り、複雑な帳票、外部システムとの連携などが必要になった段階で、プラグインや個別開発を検討します。最初に業務の流れと在庫の定義を整理し、標準機能で対応する範囲を決めることが大切です。
まとめ
kintoneで在庫管理を始めるときは、商品マスタと入出庫履歴を分け、在庫が変わる事実を履歴として残す設計から始めます。倉庫・ロケーション、棚卸し、権限、承認、通知を業務の流れに合わせて整理し、まずは範囲を絞ったパイロットで入力負担と在庫精度を確認します。
バーコード、集計、帳票、通知をプラグインで補える場合がありますが、導入後の更新や障害対応まで含めて管理できるかを確認します。複雑な引当、製造工程、大量データ、リアルタイム連携が中心なら、kintone単体に寄せず、専用システムや個別開発との役割分担を比較することが大切です。現状のデータと業務の境界を整理してから、作る範囲と使うサービスを決めましょう。
