コード体系の設計法を考える

はるか数千年前の古代中国。動物は、以下のように分類されていたという。

(a) 皇帝に属するもの、(b) 香の匂いを放つもの、(c) 飼いならされたもの、(d) 乳呑み豚、(e) 人魚、(f) お話に出てくるもの、(g) 放し飼いの犬、(h) この分類自体に含まれているもの、(i)気違いのように騒ぐもの、(j)算えきれぬもの、(k) 賂蛇の毛のごく細の毛筆で描かれたもの、(l) その他、(m)いましがた壷をこわしたもの、(n)とおくから蝿のように見えるもの。

これは哲学者Ｍ・フーコーの『言葉と物』の冒頭に紹介されている話だ。分類体系としては、いささか奇妙である。まず、皇帝に属するもので、かつ、香の匂いを放つものは、どちらに分類するのか。それに、乳飲み子から育ってしまった豚はどうするのか・・

ま、これはもちろん真面目な顔をして書かれた冗談である。調べると、どうやら元ネタは、アルゼンチンの作家ボルヘスのようだ。幻想的な作風で知られる南米の巨匠ボルヘスらしい、奇妙なウィットに富んだジョークだ。

ただ、物事を体系的に精緻に分類するのが好きな文化と、あまり分類には関心を持たぬ文化が存在するのは事実らしい。たとえばギリシャ・西欧文明は前者で、彼らの学問はしばしばカテゴリー論と認識論にこだわる。他方、東アジア・東南アジアは、後者に属するのではないかと感じている。これは個人的な感触に過ぎないが、しかしたとえば梅棹忠夫も「東南アジア紀行 」 で、タイや中国の大学研究のあり方についてそんなことを述べていた。ちなみに生物の分類学を体系化し、「学名」という命名システムを発明したのは、西洋人のリンネであった。

ところで今、分類体系とか命名システムという語を用いたが、では中国語で『系統科学』というと、何を差しているかご存じだろうか？　じつはこれ、System science すなわち「システム学」の事なのである。システムとは、元々、系統あるいは体系のことを指していた。現に今でも英語では、（生物）分類学のことをSystematicsと呼んでいる。

だから我々も日本語では、システム工学とか書かずに、「系統工学」とでも呼んでおけば良かったのではないかと、時々思う。システムエンジニア（SE）ではなく、系統技術者である。漢字の方が、カタカナより、多少は分かるような、あるいは威厳を感じさせるような気がする。今日、多くの経営者が、「俺はシステムとかコンピュータとかって、サッパリ分からん」、で済ましていて、IT分野の技術者はいつも傍流扱いの金食い虫みたいに思われている事態も、少しは防げたかもしれない。

さて、前回の記事「従業員番号のない会社、あるいは、わたし達の社会のアキレス腱について」 で、コード化に関するリテラシーの低さが、わたし達の社会のアキレス腱になっていると書いた。わたし達の仕事においては、何かを追いかけコントロールしたかったら、それに整理番号のコードをふっておくべきである。これはビジネスにおける業務知識だとか技術だとかよりももっと基本的な、思考と行動の習慣であって、わたしが「OS」と呼ぶものの一部だ。

わたし達の社会は、はっきり言って、物事にコードを振る、という部分のOSが弱い。コード体系の作り方も、あまり上手ではない。いや、それ以前に、コード体系の作り方に上手下手がある、という感覚自体が薄い。「コード設計論」を、本来は大学でも教えるべきだとわたしは思うが、そんなコースを開設したというニュースを聞いたことがない。

ビジネスでは従業員番号にはじまって、製品コード、部門コード、取引先コード、受注ジョブコード（製番）、マテリアル・コード（品目コード）など、様々なコード体系が必要だ。なのに、それらは、どこか担当部門が勝手に決めているか、あるいは（例によって、ERP導入に伴う大騒ぎの際に）IT部門の若手あたりに押しつけられる仕事になっている。そして、上に述べたような、わたし達の文化に内在する「体系的分類に関する思考の弱さ」が、足を引っ張ることになる。

一例を挙げよう。ある会社では、マテリアル・コード（品目コード）を、以下のような桁区切りのシステムでとっている。

このようなコード体系の長所は、何だろうか。そして短所は？　−−先を読む前に、少しだけ考えてみていただきたい。

ちなみにこの会社は、製造業である。日本では最も一般的な、組立加工系の業種の、部品メーカーだ。それなりの技術力も持つ、業界では一目置かれる存在の企業である。そこが、このような体系を使っている。そのことについて、あなたはどう思うだろうか。

長所を挙げよう。まず、固定桁数のコードなので、コンピュータで扱いやすい。そんなの当たり前だろ、と思われるかもしれないが、放っておくと、「1, 2, 3….11, 12, 13」みたいな桁数可変の番号を振り始める人間は、いくらでもいる。

それにもう一つの長所は、部品番号を見ると、それがどの製品に使われているか、すぐに分かることだ。これは、製造現場で現品票などがきちんと添付されているならば、「この部品ってどれに使うんだっけ」といったことが、すぐ分かるメリットがある。

