マスタのコード設計では、
「桁数が足りなかった！」
「Zや数字まで使い切って、当てはめる文字が無くなった！」
「会社や顧客が増えて、企業コードや顧客コード体系がグチャグチャになった！」
こんな事がよくあります。
- 基本のコード種類をおさえる
- コードに意味は必要？不必要？
- 将来の拡張を見通す
- システム導入を成功へ導く
- マスタのコード設計を担当されている方
- システム導入に不安を抱えている方
筆者は約20年、情報システム業務に携わりました。ベンダー側、情報システム側両方を経験しましたが「どっちも大変。」を身に染みて感じています。
情報システム部門では、システム導入時にマスタのコード体系を設定する必要があります。
システム導入中なので大忙しなので、ついテキトーにしてしまい、導入後数年してから冒頭の「しまった！」が発生します。
桁数を増やせば費用発生するので、無理矢理な文字や数字を当てはめて、いつの間にかグチャグチャなコード体系に変貌…。
よくある話です。
こうした事を防ぐためにも、設計の段階でコード種類を押さえて、適材適所なコード設計を行う必要があります。
コード設計の基本用語
シーケンスコード
順番、連番コードとも呼ばれ、文字通り順番に番号をつける
例）1001、1002、1003・・・・・
桁別コード
コードの各桁に意味を持たせる
例）コード「10109F」
「1」 ：日本
「01」 ：北海道
「09」 ：9月
「M」 ：女
ブロックコード
上位の桁をブロック（固定）して、連番を付与する
下の例の場合、「AA」「BB」がブロック
例）AA000001、AA000002、AA000003、AA000004
BB000001、BB000002、BB000003、BB000004
二モニックコード
連想コードとも呼ばれ、略語等を利用してコードから連想できるようにする
例）SY（商品）、TK（得意先）、SI（仕入先）
デシマルコード
デシマルコードとは10進コードとも呼ばれ、0～9の10個に分類して更に細分化する
例）コード「532」は、大分類：5、中分類：3、小分類：2
HTMLではお馴染みで色や文字の英数字のコードをHTMLコード化したもの。
例えば「J」。
意味有りか、意味無しか
二モニックコードのようにコード自体に意味を持たせるのか、それとも意味を持たせずに連番にするのか、迷うところです。
しかし、下の法則に当てはめて考えてみると答えは出てきます。
- 数が多い（1万以上）？
- これからもどんどん増える？
単純な法則ですが、多品種大量生産を行う工場、多品種で品種の入れ替わりの激しい小売、さらには次々と新しいコードが必要な業務の場合、連番にする方がシステム管理が効率的になります。
一方、頻繁に新コードが必要ではない場合、二モニックコードのような意味有りコードでも問題はありません。
意味が有ると愛着も沸く
意味有りコードの良さは、現場や同僚と話す際、コード自体が意味を持っているので話が分かりやすく、桁別コードで他の意味も持っていれば、他のマスタで詳細を調べること無く判別ができます。
筆者の経験では、品目コードに仕入先コードや分類コードを加え、分かりやすくした事もありました。
意味有りコードのもう一つの良さは、システムへの愛着が高まる事です。
仕事で使うものとは言え、無味乾燥とした連番よりも、意味あるコードを見ているだけで製品が想像でき、同僚とも話しやすくなります。
将来の不安
コード設計する上で将来の拡張性検討は避けて通れません。
かと言って、拡張性を持たせ過ぎると、桁が大きくなるのでさじ加減が難しいところです。
「得意先マスタのコードの桁はシステム上では増やせたけど・・・。」
「システム会社がカスタマイズした得意先売上一覧のコードがはみ出て、取締役から『見にくい！』と文句を言われた！」
「結局、帳票プログラムを修正するために費用が発生してしまった。」
と、こんな話もよくあります。
さらにビジネスの環境変化が激しい昨今では、M&Aもめずらしくないので、
「子会社が出来たのでコード増やして。」
といった事もあり得ます。
何をどこまで考えてコード設計をすればいいのか難しいところですが、下記2つは必ず考えてみる必要があります。
- 過去5年を振り返って発生した事は、今後5年で起きる可能性があるので拡張性の考慮に入れる。
- M&Aは珍しい事ではなくなったので、会社や事業部が増えたり減ったりしても対応できるようにする。
システム導入を成功に導く
コード設計も大切ですが、本丸のシステム導入も大切です。
いくらコード体系がしっかりしていても、システム導入で経営目的が実現されないようでは導入の意味がありません。
ちなみに筆者のベンダーでの役割は炎上案件の「火消し役」でした。
言った言わない、過大要求、要件抜け、設計ミス、バグ、テスト不足、経営目標未達成、完成じゃないから支払いしない、ベンダー逃走後の後処理、等々を収拾するのが筆者のライフワークでした。
その後、情報システム部門に居ても、スッキリと終わるシステム導入プロジェクトはほとんど見た事がありません。
難しいシステム導入を成功に導くために、失敗事例をよく見ておく必要があります。
こちらの本は、システム導入での「あるある」本です。
問題は列挙されていますが、解決方法についてはあまり書かれていません。
「今のプロジェクトで起きたら、どうする？」
と想像力を働かせて読んでいました。
一方、こちらの本はシステム導入時の31の「罠」について書かれています。
例えば、経営層が考えがちな、
「システム導入で業務効率化すると人件費削減につながる。」
といった考えを明確に否定し、
経営層、システム部門、ユーザー部門それぞれに、どういった視点で考えればいいのかを「POINT!」で説明しています。
導入から保守までのそれぞれの罠についても対処法が書かれているので、筆者はプロジェクトに問題が発生した時には見直して、示唆をもらっていました。
終わりに
余談に逸れてしまいましたが、システム開発や更改プロジェクトの際、コード設計は意外と疎かにされがちです。
システムの要件定義以降はシステム内部の設計が固められてしまい、コード設計をやり直す事は難しくなります。
なので、比較的時間の余裕があるシステム構想段階でコード設計をすると心配事が減ります。
これで記事は終わりとなります。
最後までお読みいただきありがとうございます。
本記事は筆者自身のSE・PG、情報システム部門業務を基にしています。
多少なりともマスタコード設計の参考になれば嬉しい限りです。
