Kansas Diary～カンザス日記

さて、パソコンが普及して久しく、写真や文書、
データやイラスト、会議の打ち合わせ覚えや、仕様表
図面、通知書など非常に簡単に電子化できる昨今。

皆さんは電子データの整理・整頓をどのように進めてますか？

整理・整頓の目的は、
必要な情報を必要なときに素早く到達できること。

デスクトップ用の全文検索ソフトなども出てますが、
情報漏洩のリスクを避ける意味からも、ちょっとそれは
使用しないという前提で、考えてみたい。
（かつ高度なデータベースソフトがない場合）

１０や２０個のデータで、それ以上増えないなら簡単だ。
ファイル名だけで内容を識別できそうだ。
あまりカテゴリーを意識せずに、漫然と保存してもたかが
しれている。

しかし実際仕事などでは、１０００や２０００ファイルは当然
存在しているし、メール履歴だけでも、増え続ける性質を
併せ持っている。

皆さんはどのようなカテゴリで分類してますか？

［年（もしくは年度）］
２００８年フォルダとか２００７年フォルダを作成するパターン。

［プロジェクト］
「コストダウン」とか「新機種開発」フォルダとかを作成するパターン。

［製品のモデル名］
「TYPE－A」とか「TYPE－B」フォルダとかを作成するパターン。

［製品の細かい部位名」
「ブレーキ」とか「ポンプ」とか「エンジン」フォルダとかを
作成するパターン。

［おおまかな部品のカテゴリ名」
「油圧機器」とか「電子部品」とか「溶接部品」フォルダを作成する
パターン。

ファイル形式で分類、ｐｄｆとかｘｌｓとか、
アクセス頻度を分析して頻度大、頻度中、頻度小フォルダを作成し、
よく使うファイルを頻度大に入れる癖をつけるとか、、
考え出したらキリがない、そしてどれもそれぞれで問題がある。

Windows標準の検索機能で使えるインデックスは豊富とは
いいがたい、、ですし、、
ファイル名、拡張子、日付、、、くらいからしか検索できない、、。

Windows上でのファイル分類というのは、MECEのように、
もれなく、だぶりなくというカテゴリ分類にしないと、ちょっと厳しい
かもしれないが、やりすぎると、フォルダが多くなりすぎてしまう。

整理整頓の目的である、必要な情報を必要なときに
素早く見つけること、、というのはフォルダ構造だけでは
達成は無理なのかもしれない。

・検索の自由度・柔軟性
　複数のキーワードで絞り込める、
　ファイル名でも、プロジェクト名でも部位でも探し出せる
　自由度、柔軟性。

・フォルダ構造の工夫で検索・絞込みの手助け
　検索機能、標準検索ソフトでヒットさせにくいカテゴリを
　物理的フォルダ構造で分けて、検索するフォルダを
　限定させて、素早く検索するように手助けする。
　
・ファイル名の工夫で内容把握のスピードアップ
　全文検索を使わずに、ぱっと見て
　報告書なのか、日程表なのか、図面なのか、外部からの
　資料なのか、部内の資料なのかなどなど、が最低限識別
　できることが重要と思う。

　報告書番号をファイル名にしているのも非常に多いが、
　１００個もあると、例の件の報告書は何番だったか？ということになり
　報告書のためのインデックス（目次）を作らねばならないとか、
　いくつか問題はありそうだ。

何年か前から、ちょっとづつ試験的に色々な案を実践しているが、
今現在、試験的に実践しているフォルダ構造は、

「生きているデータ」フォルダと
「死んでいるデータ」フォルダと
「ゴミ箱」フォルダという分類だ。

試験的なので、プロジェクト名のフォルダの下に上記の
フォルダ構造にして試している。

「ゴミ箱」にはいずれ削除すべき、間違ったファイル、新ファイルに
置き換えられたファイルで履歴参照不要なファイルなど、
見る必要が今後永久にないファイルの置き場だ。

「死んでいるデータ」というのは、情報としては今も有効だが
ある時点で完了した結果としてのファイル。
逆にいうとアップデートされないファイルだ。
全ての報告書、変更不能なPDFファイル、
何かを依頼したときのFAXや文書、図面データなどなど。
このフォルダ内の分類はまたいつか記載しよう。

「生きているデータ」フォルダの中には、
文字通り進行形のファイル、定期的にアップデートされるべき
ファイルがメインだ。
そしてこのフォルダ内には可能な限り少ないファイル数にする
ことで、情報検索速度を短くするという狙いもある。
そして自他部門が動ける最新情報を掲載しておく。

あとはこのフォルダに対する常習性を付加すれば
試験の第一段階は終了なので、ここを見れば情報がある
という気持ちを植えつけることでしょうか。
（ブログの毎日更新と訪問者の関係と同じでしょうか）

細かな内容は直接会議や電話ですり合わせが大事だが、
それ以前のレベルの情報まで会議や電話でするのは
若干ムダなので、意外に多いのが私の認識だ。
その無駄取りをできるかもしれない、という狙いもある。

シンプルな構造が、スピードアップを生むような気がする。


（以下、様々なシミュレーション、読む必要なし）
「あ～あれは、たしかエンジンのデータだったはずだが、、、、」
というときに部品分類でフォルダ分けしていた場合は
とにかく全てのモデルのエンジンデータがそこに入ってるので
そこを検索するだけでOKだ。（ファイル数が多いと、これでも問題だが）

モデル名分けしたフォルダ構造では、モデル１のエンジンのデータ
だったか、モデル２のエンジンのデータだったか、モデル数が
多くなると、モデル名分けは、ちょっと劣勢だ。
でも現実はこのモデル名フォルダ構造が一番近いかな。
（実際はプロジェクト名フォルダだが）

年度分けも、２００８年に作成したファイルが非常に重要で
次年度以降も十分通用するファイルだった場合、それを
コピー（もしくは移動）して、２００９年フォルダに持ってくる必要がある。
1個や２個のファイルならいいが、１００個を越えると、引越しのための
識別だけで嫌気が差してくる。で、結局まるごと持ってきて
容量を考えなさいと、クレームを受けたりする。（苦笑）

そしていつかは、後になって要望が出てくる欲しいデータが
何年のプロジェクトだったか忘れ、、、あちこち探して、結局
DVDに書き込まれて、書棚の中ということが想像に難くない。

「油圧」とか「電子機器」なんていう大枠でのフォルダ構造も
「油圧」フォルダの中にモデル名、部品名フォルダを作成して
いくのか？
油圧－ポンプ
　　　　　　－モデルA
　　　　　　－モデルB
　　　　　　－モデルC
　　　－シリンダ
　　　　　　－モデルA
　　　　　　－モデルB
　　　　　　－モデルC
　　　－モータ
・・・
電子機器－スイッチ
　　　　　　－ハーネス
　　　　　　－ライト
・・・

一見良さそうだが、それぞれの部品に関する図面データは
この分類ではバラバラのフォルダに入ってしまうので、
図面データは一元管理で別フォルダにまとめるのが通例ですね。

モデル間で兼用しているシリンダがあった場合は、上記フォルダ
分けでは、ややこしいことになりそうだ。

と、頭の中でのシミュレーションをつらつらと書いたが、
これはごく一部のシミュレート結果である。