ポータルの方のMagic Quadrant

Liferay's Thoughts on the 2014 Gartner Magic Quadrant for Horizontal Portals というLiferay社CEOであるBryan CheungのポストがLiferay Blogに上がっていますね。

Magic Quadrant?

ここを見て頂いている方の多くには説明が不要かもしれませんが、Gartner恒例のマジッククワドラントという各ソリューション領域毎のベンダ評価マップとそのレポートに対応した記事です。マジッククワドラントは横軸にCompleteness of Vision（ビジョンの網羅性）縦軸にAbility to Execute（実現能力）をとった4象限のグラフに各ベンダを配置したもので、それぞれ、両軸共に優れたポジションにいるリーダー（右上）、ビジョンは優れているが実行能力や実績でリーダーに劣るビジョナリ（右下）、限定された領域で優れた実行能力を示しているチャレンジャー（左上）、それ以外のニッチプレイヤー（左下）に分類されます。

この分類においてLiferayはリーダーに位置づけられています。Liferayがこの象限に入ってからもう何年もたつので若干驚きが薄れてるところもありますが、これは実は結構凄いことです。

まず、リーダーには他にどんなベンダがいるのかを見てみると、IBM・SAP・Oracle・Microsoftと業界の4巨頭のみです。Liferayの様にポータル専業の会社は他にありません。

また、IPOで盛り上がっているという意味でも、大規模案件への対応力をしっかり示しているという意味でもこれまで以上にプレゼンスを高めているAlfrescoが、ECMのマジッククワドラントでは6年連続のビジョナリ（それだって凄いことなのですが）ということからも、オープンソースモデルの専業ベンダがこの象限に入っていることが如何に快挙であるかということがわかると思います。

昨年は、MicrosoftとIBMとOracleに対して実行能力で差を付けられた形の4位（ビジョンの評価はOracleよりもやや高かったのですが）ぐらいのポジションでしたが、今年はLiferayよりも高いスコアを出しているのはIBMだけです。

Gartnerはどんなことを言ってる？

実際には原文を見て頂くのが良いと思いますが、各ベンダの強みと脅威についてのコメントが出ています。

Liferayに関しては、この数年Javaベースのポータル製品としては最も高い成長スピードを見せているし、無償版とEnterprise版をうまく両立させているという評価がまずあります。さらに強みとして、大規模案件にも怯まず実績を積んできていること、モバイル・ソーシャルへの集中投資を続け素早い機能強化を成し遂げていること、顧客満足度が高いこと、を挙げています。

一方脅威としては、ライヴァルと比較して会社が小さい（さすがにあのラインナップでは！）こと、ユーザがオープンソースベースのアップグレードやサブスクリプションのモデルに馴染みがないことが（未だに！）あり得ること、エコシステムが拡大しているが小さい会社も多くスキルセットも分散気味（ごめんなさい！）であること、標準で提供される機能が競合に比して少ないこと、などが書かれています。

とりあえず、脅威に関しては、日本で弊社が支援しながら導入を進めていく、という意味では、特に問題はなさそうですね。（標準機能は多い方がいいですが、個々の機能についてグループウェアなどと直接戦うのにも限界がありますし）

Liferay CEOのメッセージは？

これも冒頭のリンクから原文をあたって頂くのが良いと思いますが（公式の翻訳ではないので）、幾つか面白いと思った点を紹介したいと思います。

まず、なぜGartnerのこのポータル領域のレポートにいわゆるWebコンテンツ管理製品（WCM、CMS）のベンダが名前を連ねているのか、という点についてのコメントがあります。要するに、現代の企業Webサイトは一方通行の情報発信ではなく、顧客体験にフォーカスせざるを得なくなっている。結果として、匿名のアクセスを捌くための従来型からあるWCMの機能とリアクション（分析とか追跡とか）を行うデジタルマーケティングの機能と、ユーザの登録・認証前提の体験、いわゆるポータルやカスタマーサービスのための機能の両方が必要になってきている、と。

その上で、それなら、はじめからログイン前提の使われ方（後者）の方で鍛えられてきたプラットフォームの方が有利だよね？と言っているわけですね。

次に、リーンなユーザ体験（Lean UXP）というキーワードに対してもコメントを残しています。これはちょっとまた話がそれてしまいますが、要するに、「Web配信のために素材や記事を溜め込んで、使い回したり、ワークフロー承認したり...」という従来的で重厚なCMSよりも、もっとスピードを重視しつつA/Bテストをはじめユーザの挙動を分析して露出面をどんどん練り上げていく方が大事だよね、という新しいトレンドにどう対応するか、というポイントです。これについては、その重要性を受け止めつつ、従来的なフレームワークの価値を手放さずに実現する手段として、Audience Targeting EEというアプリを紹介しています。

