[2]文書管理システムの評価軸を選ぶ

ポイント

文書管理システムの製品の違いや製品の性格を把握するのに適した分類軸として、私たちは六つの評価軸を見つけました。相関関係の強い軸を統合して、二つに絞り込み、理解しやすくしてみます。

連載記事

文書管理システムの評価軸

ここから文書管理システムを選定するにあたっての評価軸について、さらに一歩考察を進めます。私たちが20年以上にわたって文書管理システムを見てきて、製品の違いが出る、あるいは製品の性格を把握するのに適した分類軸と考えているのが、次の図で示した６つの評価軸です。

六つも評価軸があると、3次元空間に生活する私たち人間には理解が困難ですので、相関関係の強い軸を統合することで、主な軸を二つか三つに絞り込み、理解しやすくしてみましょう。

管理強度による評価軸：「かたい管理」と「ゆるい管理」

これは、ユーザの操作に制約を加えて管理を強化するか、ユーザの操作をあまり制約しないか、という視点の分類です。

「かたい管理」の製品は、文書を登録する際に必須の入力項目が多いのが特徴です。担当者名や主管部門名、クライアント名やメールアドレスなどを入力しないと文書のアップロードができない。一度登録された文書の更新は変更申請を出して承認を得なければできないといったワークフロー管理、あるいは満期契約の自動更新や期限切れ文書の自動削除などの期限管理など、こういった制約が多いものが「かたい管理」の製品と言えます。

一方で「汎用ストレージ」は「ゆるい管理」の代表的な製品。文書の属性の入力は任意、ドラッグ＆ドロップなどで文書をまとめて登録可能、承認ワークフローはなく、せいぜいアクセス権管理まで、書き込み権があれば誰でも書き込めるなど、ユーザにとってはシンプルで使いやすいものです。

こうした観点で文書管理システムを見ていくと、「かたい管理」の製品は、特定種類で比較的少量の公式文書、正規文書を管理するのに向いています。公式マニュアルなど変更時にミスがあってはならない文書をダブルチェックするとか、重要文書なので査問委員会などで承認を得てから更新するとか、しっかりした手続きが必要な文書向けです。それに対して「ゆるい管理」では、文書をまとめて動かしたり登録したりできるので、多種多様で大量の、どちらかといえば非公式な作業文書がたくさんあるようなところに合う傾向があります。

対象ユーザによる評価軸：「管理者重視」と「現場ユーザ重視」

次に、管理者を重視するか、現場のユーザを重視するかという視点にも、製品の性格の違いが出ます。多くの企業や組織で、管理職や役員が文書管理システムの導入を望む場合、その動機は、どこにどんな文書があるかがわからないからシステム化を機に一元管理したい、ということが多いでしょう。複数のシステム、複数の保管場所に分散して管理されている文書を、必要に応じて巡回して確認するのは多忙な管理職の立場では困難です。そんな管理者にとって、「ここに行けばたいていの文書が見つかる」という入れ物は大変ありがたいものです。すべての文書とは言わないまでも、プロジェクトの最終成果物・最終納品文書・重要文書などが一元管理される文書管理システムに期待したくなるというわけです。

分類体系やメタデータ（属性）の入力を重視して、文書や案件の最新状況、類似文書の差異や文書の変更事由、担当者・作成者・責任者などの関係者情報、顧客・物件・案件などのキー（ID）項目など、プラスアルファの属性情報を現場のユーザにお願いして入力してもらう。その情報が入っていることで管理者が見てわかる状態を作る。こうしたニーズによって構築するシステムは「かたい管理」に向かいやすいと言えます。

一方で、現場重視の製品は、とにかく日常の効率を上げるために普段の操作を楽にしたいときに使う製品であり、業務が非定型的で臨機応変の対応が必要な場合に力を与えるような製品です。

たとえば私たちのFileBlogもこれまで、どちらかというとこの視点を重視してきました。いかにマウスの移動距離を減らせるか、クリック回数を減らせるか、キーボードの入力回数を減らせるか、検索応答性能は0.01秒単位で速いか――。こうしたことを徹底的に考えて、このボタンの隣にはこのボタンを置こう、これとこれは近くにあるべきだ、などと10年以上考えてきました。作業の標準化を支援する製品は、現場の操作性の足を引っ張らない範囲で「ゆるい管理」に向かいやすいと思います。

