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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

とにかく、

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

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

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

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

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

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

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

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

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

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

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

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