4回シリーズ記事の[2]です
ファイルサーバは、もともと汎用のストレージ、つまり、どんな種類のファイルでも、何でも保存できる記憶装置です。そんなファイルサーバを文書管理システムとして応用する場合には、ファイルサーバならではのメリットがあり、課題があります。
ポイント
ファイルサーバは、大容量データの長期保存が得意ですが、ファイルの整理整頓が難しい
物件／案件／顧客など、業務対象の何かと対応させて、フォルダで書類を管理することは一般的テクニック
それでも、件数が増えて大量になると、フォルダを見つけることが困難になります
ファイルサーバのメリット
あらためてファイルサーバのメリットを整理してみましょう。
大容量
まず、大容量データの保存が得意です。Webアプリケーションやデータベースシステムに比べると、巨大ファイルのアップロードが高速で、登録可能なファイルのサイズも上限がありません。
ファイル名・フォルダ名・分類階層の自由度が高い
フォルダ構造やファイル名の自由度が高いことも特長です。フォルダを何階層でも深く作成できますし、ファイル名・パス名の文字数制限も約3万文字と非常に大きく、いくらでも長いものが付与できます。通常のデータベースシステムは、ファルダは最大で5階層、ファイル名は最大で300文字などと、ある程度限定される場合が多いのですが、ファイルサーバの自由はケタ違いです。
ハードウェアの選択肢が多く安定供給されるので、初期コスト・長期的コストともに安い
WindowsOSが動くハードウェアであればどこでも動くので、ハードウェアや運用場所の選択肢が圧倒的に豊富です。PCサーバでは、大容量で容量単価が安いハードディスクが使えてアクセス性能が高い製品を選択できます。バックアップシステムをはじめ運用管理を支援するサードパーティ製の関連ツール群の選択肢も多く、多数の製品が常に供給されています。
個人PC並みの安価な製品から、数百テラバイト・ペタバイト級の大規模ファイルサーバまで、対応できる製品が見つからないことはありません。厳しい競合があるゆえに、相対的な低価格が保証されています。
Windowsファイルサーバは確立された技術、枯れた技術であり、今後10年、20年、30年経ってもマイクロソフトがWindowsを供給し続ける限り、様々なベンダーが安定してPCサーバを提供するでしょう。たとえば5年後、10年後にサーバが古くなっても、新しいものに入れ替えて世代交代させながら長期間使えます。文書管理システム製品で、これほど安定して将来が読めるものはありません。（実際に、お客様が社内で運用しているWindowsファイルサーバも、初代のハードウェアが老朽化して、二代目・三代目と、移行による代替わりを繰り返していることでしょう。）
PCサーバ市場の大きさからくる選択肢の多さが長期的にも続きそうなので、長期間にわたる安定運用についても、比較的低コストで継続できると信じることができます。
ファイルサーバの課題、整理整頓の限界
とはいえ、ファイルサーバを文書管理に利用するユーザにとって、課題がないわけではありません
整理整頓はユーザ責任で難しい
ファイルサーバではファイルが自由に保存できるので、何の管理も行わずに野放しにしていると無秩序に散らかってしまい、ファルダ階層の深さがあだとなって目的のファイルが見つからないといったことが起きる場合があります。
散らかったファイルサーバをどうするかという課題に対しては、大きく分けて下記二つのアプローチがあります。
- ひとつは、ルールを作って運用し、工数をかけてでも整理整頓をするというもの
- もうひとつは、整理整頓のための工数を無駄とみなし、整理整頓をあきらめ、エンタープライズサーチ製品を導入するというもの（技術の力業によってファイルが見つかるので、「見つかるなら整理整頓しなくてもよい」という立場をとるものです）
私たちは「FileBlog」というエンタープライズサーチ製品の開発元であり、「エンタープライズサーチ」はもちろん役に立つと別記事で主張しておりますが、エンタープライズサーチ製品の検索能力は万能ではありません。整理整頓されていないファイルサーバから目的のファイルを見つけ出すよりも、整理されたファイルサーバから見つけ出すほうが速いことは事実です。
そこで、以下では「整理整頓の何らかのルールがある」ことを前提とします。特定文書種類に限定した文書管理目的でのファイルサーバ利用では、比較的厳しい運用ルールのもとで、整理整頓したファイルサーバのフォルダ階層を構築していることがほとんどです。
物件No／案件ID／顧客No／原稿ID をフォルダ名にする管理
最低限の整理整頓ルールとして、どこの会社でも極めて一般的にみられるのが、管理対象のエンティティにIDを付与し、そのIDをフォルダ名としたフォルダ階層をファイルサーバ上に構築するというルールです。
たとえば、物件IDを物件ごとに1対１で付与して、そのIDをフォルダ名の先頭に必ず付けるといったような厳格なフォルダ命名ルールを設定していれば、ファイルサーバでもかなり整理された状態を作ることが可能です。物件IDや案件IDでフォルダを作成しておけば、個人や部署、チーム別のフォルダの下に担当物件のフォルダがあるといったような無秩序なものではなく、全社として物件フォルダが1か所に並んでいて、IDが分かればすぐに見つかるという状態が作れます。
整理整頓のためのルールがあっても、検索は難しい
しかし、それでも数の暴力というものには勝てません。物件数が数千件、数万件になると目的のファイルまでたどり着くのに手間取るようになってきます。また、IDが分かっていれば比較的早く目的のフォルダに到達できるのですが、顧客名や物件名からIDを調べてフォルダを開きたい場合には、一発で検索することが難しくなり、別に用意してある物件台帳管理データベース（DB）で顧客名や物件名で検索して、見つかったIDでファイルサーバのフォルダを探してアクセスするという、二段階で検索する必要が出てきてしまうのが一般的です。そうした管理台帳は小規模だとエクセルのワークシートで済みますが、ある程度規模が大きくなるとSharePointやKintone、Accessといったデータベースシステムで管理台帳を構築するということになってしまいます。こうしたことがファイルサーバでの文書管理の限界・問題点であるといえます
つづき [3]ファイルサーバによる物件データフォルダ管理事例
関連事例
物件／案件別文書保管
情報への入り口を統一して、情報共有を大幅に効率化 － 建設業 設計・工事管理部門
