ファイルサーバによる案件データフォルダ管理法［2］

専用文書管理システムへの移行不要！
ファイルサーバを丸ごと活かし
検索性と閲覧性を高めて文書管理システムとして利用する方法

物件フォルダ管理の例

では、ファイルサーバで案件フォルダ・物件ファルダを管理する場合、実際にどのような方法で行っているのでしょうか。

たとえば、建設会社や不動産会社では、物件ごとに物件IDを付与して物件フォルダを作成するのが一般的です。物件IDが4ケタの数字だとすると、図1のように物件フォルダが並んでいて、各物件フォルダの中には施工図面や現場写真などを工程別やメンテナンス時期別のサブフォルダに分類して保持します。

図 1：物件フォルダ管理の例

完全に連番だけで1つずつ増やしていくパターンもあれば、年度＋連番、受注日などの年月日＋連番といったパターンもあります。これをファイルサーバ上に置くときには、これらの連番をフォルダ名にしてもいいですし、連番の後ろに物件名称を付けたフォルダ名にする方法もあります。

重要なポイントは、フォルダ名のキー項目はIDのような長期安定型のものが必須だということです。そうすることで、ファイルのパス名を長期的に不変とすることができるからです。

図 2：IDの命名標準のバリエーション

物件名はオーナーが変わると変更される可能性があり、会社名もM&Aによって変わるケースがあります。都道府県名は変わらなくても、市区町村は合併などで変わる可能性があります。固有名をフォルダ名に含める場合には、ファイルのパスを他の文書から参照しているような場合に、いわゆる「リンク切れ」が発生する可能性が将来あることを覚悟してください

IDベースのフォルダ階層のバリエーション

物件IDを使用してフォルダ階層を作るバリエーションはいくつかあります（図3）。連番のIDそのもので完全にフラットなフォルダ構成にする。年度フォルダの下にその年度に発生した物件フォルダを配置する。年度の下に月別フォルダをはさんでより細かく分割する。あるいは連番を基準にして、たとえば上位3桁を親フォルダにして管理する。たとえば、こういったいくつかのパターンが考えられます。

図 3：IDベースのフォルダ階層バリエーション

このうち、完全フラットだけはおすすめしません。数千・数万のフォルダが並ぶとファイルシステムの一覧性能が落ちてくるからです。Windowsエクスプローラーなら1分くらいはフリーズするかもしれません。他のアプリケーションやシステムも性能が落ちます。1フォルダあたりのサブフォルダの数はせいぜい1,000件程度以内になるようにしたほうがよいと思います。

期間に係属させる場合は、基準日の扱いに注意が必要です。たとえば、竣工日を基準にしてしまうと、受注はしたが完成はしていない仕掛中の案件データを持つことができなくなります。また、年月にすると月に一度は新しいサブフォルダを作らなければならなくなるなど、必要以上に分類を細かくしてしまうと入力の手間を増やすだけになりがちです。したがって、年度でのフォルダ階層、位取りのフォルダ階層あたりが、現実的な方法としておすすめです。

ただし、ファイルサーバ全文検索エンジンがあれば、このうちのどんなフォルダ構成をとろうとも問題ありません。数の暴力にも対抗できます。トップフォルダの下でIDによるファイル名検索をすると、目的のファイルがあるフォルダに一発でジャンプできます。Windowsエクスプローラーでたどっていくよりも、このほうが30秒くらいは速く見つけられると思います。

管理台帳の必要制

物件管理では通常、何らかの管理台帳が必要になり、それを運用するデータベースをどうしても持たなくてはならない場合が多くあります。物件IDで検索するのが唯一の目的ではなく、キー項目となる物件IDや案件IDを採番したり、検索するときに取引先名や案件名、担当者、受注日などの属性で検索して物件IDを見つけ出したりするためです。昔ならAccessやFileMaker、最近ならWeb系のKintoneやSharePoint、あるいは受発注管理システムや業界向け物件管理パッケージなどで管理しているのではないでしょうか。

ただ、こうした管理台帳が別途存在していて、ファイルサーバ上に物件IDのフォルダを作っている場合は、二段階で検索することになります。たとえば、物件管理台帳DBを起動して取引先名で検索して、物件IDが見つかったら今度はWindowsエクスプローラーでそのIDのフォルダまでたどって目的のファイルを探すという具合です。

この二段階の検索手順を、1アクションにすれば当然早く見つかるようになります。その方法は原則として2つしかありません。

1つは、物件管理台帳DBに添付ファイルも登録して、各ファイルに属性として物件情報を付与するという方法です。要するに物件管理台帳システムに文書管理システムの機能を持たせるということになります。

もう1つは、ファイルサーバ上の物件フォルダに物件情報の属性を付与し、検索エンジンによって直接物件フォルダを参照できるようにするという方法です。物件管理台帳にファイルを入れるのか、ファイルサーバに物件情報を入れるのか、二者択一となりますが、前者の方が構築・運用の費用がかさむので、後者のほうが簡単です。

属性の付与はフォルダ単位を推奨します

弊社のファイルサーバ検索システム「FileBlog」は、単なる全文検索システムにとどまらず、ファイルサーバ上のフォルダやファイルに「タグ」と呼ばれる属性を付与することができます。この機能によって、ファイルサーバに物件情報・案件情報を入力できるのです。

属性（タグ）を付けるときに、フォルダ単位で付けるべきか、ファイル単位で付けるべきか。これも現場の作業工数に大きな影響を与えるポイントです。

フォルダにタグ付けする、つまり物件IDのフォルダを作って、物件ごとの情報を物件フォルダに付加すれば、タグ付けの作業は物件の発生時の一度だけで済みます。これが、入力作業負荷が最小限の方法です。

一方で、ファイルにタグ付けを行う場合は、ファイルを追加する都度必要になります。1つの案件につき多数のファイルが登録される場合、たとえば100ファイル分の情報を入力するとなると、1フォルダにタグ付けする場合の100倍の作業負荷になるわけです。

一般的な文書管理システムはファイル単位でタグ付けするものが多く、ファイルが多くなればなるほどタグ付けが面倒になります。そうなると登録が滞ったり、現場のユーザーが入力を省略してしまったり、適当なデータをダミーで入れたりするようになり、システムの利用が定着しづらくなることも考えられます。このような理由から、物件情報をタグとしてファイルに入力することを求めるような文書管理システムは、運用が事実上困難であるといえます。

ですから、当社のFileBlogのお客様ではフォルダにしかタグを付与しない運用が圧倒的に多くなっているのです。ファイルの属性管理をサポートする汎用の文書管理システムで、ファイルを階層的にグルーピングして上位のグループにタグ付けできる機能がないものは、物件管理のような用途には不向きであるといえます。物件管理システムで、1つの物件に複数の添付ファイルを付与できるものはありますが、添付ファイルをサブフォルダで階層的に管理するまでの機能を備えた製品はなかなか見つからないのではないでしょうか