アジャイルな方向に攻めすぎると管理が疎かになるので、これは良い方向性だと思います。（それでも、もっとリーンに攻めたい、っていうニーズはあるかもしれないですけどね）

最後に、ポータル領域の3大シナリオ、というGartnerのニーズの整理について言及しています。パブリックなWebサイトはデジタルマーケティング、サービスポータルは顧客体験、従業員向けイントラネットは生産性と知識、と言った感じで3つのポータルのコアなユースケースに対するフォーカスポイントを示しています。このあたりは、我々が感じている顧客ニーズの方向性とも一致していると思います。

Blogの引越を試した流れで調子に乗って書いてみましたが、例によってちょっと冗長というか長すぎますね。図もないし...

（文責 Ishii Akinori IT-Coordinator）

ECM : 文書管理ソフト なら （ ） : ワークフローソフト の空欄に入る言葉は？

先週金曜日、Questetra クエステトラさんの矢作さんにパートナー向けのトレーニングを実施して頂きました。

営業向けセッションと技術系セッションの2本立てということでしたので、弊社側も（業務改善系などの）コンサルティングチームのリーダーやOSSコンサルティングのメンバー、それにマーケティングの人間を巻き込んで色々とお話を聞かせてもらう会になりました。

なんとなく想像はついていたことではあるんですが、やはりBPMあるいはBPMSのビジネスも「他のもっと安そうな奴」との比較にさらされるという難しさがあるようです。具体的には、いわゆる「ワークフロー」のツールと言われる、「簡易的に帳票フォームを作り、ユーザ好みの申請・承認フローに流せる」というソフトウェアとの比較、ということになります。

詳しい話はここでは割愛しますが、今回お聞きした色々な話は、我々がECMのビジネスを行う上でいわゆる「文書管理」のための国産ソフトウェアとの比較で説明に苦慮していたのと同じような構図にある、ということがとにかく印象的でした。あるいはエンタープライズポータルと「グループウェア」の比較、でもいいかもしれません。

プラットフォームかプロダクトか、という話題がLiferayのプレゼンなどにもよく出てきます。その上に独自の専用アプリをくみ上げていけるような環境を提供するのか、「箱を開けてすぐに使える」完成品を提供するのか。パッケージソフトウェアのビジネスも、実は、「パッケージ」なんだから完成品だろう、というような簡単な割り切りができるようにはなっていなかったりします。

例えば、Liferayはどちらの路線も捨てずに取りに行く、と宣言しています。プラットフォームとしての価値を確固たるものにするための技術的な努力と、「すぐに使えるアプリ」を提供していくことでエンドユーザにとっての魅力を高め導入スピードを速める努力、の両方を製造元の責任と捉えているということだと思います。

公的なマーケティングメッセージはプラットフォームとしてもプロダクトとしても価値のあるものを提供する、ということになりますが、私はより本質的な価値はプラットフォームとしての部分にあると考えています。個別のアプリケーションは、ユースケースや適用業界を絞ることでより洗練された設計と実装工数の節約ができます。（プラットフォーム指向ではない）専門アプリケーションの方が、多くの場合ではそこだけ見れば「できがよく」「価格も安い」。

ただし、それらの仕組みは新たなサイロを生み出します。

エンタープライズポータルにしてもECMにしてもBPMにしても、わざわざ「サイロを作らない統合的なシステム作り」を支援するような仕組みを大げさに持ち出すアプローチは、これまではコスト的なオーバーヘッドも大きく、プロジェクト単位の投資ではなかなか正当化が難しかった面がありますが、OSS製品やクラウドサービスの台頭によりシステム構築規模に比較するソフトウェアライセンスの金額的なインパクトが小さくなってきたことで、どうにか乗り越えられそうな素地が出来てきていると思います。

「新たなサイロができてしまうとしても、安くて導入が早いものを入れる」という判断がビジネス的に正しいというケースもたくさんあり得ます。私たちとしても単純な脅し文句として「サイロ」という単語を乱発したいわけではありません。新たなサイロが生み出す技術的な負債の評価ができているのか、ということだけが問題です。

