同じ商品が2つ登録されていた。ハイフン1つで、会社が赤字を垂れ流していた話
前職で、背筋が凍った経験があります。
総合商社にいた頃の話です。扱っていた商品は何万点。私はその商品マスタを整備していました。
ある日、メーカーごとに商品を抽出して、品番順に並べ替えていました。特に何かを疑っていたわけではありません。ただの確認作業です。
眺めていて、ふと思いました。
これ、似てないか？
同じ商品が、2つ登録されていた
見比べてみると、同じ商品でした。違うのは品番の書き方だけ。
片方はハイフンあり、もう片方はハイフンなし。
登録した人が違うだけの話です。悪気なんてどこにもない。ある人はメーカーの表記通りに入れ、ある人はハイフンを省いて入れた。それだけです。
でも、システムから見れば別商品です。
問題は、そこからでした
当時はコロナ禍と物価高騰の真っただ中。メーカーから価格改定の案内が次々と届き、こちらも売価を見直していました。
そこで何が起きていたか。
片方の品番だけ、価格改定が反映されていました。
もう片方は、古い安い価格のまま残っていた。
結果どうなるか。お客様は当然、安いほうを選びます。改定前の赤字価格のまま、注文が増えていました。
これに気づいたときは、正直ビビりました。
一番怖いのは、気づけないこと
さらに悪いことがあります。
集計しても、別商品として計上されるんです。
売れ筋を出しても、2つに割れる。粗利を見ても、片方は黒字、片方は赤字で、実態がぼやける。
つまり、現場では損が出ているのに、数字を見ても分からない。
データが壊れているのではありません。正しく集計した結果が、間違っている。 判断の材料そのものが腐っている状態でした。
しかも、誰も気づけません。システムはエラーを出しません。誰かが報告してくれるわけでもない。私がたまたま並べ替えて、目で見たから見つかっただけです。
掘ったら、もっと出てきた
気になって、今度は商品名でも並べ替えてみました。
すると、品番が入っていない商品が出てきたんです。
理由はすぐ分かりました。品番が分からなかった人が、とりあえず登録していた。
これも悪意ではありません。むしろ逆で、仕事を止めないための善意です。目の前に注文があって、商品を登録しないと処理が進まない。だから空欄のまま入れた。
ルールがなかっただけです。
そうやって、同じ商品が2件どころではない状態になっていました。
ここから、私の考え方が変わりました
どう直すべきか、相当考えました。そして、そのとき自然と身についたのがデータベース思考でした。
大事なのは、「これはこの1件だ」と一意に確定できる印を、必ず持たせること。
いわゆるユニークコードです。地味です。派手さは全くありません。でも、あるとないとでは管理工数が劇的に変わります。
実際にやったこと
1. 独自の管理コードを持たせた
まず、自社で管理するための独自コードを商品ごとに振りました。
形式は3桁ハイフン4桁。前半3桁がメーカー、後半4桁が登録順の連番です。
メーカー品番は、メーカーの都合で変わります。統廃合もあります。外部の都合で変わるものを、自社の管理の軸にしてはいけない。
そして独自コードがあると、他のマスタとの連携が一気に楽になります。取引先の管理コード、他社の管理コード、そういったものと紐づけていける。軸が1本通ると、周りが繋げられるようになる。
ちなみに、間にハイフンを入れたのには理由があります。
数字だけの並びにすると、数値として扱われてしまうからです。
ExcelやスプレッドシートにIDを出したとき、数値と解釈されると先頭のゼロが消えたり、勝手に書式が変わったりします。ハイフンを1つ挟むだけで、文字列として扱われる。
重複の原因はハイフンでした。でも、ハイフンが悪いわけではありません。悪いのは、表記が揺れることです。 自分で決めたルールとして必ず入れるなら、ハイフンは味方になります。
なお、ここはエンジニアの方から見ると議論が分かれる部分だと思います。
IDに意味を持たせると、メーカーが統廃合したときにどうするのか、という問題が出ます。本来はIDを意味のない連番にして、メーカーは別の項目で持つのが定石です。
私は、その場合は旧コードを廃盤にして、新しく採番する運用にしました。
コードは書き換えません。書き換えたら、過去の取引履歴との紐付けが壊れるからです。一度振ったIDは、変えない。 状態のほうを変える。
この形にしたのは、人が扱うマスタだったからです。 コードを見た瞬間にメーカーが分かる。この可読性が、現場では想像以上に効きました。
正解は現場によって変わります。ただ、判断した理由だけは説明できるようにしておいたほうがいい。 そう思っています。
2. ハイフンあり・なしの両方を管理対象にした
メーカー品番については、ハイフンありとなしの両方を登録対象にしました。
どちらか一方に統一しようとしても、人は間違えます。だったら両方持たせて、どちらで検索してもヒットするようにしたほうが確実です。
3. 登録前に、必ず検索を挟んだ
ここが一番効きました。
新しく商品を登録するとき、まず検索を走らせるロジックを入れました。既に存在していないかを、登録の前に必ず確認させる。
重複を後から探すのではなく、そもそも生まれないようにする。
4. 品番がない商品にもルールを作った
品番が存在しない商品は、どうしても出てきます。
そういうものは、仕入先・メーカー・商品名の3点で重複がないかを必ず確認する仕組みにしました。
「分からないから空欄」を、許さない構造にしたということです。
これから作る人へ、先に言っておきたいこと
もしあなたがこれから何かのデータを扱うなら、最初にユニークコードを決めてください。
商品でも顧客でも案件でも構いません。「これはこの1件だ」と確定できる番号を持たせる。そして、システムからエクスポートするときも、必ずそのコードを一緒に出す。
ここを面倒くさがると、後で泣きます。
インポートやアップデートのときに、絶対必要になるからです。名前や日付で突き合わせようとすると、表記ゆれ、重複、微妙な差分で必ず事故ります。
そして誰がエクスポートしたデータでも、コードさえ通っていれば最終的に更新できます。 これは実務で本当に効きます。
もう一つ、地味だけど致命的な落とし穴
最後に、実務で必ずぶつかる話をひとつ。
先頭に0がつくコードは、文字列で扱ってください。
品番「0012」をExcelやスプレッドシートに出した瞬間、「12」になります。数値として解釈されるからです。
これ、気づかないうちに起きます。そして気づいたときには、突き合わせが全部ずれている。
コードを設計する段階で、文字列として扱うことを前提にする。 ここは絶対に妥協しないほうがいいです。
まとめ
ユニークコードがないと、同じものが複数登録される
気づかないうちに、片方だけ古い情報のまま残る
集計しても別物として計上されるので、異常に気づけない
独自コードを軸に持ち、外部の都合で変わるものを軸にしない
一度振ったIDは変えない。変わったら廃盤にして、新しく振る
重複は探すのではなく、登録前の検索で生まれないようにする
先頭ゼロがあるコードは、必ず文字列として扱う
派手な話ではありません。誰も褒めてくれません。
でも、ここを設計できるかどうかで、後の管理工数が本当に劇的に変わります。
前回の記事で「ツールを入れる前にやることがある」と書きました。この「ユニークコードを決める」は、まさにその手前の作業です。
ここが崩れていると、上に何を乗せても崩れます。
