統一コードの設計総点検

2025年の崖^※を目前に控えて、どの企業もシステムの再構築を急ピッチで進めています。同時に、DXの旗印のもとデータ活用ニーズの高まりにより、データ統合基盤の構築も盛んに行われています。
これらの活動を背景に、コードを見直す企業がとても多くなってきました。せっかく見直すのであれば業務変化に耐えうる安定的なコード設計を目指したいところです。一方で既存の業務システムへの影響を考慮しながら設計し直すことは容易ではありません。
そこで、今回はコード統一に焦点を当てて、設計時の注意事項をご紹介します。

※2025年の崖とは、IT人材不足やソフトウェアベンダーのサポート終了といった課題に対し、2025年までにシステム全体の見直しの必要性に直面している状況を表現したもの。この課題を克服できない場合、既存システムの複雑化・ブラックボックス化等によりDXが実現できなくなる。また、システム維持管理費の高額化やシステムトラブル等のリスクの高まりに伴い、2025年以降に多額の経済損失が生じる可能性があると予想されている。

統一コードの必要性

そもそも、なぜ統一コードが必要なのでしょうか？それは、次のような問題を引き起こす可能性があるためです。

コードの管理コストが増加する

複数業務間で別々に設計されたコードの整合性を確保するには、ある業務システムのコード発番と連動して、ほかの業務システムで使用しているコードへ変換しなければなりません。常にコード変換表のメンテナンスが発生するため、維持・管理業務に多くのコストが費やされます。

データの利便性が低下する

複数の業務システムから、別々に設計されたコードが使われたデータを集めても、コードがバラバラなためデータを紐付けることができません。そのため、利用者側でコードを読み替えて紐付けるひと手間が発生します。これでは、業務を横断したデータ活用が阻害されてしまいます。

適切な統一コードを設計する時の注意事項

全社横断で利用する統一コードは慎重に設計しなければなりません。新規に無意味連番で設計するケースや、社外とのデータ連携用に業界の標準コードを採用するケースであれば、設計が問題なることはあまりあまりせん。しかし、実際には個別の業務要件も考慮して既存のコードを基に設計する場面がたくさんあると思われます。既存コード、特に意味ありコードを含む場合に気を付けるべき注意事項について説明します。

注意事項１：不安定なコードを組み込まないこと

例えば、組織の区分のように組織改正などの影響で変更の可能性が高い不安定な値をコードに組み込んでいた場合、変更の度にコード再発行が必要になります。度重なる変更は値や桁の不足を招き、元の体系が維持できなくなる可能性があります。また、参照しているトランザクションデータの洗い替えや読み替えをしなければならず、データ利用にも支障が出ます。不安定なコードや区分をコードに組み込まず、個別のコード・区分として定義し、属性に保持する設計が望ましいです。

注意事項２：コードの構造で階層を表さないこと

例えば作業タスクなど、上位レベルと下位レベルのタスクを組み合わせて表されているコードがあったとします。

例：XX-YY-ZZ（XXはタスクレベル１、YYはレベル２、ZZはレベル3）

このような場合、上位レベルの追加・削除に伴い、下位レベルのコードを振り直さなければなりません。
また、タスクレベル別に集計する際には、上位レベルと下位レベルのコードの分解を伴うなど、利用が煩雑になります。
そのため、階層関係が固定的な場合を除いて、これらをコード上で表わさず、別の属性項目に上位階層や階層レベルを保持するような設計が望ましいです。

注意事項３：ローカルの仕様に偏らないこと

例えばある代表の拠点システム（最初に取り組んだ拠点など）のコードを統一コードに据える方針としたとします。

例：XYYZZZZZZ（Xは業務種別、YYは担当者コード、ZZZZZZは連番）

しかし、業務種別が細かく分類されている拠点では、1桁の区分では不足してしまいます。一方で、業務種別と担当者コードの組み合わせを管理しない拠点では、“その他”を表す値を使用してしまい、本来の区分の意味が十分に機能しません。
このような問題が起こりうるため、無条件に既存コードを統一コードに採用することは避けなければなりません。意味ありコードを採用する際は、ある業務や拠点固有の特性を持つコード・区分の有無をチェックした上で、代表して片寄せできるか検証する必要があります。

