システムの寿命はコードで決まる！：データベースエンジニアへの道（4）（2/3 ページ）

[吉田知史，アクセンチュア・テクノロジー・ソリューションズ]

安定したコード体系を設計する

　使いやすく、安定したコード体系はどうすれば作ることができるのでしょうか。そもそもこれらのニーズを両立させることができるのでしょうか。結論からいうと、難しいです。データベースエンジニアは時と場合に応じて、これらのニーズをうまくバランスさせることを求められます。ここでは安定したコード体系を設計するうえでの重要な検討ポイントを4つ取り上げます。

（1）適用範囲・管理者を決める

　コードの適用範囲を決めます。コードはできるだけ広い範囲をカバーできる標準的なものであることが望ましいです。各セクションでの使い勝手は落ちるかもしれませんが、一般に全体最適を優先すべきです。もし、製造業の部品コードが、設計部門・調達部門・生産部門・販売部門でばらばらに採番されたら部門間の連携が悪化します。

　そして、似たようなコードを乱立させないためには、コードを作成する際に

• 流用または参考にできる国際・業界標準のコードがないか
• 自社内に似たようなコードがないか
• 自社内で今後共通利用できる可能性はないか

をきちんと調査するとよいでしょう。また、コードの適用範囲が広い場合、管理者を複数持つことがあります。標準コードでは国別に管理機関が置かれるケースが多く見られます。

（2）有意コードにするか無意コードにするかを決める

　コードの形式を有意コードにするか無意コードにするかを決めます。標準コードでは有意コードになっているものが多いです。有意コードであることをデータの分類だけでなく国や企業といった単位で採番帯を分けることにも利用しています（前述のJANコード、後述のISBNコードもそうです）。

　また、入力のしやすさ、視覚的な理解のしやすさが求められる場合も、有意コードにすることを検討する価値があります。ただし、コードにたくさんの意味を持たせると便利になることがある一方、変更の可能性が高くなり不安定になります。可能な限りコードに持たせる意味は少なくすべきです。

（3）コード化するデータの件数を分析する

　コードのけた数を決めるため、コード化するデータの件数を分析します。人間が入力する項目の場合、けた数は短い方が望ましいのですが、けた数が不足してコードがパンクすると困ります。安定運用のため、ある程度けた数は多めに取るとよいでしょう。

　例えば、製造業で部品データをコード化する場合、そもそも完成品に比べデータ量が多いうえに、完成品と異なり修理対応のためデータを一定期間削除できないので注意が必要です。また、企業の合併や大規模な提携があると、急にデータ件数が増えることがあるので、特に近年の社会情勢の中では重視すべきポイントです。

（4）人間の使い勝手を考慮する

　適宜英数字混合にしたり、チェックディジットを設けたりするなど、人間にとって使いやすくする工夫を加えます。英字はテンキー入力できない点では不便ですが、先頭に1〜2文字の英字を添えてデータの種類が分かるようにすると効果的です。なおこの場合も、頻繁に使用するデータは先頭の英字を1文字とするとよいでしょう。

　チェックディジットは、元のコードから一定の計算式を使用して求められる数字で、これにより入力ミスが見つかりやすくなります。身近なところではクレジットカード番号やバーコードの数字にも付いています。

　ところが、最近では業務のIT化が進み、コードにおける「人間の使い勝手」という要素はあまり重要ではないケースが増えています。例えばスーパーのレジでもバーコードが定着し、商品の種類を入力することはまずありませんし、カタログ通販の場合はともかく、インターネット通販では商品の番号を入力することはあまりありません。

Point

コード体系を設計する際は、コードの安定性・使いやすさをうまくバランスさせる必要がある。コードを設計する際に検討すべきポイントは以下の4つ。

• 適用範囲・管理者（適用範囲は広めに！）
• 有意コードにするか、無意コードにするか
• コード化するデータの件数
• 人間の使い勝手

コラム2

それでもコードはパンクする

　コード体系の設計手法の解説の中で、コードをパンクさせずに安定して利用するためには、分類方法・けた数を適切に設計することが重要であると述べましたが、それでもコードがパンクすることがあります。携帯電話の番号は当初10けただったものが11けたになりましたし、IPアドレスも枯渇が近づいています。このような世の中ですから、やはりコードがパンクしたときにどうすればよいのかをあらかじめ考えておく必要があるでしょう。ここでは3つの方法を紹介します。

（1）番号を振り直す　

けた数は足りているが、分類体系を最適化するために番号を振り直すことがあります。この場合は、業務システムに与える影響は少ないのですが、既存データに与える影響が大きく、社内外を問わずすべてのコードを洗い出し、変更する必要があります。

（2）けた数を拡張する　

既存のコードはそのままで、けた数を拡張することがあります。既存コードをそのまま利用できるという点では社内外の既存データへの影響は小さくなります。ただし、業務システムに与える影響が大きく、有意コードのけたずれや、コードのけた数チェック、データベースのテーブル定義の変更など、システム改修が数多く発生します。

（3）分類を無視して採番する　

有意コードの場合、空き番号が発生します。そこで、コードが不足した場合に有意コード内の分類を無視して、空き番号を割り当ててしまうことがあります。この場合は、業務システムや既存データに与える影響がほとんどなく、非常に低いコストで問題を解決できますが、これを頻繁に繰り返すとコード体系が破たんし、（1）や（2）の方法を取らざるを得なくなったとき、現状分析が非常に困難となります。