研究ブログ

研究ブログ >> 記事詳細

2016/01/21

コードの神話

Tweet ThisSend to Facebook | by takeda
IoTとかデータシェアリングとかにとって肝要なのはちゃんとしたコードや識別子(ID)の設計と運用である。ところがこのコードに関してある種の思い込み(ここでは神話といおう)があって、それが”いい”コードの普及の障害になっている。そこで、わたしなりにこのコードの神話を書き記そう。

コードと識別子(ID)はどちらもなんらかの事象・事物を識別するために用意する一意の記号である。抽象的な事物につけるときはコード、具体的な事物なつけるときは識別子(あるいは単に番号)というようである。コードは相対的には量が少なく固定的で、識別子は量が多く動的(追加や削除が多く行われる)ものとされる。コードはコード間で関係をもつことがある(たとえば上位コード下位コード関係)が、識別子はない。
ちなみにIMI共通語彙基盤では、コードとIDという別のクラスであるが、その違いは上の関係の有無と表記の有無である。
ただ、一般用語としてのコードと識別子(番号)は必ずしも上のような原則に則っているわけではなく、混在している。たとえば、郵便番号は番号といっているがコードとみたほうが適切である。一方、電話番号は識別子である。JANコードはコードと名打っているが内容としては識別子である。

さて主にコードに関してであるが、歴史は古く、図書館分類のようにコンピュータ導入以前から使われていたものもあるが、いまあるような多種多様なコードの出現はコンピュータ利用と相まって始まった。コンピュータの出現とともに使われてきたという経緯があるため、そのときどきのコンピュータの能力に依存した形でコードが決められてきた。コンピュータの能力が変化すればコードのあり方も変わるのである。そこで古いコードと新しいコードではその作り方が変わってきている。にもかかわらず古いコードの考え方が残っているところが問題である。これあ私が呼ぶところのコードの神話である。ではその神話を順にみていこう。

(1)コードは固定長であるべきである(半分正しく、半分間違っている)
コードの対象の総量は概ね固定されていることが多いので、その総量を予め見越せは、それにあった固定長の文字列を与えることは理にかなっている。ただ、固定長であることが必須ではない。識別子のほうはとくにそうで、総量が予想つかない場合や使い勝手を考えた時、可変長のほうが理にかなっていることがある。たとえばDOI(Digital Object Identifier)は可変長で、短いものもあれば長いものもある。また、長さもあまり無理してぎりぎりにすることはない(これも神話)。むしろ余裕があったほうがいいことがある。これも識別子の例で恐縮だが、ORCID (Open Researcher and Contributor Identifier)は研究者に対するIDだが、16桁の数字からなる。研究者が京単位までいるとは思えないが、これは別の人に対するIDであるISNIとの相互互換を図るためにこの桁数にしている。

(2)コードは構造的につくるべきである
構造的なコードとは、たとえば1桁目はこの分類を指し、2-3桁目はあの分類を指すといった、コードの文字列の中に構造があるようなコードのことである。先に挙げたJANコードやISBNは最初の何桁は事業者・出版社、次の何桁は商品番号を指すように桁ごとに分けられている。あるいは生鮮食品流通でつかわれるベジフルコードではもっと細かく大分類1桁、中分類3桁、品名2桁の計6桁のようにつくっていある。
これらは一見合理的にみえるが、拡張性や変更可能性がない、使いづらいコードなのである。たとえば一部の分類が想定される桁数を超えた場合、上位の桁を変更して無理やり収納せざるをえない。そうすると想定した構造が壊れてしまう。たとえば単一の事業者・出版社・中分類が複数の番号(文字列)をつかうことが上の例でもおこっている。
そもそもなんでこんな形式がよく使われきたかというと、一つはコンピュータの処理の能力であり、もうひとつは人間可読性からである。
確かにコンピュータの処理能力が乏しい時はコードの一部を使うだけで処理可能であるコードは便利である。今はそのメリットはほとんどない。むしろ分けて処理する方が面倒である。人間可動性とは人が読んでわかりやすいということである。確かにコードの文字列を見るだけで、コンピュータを使わずに内容の一部がわかるというのは人間にとってもありがたい。しかし、いまやコードを人間が読むというのは現実的な利用法とはいえない。むしろコンピュータにまず読み取らせるというが普通である。これが制約になるというはいまや不合理である。
ではどうしたらよいかといえば、コードに意味をもたせず、単に文字列(数字列)で表現すればいい。そして、もしそのコードの意味が知りたければ、そのコードに結び付けられた情報を別途データベースに問い合わせて知ればよい。データベースの構築が面倒と思うかもしれないが、そもそも現代のコードはコンピュータ利用が前提であり、そのために元になるデータベース構築やそれへの問い合わせは必須である。

(3)コードはコンパクトのほうがいい
なるべくコードのリストの長さが短いほうがいいコードだということである。これも人間可読性からくる不必要な制約である。確かに人間が読むのなら、何百ページのコード表はいやかもしれない。が、コンピュータにとってはなんら問題ない。むしろ必要なコードが用意されず、本来分けるべきものが一つのコードに押し込められてしまう状態のほうが困ったコードである。やたら「その他」項目が多いコードリストのその典型である。

(4)最新版のコードさえきちっと作っておけば、過去のコードは関係ない
一部のコードリスト(コード表)は毎年といった具合に改訂される。必要であればコードリストが改訂されるのは致し方ない。しかし、たとえ今後必要なはこの改訂されたコードリスト(コード表)だけだとしても、以前のコードとの関係性は必ず明示されなければならないし、ましては過去のコード(数字列や文字列)の再利用はもってのほかである。いまや、すべての情報は蓄積される。そのとき過去の情報は過去のコードリストを使って表現されている。この過去の情報を理解するのはいまのコードリストとの関係を知らないといけない。市区町村コードは合併等によって市区町村がかわればコードもかわる。幸いなことに市区町村コードはほとんど再利用がされていないので、コードが間違った対象に解釈されることはない。しかし、過去の文書で使われいる市区町村コードが指すものが何かはそのときの市区町村コードが何をさしているか(たとえば合併前の市を指しているのか後なのか)はコードの履歴を管理して、そこから導けるようにしないといけないというわけである。文部科学省の科学研究費補助金では分野等の分類表というコードリストを用意しているが、これは時々(2年に一度程度)改訂される。これはコードそのものも再利用されるので、あるコードは何を指しているのかは、何年次のコードリストかとペアにしないとわからないという使いづらいコードになってしまっている。

全体をまとめると、設計指針としてはこんぐらいだろうか。
(1)人に読ませることは考えるな。コンピュータに読ませることだけを考えよ。
(2)コンピュータ利用を前提に設計せよ。コンピュータの能力が発揮しやすい形式にせよ。また、データベース利用を前提に設計せよ。
(3)過去との関係も考えよ。
13:51 | 投票する | 投票数(5) | コメント(0) | テクノロジー