そのデータは誰のもの？ ～メルマガ連載記事の転載 （2011年1月24日配信分）～
この記事は、メルマガ「デジタル・クリエイターズ」に月1回連載中の「データ・デザインの地平」からの転載です。今月で10回目になりますので、まとめて載せています。
連載「データ・デザインの地平」
第2回 「そのデータは誰のもの？」 （2011年1月24日配信分）
「存在のデバイス化」が開発者に投げかける、３つの課題
前回、UXデザインは、ブレーン・マシン・インターフェースを経て、「ヒトの存在のデバイス化」へと向かう、と述べました。この「存在のデバイス化」は、開発者に重い課題を投げかけるようになります。
その影響のおよぶ範囲たるや、デバイスたるユーザーが直接関わる、操作性や認証の問題にとどまりません。
バックエンドで動くデータベースにも及び、RDB（リレーショナル・データベース）やXMLのデータ設計（データ・デザイン）の常識に対して、次の３つの課題を投げかけます。
(1) 一意性の定義（一意なものは何か？）
(2) 一意性の承認（一意なものは、ほんとうに一意か？）
(3) 多重CRUD（入れ子化する一意なものの、境界は？）
(1)の「一意なもの」とは、RDBでいえば主キー、XMLでいえば一意であると定義されている特定のノード、それらによって表される「対象」のことです。
たとえば、このメルマガの筆者データベースを設計すると仮定しましょう。「筆者ID」を一意であるよう設計したとき、「一意なもの」とは、筆者IDが表す対象、一人の筆者という存在です。
同一の筆者IDを持つ筆者が複数存在するために、ライターAさんの連絡先や記事タイトルのデータが、ライターBさんやライターCさんのレコード（あるいはノード）にも登録されてしまう、といったことはありません。
(2)は、現在一意であるとされているものが、今後も一意であるかどうか、という問題です。
「筆者データベース」でいえば、一人の筆者という存在が分割できないという常識を前提として、データベースは設計されます。この社会的な承認に対する問いです。
(3)は、データのCRUD（Create／生成、Read／読み取り、Update／更新、Delete／削除）において、たとえば、
・Aさんの所有するデータが、(Aさん自身というデータも含めて)、Bさんのデータになった。
・Bさんの所有するデータが、(Bさん自身というデータも含めて)、Cさんのデータになった。
・Cさんの所有するデータが、(Cさん自身というデータも含めて)、Aさんのデータになった。
といった入れ子化が発生する場合、どの段階でデータを処理するか、その境界を問うものです。
今回は、「(1)一意性の定義」について取り上げます。
そもそも一意なものとは、何なのか？
ひとつ生活上の身近な例で、考えてみましょう。
読者の皆さんの中には、そろそろ確定申告の処理を始めている方もおられるかと思います。申告書の中の社会保険料控除のうち、健康保険料の申告は個人単位です。しかし、納付や高額医療費給付、発行される保険証は世帯単位です。世帯主以外の者が個人の健康保険証を必要とする場合は、別途作成してもらう必要があります。
一方、国民年金保険料は控除だけでなく納付も個人単位です。
健康つながりで、診察券も個人単位。受診する者は、健康保険証の世帯に含まれる（健康か病気かという属性を持たない）個人ではなく、患者であるから、世帯単位になるはずがない、といえば、それまでかもしれません。
医療関係者ではない、診療を受ける側の一住民の立場からすれば、健康保険加入者の情報や「診療情報を含まない」患者の情報は、おしなべて医療に関する個人の基本情報ですから、XMLで定義された業界標準の統一規格があり、それに則って記録・管理・運用され、納付や給付に係る情報も連携可能な形で記録されているのではないか、と考えるかもしれません。そして、近い将来、僻地の診療所にいたるまでデータの標準化が進み、出張先でも、自身がデバイスとなって紐付けられた診療情報が呼び出され、デスクの引き出しに置き忘れてきたのと同じ薬を、簡単に入手できるようになると夢想するかもしれません。
そこでは、一意なものとは、一人のヒトです。
では、健康保険の世帯とは何なのでしょう？一人のヒトの親ノードでしょうか。それとも、世帯の構成員であるヒトは、世帯の子ノードなのでしょうか。
一意なものとは、個人でしょうか、世帯でしょうか。
我々は、平生の目まぐるしい生活の中で、一意性の定義は、常に変わらないと思い込みがちです。
が、未来永劫それは変わらないものなのでしょうか。
そもそも一意なものとは、一意性とは、何なのでしょうか？
いまなぜ、一意なものを問うのか？
では、なぜ、いまさら一意なものを問う必要があるのでしょうか。
それは、データベースの連携に厄介な問題を持ち込むからです。
モノが動けば、それに伴ってデータが、そして（XMLでは）メタデータも、動きます。もし、Aさんの所有する「モノ」が移動して、Bさんの所有するところとなれば、モノを表すデータも、モノの意味を表すメタデータも、AさんからBさんへと動きます。XMLでいえば、品物が動けば、＜品名＞品名データ＜/品名＞も、それに伴って動きます。
Aさんのデータベース、Bさんのデータベース、それぞれの設計者が異なっていたとしても、一意なものが同じ「一人のヒト」であるならば、データの連携は比較的スムースに行われます。
しかし、一意なものが異なっていると、構造変換処理などが必要になりかねません。
そのうえ、「存在のデバイス化」時代には、境界明瞭でない「モノ」と、それを表すメタデータが数多く流通し始めます。
問題を想像しやすくするために、極端な例、ここでは、境界が分かりにくい献血と輸血を例として説明を試みましょう。チューブの中を流れている時、パックに入った時、患者の体内に入った時、互いに一意である献血者と患者の両方のものである瞬間があり、一意なものにのみ属するはずのモノやデータが重なってしまう瞬間があるでしょうか。
献血者は、誰かを助けたい気持ちはあっても、この瞬間までは自分のものであると主張したりしません。これが、大気であっても、どこまでが「私」の呼吸、私の所有する大気だと、誰も主張しませんし、水道管を流れる水でも同様です。一意なものと、それに属するデータには社会的な承認があります。
現在のデータ・デザインにおいて、このようなことについて悩むのは、ナンセンスでしかありません。
しかし、動くモノが在庫商品などではなく、デバイスたる存在＝「生命体」あるいは、その一部となった時には、どうでしょうか。
将来、簡単に身体の一部を交換し合うような社会が到来した暁には、どうなるでしょうか。
一意性の定義は、排他制御（トランザクションが完了するまで、別の更新を防ぐ仕組み）に絡む問題を引き起こしはしないでしょうか。
連携可能性のあるデータベースすべてにおいて、一意性の定義が同一でなければ、デバイスたる存在（あるいはその一部）が動き、それを表すデータが動くとき、整合性を維持できるでしょうか。
一意な「私」は、どこから、どこまで？
いくらか先、再生医療が広く普及した暁に、ネットショップで申し込めば、自分の体の一部を増やして届けてくれるサービスが登場して、一般化したとしましょう（あくまで仮定の話です）。
ネットショップという決済窓口の先には、注文生産を引き受けた会社があります。そして、その会社にも、外注先があるとします。
ユーザーのAさんは、指を火傷し、認証のために必要な皮膚を発注しました※。
日本のネットショップのB社が受け付け、C社で製造し、C社は海外のD社に一部を委託するとします。
返品はできないでしょうから、Aさんが［注文］ボタンを押した時点、あるいは、製造業者が注文請書を発行した時点で、Aさんの身体は、外注先のD社まで拡大することになるかもしれません。他方、別人で同様の怪我をしたZさんの身体は、D社とは異なる国のW社にまで拡大するかもしれません。もはやこうなると、ユーザーである個人が、複数の法人にまで拡大し、さらには注文者によって、拡大する範囲が異なり、輸送、納品、皮膚が根付いた時点で、拡がりの範囲が縮まるという、なんとも奇妙なことになります※※。
一意なものであるヒトのデータをXMLの木構造の中に押し込み、仮に、「存在とは、各個体の意識の座のある座標値を中心点とする拡がりのある場に属する情報のセット」として、拡がりの範囲（リーフノードに至る構造）を定義するとしましょう。
ノードは、どこまで拡がるのでしょう？
「私」は、どこまで拡大するのでしょう？
いったい、どこからどこまでが「私」、一意な存在の「私」、なのでしょうか。
存在のデバイス化時代には「生命体」がデバイスとなるのですから、デバイスたる一意な「生命」とは何か？「存在」とは何か？という問いに対する回答が用意されていなければなりません。そうでなければ、標準化されたデータ・デザインは難しくなります。
一意性の定義に対する社会的な承認が曖昧なまま構築されたシステムは、運用が長期化するほど、定義の変更による影響を受けやすくなり、更新や連携処理の際に問題を引き起こしかねません。そうなった時、しわ寄せに苦しむことになるのは、修復や変換処理を手がける現場の開発者（筆者含む）であろうと思います。
もっとも、今回述べたことは、一人のヒトが一意であることを前提とした話です。では、もし、一人のヒトが一意ではなくなったら？
次回は「子ノード化する脳」について述べてみます。
※想像しやすくするために、怪我の部位は皮膚としておきます。認証のために必要なものを、認証の必要なショップで注文するのはおかしな話ですが、異なる認証方法が採用されているものとします。
※※本稿でいう「拡大」とは単純な「expand」であって、拡張する心（extended mind）の「extend」ではありません。