在庫と原価の話は、kintoneの検討で最も判断が割れるところです。「できる」と言う人も「できない」と言う人も、それぞれ違う業務を思い浮かべています。
分かれ目は、扱っている在庫が「記録するもの」なのか「計算するもの」なのかにあります。入出庫を記録して残数を見るだけなら記録の仕事です。引当、ロット、配賦が入ると計算の仕事になります。以下では、この境目を具体的に置きます。
在庫管理で、乗り換えなくていい条件とは？
拠点が1つで、入出庫をその都度記録するだけの台帳なら、kintoneの標準機能のままで運用できます。
次の条件がすべて当てはまるなら、在庫のためにkintoneをやめる理由はありません。
- 在庫を置いている場所が1か所で、同じ品目のレコードを同時に触る人が複数いない
- 受注時点で在庫を押さえる「引当」の仕組みを必要としていない
- ロット番号やシリアル番号で、どの個体がどこへ出たかを追う必要がない
- 在庫の金額は月次で会計側が計算しており、システムに原価を持たせていない
- 会社で定めた頻度で棚卸でき、差異の原因と修正履歴を台帳に残せる
この形の在庫管理は、品目マスタと入出庫の記録という2つのアプリで組み立てられます。kintoneが得意とする領域そのもので、専用パッケージに移しても得られるものは多くありません。
現場では、どこで最初につまずくのか？
同じ在庫を2か所から触ったときです。片方の保存が通り、もう片方はエラーになって内容が残りません。
具体的な場面で考えてみてください。本社の出荷担当が、ある品目の在庫レコードを開いて「受注分として20を引き当てる」と入力し、保存ボタンを押す前に確認のため電話をかけています。その数分の間に、別拠点の担当者が同じレコードを開き、入荷分として在庫数を書き換えて保存しました。本社の担当者が電話を終えて保存すると、エラーが表示されます。
これは不具合ではなく、仕様として公表されている挙動です。kintoneヘルプによると、複数のユーザーが同時に同一レコードを編集した場合、最初に保存したユーザーの操作が優先され、あとから保存しようとしたユーザーにはエラーが表示されて編集内容を保存できません。同じページには、同一レコードの編集画面をほかのユーザーが開けないようにロックすることはできない、とも記載されています。
問題は、エラーが出ること自体ではありません。エラーを見た担当者が、入力し直すのではなく「手元のメモで進めて、あとでまとめて入れる」という運用を始めることです。この時点で、システム上の在庫数と現物の在庫数がずれ始めます。棚卸のたびに差異が出るのに原因が特定できない、という状態の多くはここから来ています。
在庫を複数拠点で同時に更新する業務では、後から入力した側をどう扱うかを設計で決める必要があります。kintoneの標準機能には、この「決め方」を持たせる場所がありません。
複数倉庫や引当が入ると、何が変わるのか？
在庫が1つの数から、状態を持つ数の集まりに変わります。表の1セルでは表せなくなります。
単純な台帳では、在庫は「いまいくつあるか」という1つの数です。ところが業務が広がると、同じ品目の在庫が次のように分かれます。
| 増える要素 | 在庫の数え方がどう変わるか |
|---|---|
| 複数倉庫 | 場所ごとの数と、全社合計の数を別々に持つ必要が出る |
| 引当 | 実在庫、引当済、引当可能の3つを区別しなければならなくなる |
| ロット・シリアル | 同じ品目でも個体ごとに履歴を持ち、出庫時にどれを出したかを記録する |
| 有効期限・先入先出 | 出庫の対象を、システム側が順序で決める必要が出る |
| 棚卸差異 | 帳簿上の数と実地の数を並べ、差の理由を記録して調整する仕組みが要る |
| 移動中在庫 | 拠点間を輸送中の在庫を、どちらの拠点にも属さない状態として持つ |
kintoneでこれらを表そうとすると、アプリを増やして関連レコードでつなぐ設計になります。表現できないわけではありません。ただし、引当可能数のようにその都度の計算で決まる値を、レコードの更新と矛盾なく保つ仕組みは標準機能にないため、追加開発で作り込むことになります。
kintoneヘルプの制限値一覧には、テーブルについて「1つのテーブルにつき、10フィールドかつ100行までを目安としたご利用をおすすめします」と記載されています。ロット単位の明細をテーブルで持つ設計は、この目安に早く到達します。設計時に確認しておく項目です。
原価計算は、なぜ在庫の記録より重いのか？
集計の段階が決まっているためです。費目ごと、部門ごと、製品ごとと順に積み上げる必要があります。
在庫の記録は「入った、出た、残った」の3つで完結します。原価計算はそうなりません。企業会計審議会の原価計算基準によると、実際原価の計算においては、製造原価は原則としてその実際発生額を、まず費目別に計算し、次いで原価部門別に計算し、最後に製品別に集計するとされています。つまり3段階の集計が前提です。
棚卸資産の評価方法については、企業会計基準第9号「棚卸資産の評価に関する会計基準」が企業会計原則と原価計算基準より優先して適用されます。現在の同基準が示す方法は、個別法、先入先出法、平均原価法（総平均法または移動平均法）、売価還元法です。旧来の原価計算基準に記載が残る後入先出法を、現在の選択肢として扱うことはできません。
2つの基準には、実務で設計上の分岐になる規定が置かれています。
- 材料の実際の消費量は原則として継続記録法によって計算し、それが困難なものや必要のないものについてはたな卸計算法を適用できる
- 棚卸資産の評価方法は、事業や資産の種類・性質・使い方を考慮した区分ごとに選び、継続して適用する
- 部門共通費は、適当な配賦基準によって関係各部門に配賦する
- 総合原価計算では、仕損の費用は原則として仕損費の費目を設けず、その期の完成品と期末仕掛品に負担させる
ここで効いてくるのは、どれを選ぶかが会社ごとに違い、しかも後から変わることです。移動平均法を採るなら、入荷のたびに単価を計算し直し、その時点の在庫評価額を保つ必要があります。配賦基準を変えれば、過去の集計をどう扱うかという問題が出ます。
kintoneの計算フィールドは、同じレコードの中の値をもとに計算する仕組みです。複数レコードにまたがる集計を、段階を追って保持し続ける用途には向いていません。実現するなら追加開発になり、その追加開発は業務側の変更のたびに手を入れる対象になります。在庫の記録と原価の計算を、同じ難易度で語らないほうがよいのはこのためです。
標準機能・追加開発・外部システムの境界はどこにあるのか？
3つに分かれます。記録は標準機能、単純な自動化は追加開発、状態と配賦を伴う計算は外部です。
「kintoneでは在庫管理できない」という言い方は正確ではありません。どこまでを標準機能で持ち、どこからを外に出すかという線引きの問題です。編集部の整理は次のとおりです。
| 業務 | 標準機能 | 追加開発（プラグイン・JavaScript） | 外部システムに置く |
|---|---|---|---|
| 品目マスタの管理 | 向く | — | — |
| 入出庫の記録と残数の表示 | 向く | — | — |
| 単一拠点の発注点アラート | 条件次第 | 向く | — |
| 複数倉庫の在庫と拠点間移動 | 難しい | 条件次第 | 向く |
| 受注時の引当と引当可能数 | 難しい | 条件次第 | 向く |
| ロット・シリアルの追跡 | 難しい | 条件次第 | 向く |
| 棚卸差異の記録と調整履歴 | 条件次第 | 向く | 条件次第 |
| 移動平均法などによる在庫評価 | 難しい | 難しい | 向く |
| 費目別・部門別・製品別の原価集計 | 難しい | 難しい | 向く |
「条件次第」と書いた行は、拠点数、品目数、同時に触る人数によって答えが変わります。入出庫のたびに競合が起きていないか、月次締めまでに手作業がどれだけ残るかを実測して判断してください。
この表を見るときに大事なのは、右へ行くほど良いわけではないことです。外部システムに置けば、kintoneとの間でデータを合わせる仕事が新しく発生します。困っていない業務まで外に出す理由はありません。
分けるかどうかの判断の目安は？
自社で記録した差異、保存競合、締め作業の数値から、分けるべき処理を絞り込みます。
「差異が6か月出たら移行」のような共通基準はありません。許容できる差異は、品目の単価、会計方針、欠品時の影響で変わるためです。次の数値を月ごとに残し、自社で許容値と確認責任者を決めます。
| 見るもの | 記録する数値 | 判断のしかた |
|---|---|---|
| 棚卸差異 | 品目ごとの差異数・差異額、原因不明の件数 | 自社の許容値を超えた品目と工程を特定し、入力漏れか計算の問題かを分ける |
| 同時更新 | 保存エラーの件数、入力し直した時間、発生した拠点 | 実在庫がずれた原因に保存競合が含まれるなら、更新の仕組みを見直す |
| 原価計算 | 月次締めにかかった日数、表計算での補正件数、再計算の回数 | 締めの遅れや補正がどの計算段階で生じたかを追う |
| 引当 | 手元の表への転記時間、kintoneとの不一致件数 | 二重管理をなくすため、どちらを正とするかを決める |
記録しただけで移行を決めず、まず入力手順と設定を変え、同じ数値が戻るかを確かめます。それでも許容値を超える工程だけを、外部システムへ出す候補にします。
在庫以外の切り口——改修の頻度や年間の総コストで測りたい場合は、kintoneの限界はどこか？レコード数・連携・改修費で判断するに判断材料をまとめています。
在庫と原価だけを分ける進め方は？
5段階で進めます。数字の正を決め、範囲を切り、参照だけをつなぎ、書き込みを移し、最後に運用を戻します。
- どの数字をどちらが正とするか決める。 在庫数と在庫評価額を外部システムの側で持つのか、kintoneの側で持つのかを先に決めます。ここが曖昧なまま進めると、両方に数字がある状態になり、現場はどちらを見ればよいか分からなくなります
- 移す範囲を1つの商流に絞る。 全品目を一度に移さず、拠点や品目群を1つ選びます。引当やロットの要件が最も強く出ている範囲を選ぶと、設計の妥当性を早く確かめられます
- まず参照だけをつなぐ。 外部システムの在庫数を、kintoneの画面から見られるようにします。この段階では書き込みを行わないため、失敗しても業務は止まりません
- 書き込みを外部システムへ移す。 入出庫の登録を外部システム側に切り替え、kintoneは参照のみにします。切り替え前に、旧来の入力経路を閉じる日を決めておきます
- kintone側のアプリと権限を整理する。 使われなくなったアプリを残すと、古い数字を見て判断する人が出ます。残すもの、閲覧のみにするもの、閉じるものを分けます
3番目と4番目の間には、両方の数字を並べて突き合わせる期間を置いてください。差が出る原因のほとんどは、移行前の未処理データと、システムの外で行われていた調整です。この期間の設計と切り戻しの決め方は、kintoneを捨てずに移行できるか？API連携から始める段階刷新で詳しく扱っています。
分けた場合、費用はどこが変わるのか？
3か所です。連携の実行回数、保存容量、そして取引先へ見せる場合のユーザー分が変わります。
外部システム側の費用は製品によって異なるため、ここではkintone側で変わる部分だけを、公表されている値で示します。サイボウズの料金ページには、オプションとして連携コネクタが月額0円（3,000ステップまで、3,001ステップ以上の利用は有料）、ディスク増設が10GBあたり月額1,000円、ゲストユーザーがライトコース700円・スタンダードコース1,440円（いずれも税抜、1ユーザーあたり月額）と記載されています。標準のディスク容量は5GB×ユーザー数と示されています。
在庫の連携は、この「ステップ」の数え方に影響を受けます。入出庫が発生するたびに双方向で同期する設計にすると、実行回数は取引量に比例します。1日あたりの入出庫件数が多い業務では、無償枠の範囲に収まるかを設計段階で確認してください。
APIで直接つなぐ場合は、別の枠を見ます。同じ料金ページには、1アプリごとのAPIリクエスト数がスタンダードコースで1日1万、ワイドコースで1日10万と記載されています。kintoneヘルプの制限値一覧には、1日のAPIリクエスト数は日本時刻で毎日午前9時にリセットされること、REST APIの同時アクセス数は1ドメインにつき100までで、超えるとHTTPステータスコード429が返ることが記載されています。
保存容量は、在庫を外に出すと逆にkintone側で減ることがあります。一方で、外部システムから戻した集計結果を履歴として持つ設計にすると、レコード数は積み上がります。どちらに振れるかは設計次第なので、初期の見積では「変わらない」と置いて、稼働後に実測するのが安全です。
判断の入口に戻る場合は、kintoneから乗り換えるべきか？限界・費用・移行方法を判断するを参照してください。自社の在庫業務のどこまでをkintoneに残せるか整理したい場合は、お問い合わせからご相談ください。