kintoneのレコード番号、そのまま顧客コード・商品コードにしていい？削除で欠番になる仕組みと正しい設計

ジムリンは、Excelで管理していた顧客マスタを、kintoneのアプリに移行する作業をしていた。

Excelでは自分で連番を振ってたけど、kintoneならレコード番号が自動で出るから、これ、そのまま顧客コードにしちゃえばいいかも

たしかに、それは誰でも一度は考えるよね

でも、先輩に相談したら、それ、あとで痛い目に遭うよって言われて

いったい何が問題なのだろうか。

kintoneのレコード番号、そのまま顧客コード・商品コードにしていい？削除で欠番になる仕組みと正しい設計

Excel移行のとき、kintoneのレコード番号をそのまま業務コードにしたくならないか

Excelで顧客マスタや商品マスタを管理していたころは、新しい行を追加するたびに、連番を自分の手で振っていたはずだ。番号の付け忘れ、重複、手入力のミス。こうした細かなトラブルに、心当たりのある人も多いのではないか。

kintoneにアプリを移行すると、この悩みはあっさり解消する。レコードを新規登録するたびに、システムが自動でレコード番号を割り振ってくれるからだ。連番の管理から解放された安心感から、次のような発想に至るのは自然な流れだろう。

「このレコード番号を、そのまま顧客コードや商品コードとして使えばいいのではないか」

自分で採番の仕組みを作らなくていい。番号の重複も起きない。一見すると、合理的な判断に思える。

しかし、この発想には落とし穴がある。理由は、レコード番号という仕組みそのものの性質にある。

レコード番号は、削除すると欠番になり二度と戻らない、システムが持つ内部の連番

kintoneのレコード番号と業務コードの違いを比較した図解

kintone公式ヘルプ「レコード番号」には、レコード番号について次のように明記されている。

レコード番号は、レコードに自動で付与される番号で、変更できません。

つまりレコード番号は、レコードを作成した順に自動で割り振られる、システム内部の連番だ。ユーザーが値を指定したり、あとから書き換えたりすることはできない。

この時点で、レコード番号は「業務が意味を持たせて管理するコード」とは、性質が異なっている。

商品コードや顧客コードは、採番ルール自体に業務の意図が込められている。部門コード＋連番、日付＋連番、あるいは取引先ごとの管理番号など、企業ごとに独自の体系を持つのが普通だ。

一方でレコード番号は、そのアプリのなかでレコードを一意に指し示すための、単なる内部の参照キーにすぎない。番号そのものに業務上の意味はない。

さらに見過ごせないのが、削除にまつわる仕様だ。公式ヘルプは、削除後の挙動についてもこう説明している。

削除したレコードのレコード番号は欠番になります。

レコードを1件削除すると、そのレコード番号は二度と使われない。次に新しいレコードを登録しても、削除された番号が再び割り当てられることはなく、その番号は永久に欠番のまま残る。

欠番のまま次に進めるか、後続をすべてずらすか

この仕様が、業務上どう響くかを具体的に考えてみよう。

たとえば、テストで登録したレコードを削除したとする。レコード番号は連番のため、その1件だけが歯抜けになる。この歯抜けをそのまま放置してよいのか、それとも後続のレコードすべてを詰めるように振り直すべきなのか。判断に迷う場面は、実際の運用で少なくない。

しかも、レコード番号自体は変更できないため、「振り直す」という選択肢は、実はkintoneの標準機能だけでは実現できない。欠番を許容するか、まったく別の採番の仕組みを用意するか。どちらにしても、本来は業務側で発生しなくてよかったはずの調整が必要になる。

業務コード＝レコード番号として運用していると、欠番のたびに対応関係が崩れる場面

レコード番号を業務コードに使うと削除・再登録で対応関係が崩れる仕組み

この欠番という仕様は、レコード番号を業務コードとして使い始めた時点で、確実に表面化する問題だ。

顧客マスタのレコード番号を、そのまま顧客コードとして受発注システムや在庫管理の帳票に転記していたとする。この状態で、ある顧客のレコードを誤って登録してしまい、削除して登録し直したとしよう。新しく登録したレコードには、削除前とは異なる新しいレコード番号が割り振られる。

その結果、既存の受注データや在庫データが参照していた「削除前の顧客コード」は、もうどのレコードとも対応しなくなる。過去の取引履歴を検索しても、該当する顧客が見つからない。担当者は、いつどのタイミングで番号がずれたのかを調べるところから始めなければならない。

欠番をそのまま放置すれば、番号の抜けた箇所がいつまでも残る。かといって後続のレコードすべてを振り直せば、今度は過去に発行済みの見積書や請求書に記載された番号と、実際のレコードが食い違ってしまう。

どちらを選んでも、業務側に余計な手間を強いることになる。これが、レコード番号を業務コードとして運用してしまったときに起きる、典型的な破綻のパターンだ。

レコード番号と業務コードを分離して、専用の採番の仕組みを持つ

kintoneでレコード番号と業務コード専用フィールドを分離する設計イメージ

こうした問題を避けるには、レコード番号と業務コードを、最初から別のものとして設計する必要がある。

具体的には、商品コードや顧客コード専用のフィールドを別途用意し、そのフィールドに対して採番ルールを設定する。連番、日付＋連番、部門コード＋連番など、業務の意味を持たせた採番方式をkintone側で管理し、レコード番号とは切り離しておくのが基本の考え方だ。

レコード番号は、あくまで「そのレコードを指し示すための内部的な参照キー」として割り切り、削除・再登録のたびに新しいレコードには別の番号が割り振られるものとして扱う。この前提を最初に置いておくことが、データ設計の土台になる。

とはいえ、業務コード専用フィールドの採番ロジックを自前で実装しようとすると、連番の管理や年度単位でのリセットなど、地味に手間のかかる作業が発生する。ゼロから作り込むのは、決して簡単な作業ではない。実は、こうした採番の仕組みを無料で用意できるプラグインもある。

連番や日付＋連番といった採番タイプの選択、日単位・月単位・年単位でのリセットなど、業務コードに必要な採番ルールをアプリの設定だけで用意できるプラグインだ。自前で採番ロジックを組む前に、こうした選択肢も検討する価値がある。

レコード番号はシステムの内部連番、業務コードは意味を持つ別のコード。この考え方は、顧客コードや商品コードに限らず、注文番号や伝票番号など、業務上の意味を持たせたいコードすべてに当てはまる。最初から切り分けておくことが、削除や再登録があっても崩れないマスタ設計の基本になる。

まとめ：レコード番号と業務コードは、最初から別物として設計する

レコード番号って、そのまま使えて便利だと思ってたけど、削除したら二度と戻らない番号だったんですね。危うく、顧客コードとしてそのまま使うところでした

削除したレコード番号は欠番のまま残り、二度と割り当て直されない。この仕様を知らずに業務コードとして使い始めると、削除や再登録のたびに、既存データとの対応関係が静かに崩れていく。

レコード番号はシステムが管理する内部の参照キー、業務コードは業務の意味を持たせて管理するコード。この2つを最初から別のフィールドとして設計しておけば、削除や再登録があっても、業務データの整合性を保ったまま運用を続けられる。

業務コード専用の採番ルールをゼロから作り込む手間を省きたい方は、自動採番プラグイン for kintoneも選択肢のひとつだ。

kintoneアプリの検索・絞り込みの使い勝手をさらに改善したい場合は、kintoneの一覧画面での検索・絞り込みを効率化するには？も参考にしてほしい。

関連記事