おすすめ記事

日本政府による貿易手続デジタル化施策でも触れられている国連CEFACT標準について解説するシリーズ「CEFACT標準ことはじめ」。前回は、国際CEFACT標準のキモである「CCL（コアコンポーネントライブラリ）」と「CCTS（コアコンポーネント技術仕様）」について、これらが貿易手続デジタル化に役立つ共通言語の「単語帳と文法書」に例えられると説明し、普及に向けた「壁」に触れました。今回は、そんな「壁」の大きな要素、つまり難しさの理由でもある「CCL/CCTSの設計思想」に踏み込んで、壁崩しに挑みます。

まず、その定義がわかりにくい

「CCLは単語帳である」は何となく直感的に理解できるような気がしますが、CCTSについてはちょっと理解が難しいように思えます。

CCTSとは？を手短にまとめると、

「情報の相互運用性を高めるためのセマンティクス（意味）に基づいたアプローチを定義し、ビジネスコンテキストに依存しないコア・コンポーネント（CCs）と、特定のビジネスコンテキストを適用したビジネス情報エンティティ（BIEs）の二つの抽象化レベルに基づいて、これらはアグリゲート、アソシエーション、ベーシックという分類に分けられ、コア・データ型（CDT）とビジネス・データ型（BDT）が値の領域を定義し、すべての構成要素には一意性を保証するための命名および定義の規則が設定されている・・・」
（Core Components Technical Specification Version 3.0, Section1,5-8）

となるのですが・・・このように説明されても、いったい何のこと？ となります。tradigi.jpで日々貿易やデジタルの話題に触れているJASTPROの中の人間でも頭がくらくらします。これに加えて、日本人にとっては「英語で書かれた結構な分量の技術文献」であることも精神的に大きな壁である可能性もあります。昨今、翻訳ツールが大きく進歩したこともあり英語文献の内容をざっと把握することが大変捗るようになったものの、CCTSは「ざっと読む」タイプの文書ではなく、自動翻訳しても肝心な単語が直訳だったりして、結局読んでも「わからん！」となりがちです。

実は、前提知識が求められている

CCTSは、非常に抽象的かつ汎用的な情報モデルを定義しています。そして、その設計思想は「オブジェクト指向的」と捉えることができます。そのため、オブジェクト指向とは何か？を理解していないと意味不明な記述がたくさんあります。まずこの時点で、普及の前提となる理解が進みません。

オブジェクト指向をさくっと説明

ということで、ここで少しオブジェクト指向について触れてみます。これは、複雑なソフトウェアをより自然に、再利用可能に、保守しやすくするために生まれた考え方です。

大規模で複雑なソフトウェアになると、

• データと処理がバラバラで管理しづらい
• 同じような処理があちこちに散らばって再利用しにくい
• 修正が難しく、バグが出やすい
• チーム開発で役割分担がしづらい

といった問題が出てきました。そこで、現実のモノ（オブジェクト）をプログラムで再現するために、部品（プロパティ）や動作（メソッド）を設計図（クラス）で定義してモデル化し、現実のモノの特徴や動きをプログラムの中で再現することで、複雑なソフトウェアをより自然に、再利用しやすく、保守もしやすくする開発手法として生まれたのがオブジェクト指向プログラミング（OOP）です。

CCTSは、このオブジェクト指向プログラミングのように「クラス」「プロパティ」「オブジェクト」のような構造を持ちますが、プラグラムではないので動作（メソッド）は持ちません。なので、「オブジェクト指向の要素をもったデータモデル」と考えると理解しやすいかもしれません。プログラミングに土地勘のある方には、ここまでの説明で（普及が難しい理由も含めて）お分かりいただけたのではないかと思います。

では、土地勘がなければ理解しようがないのか？というとそんなことはありません。

たとえ話として、「とても大規模な世界観とシナリオで構成された複雑なゲーム」のデザインで考えてみましょう。そのままでは作るのもプレイするのも大変なので、ゲームを「登場人物」で切り分け、それぞれの登場人物にスポットライトを当ててストーリーを見渡しやすくしよう、というのがオブジェクト指向です。この「登場人物」がオブジェクトです。登場人物（＝オブジェクト）は「状態」と「できること」をセットで持ちます。ゲームで言えば、キャラクターがHPやレベルのような「状態」と、攻撃する・防御するといった「できること」をセットで持っていると考えてください。

