「コード設計の話」では、分類集計コードは「無意コード化の原則」に違反していないかという問題を採り上げ、だいじょうぶという判断をした。しかし、だからといって他の通常の無意コードとまったく同様とみなしてよいわけではない。分類集計コードを使用するさいには注意が必要だ。
具体的にいえば、分類集計コードは、分類される側のエンティティの識別子として用いるべきではない。たとえば、「製品分類コード」を設けて製品（脚注①）を分類するとしよう。このとき、分類される側である「製品」の識別子として製品分類コードを用いるべきではないということだ。
製品としての実質には変化がなく、分類だけ変わってしまうことがある。むしろ分類が変更される場合のほとんどがこれに該当するだろう。製品分類コードを「製品」の識別子としていると、こうしたとき、「製品」じたいを登録しなおさなければならない。それだけでなく製品に付随する種々のデータ、たとえば仕様情報（部品表）とか価格情報、取引条件といったデータも登録しなおさなければならなくなる。製品の分類を変更したといっても、こうしたデータにはふつう影響がないはずである。
分類と分類対象は本来別の概念なのに、それらを混同してしまうとこのようなことになるわけだ。
上記の考え方にそって分類集計コードを使った場合のデータモデルを一般化して書くと以下のようになる。
ある一時点をとると、「分類対象」が属する「分類」はひとつに決まる。しかし、時間の流れのなかでみると、ひとつの「分類対象」が属したことがある「分類」は複数存在する。だから、「分類対象」と「分類」は、たとえ（特定時点では）一対一に対応するにしても、別の概念、別のエンティティ（タイプ）である。そして、分類集計コードはあくまで「分類」の識別子とし、「分類対象」の識別子は別にもうけるべきである。
以上の考え方はかなり筋が通っている（というか、あたりまえである）と思う。しかし、これがおおっぴらに破られているケースがある。勘定科目コードだ。
前回ふれたように、勘定科目コード体系が、分類集計コードの一種である「階層化コード」になっていることは多い。繰り返しになるが説明しておくと、階層化コードとは、親子関係のあるコードを組み合わせてひとつの概念を表すもので、勘定科目についていえば、"1000" が「現金預金」で、"1000-02"が「現金預金（当座預金）」といったふうにコードを設計するケースだ。
ここまでに説明してきた考え方に沿うなら、勘定科目の識別子としては分類集計コードではないコードを用い、こうした階層化コードは勘定科目とは別のエンティティである「勘定分類」の識別子とすべきである。この場合、データモデルは以下のようになる。
理念的なデータ構造
これに対して、じっさいには下図のように勘定科目じたいの識別子を階層化コードにすることがほとんどだ。
現実のデータ構造
このようなデータ構造になっていると、勘定科目の分類が変更された場合にデータの修正が必要になるという、まさに上述したとおりの事象が発生する。たとえば、「現金預金[1000]」勘定には「現金」のみ含めることにして名称もそう変更し、預金のためにはあらたに「預金[1010]」勘定を設けるものとしよう。このとき、「現金（当座預金）[1000-02]」の残高を「預金（当座預金）[1010-01]」といった新勘定科目に移し替えなくてはならない。そのために以下のような仕訳入力が必要になる。
| (借方) | 預金（当座預金） | [1010-01] | 1,000 | (貸方) | 現金（当座預金） | [1000-02] | 1,000 |
仕訳入力だけでなく、「預金管理システム」のような周辺システムでのマスタ登録内容の変更も必要になるかもしれない。
こうした面倒くささがあるのに、あえて勘定科目コードを分類集計コードとして設計するのはなぜだろうか。まず第一に、そのほうがデータモデルが簡単になる。それにこんな変更はそれほど頻発するものでもない。まあ、これだけでも十分かもしれない。しかし、本当はもうひとつ、すこし目に映りにくいがだいじな理由がある。
これも例で説明しよう。年度の切れ目で現金預金勘定を分割したとする。この時点での現金預金の残高は2,000で、そのうち当座預金の残高は1,000とする。また、新年度においては取引は一切発生していないことにしよう。「理念的なデータ構造」を採用していて、新年度元帳の金額を新しい集計階層にしたがって集計するなら、勘定科目レベルでの勘定残高の推移は以下のようになる。
旧年度と新年度で残高が不連続になっているのは、「当座預金[10002]」の金額が、旧年度においては「現金預金[1000]」に含まれ、新年度においては「預金[1010]」に含まれているためだ。
このように前年度の帳簿と当年度の帳簿の数値が不連続になることは、とくに制度会計では嫌われる。
望ましいのは以下のような表示だ。
「現実のデータ構造」を採用していて残高移し替えのための仕訳を入力した場合には、まさにこのとおりになる。
「理念的なデータ構造」が絶対にだめというわけではない。前期末と当期首が不連続になっている勘定科目について、その理由がちゃんとわかるレポートが作成できれば、それはそれでかまわない。しかし、これはよく考えていくとけっこう面倒くさい処理になる。そうしたわけで、現実解としては勘定科目の識別子を「階層化コード」として設計することが多くなるのだ。
勘定科目について書いてきたが、これを一般化すれば「集計データの時系列的な連続性の確保の要請」とでもいえる、システム要件の類型が存在するということである。分類集計コードを使う場合、この要件があるのかないのかしっかり見極めないと、設計を誤ることになる。さらにいうとこの要件は、じつは会計システムにおける組織変更（あるいはなんであれ集計構造の変更）の影響を理解する上でのかなめである。次回は、今回の話も踏まえて会計システムでの組織変更対応について書いてみたい（なまけもののため、意気込みだおれになる可能性も高いが）。
脚注① 製造番号などで識別される個々の具体的製品ではなく、品番などで識別される製品の型式の方の意味である。
