文系のための「調査データの構造」（２）

どのような調査でも、調査の段階は大きく分けて二つの段階に分けることができる。
第一段階は情報収集の段階であり、第二段階は情報構築の段階である。
研究段階の分析と解釈は、再構築された情報を用いて行うのが常である。

紙媒体が中心であった時代には、主として分析と解釈に焦点を当てられてきたが、
その背景には、紙媒体の物理的な限界があると考えられる。
全データを記載しても、必要な情報を得難いにも関わらず、紙面をかなり圧迫する。

しかしながら、デジタルデータを用いるようになるとこの状況は大きく変わる。
記録媒体の大容量化、検索システムの高度化、情報通信速度の高速化、
こうした技術革新は、紙媒体の持つ物理的限界を簡単に克服してしまった。

問題は、こうした技術革新に多くの人がついて行けていない現状...。

一般的に研究「資料」は費やした人的、金銭的、時間的コストに価値があるが、
一方、構築された「情報」は認知度と共有性に価値がある。
情報は、公開し、共有することで価値が産まれる。これ超基本。

珍しいデータや貴重なデータをハードディスクに放置しても意味が無い。
著作権と個人情報が関係しないデータであれば、積極的に公開した方が良い。
もちろん、きちんと整理された状態で公開しないといけないが。

このように言うと、多くの人は納得してくれるのであるが、残念なことに、
自分が他人のデータを使うことには何の抵抗も感じないが、
自分が他人のためにデータを公開することを拒否する人は非常に多い。

近年、欧米を中心に過去の資料のデジタル化と公開化が進められていて、
それに伴って、歴史的な資料の再発見が相次いでいるが、日本では少ない。
デジタル化と情報公開は、一緒に考える必要があるのだが...色々と中途半端。

さて、最初から話が逸れそうになったが、要するに、分析と解釈だけの時代は終わり、
現在は、分析と解釈に至るまでに、どのような資料が収集され、情報が構築されたかが、
重要視されつつあるということ。この問題は改めて考える必要がある。

情報を体系的に管理することは、研究データの消失の危険性を低減し、
また、データ改ざんの問題を未然に防ぐこともできる。
第三者が後に研究過程を復元できるような試みは必須条件になりつつある。

本ブログで紹介する方法は、データ公開の要請に迅速に対応できる方法にもなる。
前回の話では、第一段階として、一次取得データの管理方針について述べたが、
今回の話では、第二段階として、二次加工データの管理方針について述べる。

一次取得データの話でも述べたように、取得した生データは直接加工しない。
これはオリジナルの状態で保存する。再度、取り直しができるとは限らない。
二次加工データは、一次取得データから必要な物のみをコピーして編集したデータ。

まずは、データの構造を考えてみる。以下は、その模式図。

二次加工データは、「調査成果」というまとまりで管理され、
さらに調査成果のまとまりを「版」としたサブディレクトリを複数持つ。
版は、調査次数（年度）に対応するかもしれないが、対応する必要は無い。

各「版」の中には、各々の「作業」に応じたサブディレクトリが作られる。
例えば、図面、文章、集計表、測量図、写真、動画、音声...など。
要するに、日付毎で取得されたデータを種別毎に再割り振りする感じ。

ここで重要なポイントは、元データは、一次取得データから「コピー」すること。
間違っても「移動」してはいけない。データの重複が生じても構わない。
一次取得データは、何があっても直接には触らないこと。

コンピュータのデータは、見た目が変わらなくても、
ちょっとした操作で、メタデータが書き換えられることがある。
データを得た時の情報を可能な限り維持することが重要。

あとは、フォルダ名とファイル名の付け方。何を注意するのだったか？
確か、半角英数でスペースと記号は使わないのだった。
そうそう、使って良いのは「_」の記号だけだった。

さてさて、これで、調査データの管理方法の初歩的な方針は理解できたはず。
ただし、このブログで示した方針は、あくまで全体的な概要であって、
より厳密に情報管理を行うためには検討すべき問題が山積している。

ファイル名やフォルダ名の付け方について、あまり詳しく述べていないが、
具体的に、どのような名称を付けるべきか？という問題や、
各フォルダには、メタデータが必要かもしれないという問題もある。

また、二次加工データに関しては、作業記録のログの記録方法や、
編集で行われた個別操作の記録の取得方法なども必要かもしれない。
では、ソフトウェアに依存するような操作の場合はどうするべきか？

実は、こうした内容こそ、各分野における情報標準の問題として議論すべきなのだが...。
まぁ、愚痴を言った所で、現状が変わる気配は全く無いので、
このままデファクトで標準を作ってしまうのは有りかもしれない。

ところで、前回の話と今回の話を合わせて見てみると、
全体的に複雑に見えたかもしれない。
これをもっと簡単にするには？という要望があるかもしれない。

本ブログでは、入門編からPython というプログラミング言語を使っているが、
要するに、前回と今回の記事で述べた方針を、Pythonで実装してしまおう、
というちょっとした意図があってのこと。

まだまだ、先は長いけれど、「えっ、パイソン？それって蛇？」って人には、
一応、文系のための「情報管理」の話を最初から読み進めることを推奨。
これから、少しずつ、難しくなっていく。

文系のための「調査データの構造」（１）

Windows95 が発売されて以降、パソコンは急激に普及し、
それに伴い、あらゆる作業が電子化されるようになった。
この変化は、フィールド調査においても同様である。

パソコンと連携できる電子機器も多く登場してきた。

デジタルカメラ、デジタルビデオ、ICレコーダ、電子地図、そしてGPS。
最近では、これらの機能が一体化したような電子機器もある。
スマートフォン。ある意味、最強の調査デバイス。

