[付録] 人間のコミュニケーション
本編でも記載しましたが、人間のコミュニケーションとコンピュータのコミュニケーションはよく似ています。そこでまずは、人間同士のコミュニケーションをちょっと振り返ってみましょう。
よく感じると思うのですが、世代が違ったり出身地が違ったりすると、時々意味が通じなかったり誤解してしまったりします。これは、コンテキスト(コンテクスト)という考え方で説明できます。コンテキストとは、文脈・前後関係・背景などを意味すると説明されていますが、要するに会話の前提となる暗黙の了解です。このコンテキストが相互に理解されていないと意味が通じなかったり誤解を招いたりします。例えば、北海道や東北で「おやき買ってきて」と言うと甘い円筒形の焼き菓子を買ってくると思いますが、長野県で同じことを言うと野沢菜が入っている食べ物を買ってくるかもしれません。どちらも美味しいですが、やはり目的のものを買ってきて欲しいですよね。更に言うと、別の地方では回転焼きとか今川焼と言わないと通じないかもしれませんね。これらの問題は、コンテキストが合っていないために発生します。
近頃「マルハラ」という話題がテレビなどで紹介されますが、Line等のTextツールでチャットをする時に文章の最後に丸を付けると威圧的だなどと言われます。テレビなどでは面白おかしく世代間ギャップだと説明していますが、実際には世代間によらずコンテキストが一致しない場合のコミュニケーションで同様なことが多発します。コンテキストが合わない場合、より説明的な長文でコミュニケーションする必要がありますが、Textツールでは長文がマッチしないので短文で送る事になりますが、そうすると行間を一所懸命読み取ろうとするので威圧的だとか距離感を感じるなどの現象が発生します。
閑話休題。コンテキストの正しい解説は情報科学の本や論文に譲るとして、本編に関係するものには例えば以下のものがあります。
- 前提となる知識や情報
「大谷のホームラン、すごかったねぇ」と言うと大谷翔平の事だと多くの人が思います。それは、大谷翔平が野球のスーパースターだと日本では幅広く認知されているためです。このため、日本人同士の会話ではほとんどの場合誤解を生じさせません - 会話の対象の範囲
広島県で「昨日府中市で昼ごはん食べた」というと広島県の府中市だと思いますが、東京で同じことを言うと東京都府中市だと思います。また、家族に椅子を持ってきてと頼むときに「二階の和室に椅子があるからそれを持ってきて」というと話は通じますが、家族であれはまさに住んでいる住宅のに以下の和室だと理解できます。隣の家の和室から椅子を持ってきたら、それはかなり変わった人ですよね。この様に人間は会話の参加者の関係性は物理的な位置などから会話の対象の範囲を無意識のうちに限定することで会話が成り立っています - 以前の会話や共通する経験
長年連れ添った夫婦では「あれとって」「あれはどうなったかな」など、代名詞で会話が済んでしまいます。これは年を取ると名詞が出で来ないという理由もありますが、会話や経験の積み重ねで共通する会話の土台が構築されている事によります。そこまでいかなくても、例えば知らない土地で知らない人と話をすると、言語は理解できても意図が理解できないという経験はよりしますよね - モノやコト
人・建物・施設・設備・故障などの現実世界のモノやコトをどの様な単位で捉えるか、また、それぞれのモノやコトにはどの様な属性を有していると思っているのかもコンテキストです。例えば、災害時に被災地に水を送るとして、送る政府側は「水10トン」で良いかもしれませんが、自治体側は「何リットルの箱が幾つ」と言って貰わないと避難所に分配できません。更に各避難所は500mlペットボトル100本と言って貰わないと作業が出来ないかもしれません。この様に何をどの様な単位で捉えるかもコミュニケーションの重要な前提です。モノやコトの属性とは例えば、人には生年月日や名前などの属性がある、建物には階数やフロア面積などの属性があるという考え方です。例えば「あなたの氏名は」と聞いた時、暗黙に人間は皆姓と名があるものだという事を前提としています。これは明治以降の日本では概ね成立するコンテキストですが、世界で見るとそうとは限りませんよね。勿論、日本でもこれが成り立たない人は沢山いますが - モノ・コトの関係
人というモノと建物というモノとの間には関係があり、その関係は「居住」と呼ぶなどの考え方です。例えば、日本で「あなたの住所は」と聞いた時、暗黙に人間は特定の建物に定住しており、建物は土地に固定されているので住所があるはずだという事を前提としています。 - 情報の表現における制約事項
例えば住所などの構造がある情報はどの様な形式で表現するのか、モノやコトの属性を表現する場合どの様な用語をどの様な意味で使うのか。数値の場合は桁数や精度はどうするのかなど、数多くの制約事項があります。制約とは言いにくいですが、用語が決まっているものもあります。例えば、建築基準法(の施行規則)では建物の用途を列挙していて、各種申請ではそれを使う事を求めていますし、ますし
これらの内、1から3は会話の参加者に依存しますし局面でも変化していきます。人間の場合でもこれらの情報を共有することなしにコミュニケーションが必要な場合があります。例えば、全くの他人同士がコミュニケーションする窓口業務などですね。その場合人間は「帳票」というツールを使います。この帳票というツールば情報を受け取った側が誤解を起こさない様に工夫されています。必要な情報を全て記載させることで、間違いを起こさない様にしてあるわけです。
これに対し、4から6は参加者への依存は少ないですよね。従って「帳票」というツールはその辺りは多くの場合「当たり前」や「常識」として無視してしまいます。例えば名前が姓と名の2つの文字列だけで構成されていない人が帳票を記入しようとすると困ったことになります。そこで、4から6はちゃんと定義して何を暗黙の前提としているのかを見える化しようと考える場合があります。4から6を情報科学風に言うとオントロジーという事もあります。このオントロジーが曲者で、現実世界を正確に表現しようとすると、モノやコトはかなり細かくなります。例えば、建物はより正確に表現しようとすれば、建物全体をひとつのモノとして定義するよりも、フロアごとに表現した方がより細かく表現できますよね。更に言うと部屋ごとの方が良いかもしれませんし、更にさらに言うと壁や天井などを全てバラバラに表現した方が良いかもしれません。人間のコミュニケーションでは、この細かさは会話の中の文脈で判断しています。
[付録] コンピュータ同士のコミュニケーション
さて今度はコンピュータのコミュニケーションです。コンピュータのコミュニケーションでもコンテキストの相互理解が大事です。単純に考えると、前記の1から3に対してはコミュニケーションに必要な情報を細大漏らさず項目としてある「帳票」をデータモデルとしてコミュニケーションすると共に、前記の4から6に対してはデータモデルを策定する際にオントロジーをそのままデータモデルとして定義してコミュニケーションを行えば汎用性が高い様に思われます。でも、前記の様にオントロジーは正確に現実世界を表現しようとすると大変な労力とコストと期間が必要となってしまい、その実装が非現実的になってしまいます。
そこで、実装上はデータモデルを策定する時にはオントロジーを端折って現実的な粒度で捉える事にします。この「現実的な」という粒度は本協議会では普段業務で使っている粒度でと言う意味と捉えます。そこで、普段業務で使っている帳票・表計算ソフト・データベースなどを集めてそれらが暗黙の内に前提としている粒度で策定する事になります。
本協議会で策定しているデータモデルの多くは多目的なデータモデルであり、データモデルは「モノ」や「コト」の単位に策定すると記載しましたが、実はこれらのモノやコトは実世界のオントロジーを実際に行っている業務に照らし合わせて端折っています。ですので、オントロジーの汎用性はある程度保ちつつ、実用的なレベルの細かさになっています。
余談ですが、策定しているデータモデルを「汎用」とは言わず「多目的」と言っているのは、オントロジーを端折っているからです。汎用ではないけれど、ある程度多目的に使えるという趣旨です。この多目的なデータモデルがデジタルツインのデータモデルと言う事になります。
