商品コードはがんばってる。だけど、変わりたい時もある。 - アールスリーインスティテュート

公開日：2025-04-28

（更新日：2025-04-02）

こんにちは！システム開発グループのやまさです。

早速ですが、kintoneでアプリを作るとき、「このアプリのキーは何にしよう？」という検討を行うと思います。
（以下の動画でも、キーについて詳しくご説明しています。ぜひご参照ください。）

そしてそのキーを使って、他のアプリと連携させたり、レコードを検索したりといった活用をしますよね。

しかし、キーとして何を選ぶかは実はとても重要です。
慎重に選ばないと、後々後悔するかもしれません。

今回は、「キーに変更される可能性のある値を使うと困ることがある」というテーマで、商品コードを例にご説明していきます。

アプリの「キー」って何？

まず、「キー」という言葉の定義をしておきましょう。

キー（Key）とは、あるkintoneアプリ内における、レコードを一意に特定するための項目（フィールド）です。
アプリの中で「ユニークな値」となる項目ですね。

このキーは、業務の中で人が参照するだけでなく、システムの仕組みでも利用されることがあります。
例えば、以下のような用途で使われることがあります。

他のアプリとの紐づけ（ルックアップや関連レコードの設定）
カスタマイズのロジック内で、レコードを検索・特定

前者の具体的な例をあげると、得意先の情報を管理する「得意先マスタアプリ」と、得意先からの受注情報を管理する「受注アプリ」を作成したうえで、得意先マスタアプリのキーを使ってアプリ間を紐づける、というようなイメージです。

商品コードってキーに使えそう！

さて、今回の主役である、商品コードのお話です。
ここでいう商品コードとは、その名の通り「商品を特定するためのコード」のことです。
（品番　という呼び方をされることもあります）

具体例として、食料品を販売する会社における商品コードの構成を考えてみました。

商品コード構成の説明

商品名	分類名	プレフィックス	商品コードの例
りんご	果物	FRT	FRT-001
牛乳	飲料	DRK	DRK-001

「FRT」はFruit（果物）、「DRK」はDrink（飲料）の略とし、後ろの番号で個別の商品を識別する、という構成になっています。

このような商品コードは、重複せず、見た目にも意味があって業務的にも扱いやすいため、商品の情報を管理するkintoneアプリを作る際にも、キーとして利用されがちです。

例えば、以下のような商品マスタアプリを考えてみましょう。

商品マスタアプリ

商品コード	商品名	分類	価格
FRT-001	りんご	果物	500円
FRT-002	バナナ	果物	250円
DRK-001	牛乳	飲料	200円
DRK-002	コーヒー	飲料	300円

どうでしょう？いかにもありそうですし、特に問題なさそうに見えますね。

でも…商品コードは「変わること」がある

業務を行っていく中で、商品コードの命名規則を変更する、というケースがあります。
先の食料品の商品マスタの例でいうと、以下のような、分類名の変更や増減が発生した場合が該当します。

「果物」が「青果」に名称変更された
- プレフィックス「FRT」を「FAV」（Fruit and vegetables の略）へ変更
「飲料」がさらに「冷たい飲料」と「温かい飲料」に分類されるようになった
- プレフィックス「DRK」がCDRK（Cold drinkの略）とHDRK（Hot drinkの略）の2つへ変更

これらが発生すると、商品コードの変更が発生します。
そして、先ほど例にあげたような商品マスタアプリにも、商品コードの変更を反映する必要があります。

これがお困りごとの始まりになります。

商品コードをキーにすると起こる困りごと

具体例をあげて説明します。
例えば、「商品マスタアプリ」と「受注アプリ」を以下のように作っているとしましょう。
商品コードを使って、2つのアプリを紐付けているとします。

商品マスタアプリ

商品コード	商品名	分類	価格
FRT-001	りんご	果物	500円
DRK-001	牛乳	飲料	200円

受注アプリ

受注番号	商品コード	商品名	数量	合計金額
1001	FRT-001	りんご	2	1000円
1002	DRK-001	牛乳	1	200円

kintoneアプリのイメージは以下のような形です。
商品マスタアプリの関連レコードフィールドにて、受注アプリのレコードが表示されています。

ここで、「果物」の分類名が「青果」に変わった影響で、商品マスタアプリにて、商品名「りんご」のレコードの商品コードを「FAV-999」に変更したとします。

商品マスタアプリ（分類名変更後）

商品コード	商品名	分類	価格
FAV-999	りんご	青果	500円

すると、どうなるでしょう？
そうです。受注アプリとの紐づけがなくなってしまいますね。
その結果、商品マスタアプリの関連レコードに、受注アプリのレコードが表示されていません。

画面上表示されない、というだけなら、まだ我慢できるかもしれません。

しかし、もし、システムがこの商品コードを参照して何らか処理を行っているとしたらどうでしょうか。

例えば、受注アプリ上でのユーザーの何らかの操作をトリガーに、商品マスタに入力されている在庫数を減らす、という処理が自動で動いているとします。いわゆる、引当というやつです。

このとき、システムは受注アプリのレコードに入力されている商品コード「FRT-001」を使って商品マスタのレコードを特定した上で、在庫数を減らそうとします。
しかし、商品マスタ側で商品名「りんご」のレコードの商品コードが「FAV-999」に変わっているため、在庫数を減らすべき商品マスタのレコードが見つかりません。
結果、在庫数を減らす、ということができなくなってしまいます。

