2011.01.04 晴れ
穏やかな天気。寒くてもこんな穏やかな天気を逃してはならない。洗濯。土の上の雪は残っている。アスファルトの上の雪は液体へ変化した。一カ所だけ残っている。原形をとどめていない雪だるま。窓越しに雪だるまを見ていた。次に見たとき顔がなかった。ぎょっとした。雪だるまの顔が胴体から落ちる瞬間を見たかった。顔が落ちる前と落ちた後の映像に対して質感を鮮明に知覚した。擬人化してしまうもんなんだ。
読書とファイルサーバのファイルを整理。ファイルサーバの整理は1日で終わらなかった。ファイルを整理して「データ」を強く意識したから。「データ」の価値を再考した。
データの価値は How から What へ移行する。
再考を一文にした。これまでもデータは重要と考えていた。その点は揺るぎない。データの価値が変わる。
データの価値は「集計方法」と「保存方法」を基準に判別されていた。アナログで集計したデータをデジタルへ入力する。その際、ソフトが指定するファイル形式に変換して保存する。入力と保存のプロセスがデータと判定していた。
年賀状ソフトがまさにそう。紙の住所録をソフトの住所録へ入力して保存する、という「作業」がデータだった。もちろん作業がデータじゃない。「郵便番号・住所・氏名・電話番号・メールアドレス・その他」がデータ。そのデータは年賀状用にしか使われない。汎用性が低い(エクスポートは除外しています)。なぜ低いのか。年賀状ソフトのメールアドレス欄にアドレスを入力する人は少ない(と思う)。反対にメールソフトのアドレス帳に郵便番号や住所を入力している人は少ない。
住所は拡張すれば「個人情報」というデータ(＝メタデータ)になる。このデータはひとつ。ひとつのデータは要素(郵便番号・住所・氏名…..etc)に分解されてファイル形式とソフト別に分散保存される。
FUJINO Masaaki のメタデータは分解されてファイル形式ごとに保存される。データは重複する(あるいは分散する)。メタデータは存在しなくなり一元管理されない状態。
この状態のメリットは復元。ひとつのデータがクラッシュしても他のファイル形式のデータから復元できる。デメリットは更新。同じデータをファイル形式やソフト別に更新しなければならない。
昨年、サイトのリニューアルについてO先生と打ち合わせしていた時、何度もデータの一元管理を想い描いた。一元管理という表現は不適切かもしれない(適当なタームを知らない)。
たとえば症例写真。症例写真は保存されている。それらは写真データであって症例の内容、個人情報などのデータとリンクしていない。テキストデータや医療データなどはレセコンやカルテなどに分散保存されている。それらのデータを統合する環境はない。
一枚の症例写真を開くと個人情報や数値、属性などが表示される。統合環境。ただしそれ自体に価値はない。統合環境は前述のとおり、「集計方法」と「保存方法」を基準にした「作業」である。
これからのデータの価値は、「何を」にある。何のデータを収集するのか。汎用性と普遍性が高いデータを選別する。選別は足し算ではなく引き算。
デザインとは「デ(de)」＋「サイン(sign)」、つまり、従来の意味(記号)の組み合わせを否定し、変えることです。常識を否定し眼前の複雑な状況をシンプルに解決しようとする「引き算」のアプローチでもあります。それは何らかのフレームワークをあてはめ分析を駆使して一般解に至るのとは逆のアプローチです。私たちの直観、身体・感情・知性を用いて現場での個別具体の現実から仮説を生み出し、目的に向けて諸要素を綜合・創造する知です。『ビジネスのためのデザイン思考』 紺野 登 P.2
メタデータが存在せずデータは一元管理されない。この状態が長らく続いた。長らく続いたのはPCのおかげだ。PCがデータを加工・編集しているから。データはソフトに依拠する。データの独立性と柔軟性が確保されにくい。ソフト開発の設計を想像したら仕方がないとも思う。
これからはメタデータへアクセスする、そんなデザインが必要だと思う。観点を変える。拡張と持続の観点へ。メタデータからデータを取り出し、それを各デバイスで加工・編集・分析する。
PCのソフトに依存する環境はもろくて弱い。PCが中心でなくなる。メタデータへアクセスする手段はPCだけじゃなくなる。iPhone や Android、iPad や Tablet PC などが普及しはじめたし、デバイスはこれからも姿形を変える。
データの価値が How から What へ移行すれば、思考と設計と行動の領域が重要になる。それはヒトでなければできない作業。ヒトが「何を」吟味して検証する。
つまり今までは、「How → What → (Why)」という流れだったデータは、「Why → What → How」への変わる。古くて新しいアプローチ。How と What と Why を独立した系とするのは無意味。これらは集合体だと僕は思う。どうやって収集するかから入って何を収集するかを決めて入力していた。「なぜ」を思い出すのは時々。このアプローチは続かない。
データの統合環境を構築するには、「なぜ」を考察して「何を」吟味して、入力から出力までの「どのように」を再検証しなければならない。従来の組み合わせを否定する。
「Why → What → How」のアプローチによってデータの統合環境を構築するとき、もっとも重要な要素は「時間」。あたりまえのことだけど忘れてしまいがち。「時間」を必ず各行程に組み込まなければならない。時間。しつこく書くけど「時間」。
ファイルサーバを整理していて、整理あっちのけでそんなことを考えていた。自分のデータ環境を再構築したくなった。