ここから本文です
CMS Watch：企業におけるwiki /エンタープライズwikiとはいったい何か？
2007年10月26日 掲載
しかし、エンタープライズというコンテキストでwikiを見はじめると、2つの重要な疑問に直面しなければならなくなる。
- wikiとCMSの違いはどこにあるのか。既存のCMSを使ってwikiのサービスを提供することはできないのか。
- wikiのツールは、エンタープライズ・レベルで使えるほどになっているのか。CIOが認めるようなものなのか。
この2つの質問に答えていこう。
wikiとコンテンツマネジメント
wiki[en.wikipedia.org] とは、ユーザーがページを作成・編集し、コラボレーションで作っていくタイプのウェブサイトだ。概念的には、広義のコンテンツマネジメントの概念に含まれるもので、既存のCMSを使ってwikiのようなサイトを作れることは間違いない。けれどもwikiには、平凡なCMSとは異なるユニークな特徴がある。
wikiが特徴としているのは、コンテンツ作成が容易という点だ。このシンプルさは、多くの理由から来ている。
- wikiのマークアップ言語には、テキストをフォーマットし、ドキュメントをリンクさせるための簡単な表記法がある。
- ユーザーが自分で直接的にページを作成し、編集できる。
- サイトの構成やナビゲーションに対して、ボトムアップのアプローチを取っている。
- テンプレートがきわめてシンプルである。
- ワークフロー、あるいは簡易な承認ステップですら回避する、意図的な決定が成されている。
では、これらを順番に見ていこう。
コンテンツの作成と編集
wikiソフトは、ユーザーに自分自身のページを作成・編集する力を与える。しかし、CMSもコンテンツの作成・編集ツールを提供するのは確かだ。この2つの違いは、アプローチにある。wikiが初めて登場した時（1995年）、ブラウザ内からWYSIWYG編集をするためのオプションはあまりなかった。そこで、wikiマークアップ言語（wikitextと呼ばれることもある）は、テキストをフォーマットするための表記法として、純粋なHTMLよりも学習がずっとやさしい簡略表記法をもたらし、これがきわめて貴重な存在となった。
すぐれたCMSは、WYSIWYGのインターフェースを備えており、ワープロを使っているような感覚でウェブのコンテンツを書けるようになっている。今日では、WYSIWYGの編集機能を備えたwikiも増えているため、wikiマークアップ言語は、フォーマットという意味ではそれほど面白い機能ではなくなっている。ただし、あらゆるプラットフォームのあらゆるブラウザにサポートされているというメリットはある。多くのリッチテキストエディターはそうではないからだ。wikiの多くは、wikitextとリッチテキストエディターの両方をサポートしている。次の図は、Wikipediaのエディターの例を示しているが、これは両方の不コンテンツフォーマット方法をサポートしている。
しかし、今でもwikitextが力を発揮するエリア、wikiソフトがCMSとは一線を画すエリアが、ひとつある。それは、リンク機能だ。wikiソフトは、そのwiki内でページをリンクさせるという点では、ずっと簡単な方法を持っている。リンクはページのタイトルに基づいて付けられるため、ページの作成者は、長々しいURLを覚えたり入力したりしなくて済むというわけだ。これがどう機能するかは、Wikipediaの「wiki」解説ページ[en.wikipedia.org] で簡単に説明されている。
Wikipediaの編集ページ
サイトの構成とナビゲーション
wikiでは、コンテンツの執筆者が新しいページを作って簡単に他のページにリンクできるため、サイトの構成とナビゲーションに対してもユニークなアプローチを取っている。
CMSは通常、サイトの構成とナビゲーションを処理するにあたって、よりフォーマルなアプローチを取る。情報アーキテクトがサイトを階層構造に整理する、というアプローチだ。一方、wikiでユーザーがページを作成するということは、この階層構造や構成がその場で作られていくことを意味する。ナビゲーションは往々にして単純で、階層はフラットだ。例えば、Wikipediaには様々なトピックの何十万件という記事があるが、これらのトピックは、概念的な階層構造にアレンジされているわけではない。「犬」についてのエントリを見てみれば、それがよく分かるだろう。犬の記事のURLは次のようになっている。
http://en.wikipedia.org/wiki/Dog[en.wikipedia.org]
そして、「パグ」という犬の種類についての記事は、次のURLで見られる。
http://en.wikipedia.org/wiki/Pug[en.wikipedia.org]
パグは犬の一種なのだから、URLは次のようになるだろうと思う人もいるかもしれない。
http://en.wikipedia.org/wiki/Dog/Pug[en.wikipedia.org]
しかし、ここではそうなっていないのだ。wiki製品のなかには、多少複雑なコンテンツのカテゴリー分けをサポートするものもある。しかし、多くは完全にフラットで、まったくWikipediaのような格好だ。たとえソフトがサブページをサポートしているとしても、コンテンツ執筆者は即興的にサブページを作れるため、サイトの情報アーキテクチャに体系的なアプローチはない。
コンテンツレポジトリとAPI
経験の豊富なシステム管理者やアーキテクトならば、どんなコンテンツ技術に対しても、「レポジトリはどうなっているのか？」と考えるだろう。もちろん、これには理由がある。彼らは、互換性やパフォーマンス、バックアップ、その他もろもろのことを考えなければならないからだ。
wikiは歴史的に、データストレージに対して非常にシンプルなアプローチを取ってきた。最初のwikiは、wikiマークアップ言語を使ってコンテンツをシンプルテキストで保存した。ユーザーがページをリクエストすると、ページが表示された。スピードは遅かったが、それで機能はしていた。最近のwiki製品は、いくつかあるバックエンド手法のどれかを採用していて、多くはデータベースにコンテンツを保存している。
システムが自動バックアップをサポートしているかどうかは、重要な検討事項だ（商用wikiアプリケーションの多くはサポートしている）。もうひとつ検討すべき点としては、wikiのコンテンツを他のシステムで管理されているコンテンツに統合するにあたって、これが何を意味するかという点が挙げられる。例えば、wikiのコンテンツをエンタープライズ検索システムでインデックス化できるだろうか。インデックス化されたコンテンツは、wikitextのままなのか、それともHTMLのページ表示形式となるのか。
こうして考えていくと、APIの問題が浮上してくる。ほとんどのwikiは、APIは持っていない。このため、ポータルを通じてwikiにアクセスしたり、あるいはイントラネットのCMSコラボレーション・システムに統合させたいという目標があるのかどうかも、重要なポイントに成る。今の段階では、一般に、そのベンダーから購入することになる。しかし今後は、より多くのwikiがシステムをオープン化し、他のエンタープライズ製品との統合ができるようになるだろう。
テンプレート
wikiは、ワークフローの考え方をまったく覆してしまう。wikiは非中央化されていて、たいていは、正式な承認プロセスを伴ったワークフロー・システムをコントロールするメカニズムを持っていないためだ。
wikiが非中央化されていて、高度なワークフロー・システムや承認プロセスを持っていないという事実は、wikiの特徴であって欠点ではないと考えられている。多くのCMSが、民主化よりもコントロールを強調していることを考えると、その基本的哲学は対照的だ。
ワークフロー
wikitextのページがリクエストされると、それは、2つの部分から成るプロセスを経てHTMLで表示される。まず、wikiマークアップがHTMLに変換されて、ページ間のリンクが作られる。次に、このコンテンツがテンプレートに収められて、すべてのページに一貫性のあるデザインを確立する、というプロセスだ。
CMSに比べると、ほとんどのwikiは、シンプルなテンプレート・システムを持っている。すべてのサイトを通じてテンプレートが1つということも多い。wikiのテンプレートはキャッシュに保存されないことも多く、このため、リクエストされるごとにページが表示される。エンタープライズという観点からすると、キャッシュがないことは明らかに、システムのスケーラビリティという点で限界をもたらす。一方で、面倒なキャッシュ・メカニズムに対処しなくて良いというのも事実だ。
しかし、wikiが非中央化アプローチを取っているとはいえ、忘れてはならない重要なことがひとつある。「誰でも編集できる」というポリシーは、あくまでポリシーであって、ソフト本来の機能ではないという点だ。同時にwikiは、CMSのような方法でコンテンツ・コントロールを行わない。ゆえに、別のアプローチが必要になるだろう。
コントロールVS柔軟性
CMSソフトでは、というより、世の中一般に言えることだが、コントロールと柔軟性の間にはクラシックとも言えるトレードオフがある。伝統的なCMSでは、コンテンツがパブリッシュされる前に読んで承認する何らかの編集者によって、意思決定がしばしば中央化されている。一方、wikiでは、書き手が書き、編集上の監督も承認もないままにパブリッシュする。パブリッシュに対するこの直接的なチャネルこそが、スピードや柔軟性を重視するシナリオにおいてwikiが力を発揮する理由だ。
しかし、もしも企業が少なくとも何らかのコントロールを持ちたいと考えた場合はどうなるのか。伝統的なワークフローのコントロールがない状況では、wikiのコンテンツ作成は、変更監視、自動スパム防止、そしてユーザー・アクセスコントロールによって管理されている。では、これらを順番に見ていこう。
変更監視
予想できることかもしれないが、防御壁のひとつの層として使えるのが、wikiに加えられる変更を単純に監視するというやり方だ。これは、ファイヤーウォールの内側だけで使われるwikiの場合、特に理にかなっている。
変更を監視するほかに、歓迎できない変更を直すことについても、何とかする機能がほしいと感じるだろう。例えば、前のバージョンにロールバックするなどだ。つまり、「変更監視」のアプローチは、2つの基本的な機能を必要とする。最近の変更を監視する機能、そして何らかのバージョン・コントロールだ。
最近の変更は、次のような方法でモニタできる。
- ほとんどのwikiには、「最近の変更」というページがあり、変更されたページをすべてリストアップする。これは図2で示すとおりだ。登録をサポートするwikiであれば、誰がその変更を加えたのかも表示されるだろう。
- 変更のEメール通知は、「最近の変更」ページの単にEメール版というだけのことだ。ただし、通知が来るという利便性がある。
- 様々なEメール通知は、RSSシンジケーションのサポートとなり、好みのRSSリーダーを使って最近の変更が監視できる。
- より高度なシステムになると、「小さな」変更を大きな変更からは区別して特定することができる。例えば、誰かがスペルの間違いを正すたびにEメールの通知はほしくないかもしれない。
- 変更監視のタスクを複数の人が担当する場合は、最近の変更のページが確認されたかどうかを記録し、仕事の重複の可能性を減らすことができる。
そもそもwikiがバージョン・コントロールをすべきかどうかという哲学的な議論を、私は聞いたことがある。この時、理想主義者は、バージョン・コントロールが「wiki流」に反し、哲学的な純粋性を欠くと主張した。現実主義者は、人間のやることに間違いはつきもので、時にはわざと悪いことをする人もいる、ゆえに変更をロールバックできる機能は良いことだと訴えた。現在、幅広い市場で優勢なのは現実主義の考え方だ。wikiソフトの多く（ほとんどとは言えないにしても）のバージョンは、バージョン・コントロール機能を持っている。確認すべき機能は、CMSの機能と似ていて、次のようなものだ。
- 変更前のバージョンにロールバックできること
- 異なるバージョンをつき合わせて比較できること
- バージョン間の特定の違いがすぐに特定できるよう、ファイル比較機能「ディフ」を使っていること
スパム防止
コンテンツの変更を監視するもうひとつのアプローチは、プログラム的な方法だ。これは、スパム防止と呼ばれることもある。スパム防止は、コンテンツそのもの、あるいはユーザーの行動に基づいて編集を監視するという点で、ユーザー・アクセスコントロールとは違っている。システムによっては、IPアドレスやURLへのアクセスをブロックしたり、次のような基準で個別の変更のポスティングをブロックしたりできるものもある。
- 単語のリストや標準的な表現に基づいて、特定の単語や語句の使用を制限する。
- 過剰なアクティビティに基づいてアクセスをブロックする。
ユーザー・アクセスコントロール
wikiのソフト製品が「エンタープライズwiki」とうたっている場合は、たいていの場合、ユーザー・アクセスコントロールがあることを意味している。ほとんどのwikiは、登録ユーザーとそうでないユーザーの区別ができ、非登録ユーザーは変更ができないようにすることが可能だ。最近では、より詳細なレベルで権限を割り当てるアクセスコントロール・リストを使って、より高度なユーザー・アクセスコントロールができるwikiソフトのプロジェクトも増えている。ユーザーやグループに権限を割り当てて、ページ閲覧、書き込み、編集、以前のバージョンへのロールバックなど、異なるタスクを許可できる。
こうした権限をどうやってサイトに適用するかという点では、wiki製品の間でも様々な違いがある。サイトの特定セクションへのアクセスを制限するものもあれば、個々のページへのアクセスを制限するものもある。あまり一般的ではないが有意義な機能としては、ページの特定部分へのアクセスを制限する機能などもある。例えば、記事に対してコメントを投稿する許可は、全員に認めたいわけではないかもしれない。
最も高度なエンタープライズwikiになると、Siteminderのようなシングルサインオン・セキュリティも使うことができるか、あるいは、ユーザー承認、ユーザー認証のためのネットワーク統合、ディレクトリ統合（LDAPおよびアクティブ・ディレクトリ）を備えていることもある。
終わりに
一般的にはそうは思われていないかもしれないが、wikiは管理可能なCMSだ。厳格なコントロールよりもスピードと柔軟性を重視することによって、単にコンテンツ管理に対して異なるアプローチを取っているというだけのことだ。wiki製品をうまく導入するには、ワークフローを違った観点から見て、自分の会社にとって正しいレベルのコンテンツ監視とアクセスコントロールをもたらしてくれるwikiソフトを選ぶ必要があるだろう。
マーク・チョートは、インターネット・パブリッシャー、Eビジネス・コンサルタント、そして教育者として活動している。特に専門とするのは、クロスメディアのコンテンツマネジメント・ツール、ブログ、wikiで、現在は、企業や団体に対して、これらの新しい技術を革新的な方法で導入し、業務の質と効率を高めるためのコンサルティングを手がけている。
この記事の原文「What makes an enterprise wiki?」は、2006年4月28日、「cmswatch.com」に掲載された。
本サイトに掲載している CMS Watch の記事は、CMSWatch.com より許可を得て、翻訳・転載しているものです。
CMSWatch.com は、ウェブ・コンテンツマネジメントおよびエンタープライズ・コンテンツマネジメント・ソリューションについて、ベンダーから完全に経済的独立をした形で、利用者の立場に立って、独自の情報やトレンド、意見、評価を提供しているサイトです。
CMS Watch はまた、最新の CMS 関連の製品分析やアドバイスが掲載されている The CMS Report の販売(無料サンプルあり)もしています。
・The CMS Report について
トラックバック
このページのトラックバックURL
http://www.designit.jp/mt/mt-tb.cgi/1042