もし、受注アプリ側に入力されている商品コードの値も、「FAV-999」へ変えることができるならば、システム側の観点では解決できます。
しかし、業務側の都合でそれはできない、ということがあります。
例えば、後々得意先から問合せが来たときのために、受注時の商品コードを残しておきたい、というような場合、受注アプリの商品コードの値を変えることはできません。

このように、既存レコードの商品コードの値を変えることが難しい場合があります。

じゃあ新しいレコードを追加しよう！…それも落とし穴

商品マスタアプリの既存のレコードの商品コードを変えると影響が大きいため、新しい商品コードで別のレコードを作る、という対応もありがちです。以下のようなイメージです。

商品マスタアプリ（更新後）

商品コード	商品名	分類	価格
FRT-001	りんご（旧）	果物	500円
FAV-999	りんご（新）	青果	500円

しかし、この方法にも課題はあります。

在庫数の振り分けをする必要がある

例えば、りんごの在庫が100個あったとしましょう。
商品コード変更により「FRT-001」と「FAV-999」の2つのレコードに分かれた場合、それぞれに在庫数をどう配分するかを考えなければいけません。

在庫管理の例

商品コード	商品名	在庫数
FRT-001	りんご（旧）	40
FAV-999	りんご（新）	60

このように分割することが必要になりますが、受注の状況に応じてそれぞれの在庫数を割り振る、といった判断が煩雑になり、運用ミスの原因にもなります。

集計時の困難さ

例えば、「りんごの売上を過去3年間で集計したい」というとき、FRT-001とFAV-999両方を調べる必要があります。
商品コードの変更頻度および変更が発生した商品の数が少ないうちは手作業でも対応できますが、数が増えると現実的ではありません。
ちなみにこの集計の話は、先に記載した既存レコードの商品コードの値を変えた場合も同様に発生する課題です。

以上のように、新しい商品コードで別のレコードを作る、という案にも課題はありそうです。

では、どうすれば良いのか？

答えはシンプルです。

キーは「変更されない値」を使いましょう。

今回の例でいうなら、商品コードとは別の項目を設けて、そちらをキーとして利用しましょう。
このとき、キーの値はただの連番のような形にしておくのがオススメです。
というのも、変更が発生する可能性を低くするためです。

先程の商品マスタアプリを例にすると、「商品ID」のような項目を設けてキーとして使いましょう。

商品マスタアプリ（改善案）

商品ID	商品コード	商品名	分類	価格
001	FRT-001	りんご	果物	500円
002	DRK-001	牛乳	飲料	180円

受注アプリ（改善案）

受注番号	商品ID	商品名	数量	合計金額
1001	001	りんご	2	1000円
1002	002	牛乳	1	180円

このようにしておくと、商品コードが運用の中で変更されても、システム側への影響をなくすことができます。

商品マスタアプリ（商品コード変更後）

商品ID	商品コード	商品名	分類	価格
001	FAV-999	りんご	青果	500円
002	DRK-001	牛乳	飲料	180円

受注アプリ

受注番号	商品ID	数量	合計金額
1001	001	2	1000円
1002	002	1	180円

商品マスタアプリと受注アプリは商品IDで紐づいているので、商品コードが「FRT-001」から「FAV-999」に変わっても、アプリ間の紐づけやレコードの特定に影響がありませんね。

ちなみに、上の受注アプリの例には記載していませんが、商品コードは受注アプリ上に項目として配置しても問題ないです。
ただし、あくまで業務上参照するための項目として活用するようにしましょう。
システムが参照するのは、商品IDの方にしましょう。

他にもある、変わるかもしれない「xxコード」

商品コードのように、「xxコード」という名前をした、実は変わるかもしれない項目は多くあります。

例

項目名	変更が発生するきっかけ
得意先コード	会社名の変更、合併
部署コード	部署名の変更、統廃合

これらも、運用の中で変更が発生する可能性があるので、システム的にキーとして使うのは避けたほうがよいですね。
「xxコード」という名前をしているので、一見キーに使えそうですが…要注意です。
最初にアプリを作る段階で、実は変更が発生する可能性があるのでは？と慎重に考えるのがポイントです。

まとめ

商品コードはがんばってます。
画面や帳票など、色々なところに出されて人にジロジロ見られたり、システム内でも詮索検索されたりと。私だったら耐えられません。
せめてキーの役割ぐらいは、他の項目に担ってもらってもよいのではないでしょうか。

今回の記事が、皆様のお役に立てれば幸いです。

キミノマホロ for kintone

アールスリーでは業務改善・システム開発を行うサービスを「キミノマホロ for kintone」として提供しています。
「キミノマホロ for kintone」は業務改善のプロセスをイロハで3つのフェーズに分け、フェーズごとに作業をメニュー化しています。
　　【イ】業務改善の始まり：業務改善の方向性を決める
　　【ロ】業務改善に必要なkintoneアプリ作成：業務改善を実現するための仕組み（kintoneアプリ）を作る
　　【ハ】業務改善の実行サポート：業務改善を進める

今回の記事のようなお話は、「【ロ】業務改善に必要なkintoneアプリ作成」にて考慮する内容となります。
お客様の業務や、今回の記事のような内容を考慮しながら、kintoneアプリの設計や開発を弊社にて実施したり、お客様の作業をサポートする、といったことを行っております。

また、システム開発グループではkintoneに関するお悩み相談をお受けする「kintone駆け込み相談室」を随時開催しています。kintoneのシステム開発でお悩みの方がいらっしゃいましたらぜひお申し込みください！

投稿者プロフィール

やまさ: システム開発グループで働いています