さて、ここまで電子化が進んでいるにも関わらず、
何故か、デジタルデータの整理方法の標準化は進んでいない。
どの機器を使うべきか、何を記録するべきかとか、無意味な議論はされているようだが...。

はっきり言って、そのような問題を時間をかけて議論する意味は無い。
非常に短い期間で、様々な電子機器が開発される昨今、状況はすぐに変化する。
重要なことは、様々なデジタルデータを円滑に共有するための方法を整理すること。

特に、調査チームを組織して調査する場合、
調査メンバー同士が後にデータを容易に統合できるような工夫は不可欠。
また、長期の調査の場合には、異なる調査年次のデータを統合する必要もあり得る。

この問題は極めて重要。私自身、以下のような経験がある。

• 前任者のデータを受け取ったものの必要なデータが見つからない...。
• あるいは、数年前の調査データを探しても中々見つからない...。
• データが散在していてコピーをし忘れてそのまま消去してしまった...。

似たような経験をしている人は少なくはないハズ。具体的な対策は？
デジタルデータは、ある意味、紙媒体の情報よりも消失しやすい。
それゆえに、紙媒体の資料以上にデータ管理には注意しなくてはならないのである。

ということで、ファイル管理の方法について色々と考えてみる。

そもそも、調査データには、一次取得データと二次加工データの二種類があり、
今回の話では、一次取得データに焦点を絞ることにする。
二次加工データについては、次回の話で。

さて、最初に考慮するべき問題は、調査データの構造である。
そもそも、調査プロジェクトの情報はどのような構造を持っているのか？
まずは、これを整理するところから始める。

ディレクトリの話で述べたように、コンピュータは階層構造によってデータを管理する。
したがって、様々な種類の調査データはこの階層構造に写像する必要がある。
これを可能にするソフトウェアを作るという手もあるが、今は手作業な方法で。

まずは、調査の階層構造について考えてみる。
概念的に解り易くするために図化したものが下の図。

あるプロジェクトがあったとして、
そのプロジェクトは年度区切りあるいは複数の調査次数から成る。
たとえ、一回限りだったとしても、プロジェクトは調査次数がある。

ある調査次数あるいは調査年度においては、複数の担当者が参加し、
各メンバーが、それぞれの仕事の中でデータを作成する。
通常、仕事は「日」単位で行われるため日付で管理される。

各日付で管理される情報は、写真、メモ、動画、音声、日誌、などなど...。
要するに、デジタル化され得る全ての情報が、
データの種類毎に分けて管理される。

データの種類については、拡張子によって分類する方法と、
取得したデータの性質によって分類する方法が考えられるが、
今は、この点には踏み込まないことにする。

本当は、この部分こそ標準化する必要があるのだが。
この部分を明確化すれば、フィールドデータのメタデータを規定できる。
ちなみに、私の場合は拡張子方式を採用している。

さて、このように、階層的に調査プロジェクトを整理し、
この階層に従って、フォルダを作成すると、
複数のメンバー間のデータを効率的に統合できる。

ここで、重要なポイントは、例外無くこの階層に従うこと。
例外規則を作ると、後の処理が複雑になってしまう。
こういった所で、論理的な思考が出来る人と出来ない人が見えてくる。

単なる理屈上の話なので、文系と理系の違いは無いハズ。
実際、工学系の人の中にも、この辺りのことが苦手な人は多い。
まぁ、そんなことはどうでも良いのであるが。

とにかく、

「今回の調査の一回限りだから、調査次数のフォルダを作らなくても良い。」とか、
「調査メンバーは、一人だけだから、担当者フォルダを作らなくても良い。」とか、
そういった、その場の思いつきや手抜きは絶対にダメ！！！！！

次に考慮すべきは、フォルダ名とファイル名の付け方。これは半角英数が基本。
フォルダ名やファイル名に日本語の名前を付けたがる人は多いが、
日本語は、異なるOS間でのデータ交換の際に文字化けする可能性がある。

この問題は、特に、圧縮ファイルを扱う場合に生じる。
Windowsでは、圧縮する際にファイル名をShift-JISに変換し、解凍時にUnicode に戻す。
ところが、Mac やLinux 上では、Shift-JISのまま解凍されるため文字化けしてしまう。

文字コードの話については、すでにしている。

Windowsしか使わないから、とか、そういった考えは良くない。
一次データを作成する段階で回避できる問題は、可能な限り回避することが重要。
半角英数の部分は、Shift-JISとUnicodeのいずれもASCIIコードに従うのでこの問題は生じない。

また、フォルダ名やファイル名に関しては、スペース（空白）を入れたり、
「.」「,」「;」「:」「<」「>」「-」「+」「=」「\」「/」「|」「?」「！」...。
といった記号類も使ってはいけない。

使って良い記号は「_（アンダースコア）」のみ。と覚えておくと良いかもしれない。

以上が、一次取得データの管理方法の一例である。
基本的に一次取得データは、データ取得時の状態のまま触らない。
間違っても、上書き保存は絶対にしてはいけない。

このデータをコピーしたものを別の場所に移動し、二次加工データとして編集する。
一取得データは、調査の段階に戻る為のデータであり、
調査のバックアップであるとの認識が必要。

ところで、一つのファイルを何日もかけて処理する場合はどうするか？方法は二つある。
一つ目の方法は、前回のデータを新しくコピーしてから再編集する方法であり、
もう一つの方法は、二次加工データとして扱う方法である。

一つ目の方法は、中間データのバックアップにもなるため、
途中で大きなミスが生じた場合、編集前の段階に戻ることができるという利点がある。
しかしながら、データ容量が非常に大きい場合、ディスク容量を圧迫する可能性がある。

二つ目の方法は、あくまで二次加工データとして扱い、
今回の話で述べてきた体系とは異なる体系で管理する方法である。
次回の話では、この辺りを整理してみる。