2012/12/28

文系のための「調査データの構造」(1)

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

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

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

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

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

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

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

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

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

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

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

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

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

まずは、調査の階層構造について考えてみる。
概念的に解り易くするために図化したものが下の図。
あるプロジェクトがあったとして、
そのプロジェクト年度区切りあるいは複数の調査次数から成る。
たとえ、一回限りだったとしても、プロジェクトは調査次数がある

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

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

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

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

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

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

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

とにかく、

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

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

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

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

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

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

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

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

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

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

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

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

0 件のコメント:

コメントを投稿