第34回 生活の中のデータ・デザイン ～メルマガ連載記事の転載（2013/10/07 配信分）
この記事は、メルマガ「デジタル・クリエイターズ」に月1回連載中の「データ・デザインの地平」からの転載です。
連載 「データ・デザインの地平」第34回 生活の中のデータ・デザイン
ユーザーの行動に関わる、データ・デザイン
データ・デザインは、ITエンジニアだけが目にするものではありません。すこし視点を変えてみれば、誰でも日常生活の中に見てとることができます。データベース設計やデータ処理プログラミングの経験がなくても、どのようなデータが処理されているのか、その形を想像することはできることでしょう。
たとえば、病院の患者受付番号を想像してみてください。
番号データが受付順の連番になっていれば、受付や会計の電光掲示板に自分の番号が表示されていなくても、前後の番号から、自分の番号がこれから表示されるのか、あるいは余所見をしていた間に既に表示されてしまったのかを、推測することができます。
連番でなくとも、固有の患者番号であったり、初診と再診に分類されていたり、各科ごとの受付順になっているなら、同様に推測できるかもしれません。
どのような方法にせよ、根拠を推察しやすい番号であれば、患者は、データというものをとりたてて意識することなく、手続きを済ませることができるでしょう。
何気なく電光掲示板を眺め、何気なく手続きができているなら、それは少なくともユーザーにとって、悪くはないデザインです。バックグラウンドで動くシステムの、そのまた基盤となるデータ・デザインは、衣服のポケットの裏地のようなものであって、ユーザーには意識されない方がよいのです。
逆に、電光掲示板の表示が、まるでフラッシュ暗算のようにランダムな数字の羅列にしか見えず、少なくない患者が戸惑っているなら、それはちょっと困ったデータ・デザインであるといえるでしょう。
ユーザーの利便性よりも事務処理のしやすさを優先せざるをえないケースもあるかもしれません。しかし、複数のユーザーが、利用するたびに引っ掛かりを感じたり、何度利用しても手続きに慣れないならば、それは「データを見てヒトを見ていない」データ・デザインといえるでしょう。
ここでは病院の例をあげましたが、手続きを必要とするいろいろなシステムのある場所で、ぜひ、ヒトの動きを観察してみてください。
複数のユーザーが戸惑っていたり、操作に時間がかかりすぎて渋滞が発生しているならば、問題は、ユーザーの操作スキルではありません。
担当者に詰問口調で質問している光景が見られたときは、訴えの内容に聞き耳を立ててみてください。モンスター・ペイシェントではないと確信できるならば、ユーザー・インタフェース・デザインあるいはデータ・デザインに改善すべき点があると考えられます。
情報の正確性に関わる、データ・デザイン
ユーザーが能動的に利用する検索などのシステムでは、データが直接目に触れるため、データ・デザインはより一層身近なものになります。
データの元であるオリジナルの情報と、プログラムの処理対象であるデータは、同一であるとは限りません。
それらが乖離していなかったり、差異が小さく押しとどめられていると思われるならば、ユーザーにとっては比較的よいデータ・デザインといってよいでしょう。
つまり、誤ったデータを許容しにくい構造にデザインされているということです。
何を選択項目にするか、データの型をどうするか、どの項目をデフォルト扱いにするかといったことは、データ・デザインで制御できます。
誤ったデータが散見されるならば、データ・デザイン上の定義あるいはプログラムによる検証が緩い可能性もあります。
もっとも、いかなる方法を使っても、データを完全に制御することは不可能です。データの中に、人の手で入力されるフリーテキストが含まれる限り、正確でないデータが紛れ込む可能性はゼロではありません。
情報の順序に関わる、データ・デザイン
データ・デザインでは、「順序」は重要な要素です。
たとえば、ネット上でしばしば話題になる、小学生が習う掛け算の問題を思い出してください。
品物を複数の人に配るために必要な数をもとめる場合、個数に人数を掛けても、人数に個数を掛けても、同じ答えがえられます。かけられる数とかける数の順序に関係なく正答とする意見もあれば、順序を重視すべきという意見もあります。
データ・デザインの視点からこの問題をみると、掛け算の学習では順序が重要ではないかもしれないが、単価と個数から小計を計算するような事務処理の現場では順序が重要になることもある、といったところです。この順序とは、RDBならフィールドの順番、XMLならノードの出現順序にあたります。
個数と人数のどちらを先に出現させるべきかはさておき（※1）、順序というものを意識する姿勢は必要です。
なぜなら、XML文書の処理では、しばしば、ノード名（「単価」や「個数」といったデータを表す名前）ではなく、ノードのインデックス（各項目の出現する階層や順序を表す数字）を利用したプログラムが書かれることがあり、出現順序が異なると計算結果も異なってしまうからです。
RDBやXMLに馴染みのない人は、Excelのブックを想像してみてください。A列に単価、B列に個数、が入力されたワークシートと、その逆に入力されたワークシートが混在しているブックがあるとします。そして、もうひとつ、どちらかの順序に統一されているブックがあるとします。
ひとつのブック内の複数のワークシートの数値を利用して計算するとしたら、ミスが生じにくいのは、順序の統一されている後者ではありませんか？
掛け算を教える授業の目的が「より多くの生徒に算数を好きになってもらうこと」や「数学に関わる仕事に就く人材を育てること」なら交換法則が重要かもしれません。一方、「データを定義したり入力する仕事に就く人を育てること」ならば、順序について意識する機会を与えるのも悪くはない、といったところでしょうか。
順序を問う必要があるかどうかは、学校教育の目的とカリキュラムの企画目的次第だと考えられます。
※1 個数と人数のどちらを先に出現させるかは、国内と海外でも異なりますし（おそらく国によっても異なるでしょう）、エンジニアによっても異なります。
W3Cの「XML Schema Part 0」などでは、quantity、price、という順ですが（http://www.w3.org/TR/xmlschema-0/）、price、quantity、total、の順に定義する英語圏のエンジニアもいます。
デザインとは「情報の整理」
日常生活のそこかしこにあるデータを意識してみると、我々の生活は、データ・デザインなしでは成立しないことに気付かされることでしょう。
データ・デザインは、「対象となる人や処理するプログラムに情報が正確に伝わるよう、情報を整理する仕事」です。 元となる情報は、形式の異なるレガシーデータとして存在する場合もあれば、クライアントの記憶の中に埋もれていることもあります。デザインの目的に合わせて、情報を引き出し、見極め、取捨選択し、プライオリティを判断し、データの意味をもっとも適切に表現し、且つプログラムから効率的に処理できる構造を考えなければなりません。
もっとも、デザインが「情報を整理する仕事」であるのは、データ・デザインに限ったことではなく、ヴィジュアルデザインでも、インタラクティブ・デザインでも、ユーザー・インタフェース・デザインでも、「デザイン」と名のつく仕事すべてに共通することです（※2）。「いかに表現するか」よりも、「どの情報を表現するか」を見極めることが先決です。
デザイン経験がなくても、ヒアリングして顧客の要求を整理したり、（誰もやりたくはないでしょうが）スパゲッティ・コードを整理できる人は、「情報を整理する能力」を持ち合わせています。
一方で、そういった「情報の整理」の苦手な人もいます。
モノの整理の苦手な人のために片付けのセミナーがあるように、情報の整理が苦手な人のために情報の片付け方を教えるセミナーが必要かもしれません（※3）。もっとも、情報整理能力を後天的に獲得させる方法を、筆者はまだ見つけられていませんが.....。
※2 情報を整理することさえできれば、最低限のラインの表現方法は、後から身に付けることができます。
ビジュアルデザインにおいては、微細な色彩の違いを見分ける力を持ち合わせていなくても、そもそも閲覧者側の環境が一定ではありませんし、わずかな位置のずれを感知する力を持ち合わせていなくても、ソフトウェアが数値を表示してくれます。配色やレイアウトが分からなくても、参考になるデータは探せば多々あるでしょう。
しかし、それらの表現方法を身に付けても、情報を整理できなければ、デザインはできません。
※3 あくまで私見ですが、情報の取捨選択には優先順位の決定が必要であり、何を優先するかの判断、つまり目先重視（短期報酬）か将来重視（長期報酬）かは、（報酬系に影響するという研究結果のある）セロトニンなどの脳内物質に左右されるのではないでしょうか？さらにいえば、脳だけではなく腸も関わるかもしれません。また、空間認識が、情報整理の得手不得手に関わっているのではないでしょうか？
近い将来、神経系に作用する薬剤によって、本人努力なしで、情報整理能力を獲得できる方法が見つかるかもしれません。