注意事項４：共通のコード・区分と異なる定義は使用しないこと

例えば次のようなケースがあります。

例：XYZZ（Xは事業区分、Yはエリア、ZZは連番）

このコードで使われているエリアは1、2、3…だが、全社共通で使われるエリアコードは10、20、30…と定義されている、というように値が異なるケースです。両者の間で粒度や範囲に違いがない場合は変換対応も可能です。しかし、違いが生じる場合にはデータを集計・分析する時に使う値によってその結果が変わってしまい、データの信頼性低下の要因になります。
意味ありコードに使用する業務上のコード・区分は新たに定義したものとせず、これらも共通のコード・区分として定義されているものを採用します。

パッケージも含めた統一コードの設計

業務システムとしてパッケージ導入が一般化してきており、パッケージ内のコードを統一コードとして採用してもよいか、悩まれる話もよく聞かれます。これには次のような選択肢が考えられます。

統一コードを別に定義する

パッケージの制約を避けるために、本来業務で管理したい粒度や体系で別に採番したコードを統一コードとして定義するのも選択肢の一つです。その際は、コード発番やパッケージのコードとの紐付といったマスタデータ管理機能が別で必要になります。

パッケージ内のコードを採用する

粒度や体系に問題がないのであれば、パッケージ内で採番されたものを統一コードと定義し、他のシステムでも利用するようにします。ただし、これはパッケージの制約がなく自由に採番できる場合に限定した方がよいです。なぜなら、パッケージは、仕様変更やバージョンアップ、別パッケージへの切り替えなどが考えられるため、パッケージに依存して設計されたコードでは、その都度見直す必要性が出てきてしまうからです。

コード設計におけるその他の観点

統一コードの候補となるコードを検討する際の注意事項を述べてきましたが、統一コードを設計するにはその他にも次のような点を考慮する必要があります。

業務共通で必要な粒度・範囲

業務で取り扱われるコードをすべて統一コードにすべきということではなく、業務を横断した利用が想定されるものを対象とします。例えば、取引先に関する情報として、支店単位までは全業務で利用するが営業所は営業部門でしか利用しない場合や、同じ顧客IDでA事業とB事業の販売情報を統合するニーズがある場合などです。業務内に閉じて利用される固有のコードは、個別に管理を任せて構いません。

コードの持続性・拡張性

通常、マスタは永続的に蓄積することが多いため、桁数の枯渇が問題になります。将来的にどれくらいのデータ件数の増加が想定されるかあらかじめ試算しておくなど、持続性を考慮します。それとともに、業務変化を見込んで余裕ある値の有効範囲を設定するなど、拡張性にも考慮が必要です。

このように、統一コードの設計には共通利用が必要な粒度・範囲を正しくとらえた業務的な観点と、コードの持続性・拡張性といったIT（システム）的な観点の両面から検討が必要です。

最後に

ここまでは主に適切なコードの設計について述べてきましたが、品質の高いコードを維持管理するための運用設計も合わせて考えなくてはなりません。例えば、コードの採番には誰が責任を持つのか、どのように誰が整備するのか、といった点についても十分な検討が必要になってきます。適切な設計に基づいて正しく管理されたコードを利用することで最大の価値提供に繋がります。これまでに述べた注意事項や観点を参考に、自社のコード設計の状況を振り返る機会となれば幸いです。

なお、マスタデータ管理については、別の記事でもご紹介しています。また、弊社ではコード統一やマスタ統合といったシステム再構築やデータ活用に欠かせないマスタデータ管理の進め方に関して、専門の研修サービスをご提供しています。ご興味・ご関心のある方は是非、次のリンクより詳細をご参照ください。

ブログ記事：
「マスタデータ管理とは　データガバナンス用語解説14」