メソッドは、オブジェクトが実行できるアクションととらえましょう。例えば「ボタンを押したら登場人物が剣を振る仕組み」、これがメソッド（＝動作）です。なお、CCTSに登場しない理由は、CCL/CCTSはこの「具体的な動かし方（コンピュータ的にいえば具体的な実装）」を規定していないためです。

そしてクラスは、登場人物そのものではなく「登場人物とはこういう構造だ」という設計図に該当します。同じクラスからは似た性質を持つ登場人物（オブジェクト）を何体でも作れます。例えば「戦士」クラスからは複数の戦士が生まれ、状態（HPなど）はそれぞれ違うけれど、攻撃する・防御するというメソッドは共通している、といった具合です。

つまり、オブジェクト指向とは

• 物事を「役割」と「行動」と「構造」に分けて理解すること
• 大きく複雑な仕組みを「登場人物どうしの関係」として整理すること

このように捉えれば、コンピュータやプログラミングへの土地勘にこだわる必要もなく、CCLやCCTSの理解が捗るのではないかと思います。

「データモデリング」もついでに説明

残念ながら、もうひとつ分かりづらい要素があります。CCTS Version3（最新版）には、「ユーザーは、基本的なデータモデリングの概念と基本的なビジネス情報交換の概念を理解している必要がある」とも書かれています。データモデリング！ またわかるような、わからないような用語が出てきました。

これもまた技術者専売特許のような印象を受けがちな言葉ですが、実際はそんなたいそうなものではありません。日常的なたとえで言うと、片付け上手な人が、部屋のモノの置き方を決める作業のようなものです。つまり、どこに何を置くか、モノをどういう名前で呼ぶか、いくつかあるモノのどれとどれがどういう関係にあるか・・・そういうことをあらかじめ決めておくことで、あとで混乱しないようにするためのやり方です。

現実世界では「モノ」を取り扱いますが、コンピュータの世界では「データ」を取り扱いますので、片付けの例えからいうと、データモデリングというのは「データを整理し、名前をつけ、関係性を明確にして、後からコンピュータが迷わず扱えるようにする設計作業」となります。先のオブジェクト指向では物事を「役割」と「行動」と「構造」に分けて理解し、「登場人物どうしの関係」として整理することと説明しました。つまりデータモデリングはそのための具体的なやり方である、ということです。

結局のところ、現実世界で片付け上手な人ならデータモデリングなどちょっと勉強すればたやすく理解できるということです。このように、別に技術者の専売特許ではないので、あまり身構えずに理解を進めていただければと思います。

出てくる用語に親しみがない

ここまでで、CCTSを理解するための壁を次々に崩してきたつもりですが、最後の関所は「出てくる用語」です。例えば基本的なデータモデリングの概念（データの構造と関係の考え方）として、CCTSでは以下のような用語が頻繁に出てきてしまいます。先の説明とも照らし合わせて意味や考え方を押さえておくと、CCTSを読み解くのに役立つものと思います。

基本的なビジネス情報交換の概念についても、要は仕事においてコンピュータを使って情報交換しましょう、となった際の考え方のことで、以下のような概念を把握しておくと理解が捗ります。

今回のまとめ

これまでの国連CEFACTに関する広報普及活動は、「コンピュータ関連のことはわかっているものとして話を進める」「わかる人だけわかれば良い」という姿勢が強すぎたように思います。その結果が「なんでそんな良さそうなものがロクに知られていないのか」なわけで、本当に笑えません。長年国連CEFACTの日本窓口を務めてきたJASTPROとしては反省しきりです。

前提として求められている知識に触れることなく、いきなり専門用語だらけの抽象的なモデル論を展開したところで、現場を預かる責任者はもちろんのこと、現場の業務をより良くしたいと日々奮闘するエンジニアからすれば「はぁ？」です。そんな状態でいくら「この国際標準は良いものだから使ってね」といったところで、まともに話を聞いてもらえるとは思えません。

ということで、しっかり反省した結果がこの連載です。JASTPRO自身、改めて国連CEFACT標準に向き合い、そのメリットを日本における貿易手続デジタル化のために生かせるよう、広報活動を進めていこうと思います（つづく）