そこで節約したコストと得られたスピードは、将来の維持コストの増大や潜在的な適用分野に関する制約（ある一定以上の範囲に広げようとすると技術的な無理が急激に増すとか、別製品への引越が必要になるとか）と見合うものなのか。

ECMやBPMなどの3文字略語の「意識高い系（？ 今日的な揶揄も込めて）」は、以前はビッグベンダや大手SIerによる安心料的な高コスト体質と不可分でしたが、今では違います。コストは如実に下がっていますし、クラウドの無償プランやOSSを組み合わせて、その気になれば自社でも検証や構築ができてしまうわけです。自社のシステムを長期の視点で主体的に育てていく気があるのかどうか、ということが実質的な分水嶺になると思います。

うーん、うまくまとまらない。一番言いたいのは、LiferayもQuestetraも、プラットフォームとしての目線の高さは維持したままプロダクトとしてすぐに使えるソリューションの提供に腐心しているから、最後のとこだけ見てる人から見るとその足枷が無い（逆に言えばそのソリューション領域に専心している）ツールに対して分が悪いこともあるかもしれない。でも、この目線の高さは、思った以上にすぐにメリットとして返ってくるもんですよ、ってところなんだけど。

表題は、イギリス:牛乳　＝　ロシア:（　　）の方が良かったですかね？
それとも、オランダ:靴　＝　（　　）:樫鳥で、ローカライズの困難さ問題に切り込むとか。

（文責 Ishii Akinori IT-Coordinator）

ECMサミット2014を無事に終えました

ナビゲーターとして、さも挨拶やらラップアップやらをやりそうなプログラムでしたが、ただの発音が不明瞭な棒立ち司会としての仕事しかやれませんでした。が、とにもかくにもECM委員長としての初のイベントから生還しました。残念ながらOracleさんだけは情報非公開ですがECMポータルのこちらのページから、各スピーカーの方々の発表資料をダウンロードして読むことができます。（OPENTEXTさんは差し替え修正が発生したようなので、公開が少しずれ込む予定です。）

ということで、現地であまり押しつけがましく語り出すのも良くないかと考えて控えさせて頂いた（？）、大まかな感想とまとめについて、ここにメモを残しておきたいと思います。

まず、この競業関係にあるビッグベンダによる競演形式についても、さすがにこれだけの回数繰り返してきていると各社も距離感が掴めてきているのか、テーマに謳われていなくても、必ず（社名の公開有無や国内外などの条件の差違こそあれ）具体的なケースについてのお話を入れてきて下さいました。やはりそういう要素がないとお客様が飽きてしまってあまり高い評価が得られないという傾向は確かにあります。

一方で、明日を語る、最新動向、というテーマですから、（世間一般でも言われているような意味での）デジタル化など新しい社会動向に対応する形でのビジョンやコンセプトについてのお話も、ある種似通った形になりました。コンセプト＋事例、ですね。

ECMは伝統的には「紙情報の電子化」というコンセプトを引き継いでいます。電子情報にすることで得られるコスト削減や利便性を実現する一方でコンプライアンスなどの課題解決にも資する、というのが最初の存在意義。次いで、そこで実現された高い機能や性能が、Born Digital、紙を経由せずに始めから電子的に作られるコンテンツの統一的管理基盤として認められたのが、ECMとしてのアイデンティティでした。さらに、いわゆる業務システム／業務プロセスの枠を超え、世の中全体がデジタル化していっている今、適切に電子化されたプロセスとコンテンツはさらにレバレッジを効いた大きな効果を生み出せるようになってきている... というのが各社がほぼ共通したメッセージとして語っていたところではないかと思います。

主催者の1人としてここで付け加えたいのは、ここで語られた新しいワークスタイル、ワークフロー、現代的なコンテンツの活用法のすべてを、新たなサイロを生むこと無く実現するためには、ECMプラットフォームが必須である、ということです。さらには、そうした実現能力を持つECM製品の技術の大半を、すでに見て頂いているということでもあります。

「デジタル化に対応した（そのメリットを最大化できるような）新しい仕組みを導入したい」と「これ以上の情報（システム）のサイロ化は進行させたくない」を両立させるようなまだ見ぬ銀の弾丸というのは存在しないということです。あるのはECMという（海外では良い意味でそれなりに枯れた）技術の集積のみです。　　　

...あ、弊社aegifだけは別、って話をこの流れでするのは良くないですよね？