では、欠点は？　まず思いつくことは、製品の後の部品の連番が、3桁しかないことだ。一つの製品を作るのに、999個を超える部品数が必要な、複雑な製品だったらどうするのか？　・・まあ、この会社は部品メーカーだから、この会社にとっての「製品」は、顧客である自動車メーカーや家電メーカーにとっては、小さな「部品」にすぎないので、たぶんそんなケースはないと思ったのかもしれない。だが、この会社が、将来もっと消費者に近い製品を開発して、売り出さないと、誰が決めたのか？　経営者か？　そうではあるまい。

もう一つの欠点。それは、複数の製品で共通の部品を使う場合はないのか、という問題である。ボルト・ナットの類いは、おそらく共通性が高いはずだ。それはどうするのか？　まさか、製品ごとに、異なる品目コードを振り直しているのか？　だとしたら、合計の在庫数量は、どうやって管理しているのか。謎である。

そもそも、このような部品コード体系を考える、ということは、この会社の技術部門には、「部品の共通化」という大事な問題意識が、最初から欠落しているらしいことを示している。部品メーカーは、顧客の個別注文にいちいち応じることが、命題になっている。だが、自分たちの生産性を上げたかったら、いかに共通部品を増やし、設計を再利用するかが、ポイントとなるはずではないか。

でも、もう少し続けよう。次の例は、どうだろうか？

このようなコード設計の長所をあげるとしたら、最初の5桁で表される製品コードの決め方が、より体系的（システマティック）であり、2桁目までで種別が明確なことだ。

では、短所は？　これは、ここではあえて論じない。読者諸賢は、ご自由に考えてみていただきたい。

この例のように、コードを複数の桁の単位に区切り（見た目が分かりやすいように、ハイフンが良く使われる）、その後に連番を打つ、という方法は広く使われる。前方に置かれるのは、分類を示す記号である。それも大分類・中分類・小分類といった、複数のレベルにまたがる分類であったり、異なるカテゴリー（分野別・素材別・地域別など）の表示だったりする。

つまり、こうしたコード体系では、前半は主に人間にとって「意味」のある判別記号を表し、後半は意味のない番号になっている。問題は、そのようなコード体系の「意味」を、どこまで普遍性を持ち、かつ、長持ちできるように定義できるかだ。

最初にあげた中国の動物分類は、あまりにも馬鹿げているので、まずい体系だということは誰でも分かる。あのような体系は、MECEになっていない。MECEとは、Mutually Excludive and Completely Exhaustiveの略で、ロジカル・シンキング用語である。意味は、「お互いに重複もなく、漏れもない」という意味である。

何かを分類する人は、その分類方法が、MECEであるかどうか、意識する必要がある。ところが、これが案外、難しい。わたし達の文化では、そのような思考の訓練を、初等教育でも高等教育でも、受けていない。

それにもう一つ。西欧的な文化で育った人は、MECEには慣れている。しかし、逆に、分類というものが、時と共に移りゆく可能性のある、動的なものだという感覚が薄い。コード設計には、このMECEセンスと、分類は動的なものという感覚の、両方が必要になる。

じつをいうと、上にあげた２例は、藤井一良著『「品目コードNo.」の考え方・採り方』（日刊工業新聞社）から引用させていただいた。本書は、わたしの知る限り、この問題を正面から扱った唯一の和書である。

この中で著者は、こう指摘している：

「実際、長年パンクなど大きな不具合もなく運用され続けている体系に共通しているのは、“分類の定義設定が懲りすぎていないこと”です。コード体系は永久に継続していくことが大切なのです。」

まことに正しい指摘だ。過度に分類しすぎた体系は、時の移り変わり（事業環境やビジネス構成の変化）についていくことができなくなる。

ついでにいうと、上の文章で「パンク」と表現されているのは、『品番爆発』とよばれる現象である。品目数が、色や外形や表面処理などのバリエーションのために掛け算で増えてしまい、連番の上限を超えてしまう現象である。上の例では3桁しか連番がないから、1000以上に増えると、コード体系が破綻してしまう。

したがって、上手なコード設計では、「意味」の部分をあまり多く取り過ぎず、なるべく単純な「連番」を使う方が良い、ということになる。とはいえ、連番部分の桁数が増えすぎると、人間が覚えきれないし、入力時にミスを誘発しやすい、といった副作用が出る。しかもいったん設計に失敗すると、後でコード体系の変更などという、とんでもないコストを支払うことになる。

コード設計は、こうしたトレードオフの中で、リーズナブルな形態を決めていく、高度に知的な作業なのである。いってみればIT技術、とくに上流工程といわれるビジネス・アナリシスにおいて、きわめて重要なスキルである。なのに、こうした知恵について教える大学もなければ、書いている本もきわめて少ない。こういう知的状況を見ると、わたし達の社会のアキレス腱は本当に大丈夫かなと、いつも心配になるのである。

＜関連エントリ＞

　→「従業員番号のない会社、あるいは、わたし達の社会のアキレス腱について」（2018-10-19）https://brevis.exblog.jp/27603707/