生きたサイト運営を実現するための
実践CMS導入・運用ガイド
文＝清水 誠
実践系Web/CMSコンサルタント。コンテンツの見せ方（情報デザイン）、伝え方（IA、プレゼン、執筆）、管理方法（CMS）の研究と実践を続けて13年。DTPの領域も取り込むECM/CMSプロジェクトを企業側で推進中。1995年国際基督教大学卒
第2回
ツールの評価から運用上の問題点を見極めよう
前回は、企業内の知識共有プロジェクトを取り上げ、現状の課題を整理した。今回はこの要件に基づいて、CMSツールを評価しながら要件や設計の完成度を高めていくアプローチの進捗をレポートする。
■世の中にどんなWikiがあるのか?
前回のまとめ
前回は、社内で知識が明文化・共有されないという問題を解決するための事例を紹介し、問題の要因を検索や更新の操作方法がわからない、公開後に更新する手順や必然性が足りない、情報の体系化が難しい、の3点として整理した。そして初期考察として、Wikiのような手軽な更新システムや、全員でコンテンツを所有するという概念、コンテンツの分類に関する方針策定、タグ付けによる分類とナビゲーションなどが有効だろう、という当たりをつけた。
今回は、実際にWikiを評価しながら、わかったことを要件に反映していく。
Wikiを絞り込む
世の中にどんなWikiが存在するかを知るには、Wiki Matrixというサイトが役に立つ。単なるリンク集や比較表とは異なり、対象の製品や機能の項目をカスタマイズした比較表をつくることができる【1】。ここで検索可能な機能は、掲載対象のWikiが実際にもっている機能であって、理想のウィッシュリストではない。各機能の解説やディスカッションを読むだけでも、世界のWeb担当者が抱える共通の悩みとそのソリューションを知ることができる。前回述べたような現実的な要件定義を行うには役に立つサイトだ。
【1】Wiki Matrixでは、Wikiの機能を比較することができる
Wiki特有の入力方法がネック?
今回の事例では、知識共有のボランティア性が高い（＝強制力が低い）ため、手軽に心地よく入力・更新が行えることが重要、と位置づけた。Wikiは特有の書式でコンテンツを入力するのが通常だが、最近はWordのようにWYSIWYG形式でコンテンツを編集できるWikiも登場した。
Wiki MatrixでWYSIWYG対応のWikiを検索し、今回は無償で利用可能なWetpaint、Zoho Wiki、DekiWiki、MoinMoinを評価対象として選定した。また、英語圏のWikiとの違いを明確にするため、日本のPukiwikiも評価していく【2】。
【2】絞り込んだ5種類のWiki
■AJAXでWikiは進化したか?
実際に入力してみる
リアルなストーリーを想定して製品を評価すると、機能の比較表ではわからない違いが見えてくる。ここでは、Wordドキュメントを原稿とし【3】、コピー&ペーストしたあとに編集を行い、ページを完成させるというシナリオを想定した【4】。また、最終的に生成されてユーザーのブラウザへ配信されるHTMLコードも見比べてみると、コンテンツ入力に関して、いくつかのアプローチがあることがわかる。
【3】Wordによる元原稿
【4】リアルなストーリーで入力方法を評価する
独自言語（Wiki書式）
HTMLは複雑で自由度が高すぎるため、構造を表すシンプルな言語をつくってしまおう、というアプローチ【5】。もともとWikiはこの考え方で生まれた。が、表現上の自由度を求めるユーザーも絶えず、HTMLを使えるようにするプラグインがあとで開発されることが多い。Wikiの書式を統一しようとする動きもあるが、実現には遠いのが現状だ。コンテンツの入力や更新に対して意欲の高いユーザーが多いコミュニティでは成立するが、WYSIWYGエディタの進化が進む最近ではやや下火になりつつある。
【5】Pukiwikiの入力書式（左）と出力結果（右）
制限WYSIWYG
最低限のスタイル指定のみに絞り込んだWYSIWYG機能を提供するアプローチ。Wetpaintなどはかなりシンプルで、見出しは2種類のみ、文字の色も指定できない【6】。HTMLモードもないため、自由度はかなり低いが、生成されるHTMLのクリーン度は保証される。
【6】絞り込まれたWetpaintの編集機能
■HTMLのクリーン度が異なる
フィルタリング
使えるタグを制限し、保存時にタグを除去したり整形を行うアプローチ。今回の評価ではWord原稿を使ったため、テキストに目に見えない情報が含まれていた。にもかかわらず、Wetpaintは冗長なタグを除去したクリーンなHTMLを生成した【7】。
【7】生成されたHTMLコードの比較。左はWetpaint、右はZoho Wiki
文法チェック
最終的に生成されるHTMLの構文チェック機能。HTMLを直接編集した場合のタグのスペルミスや閉じ忘れ、非推奨のタグや属性に対する警告や修正を行う。
貼り付け支援
コンテンツをWebページやWordから貼り付けると意図しないタグが混じることが多いため、テキストのみを貼り付けたり、Word特有のタグを除去してから貼り付ける、などの実際的な機能をもつようにWYSIWYGエディタは進化してきた【8】。
【8】MoinMoinのWord貼り付け機能（左）と貼り付け結果（右）。スタイルのみが除去された
■画像の扱い方が異なる
添付ファイルのインライン表示
ページにファイルを添付できるようにし、画像の場合はインライン表示、そのほかの場合はファイルへのリンクをリスト表示するというアプローチ。機械にとっては画像もファイルも同じ、というのは開発側の視点であり、操作性が劣る。たとえば、テキストを入力中に画像を貼り付けるには、入力途中のテキストを一度保存し、そのページへファイルを添付、再度編集して画像を貼り付けるコマンドを入力し、プレビューで確認したあとにテキストの編集を再開する、という手順が必要になる。また、特定のページに画像をひも付けてしまうため、画像を複数ページで利用することが想定されていない。
IMGタグ支援
画像用HTMLタグの編集を支援するアプローチ。画像専用の画面でALT文字列やサイズなどを指定できる【9】。画像はURLを指定するか、新規にファイルをアップロードする。画像ファイルとページが独立しているため、複数ページへ共通画像を貼り付けることができる半面、どのページにどの画像が使われているかを把握しにくい。
【9】Zoho Wikiの 画像挿入機能。画像を選択し、プレビューしながらアラインや余白、ボーダーを指定することができる
要件を見直す
以上、アプローチの違いとその背景を理解したところで、入力に関する要件を修正しておこう【10】。
【10】出力されたコンテンツの見え方とページ校正した要件のポイント
本記事は『Web STRATEGY』2007年 5-6月号 vol.9からの転載です
この号の特集など、ほかの記事の紹介はこちら！
『Web STRATEGY』最新号の情報はこちら！
Amazon.co.jpでの購入はこちら！
定期購読はMdN Squareで！
実践CMS導入・運用ガイド
文＝清水 誠実践系Web/CMSコンサルタント。コンテンツの見せ方（情報デザイン）、伝え方（IA、プレゼン、執筆）、管理方法（CMS）の研究と実践を続けて13年。DTPの領域も取り込むECM/CMSプロジェクトを企業側で推進中。1995年国際基督教大学卒
第2回
ツールの評価から運用上の問題点を見極めよう
前回は、企業内の知識共有プロジェクトを取り上げ、現状の課題を整理した。今回はこの要件に基づいて、CMSツールを評価しながら要件や設計の完成度を高めていくアプローチの進捗をレポートする。
■世の中にどんなWikiがあるのか?
前回のまとめ
前回は、社内で知識が明文化・共有されないという問題を解決するための事例を紹介し、問題の要因を検索や更新の操作方法がわからない、公開後に更新する手順や必然性が足りない、情報の体系化が難しい、の3点として整理した。そして初期考察として、Wikiのような手軽な更新システムや、全員でコンテンツを所有するという概念、コンテンツの分類に関する方針策定、タグ付けによる分類とナビゲーションなどが有効だろう、という当たりをつけた。
今回は、実際にWikiを評価しながら、わかったことを要件に反映していく。
Wikiを絞り込む
世の中にどんなWikiが存在するかを知るには、Wiki Matrixというサイトが役に立つ。単なるリンク集や比較表とは異なり、対象の製品や機能の項目をカスタマイズした比較表をつくることができる【1】。ここで検索可能な機能は、掲載対象のWikiが実際にもっている機能であって、理想のウィッシュリストではない。各機能の解説やディスカッションを読むだけでも、世界のWeb担当者が抱える共通の悩みとそのソリューションを知ることができる。前回述べたような現実的な要件定義を行うには役に立つサイトだ。
【1】Wiki Matrixでは、Wikiの機能を比較することができる
Wiki特有の入力方法がネック?
今回の事例では、知識共有のボランティア性が高い（＝強制力が低い）ため、手軽に心地よく入力・更新が行えることが重要、と位置づけた。Wikiは特有の書式でコンテンツを入力するのが通常だが、最近はWordのようにWYSIWYG形式でコンテンツを編集できるWikiも登場した。
Wiki MatrixでWYSIWYG対応のWikiを検索し、今回は無償で利用可能なWetpaint、Zoho Wiki、DekiWiki、MoinMoinを評価対象として選定した。また、英語圏のWikiとの違いを明確にするため、日本のPukiwikiも評価していく【2】。
【2】絞り込んだ5種類のWiki
■AJAXでWikiは進化したか?
実際に入力してみる
リアルなストーリーを想定して製品を評価すると、機能の比較表ではわからない違いが見えてくる。ここでは、Wordドキュメントを原稿とし【3】、コピー&ペーストしたあとに編集を行い、ページを完成させるというシナリオを想定した【4】。また、最終的に生成されてユーザーのブラウザへ配信されるHTMLコードも見比べてみると、コンテンツ入力に関して、いくつかのアプローチがあることがわかる。
【3】Wordによる元原稿
【4】リアルなストーリーで入力方法を評価する
独自言語（Wiki書式）
HTMLは複雑で自由度が高すぎるため、構造を表すシンプルな言語をつくってしまおう、というアプローチ【5】。もともとWikiはこの考え方で生まれた。が、表現上の自由度を求めるユーザーも絶えず、HTMLを使えるようにするプラグインがあとで開発されることが多い。Wikiの書式を統一しようとする動きもあるが、実現には遠いのが現状だ。コンテンツの入力や更新に対して意欲の高いユーザーが多いコミュニティでは成立するが、WYSIWYGエディタの進化が進む最近ではやや下火になりつつある。
【5】Pukiwikiの入力書式（左）と出力結果（右）
制限WYSIWYG
最低限のスタイル指定のみに絞り込んだWYSIWYG機能を提供するアプローチ。Wetpaintなどはかなりシンプルで、見出しは2種類のみ、文字の色も指定できない【6】。HTMLモードもないため、自由度はかなり低いが、生成されるHTMLのクリーン度は保証される。
【6】絞り込まれたWetpaintの編集機能
■HTMLのクリーン度が異なる
フィルタリング
使えるタグを制限し、保存時にタグを除去したり整形を行うアプローチ。今回の評価ではWord原稿を使ったため、テキストに目に見えない情報が含まれていた。にもかかわらず、Wetpaintは冗長なタグを除去したクリーンなHTMLを生成した【7】。
【7】生成されたHTMLコードの比較。左はWetpaint、右はZoho Wiki
文法チェック
最終的に生成されるHTMLの構文チェック機能。HTMLを直接編集した場合のタグのスペルミスや閉じ忘れ、非推奨のタグや属性に対する警告や修正を行う。
貼り付け支援
コンテンツをWebページやWordから貼り付けると意図しないタグが混じることが多いため、テキストのみを貼り付けたり、Word特有のタグを除去してから貼り付ける、などの実際的な機能をもつようにWYSIWYGエディタは進化してきた【8】。
【8】MoinMoinのWord貼り付け機能（左）と貼り付け結果（右）。スタイルのみが除去された
■画像の扱い方が異なる
添付ファイルのインライン表示
ページにファイルを添付できるようにし、画像の場合はインライン表示、そのほかの場合はファイルへのリンクをリスト表示するというアプローチ。機械にとっては画像もファイルも同じ、というのは開発側の視点であり、操作性が劣る。たとえば、テキストを入力中に画像を貼り付けるには、入力途中のテキストを一度保存し、そのページへファイルを添付、再度編集して画像を貼り付けるコマンドを入力し、プレビューで確認したあとにテキストの編集を再開する、という手順が必要になる。また、特定のページに画像をひも付けてしまうため、画像を複数ページで利用することが想定されていない。
IMGタグ支援
画像用HTMLタグの編集を支援するアプローチ。画像専用の画面でALT文字列やサイズなどを指定できる【9】。画像はURLを指定するか、新規にファイルをアップロードする。画像ファイルとページが独立しているため、複数ページへ共通画像を貼り付けることができる半面、どのページにどの画像が使われているかを把握しにくい。
【9】Zoho Wikiの 画像挿入機能。画像を選択し、プレビューしながらアラインや余白、ボーダーを指定することができる
要件を見直す
以上、アプローチの違いとその背景を理解したところで、入力に関する要件を修正しておこう【10】。
【10】出力されたコンテンツの見え方とページ校正した要件のポイント
本記事は『Web STRATEGY』2007年 5-6月号 vol.9からの転載です
この号の特集など、ほかの記事の紹介はこちら！
『Web STRATEGY』最新号の情報はこちら！
Amazon.co.jpでの購入はこちら！
定期購読はMdN Squareで！