他には、ケースマネジメントがある意味で典型的なECMの活用技法として定着しつつあるということ、プラットフォームとしてこそ輝くという点では一致していても、コーディングなしに拘るか標準技術の組合せをアピールするかという点で差が出ている、なんていうのも面白い点でしたね。専業ベンダーさんよりも、ビッグベンダー陣営の方が標準規格の推進に熱心であるような技術構成になっているという傾向なども綺麗にやり方が別れているようでした。目指すところはある程度重なっていても、実現方法はポジションによって結構変わってくるわけですね。その辺りもひっくるめてのアドバイザリー、というのも面白いかな、と思わないでもないんですが、委員としてはともかく本業的には今やうちもベンダーですから、独立した助言にはなり得ないんですよね。

次回は来年2月です。ECMサミットとしての単独イベントで、さらに盛りだくさんの内容になる予定です。是非とも多くの方にご参加頂ければと思います。

（文責 Ishii Akinori IT-Coordinator）

ECMサミット2014

恒例のECMサミットが近づいてきました。イベントの詳細については、ECMポータルの案内ページをご覧頂いた方がよいと思いますが、JIIMA最大のイベント、eドキュメントJAPANの中の1コマとして実施します。

ECM委員長をやらせて頂くようになって初のECMサミットであるため、緊張しております。

今回は残念ながらEMCさんは欠席（実は早いもの勝ちだったりするので、サミットとしての単独開催ではない今回のようなイベントの一部の場合枠に限りがあるのです）ですが、OPENTEXTさん・Hylandさん・IBMさん・Oracleさんというラインナップです。大雑把なくくりをしてしまえば、専門ベンダ2社、所謂ビッグベンダ2社という構成ですね。

国際展示場は交通の便の良いところではありませんが、お時間のある方は是非いらしてください！

（文責 Ishii Akinori IT-Coordinator）

BPMSはじめました（？）

怠け者の節句働きというか、降れば土砂降りというか（2回でそれは言い過ぎか）、昨日に引き続いて投稿します。

京大情報研の超交流会でもお世話になっているQuestetra クエステトラさんのパートナーシッププログラムに参加することになりました。

取り組みとしては2つのスタイルを考えています。1つは、BPRプロジェクトなどにも参加するいわゆるコンサルティングファームとして、もう1つはECMの専門家集団として、です。

イージフのコンサルティングとBPMS

弊社の技術系ではないコンサルティングのチームは、その多くが「業務改善」のプロジェクトで活躍しています。技術系のチームがOSSという旗印があるのに比べて、今ひとつ対外的にアピールしきれていませんが、こちらのチームに関しても特徴を持ったサービス作りを心がけています。（でないと、大手ファームと比較されると純粋に劣化版に見えてしまいますし、そう見られた状態でのコンサルティングは非常な困難を伴いますし）

具体例を挙げずに説明するのが難しいところではありますが、ビジネス環境の変化（商材や販路の追加・変更）が激しかったり、例外処理が多すぎてキーマンの判断依存の案件が山積みになっているような、IT視点でみて「成熟度が低い」修羅場にあえて踏み込んでいく、という経験は他社と比べても結構豊富なのではないかと思います。

こうしたケースでは、業務を効率化するための検討や判断にもキーマンの参画が必要になりますが、その人達の時間がすでに大幅に不足して限界状態にある、というのがスタート時点の前提条件であったりするわけです。そこで、改善に入る前に、弊社のメンバーが現場に入り込んで業務執行のレベルまで手を動かし、通常業務（とはいえ例外処理は多数含まれますが）の負荷を減らしてスペースを作り、そこから徐々に改善に入る、なんてことをやったりします。

このあたりのノウハウが形成された経緯としては、弊社が起業時点では平均年齢20代の若い会社だったということや、当時は内部統制ブームで各社とも業務執行の現場への負担を増やさざるを得ず、その追加分に関しては抽象化された業務プロセスの知識を持ったメンバーの価値を発揮しやすかった、ということがあると思います。いずれにしても、業務執行のレベルからお手伝いをする、そしてそのことの身の証を立てるために作業品質の向上を可視化してレポートできる状態をキープしていく、というスタイルには自信を持っています。

Questetraはクラウドサービスであり、ユーザ企業側が自発的に使いこなした時にその真価が発揮される、という面は確かにあると思います。コンサルなんかに頼っていては駄目なんじゃないの？ っていうことですね。そういう意味では、単に業務フローのお絵かき代行という意味でのコンサルティングサービスには、あまり大きなビジネスチャンスも無く、やりがいに溢れたお仕事でもなさそうな気がします。

