最近、自社関連の各Blogが、書き出し部分にスマートに近況報告的な世間話を混ぜ込んでいくスタイルに収斂しつつあることに危機感を感じています。
前回の、補足でもあるのですが、ECMはファイルが基本の管理単位になります。従って、図面管理においても物理的には1ファイルにまとめてある中で「特定のページをめがけたリンクを埋め込みたい」、というニーズがある場合は、そのまま適用するのは難しくなります。（例えば1ページ毎のレンディション（PDF版）を別途作成し、そちらを参照させる、などのテクニックはありますが）
今回は、ファイルが主役である、という特性を改めてご説明した上で、CCMS（Component Content Management System） コンポーネント・コンテンツ・マネジメントシステムというコンセプトについてもご紹介したいと思います。
ECMの基本とする管理単位が「ファイル」であるということ
あちこちの講演でも繰り返しご紹介していますが、ECMはかつてはEDMS、電子的文書管理システムといわれたコンセプトの後継にあたります。時期としてはおおよそ2000年あたりにこのキーワードの交代劇が発生しました。なぜ、文書（Document）をコンテンツ（Contents）と読み替えることになったのでしょうか？
1つには、Webに代表されるインターネット技術の台頭があります。HTMLで記述される「ページ」は、その呼び名とは裏腹にあえて再現性の低い印刷工程を通さないと「頁」もなく、文書という従来からある言い回しに収まらないインパクトを持つものでした。また、技術的にも、体裁情報を定義したスタイルシートや画像ファイルなど複数の「ファイル」によって構成されていますし、特定のポイントを指さすリンク構造も持っています。そのため、当時はWebページを管理するためのコンテンツ管理システム、WCM（Web Content Management）の製品が多数出荷されました。このジャンルは後にPHPベースのシンプルで安価な製品群が席巻し、カジュアルにCMS（Content Management System） コンテンツ管理システムと言った場合、一般的にはECMの様な文書管理ではなくこれらのWebコンテンツの管理システムを指すようになっています。
2000年代においては、EDMSから進化したECM製品もWebコンテンツの管理機能を取り込もうとしていましたし、Javaで構築されたような重厚なWCM製品もECM的な文書管理やワークフロー、コラボレーション機能などを製品に取り込む努力をしていました。例えば、2005年に立ち上がったAlfrescoにおいても、WCMモジュールが後から追加されています。この時は、「重厚なWCM製品」の代表格であったInterwovenのチームのエンジニアを引き抜いて、かなり大がかりなフォルダ仮想化技術を実装していました。これは素晴らしい機構でしたが、ここでお話しているようにECMがファイルを基本単位としている一方でWebコンテンツはその枠組みに収まらないというギャップがあり、Alfrescoの内部構造に異なる2つのリポジトリエンジンを抱える構造を余儀なくされていました。結果、数年後彼らはこの重厚な仕組みを放棄して軽量なWebページ作成機能を別途開発します。そしてさらに、現在ではWebサイト側にもそれなりに複雑な要件があるケースではDrupalなどのPHPベースのCMSを別途立ててインテグレーションしたり、Liferayを並立させたりする構造が一般的になっています。
それだけ何を基本の管理単位としてシステムを設計するのか、というのは大きな問題であるということだと思います。
ワンソースマルチユース
全社的にECMが導入された場合、所謂コンテンツ・文書・非構造データについても、ワンファクト・ワンプレイスが実現します。冗長なコピーを作る必要がなく、漏洩の恐れもなく、必要な時に必要な人に必要なコンテンツへのアクセスを提供できます。（かなりの理想論ですが）
一つの文書が、色々な目的で使い回されることになります。
ワンソースマルチユースというキーワードがありますが、これはここでいうような「複数の業務プロセスや部門から横断的に同一のコンテンツが利用可能になる」というのとは少し違うニュアンスを持った言葉です。具体的には、コンテンツの意味内容をXMLなどのプレーンな形式で管理し、体裁情報をスタイルシートとして別管理しておけば、印刷用、Webページ用、ダイジェスト出力用、など同一の内容で体裁が異なる出力結果を得られる、という状態を指しています。これにより、意味内容に変更があった場合は1カ所だけ修正すれば、すべての出力結果にその修正を反映させることができるようになるわけです。
弊社の取り扱い製品のラインナップの中では、Alfresco上にDITAというXML標準を扱う機能を実装したComponizeが、このワンソースマルチユースを実現するための仕組みになります。
DITAの詳細の説明はここでは省きますが、トピックという単位で意味内容を表現した（主にテキストの）部品をなるべく文脈に依存しない形で構成し、マップという単位でそれらのトピックの構造をまとめあげ（目次を定義して、どの順番でトピックを並べるのか、を決めてあげます）、そこにスタイルシートを適用して体裁情報を加えた出力結果を得る、という仕組みです。意味と体裁、ではなく、意味の断片と構造と体裁、を独立したコンポーネントとして管理するわけです。
これらの管理をシステム的にサポートするのが、CCMS コンポーネント・コンテンツ・マネジメントです。この仕組みでは最終的には1つのファイルとして提供されるマニュアルの中の特定の箇所をめがけてリンクをはったり、そこを書き換えたりということも可能になるわけです。
CCMSではファイルが基本単位になっていない？（＝ECMとは相性が悪い？）
DITAはXMLの規格ですから、通常ECMが扱うような文書ファイル、Word Excel Powerpoint PDF、の類いに比べてHTMLやWebページに近い技術です。そう考えると、ECMによるWCMの取り込みが失敗に終わった歴史を振り返るに、Alfresco上にDITAコンテンツの管理機能を実装するというComponizeの取り組みは一見筋が悪いものにも見えてきそうです。
しかし、私はこれは非常に洗練された仕組みだと考えています。つまり、出力結果の1ファイルに主眼を置いてしまうと、その構成要素は複雑に絡み合う複数の部品となり、ECMが苦手とする領域に踏み込んでいるように見えますが、通常直接編集を行う個別のトピックを定義するファイルに注目して考えた場合は、依然として1ファイルが基本の単位になっているからです。
AlfrescoもECM製品として十分な「ファイル同士の」関連付け機能を備えていますので（残念ながら基本のUIからはその機能は見えづらいのですが、内部機構には強力な仕組みがあります）、どのトピックがどの出力結果に利用されているか、などの情報はファイルを基本単位としたまま適切に管理されています。
これらはDITAという標準規格がしっかりと定義されていて、わざわざ関連付けまで含めた管理機構を実装するに足るメリットがあるからこそ実現している仕組みであるとも言えるでしょう。
DITA/CCMSのメリットや必要性
残念ながらこれでワンソースマルチユースの洗練された管理機構を実現できるのはDITAが対象としているようなマニュアルや仕様書などのテクニカルドキュメントだけですが、その導入メリットは非常に高いものであると考えられます。
もちろん、管理の仕組みが大きく変わるだけでなく文書の作成方法も従来通りとは行かないため学習コストは相対的に高くなりますし、いかにDITAが洗練された規格であったとしても、既存の規格を知らずに作成されたコンテンツをその枠組みに押し込むには難しい判断を求められるケースも多くなります。（最近では、規格自体のアップデートなどもあり得るので、その動向に目配せをしながら判断した方がより望ましい、なんていう面もあります）
それでも、最終的なコンテンツの管理コストを下げ、陳腐化したコンテンツが滞留しないようにしていくことのメリットは非常に大きいはずです。未だ多くの企業においてはコンテンツの整備は製品・サービスそのものの提供と比べると副二次的なものであるという扱いを受け、管理人員が十分に提供されない状況があります。製品・サービスそのものと違い、コンテンツは何もしなければ堆積していきます。活用機会を失うだけでなく、誤った情報が残り続けることで、様々な領域で問題を生じる可能性があるわけです。
こうした観点から、広く技術系のコミュニケーションに問題意識を持っている方も徐々に増えているのではないかと思います。Componizeはクラウド上でのトライアルも可能な製品ですので、是非お気軽にお声がけを頂けると幸いです。
あー、また長文ポストになってしまった。一応、営業っぽいメッセージも入れたから許して欲しい、という業務メッセージを追加して、結びの挨拶とさせて頂きます。
（文責 Ishii Akinori IT-Coordinator）
最近のコメント