機能による評価軸：「管理機能の充実」と「共通機能の充実」

機能による軸で見た場合、管理機能の充実は、先ほどから見てきた「かたい管理」と「管理者重視」に相関関係があります。文書管理システムの管理機能にまず必要なのは、文書を分類する機能です。そこにアクセス権管理や属性管理が加わると、少しずつかたい文書管理システムに近づいていきます。さらに、属性値の入力を支援したり入力値をチェックしたりする機能、文書の変更履歴を自動的に残して古いバージョンを戻せたり新旧バージョンの差分を比較したりする版管理の機能、文書の変更申請をして上長が承認するといったワークフロー機能などがあると、管理機能が充実した製品と言えます。個別業務や特定の文書を扱う専用システムでは、その業務向けにワークフローを設計したり、ある文書種類に限定した版管理機能を作ったりすることで、管理機能が充実していく傾向があります。

一方でこれらの管理機能以外にも、あらゆる文書、あらゆる業務に使える、文書横断的、業務横断的な共通機能、便利機能というものがあります。例えば、文書を一覧表示して閲覧する機能。検索機能もファイル名検索、属性検索、全文検索はあれば便利な必要です。しかし、全文検索の機能を持つ製品はそれほど多くありません。近年はリモートワークの定着により、Webブラウザから文書を閲覧したいというニーズも高くなり、デザインを工夫して登録・参照・更新などの操作性を向上させることにどれだけ力を入れて開発しているかなど、こうした共通機能の充実が問われる機会が増えています。この「共通機能の充実度合い」も、製品の性格を物語るもう一つの軸であるといえます。

管理機能と共通機能は決して矛盾するものでなく、同時に充実させることもできますが、実際の製品開発において、限られた期間と予算で両方作ることは困難です。したがって、汎用性の高い文書管理システムは管理機能をそこそこにして共通機能の実装に力を入れがちです。逆に専用の文書管理システムではワークフロー管理を含めて管理機能を一生懸命作りこむ傾向が強く、共通機能まで手が回らなくなって省略される、という傾向があるのではないかと思います。

所有形態・運用形態による評価軸：「クラウド」と「オンプレミス」

最後に、サービス事業者が所有するハードウェアに利用料を支払って使う「クラウド」なのか、自社でハードウェアを所有して運用する「オンプレミス」なのか、という所有形態・運用形態による評価軸を考えてみます。オンプレミスは自前で運用管理する必要があるので、管理の面ではどう考えてもクラウドが楽です。サービスが順調に成長しているときは料金も安く、バージョンアップもされて継続的に機能改善されるメリットがあります。ただし、サービスが成熟して低成長局面になると、利用料の値上げやバージョンアップの停止などによるサービスレベルの低下、最終的にはサービスの終了やサービス事業者の倒産といったリスクが出てくる可能性もあります。

オンプレミスの運用では、製品の保守切れやハードウェアの交換時期になると新しいシステムへの移行が必要になるので、定期的に作業工数やコストが発生します。これは確かにオンプレミスのデメリットです。しかし、Windowsファイルサーバによる運用ではそれほど心配ありません。Windowsファイルサーバは、Windows 95の時代から30年近く世の中に存在していて、Windowsが動くPCサーバが複数のベンダーからいつでも買える。例えば、購入から5年が経過して新しいハードウェアにのせかえる場合、どのベンダーの製品であっても比較的簡単に引っ越しが可能です。バックアップツールや運用ツールが充実していて、構築・運用に詳しくノウハウを持つ人材も豊富です。大量のデータを比較的安価に保管できるソリューションだと言えます。

また、クラウドがどう逆立ちしてもオンプレミスにかなわないのは、LAN内に機器があるので社内で使う分には圧倒的に速い（応答性能に優れている）ことです。社内のファイルサーバの文書をダブルクリックして開くのとインターネットの向こう側にある文書をダウンロードして開くのでは、かかる時間がまったく違います。特に文書のサイズが大きくなると顕著になってきます。