kintoneで在庫管理アプリをはじめて作るときの基本構成
在庫管理をExcelや紙の台帳で回している現場では、入出庫のたびに手集計をして、拠点や担当者ごとに数字が微妙に合わなくなっていく、という悩みをよく聞きます。「本社の在庫表と倉庫の実数が合わない」「担当者によって集計のタイミングがバラバラで、いつの時点の数字か分からなくなる」といった声は珍しくありません。
kintoneで在庫管理アプリを検討し始めた担当者が最初につまずくのは、実は同時更新のような技術的な問題ではなく、「何から作ればいいのか」という設計の入口そのものです。とりあえずフィールドを並べて動くものは作れても、運用が始まってから数字が合わなくなり、結局Excelでの二重管理に逆戻りしてしまう——という失敗パターンが典型的です。
基本になるのは、次の2つの要素です。
- 品目マスタ: 品番・品名など、扱う商品や資材の基本情報を持つアプリ
- 入出庫の記録: 入庫・出庫が起きるたびに記録を残し、そこから在庫数を導き出す仕組み
このとき最初の分かれ道になるのが、「在庫数」という1つの数字を入出庫のたびに直接書き換えていく設計にするか、入出庫のたびに記録を積み上げてそこから在庫数を計算する設計にするか、という選択です。前者は一見シンプルですが、複数人が同時に使う環境では次章で説明する壁にぶつかります。この記事では、なぜ直接書き換え型の設計が破綻しやすいのかという理由から、実際にどう設計すれば安定して運用できるかまで、品目マスタ・入出庫記録・在庫数集計という基本フィールド構成に沿って順を追って解説します。
在庫数を直接更新する設計が招く、同時更新エラーという壁
前章の「直接書き換え型」を選んだ場合、多くの現場が壁にぶつかるのが更新の競合エラーです。複数人がほぼ同時に同じ在庫レコードを更新しようとすると、最初に保存できたのは1人だけで、残りのユーザーには「レコードを再読み込みしてください。編集中に、ほかのユーザーがレコードを更新しました。」という更新の競合エラーが表示されます。kintoneには、レコード編集中に他ユーザーの編集をロックする機能自体が存在しません。
複数拠点や複数担当者が同じ在庫アプリを日常的に触る環境では、この競合エラーは「たまに起きる不具合」ではなく「構造上いずれ起きる現象」だと考えたほうが実態に近いです。「棚卸のたびに数字が合わない」「結局Excelで在庫を二重管理するようになってしまった」という声の背景には、この仕様があることが少なくありません。
なぜ在庫数の直接編集は破綻するのか
競合が起きる根本的な理由は、「在庫数」という1つのフィールドを、入庫のたびに出庫のたびに書き換え続けるという設計そのものにあります。この「同じレコードを取り合う」構造がある限り、担当者が増えるほど競合の発生頻度も上がります。複数人での入力ルール定着については、kintone日報アプリの作り方と運用定着のコツも参考になります。
サイボウズが公式に案内している対策の一つに、レコード取得時のリビジョン値を更新APIに指定し、他ユーザーの変更があれば更新をキャンセルする技術があります。ただしREST APIとJavaScriptによる追加開発が前提のため、標準の画面操作だけで運用したい現場では採用のハードルが高くなります。
そこで発想を変えます。「在庫数フィールドを書き換える」のではなく、「入出庫のたびに新しいレコードを追加する」設計にすると、複数人が同時に操作してもそれぞれが独立した新規レコードを追加するだけになり、「同じレコードを取り合う」状況が発生しにくくなります。現在庫は、特定の1レコードが持つ数値ではなく、積み上がった明細レコードを都度合計した結果として求める形になります。
これは公式ドキュメントの仕様から導いた設計上の考え方であり、「レコード追加なら競合が絶対に起きない」と保証されているわけではありません。それでも、在庫数を直接書き換える設計に比べれば、競合が発生する条件は大きく減らせます。
正解の設計: 入出庫トランザクション型+集計レポート
具体的な作り方は、次の2アプリ構成です。
- 品目マスタ: 品番・品名などの基本情報を持つアプリ
- 入出庫明細: 入庫・出庫のたびに1レコードずつ追加していくトランザクションアプリ
入出庫明細アプリのフィールドは、次のように設計します。この構成表がフィールド型の唯一の基準です。
入出庫明細アプリのフィールド構成
| セクション | フィールド | 型 |
|---|---|---|
| 基本情報 | 品番、品名 | 文字列(ルックアップ) |
| 基本情報 | 処理日、担当者 | 日付／ユーザー |
| 入出庫情報 | 区分 | 選択肢(入庫／出庫) |
| 入出庫情報 | 数量 | 数値 |
| 集計用 | 符号付き数量 | 計算(数値表示) |
| 管理 | ステータス、備考 | 選択肢／複数行 |
品番・品名は品目マスタからのルックアップ(別アプリのレコードを検索し、指定したフィールドの値をコピーする機能)で呼び出します。コピーされた値が品目マスタ側の変更に自動で追従するかどうかは確認できていないため、明細に記録される品名は入出庫時点のスナップショットとして扱うのが安全です。
数量フィールドの設定で押さえておきたいのは「値の制限」です。フィールドの設定パネルで最小値を0に指定すれば、マイナスの数量そのものを入力できなくできます。出庫は数量を負にするのではなく、区分(入庫／出庫)という選択肢で表現します。
数量フィールドの設定内容
| 設定項目 | 値 |
|---|---|
| フィールドタイプ | 数値 |
| 値の制限(最小値) | 0 |
そのうえで、符号付き数量という計算フィールドを用意し、次の式で自動計算させます。
IF(区分 = "出庫", -数量, 数量)IF関数は「IF(条件式, 真の場合の値, 偽の場合の値)」という書式です。区分の値が「出庫」かどうかを=で判定し、出庫のときだけ数量の符号を反転させます。この式によって、出庫は自動的にマイナスの数量として記録され、あとは合計するだけで現在庫を導けます。数値フィールドを設定なしのまま使うとマイナスを入力できるかどうかは公式の記載が見当たらないため、この設計では最小値の制限と計算フィールドの組み合わせで、その不確定要素に依存しない形にしています。
現在庫を見るには、入出庫明細アプリでグラフ(レポート)を作成します。在庫集計に使うには、次の3か所を設定します。複数データの集計表示については、進捗管理ダッシュボードの設計も参考になります。
グラフの設定内容(在庫集計用)
| 設定項目 | 値 |
|---|---|
| グループ化項目(大項目) | 品番 |
| 集計方法 | 合計 |
| 対象フィールド | 符号付き数量(数値の計算フィールド) |
グループ化項目を「品番」、集計方法を「合計」、対象フィールドを「符号付き数量」に設定すれば、品番ごとの合計が一覧できます。集計方法は「レコード数」「合計」「平均」「最大値」「最小値」の5種類のみで、入庫合計と出庫合計を別々に出して差分を取るような計算はこの集計方法だけでは表現できません。符号付き数量という1つの数値フィールドに正負をあらかじめ織り込んでおくのは、この制約を回避するための工夫です。
この時点では、ステータスを問わずすべての明細が合計に含まれます。未承認の申請中明細も現在庫の数字に反映されるため、この扱いは次の章で説明します。関連レコード一覧フィールドには集計機能がないため、現在庫の確認はこのグラフ経由になります。
ここまでの設計は、フィールドの型設計・値の制限・計算式・グラフの集計軸を一つずつ組み合わせる作業になるため、最初は迷うところも多いはずです。ここでつまずいたら、無料相談で画面を見ながら一緒に確認できます。
承認フローで統制する
入出庫明細を誰でも自由に追加・修正できる状態のままにしておくと、今度は「本当に出庫した数量なのか」というデータの信頼性の問題が出てきます。ここでプロセス管理を使い、申請・承認の統制を加えます。進捗管理にステータスを使うkintone案件管理アプリの作り方｜基本フィールドと進捗管理のように、ステータスを中心に業務フローを設計することで、並行処理の統制が可能になります。承認フローに担わせる役割は、明細の集計そのものを絞り込むことではなく、承認が済んだ数字を誰にも書き換えさせないことの一点に絞ります。
設定手順は次の流れです。
- アプリの設定でプロセス管理を有効にする
- ステータスは初期値の「未処理」「処理中」「完了」をそのまま使います(名称は変更できますが、この記事では変更しません)
- 各ステータスにプロセスを設定する(作業者、アクションが実行できる条件、アクション名、実行後のステータス)。未処理→処理中のアクション名を「処理開始」、処理中→完了のアクション名を「完了する」に設定します
- プロセスのフロー図で流れを確認する
- アプリを更新する
ステータス名は初期値のまま、アクション名だけ「処理開始」「完了する」とすることで、担当者が申請し上長が承認する、という業務の流れがそのまま画面に表れます。
承認済みの数字を書き換えさせない仕組みは、**計算フィールドではなく「アプリのアクセス権」**で作ります(先ほどの符号付き数量のような計算フィールドの条件式で、プロセス管理のステータスを直接参照する方法は使いません)。アクセス権の設定で、条件を「ステータスが完了を含む」、対象レコードの権限を「閲覧のみ」にすれば、いったん承認された明細は数量を含めて編集・削除ができなくなります。未処理・処理中の間はまだ誰でも修正できる状態のままです。
ここで押さえておきたいのは統制できる粒度です。kintoneの標準機能には、特定のステータスになったときに数量フィールドだけを編集不可にする、フィールド単位の制御はありません。実現できるのは、ステータスの条件と組み合わせた「レコードのアクセス権」による、レコード単位の権限制御です。「承認済みの明細だけ数量欄がロックされる」のではなく、「完了した明細はレコード全体が編集不可になる」という粒度で理解しておくと、設計時の期待値のずれを防げます。
棚卸などで現在庫を確定値として扱いたい場面では、未処理・処理中の申請が残っていないかも合わせて確認する運用ルールにしておくと安全です(前章のとおり、これらもグラフの合計には含まれています)。
プロセス管理とアクセス権の設定内容
| 区分 | 設定項目 | 内容 |
|---|---|---|
| プロセス管理 | ステータス | 未処理、処理中、完了(初期値のまま変更しない) |
| プロセス管理 | アクション | 処理開始(未処理→処理中)、完了する(処理中→完了) |
| アクセス権 | 条件 | ステータスが完了を含む場合は閲覧のみに設定 |
自作 vs テンプレート
ここまで組み立ててきた「在庫数を直接編集させず、申請から承認を経て在庫に反映する」設計は、いわば申請フロー型と呼べる仕組みです。フィールドの型設計・値の制限・計算式・グラフの集計軸・プロセス管理という要素を一通り自分で組み合わせれば、プラグインやJavaScriptを使わず標準機能だけで再現できます。
一方で、「設計の考え方は理解したが、フィールドの組み合わせや計算式を試行錯誤する時間が取りにくい」という場合は、同じ設計思想をあらかじめ形にしたテンプレートを使う選択肢もあります。当社の「在庫管理スターターパック」は、品目マスタと入出庫申請の2アプリ構成で、この記事で解説した申請フロー型の設計をベースに、在庫数を直接編集させず申請→承認→在庫反映というプロセス管理まで設定済みの状態で提供しています。
自作とテンプレートの比較
| 項目 | 自作 | 在庫管理スターターパック |
|---|---|---|
| 設計 | この記事を参考に自分で組む | 申請フロー型を設計済み |
| 価格 | 0円(自分の作業時間はかかる) | ¥9,800(買い切り) |
| プラグイン・JS | 不使用(本記事の設計) | 不使用 |
自作するかテンプレートを使うかは、社内にkintoneの設計に慣れた担当者がいるかどうかと、かけられる時間次第です。開発パートナーに相談する場合は、外注の際のチェックリストも参照ください。詳しい構成は在庫管理スターターパックのページで確認できます。
まとめ
kintoneで在庫管理アプリをはじめて作るときの基本は、品目マスタと入出庫記録という2アプリ構成で、在庫数を1つのフィールドとして直接書き換えない設計にすることです。入出庫のたびに新しいレコードを積み上げるトランザクション型に変え、現在庫はグラフ(レポート)の集計で導く設計にすれば、複数人が同時に操作しても競合が起きにくい状態を作れます。
そこにプロセス管理による申請・承認のステップと、完了レコードを閲覧のみにするアクセス権を組み合わせれば、承認済みの数字を誰にも書き換えられない状態で運用できます。ただし集計の対象はステータスを問わず全明細のままなので、未処理・処理中の申請が残っていないかは運用側で確認する必要があります。
自分の環境で一つずつ組んでみるか、設計済みのテンプレートから始めるかは、社内の体制と時間次第です。どちらのルートを選んでも、品番ごとの現在庫をグラフの集計から確認できる仕組み自体は組み立てられます。ただし、棚卸のたびに数字が合わないという状態が実際に減るかどうかは別の問題です。入出庫のたびに明細を登録し承認を通すという入力ルールを現場に定着させられて初めて、その効果は現れます。まずはこれから作る、あるいは今使っている在庫アプリが、在庫数を直接書き換える設計になっていないか、一度見直してみてください。
