今週のブログは企業システムのあらゆるモデルの出発点となる“データの意味”の整理法について書いてみたい。“意味”と言った瞬間に何か小難しい話?と感じる読者の方も多いのではと思われるが、姿、形のないソフトウエアにおいて、曖昧な”意味“を出来る限り明確にすることは、品質を向上させるために避けては通れない。
バックナンバー[2014.5.7 REPOSITORY]で記載した通り、プログラム製造の主原料はメタデータ*であり、“形式(型、桁)”と“意味”から構成される。今回はその“意味”の部分に焦点を当ててみたい。業種に関わらず企業のシステム部門では、何らかのかたちで、この意味を“管理”している。そのレベルは、社員の頭の中に記憶されている(管理とは呼べない)レベルから、リポジトリ・データベースに全てのメタデータ定義が格納されている(理想的な)レベルまで様々である。テーブル定義書やCOPY文の中のデータ項目の備考に記載されたメモや、“用語辞書”と称して難解な単語についてのみテキストベースで説明したもの等が一般的だろうか。
さて「“データの持つ意味“を記述しなさい」と言ったところで、自然言語を用いた自由記述では作成者によるバラツキや大事な部分の抜け漏れも予想される。そこで、必須事項を漏らさないようにする為、またダラダラとしたセンテンスを区切る為に、”タグ”を用いて記述してみる。ヒントは皆さんがよくお世話になるWikipediaの様式である(実際に前職の会社ではWikiのフリーウエアを用いてリポジトリを構築)。
以下に、どのようなタグを設ければ良いかについて考察してみた。 ① 【D/L区分】(必須)⇒ドメイン(D):エンティティに依存しない、意味と形式が共通な原始的データ。ローカル(L):エンティティ上に存在する個々のデータ。 ② 【ドメイン】(ローカルデータでは必須)⇒継承するドメイン名(定義域)を記載。 ③ 【データ種別】(必須)⇒“コード”、“区分”、“名称”、“数量”、“番号”、“時間”の区別。 ④ 【データ発生源、生成過程】(ローカルデータでは必須)⇒データの発生源となるシステム名とその生成過程。 ⑤ 【データオーナー】(ローカルデータでは必須)⇒ データコンテンツの責任部門。 ⑥ 【意味説明】(ドメインでは必須)⇒データの持つ意味を出来る限り平易かつ抽象的に日本語で説明。 ドメインの場合:利用される局面に依存しない普遍的な意味を記述。ローカルデータの場合;継承するデメインの説明で不足する補足説明を記載。例:仕入先コード・・・商品の仕入先となる取引先コードなど。 ⑦ 【変更履歴】(任意)⇒データの意味を変更、拡張した履歴について、変更年月とともに記載。
図1には受注エンティティ内の届け先コードの意味説明の例を掲載した。どうだろうか、無秩序な自由記述よりもかなりマシではないだろうか。しかし、ポイントは自由記述部分の⑥【意味】のタグに、いかに簡潔な日本語で大勢が理解できるように書くかである。そこでもう一段掘り下げて“データ種別毎”に何を書くかを考えてみると…コードの場合;モノやコトに付与する粒度や、インスタンスのカバー範囲について明確化(ベン図等で捕捉)。区分の場合;「 取り得る値そのもの」とその説明を記載(通貨区分=1:円、2:US$、3:€、4:その他など)。数量の場合;”どんな量か“長さ、重さ、容積、… ”やその単位を記載。名称の場合;“XXに付与された名前“と記述(全角/半角も)、時間の場合;時刻と時間の識別に注意 となる。
そして最後は、文章を書く力を養うしかない。決して饒舌である必要はない。金田一先生のようになる必要はないが、量をこなして行くと少しずつ進歩してくる。ここは思い切り悩みもがいてみよう。歴史を振り返れば、パピルスにはじまり、ロゼッタストーン、グーテンベルクと、”記録を残し第三者に伝える”ことが、人類の進化に大きな役割を果たしてきた。歴史上には文字を持たない謎の文明もあるが、”記録のない謎のシステム”はシャレにはならない。あらゆる“記録”は、次世代の人間の手戻りを最小限に抑える。そして、そこで用いる“言葉”は最も重要であり、細かい微妙な表現に至るまでこだわり大切にしたい。
※メタデータとは・・・データについての情報を記述したデータ。これがないデータは単なるゴミの山と言っても過言ではない。