 |
||||||||||
|
||||||||||
| 前のページ 1 2 3 次のページ | ||||||||||
|
||||||||||
| ドキュメント管理：「技術」が先か「ユーザ」が先か | ||||||||||
|
このように、代表的なデータベースであるリレーショナル・データベースにて、ドキュメントを格納／管理しようとすると、実際の活用／運用ベースで考えた場合に大きな問題が生じる。つまり、情報の入力方法が不便であれば、そもそも誰も「情報を入力しない」ことは容易に予測がつくであろう。 ましてや過去のドキュメント資産がそのまま登録できず、当該の「新たなツール」に即して再登録が求められるとなれば尚更のことである。また、ドキュメントの生成を例えばWordなどにて手軽に作成でき、データベースへの格納も当該のファイルのまま行えるとしても、格納したドキュメントが的確に検索できなければ、そのうちに使われないシステムとなって行くのは自明のことだろう。 例えば、従来はWordで作成されていたドキュメントをファイル共有からデータベースでの管理へ移行するケースを考えてみると、「ファイル共有では的確なドキュメント検索ができないので、全文検索ではなく項目単位での検索を重視したい」「ドキュメントの部分的な再利用を促すために、意味構造に即した要素／断片に分解し管理したい」という要望がユーザ側から上がっていた場合、担当SEは「リレーショナル・データベースで当該要件に対応するには、データベースに適した構造に分解／再構成して格納する必要がある」という技術的な制約に基づく判断のもと設計／実装を行うだろう。 しかし、実際にシステムを導入してみると、データベースの構造に即した入力に適したインタフェースとして採用された「フォーム入力画面」に対して、ユーザ側からは「数字や短いテキストの入力なら我慢できるが、長い文章の入力となると、Wordのように仕上がりを確認しながらドキュメントの全体を俯瞰できないので使いにくい」といった操作に関する不満から、「業務上の要件で必要な例外事項に対応する項目がない」といった運用に伴う不満まで、様々な問題が噴出することが予想できる。 つまり技術的な諸制約を前提に、それらにユーザを無理に合わせようとするやり方、ましてやそれが「ユーザが慣れ親しんだ環境を一変させる」方法（先の例では、Wordからフォーム画面への変更）となると、自ずと無理が生じてくる。 このように潜在的な問題が存在しているにも関わらず、ドキュメント管理の現場では「システムを設計／構築する側」の理屈と「利用者側」の理屈が噛みあわないまま導入が行われ、運用の段階になり問題が噴出するケースが多い。 では、ユーザにドキュメント作成環境の大幅な変更を強いることがない、ドキュメントの管理に適した技術は存在しないのかといえば、それは否である。現時点ではまだ主流にはなっていないが、ネィティブXMLデータベースとOffice XMLの組み合わせこそがその「突破口」であると、筆者は考えている。そこで次項では、ネィティブXMLデータベースにおけるドキュメント管理について簡単に説明する。 |
||||||||||
|
前のページ 1 2 3 次のページ |
||||||||||
|
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
-
-
連載