しかし、上記の通り業務改善に関する限り、弊社のサービスは業務執行のレベルまで踏み込んで関与し、徐々に改善に向かっていくというスタイルが基本ですので、単なる代行ではないことができるのではないかと思います。また、我々にとっての生命線である「業務品質の向上分の可視化」についてもBPMSは強力な武器になるのではないかと期待しています。

このあたりは具体的な（公表できる！）事例が出てきた際にまた突っ込んでご紹介させて頂ければと思います。

ECMとBPM

思いの外前段が長くなっちゃいました。どうしよう。

こっちはリクエストがあったらまた日をおいてゆっくり考えることにして、今は考えていることを簡単に箇条書きするだけですませたいと思います。

• 単純なワークフローシステムとBPMSの違いは文書管理ソフトとECMのそれに似ている


• BPMSによるトークン管理の（ある種抽象的な）価値はECMによるコンテンツ単位のアクセス制御のそれに似ている


• CMISにはワークフローの規定がなく、弊社のNemakiWareにも該当機能がないのでQuestetraとの連携に期待している


• （ECM上のチェックアウトって該当ユーザが「球を持っている」状態を作ってるよね？ システム的に上手くマッピングされてる例をみたことないけど）

って感じです。

（文責 Ishii Akinori IT-Coordinator）

JIIMAのECM委員会で委員長をやらせて頂くことになりました

2ヶ月以上ぶりです。この所、社長の方が結構頑張ってコンスタントに記事をあげている感じなので、一段と心苦しい限りです。

さて、以前から予告めいたお話はそこかしこでさせて頂いておりましたが、今月から、公益社団法人 日本文書情報マネジメント協会JIIMAのECM委員会の委員長を務めさせて頂くことになりました。中学時代以来の委員長ポジションです。

JIIMAには幾つか委員会があるのですが、ECM委員会はその中でも「ナレッジ系」と言われる系統に属しています。資格試験やセミナーイベントなどの事業運営とは異なる、知識の収集整理と普及啓発を目的とした組織です。

これまで委員会を引っ張ってきた前任の方が初代委員長で（どこまで細かい情報を出していいのか判断が難しいので、少しぼかしますが）、EDMSと呼ばれていたころのECM製品を日本に最初に持ってきた人達の中の1人にあたります。まさに国内のECM市場を作ってきた人達なわけです。JIIMAは元々マイクロフィルムを扱う人達の業界団体で、ついこの間まで日本画像情報マネジメント協会という名前でしたし、マイクロフィルムからスキャナベースのイメージングという「紙の電子化」を経て、その上でECMに取り組んできた経緯があります。

対する2代目の私は、社会人キャリアのほぼ最初の時点からECM製品を取り扱ってきました。言わば、ECMネイティヴな世代と言えるかもしれません。年齢的にも結構な若返り人事ではありますし、伝統的なバックグラウンドに欠ける面があるという不安もあります。しかし、折角のチャンスですし、国内でのECMのさらなる普及とより一層の利活用を目指して頑張っていきたいと思います。

告知 大事なお知らせ

別に委員長になったからということではなく、これまでも委員として積極的にアピールしなければならなかった話ではあるんですが、今月JIIMA最大の恒例イベントであるeドキュメントJAPANが開催されます。我々ECM委員会が絡む企画として、2日目である16日に、これまた恒例のECMサミットを予定しています。皆さん是非お越し下さい！

ECMサミットは、主要ECMベンダさんが呉越同舟的に一堂に会して共通したテーマでプレゼンを行ってくれる珍しいタイプのセミナー企画で、今回で第10回目になります。同一カテゴリのソフトウェア製品のプレゼンを連続聴講するという経験は、他ではなかなかないことだと思います。ECMそのものずばりに関心がなくても、業務アプリケーション分野に携わる方であれば、面白いと感じて頂けるのではないかと思います。（各社が同じ事を言っているように見えるのか、それとも全然異なる戦略を取っているように見えるのか、そしてその印象を有無原因は何なのか、なんていうのは割と一般的な関心時だと思うので）

...本当は、これまでの委員会活動で色々なことを教えて頂いた尊敬すべき諸先輩についてのお話もしたかったんですが、変に湿っぽくなるか、単なるガジェット好き集団だと誤解されるか、のどちらかである気がして仕方が無いので、断腸の思いで割愛したいと思います。

皆様今後ともよろしくお願い致します。

（文責 Ishii Akinori IT-Coordinator）

文書・コンテンツ・ファイル 半構造データ（XML）とCCMS

最近、自社関連の各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）