生きたサイト運営を実現するための
実践CMS導入・運用ガイド
文＝清水 誠
実践系Web/CMSコンサルタント。コンテンツの見せ方（情報デザイン）、伝え方（IA、プレゼン、執筆）、管理方法（CMS）の研究と実践を続けて13年。DTPの領域も取り込むECM/CMSプロジェクトを企業側で推進中。1995年国際基督教大学卒
第1回
CMSの要件は何を定義すべき?
CMSに関する記事や広告が増えてきた。ツールもオープンソースから企業向けまで幅広い。メリットは多いようだが、実際のところどうなのか? この連載では、事例を紹介しながら、CMSの選定から導入、運用までを利用者（企業）の視点で具体的に紹介していきたい。
■すれ違いの多いCMS
まだまだ成長中のCMS
CMSの普及が進んでいる。blogツールから多機能CMSまで幅広く、導入サイトも個人サイトから企業サイトまでさまざまだ。ライセンスが無償のオープンソース製品や、インストールが不要のASPサービスもあり、導入しない手はないように思える。
ところが、実際はそう簡単ではない。CMSは10年以上の歴史をもつが、振り返ってみると失敗事例が数多く、導入側は不満を抱えながら試行錯誤を繰り返し、開発側がそれに何とか応えながら共に成長してきた感がある。CMSプロジェクトはなぜ、そんなに難しいのだろうか?【1】
【1】CMSが難しい要因
「コンテンツ」とは?
「コンテンツ」は定義があいまいで、業界や企業、かかわる人の立場によってその性質や粒度が大きく異なる。また、コンテンツはさまざまなレベルで有機的に絡み合うため、明確に切り分けたり分類することが難しい。生き物のようにライフサイクルをもち、使われる場所やタイミング、読者によって自在に変貌していく。フォルダとファイルというメタファーで単純に扱うことはできないのだ。
「管理」とは?
コンテンツはさまざまなライフサイクル（段階）においてさまざまな人が制作、編集、参照、保管、廃棄などを行っていく。コンテンツを管理するということは、コンテンツにかかわる業務プロセスを整理し管理していくことにほかならない。このプロセスのリエンジニアリングのためには、業務や制作・運用プロセスへの深い理解だけでなく、多くの関係者を対象とした意識改革や、組織体制、評価までにも及ぶ業務改革、何よりもほとんどの関係者にとって未知の領域を想像しながら想定を重ねて要件を定義し、実情に合わせて修正と改善を続ける柔軟性や根気も必要とされる。
長期的な視野が必要
必然性があってCMSを導入し、一度そのメリットを享受してしまうと、もうCMSなしの業務には戻れないものだ。ビジネスにPCやインターネットがもはや必須なのと同じように、多くの組織にとってCMSはサイト管理に必須のものになっていく。このため、導入者は長期的にCMSと向き合っていく必要がある。管理対象のサイトは日々メンテされ、成長していく。それを運用するスタッフや企業も、そしてビジネスそのものも成長していく。それに合わせて、一度導入したCMSを改善したり、ツールを入れ替える必要も生じるだろう。CMSの導入にあたっては、このような長期的な視野をもって取り組みたい。
■連載の進め方
筆者は現在、規模の異なる3つのCMSプロジェクトを進めている。意図どおりには進まない実際のプロジェクトから得られる知見を、現在進行形に近い形で紹介していく。そのため、実際のプロジェクトと同じように、以下のようなステップで連載を進めながら、要件定義から設計、導入、運用までを幅広くカバーしていく【2】。
【2】CMSプロジェクトの流れ＝連載の進め方
1. 要件定義
課題の整理、RFP作成、製品の評価と選定など。
CMSプロジェクトは、IT系のソフトウエア開発プロジェクトとして扱ってしまいがちだが、前述のように「コンテンツ」「管理」は複雑であいまいであり、ITで通常扱う「データ」と「コンテンツ」は似て非なるものなのだ。このため、コンテンツの制作や管理を熟知した制作部門が中心となって、プロジェクトを進めていくべきだ。本連載はこの視点で、テクノロジーよりもコンテンツのIAやWeb戦略、管理・運用面を重点的に取り上げていく。
2. サイトとCMSの設計
IA、デザイン、CMS、ほかのアプリケーション、運用を組み合わせ、課題をどう解決していくかの方針策定と設計。
世の中に数え切れない数のCMSツールがあることからわかるように、多様なニーズを満たす万能なCMSは存在しないため、小規模でニッチな製品にも目を向ける必要がある。またCMSが通常どのような課題をどう解決しようとするのかを理解したうえで、ツールとしてのCMSを使ってどこまで課題を解決するかを見極めないと、高度なライセンス費やカスタマイズ費、運用や将来のバージョンアップなどの費用（TCO）が膨大に膨らんでしまうことがある。理想と現実の両面から歩み寄ることも必要だ。
3. CMS導入
テンプレートやワークフローの開発と実装、コンテンツ移行、マニュアル作成やトレーニングなど。
CMSの場合、どのツールを選ぶかによって、この部分が大きく異なる。たとえば、同じ「テンプレート」機能でも、デザイナーとの親和性、移行の容易さ、柔軟な管理機能、のどれを重視するかによって、機能や操作性、開発期間が異なってくる。設計や導入の過程でわかったことを要件定義や設計に反映できるような体制・スケジュールにしておく必要がある。
4. 運用
運用、ユーザーサポート、効果測定、改善プランなど。
重要だが、あまり語られることがないのが、この運用だ。コンテンツを「管理」するのは多くの組織にとって未知の領域であるため、それを想像しながら的確な要件定義ができることはほとんどない。運用とは改善である、というコンセンサスを得ておかないと、あのCMS導入は失敗だった、とも言われかねない。
具体的で実践的な情報に
CMSに関する記事や広告が増えてきた。が、結果重視の美しいケーススタディや、特定の製品に偏った記事広告、システムや機能面のみを取り上げた記事、机上の空論などが多いように思える。本連載では、売り手やコンサルタントではなく実際の導入者の視点で、IA、デザイン、運用、IT、体制などを総合的に検討しながら、CMSの最新動向を踏まえて、長期的に破たんしない効果的なCMSを追求していきたい。
■要件定義
では早速、今回から数回に分けて、具体的な要件定義を進めていく。
CMS要件定義の留意点
オーストラリアのStep Two Designs（http://www.steptwo.com.au/）は、2005年に「Top 10 mistakes when selecting a CMS」（CMS選定のまちがいトップ10）を公開した【3】。このリストを参考に、まずはCMSの要件定義における留意点と疑問点をまとめておく。
【3】CMS選定のまちがいトップ10
●解決すべき問題を明確に
言うのは簡単だが、何をどこまで「明確」にしておけばよいのか?
●CMSは機能の有無ではなく問題をどう解決するのかが重要
個々のCMSツールを具体的な事例に当てはめて、課題解決のアプローチやユーザーインターフェイスの違いを明らかにしたい。CMSツールは多いが、本質的なアプローチはそんなに多くないハズだ。であれば、そのアプローチの傾向とパターンを理解したうえで、過去のノウハウに基づく効果的な選定や設計を行いたい。
●どこまでCMSで対応すべきか
課題によっては、CMS以外のユーティリティやデバイスで解決できることもある。ソリューションをCMSに限定しないで、総合的に検討していく。
●CMSの現状を理解したうえで、現実的に要件定義をする
ツールの評価によって得られる知見を生かし、要件そのものを柔軟に進化させていく方法を試したい。
■事例1 企業内の知識共有
まずはシンプルな事例として、企業内の知識共有サイトを取り上げる。
現状の悩み
職務に必要な知識は個人の頭の中にあり、長期休暇や異動、退職が原因で職務の質や効率が下がることがある。知識や情報、マニュアルを共有するための仕組みとしてLotus Notesが昔から使われているが、足りない情報や古い情報が多く、最大限活用されているとはいえない状況だ。情報は増えるほど整理が難しくなっていき、重複したり粒度がまちまち、一貫性がないなどの問題が目立つようになってきた。多くの人によってメンテされ続ける集合知を実現するにはどうすればよいのか?
課題の整理
この事例の課題とその要因を整理してみよう。
●情報が共有されない
・何がすでに公開されているかがわからない
・どこにどう書けばよいかわからない
・公開の方法がわからない
・気軽に更新できない
●情報が更新されずに古くなる
・オーナーが不明確または不在
・まちがいや不足に気づいたり質問があっても、伝える手段がなく放置される
・検索されずに埋もれてしまい、内容が古いことにだれも気づかない
●情報の体系化が難しい
・サイト全体の目次がカオス状態
・情報の粒度がまちまち
・書式や用語が統一されていない
・内容の編集者やモデレータが不在
通常のITプロジェクトであれば、この時点で課題をさらに整理し、優先順位をつけたうえで関係者のコンセンサスや承認を得るところだが、CMSプロジェクトの場合は机上の空論に終わってしまうことがある。CMSを評価したり実際に導入して利用することで、今まで気づかれなかった問題が表面化したり、CMSを導入したために新たに課題が発生することもある。この時点では課題と要因を洗い出す程度にしておき、CMSの選定と設計を進めながら要件そのものを修正し進化させていくことにする。
CMS選定前の初期考察
●Wiki?
このような事例にはWikiによる情報共有が適しているように思えるが、Lotus Notesという既存の仕組みとWikiは考え方が大きく異なるので、慣れるのが難しいだろう。学習のコストを正当化するためには、メリットを明確にして広報していく必要がある。
また、Wikipediaは閲覧や執筆するユーザーが多いため、コミュニティの自浄効果でまちがいや不足が修正されていくが、ひとつの企業や部署という少ない人数の中でうまく機能するだろうか。
●情報の共同所有?
コンテンツを担当者だけのものと限定しないで、全関係者がコラボレートしながら完成度を高めていくためには、まちがえても元に戻せるようなバージョン管理、何がどう変更されたかの更新差分表示、それを関係者へメール通知する機能などが最近のWikiでは一般的だ。他人が書いたコンテンツを直接直すことに抵抗がある人もいるため、コメントや質問を追記できる機能も必要だろう。
●分類が問題?
Lotus NotesはWYSIWYG編集なので、入力が難しいということは考えにくい。コンテンツの一貫性が問題になってきているということは、情報の整理と表現方法が最大の課題かもしれない。情報は増えると分類が難しくなる。情報をいろいろな切り口で分類するためのタクソノミー(分類体系)をつくっておく必要がある。ただし、知識という多様なコンテンツは複雑なため、明確な分類は不可能に近い。フォルダにコンテンツを入れるのではなく、コンテンツに対してその内容を表すタグを複数付けるアプローチが必要だろう。
●フォークソノミー?
このタグ付けを応用して、同じキーワードをもつコンテンツ同士は関連性が高いと見なし、関連リンクを自動生成できるCMSツールもある。わざわざ検索をしなくても埋もれた関連コンテンツを見つけることができれば、重複を避けつつメンテナンスしやすい情報の宝庫を実現できるかもしれない。
となると、タグは多いほどよい。他人が気軽にタグをつけられれば、管理者や著者には思いつかない多様な視点で、コンテンツに関する情報が充実していく。
●ユーザーエクスペリエンスが重要
厚いマニュアルを読まないと活用できないような仕組みは、知識共有というボランティア性が高い用途の場合、使われずに失敗に終わりがちだ。操作性や快適なユーザーエクスペリエンスが重要になるため、ユーザビリティを評価の項目に加えることにする。
次回は、この事例の要件に基づいて、各種のCMS製品を評価しながら、最近のCMS開発者がコンテンツ管理に関する課題をどうとらえ、解決しようとしているかを明らかにしていく。
本記事は『Web STRATEGY』2007年 3-4月号 vol.8からの転載です
この号の特集など、ほかの記事の紹介はこちら！
『Web STRATEGY』最新号の情報はこちら！
Amazon.co.jpでの購入はこちら！
定期購読はMdN Squareで！
実践CMS導入・運用ガイド
文＝清水 誠実践系Web/CMSコンサルタント。コンテンツの見せ方（情報デザイン）、伝え方（IA、プレゼン、執筆）、管理方法（CMS）の研究と実践を続けて13年。DTPの領域も取り込むECM/CMSプロジェクトを企業側で推進中。1995年国際基督教大学卒
第1回
CMSの要件は何を定義すべき?
CMSに関する記事や広告が増えてきた。ツールもオープンソースから企業向けまで幅広い。メリットは多いようだが、実際のところどうなのか? この連載では、事例を紹介しながら、CMSの選定から導入、運用までを利用者（企業）の視点で具体的に紹介していきたい。
■すれ違いの多いCMS
まだまだ成長中のCMS
CMSの普及が進んでいる。blogツールから多機能CMSまで幅広く、導入サイトも個人サイトから企業サイトまでさまざまだ。ライセンスが無償のオープンソース製品や、インストールが不要のASPサービスもあり、導入しない手はないように思える。
ところが、実際はそう簡単ではない。CMSは10年以上の歴史をもつが、振り返ってみると失敗事例が数多く、導入側は不満を抱えながら試行錯誤を繰り返し、開発側がそれに何とか応えながら共に成長してきた感がある。CMSプロジェクトはなぜ、そんなに難しいのだろうか?【1】
【1】CMSが難しい要因
「コンテンツ」とは?
「コンテンツ」は定義があいまいで、業界や企業、かかわる人の立場によってその性質や粒度が大きく異なる。また、コンテンツはさまざまなレベルで有機的に絡み合うため、明確に切り分けたり分類することが難しい。生き物のようにライフサイクルをもち、使われる場所やタイミング、読者によって自在に変貌していく。フォルダとファイルというメタファーで単純に扱うことはできないのだ。
「管理」とは?
コンテンツはさまざまなライフサイクル（段階）においてさまざまな人が制作、編集、参照、保管、廃棄などを行っていく。コンテンツを管理するということは、コンテンツにかかわる業務プロセスを整理し管理していくことにほかならない。このプロセスのリエンジニアリングのためには、業務や制作・運用プロセスへの深い理解だけでなく、多くの関係者を対象とした意識改革や、組織体制、評価までにも及ぶ業務改革、何よりもほとんどの関係者にとって未知の領域を想像しながら想定を重ねて要件を定義し、実情に合わせて修正と改善を続ける柔軟性や根気も必要とされる。
長期的な視野が必要
必然性があってCMSを導入し、一度そのメリットを享受してしまうと、もうCMSなしの業務には戻れないものだ。ビジネスにPCやインターネットがもはや必須なのと同じように、多くの組織にとってCMSはサイト管理に必須のものになっていく。このため、導入者は長期的にCMSと向き合っていく必要がある。管理対象のサイトは日々メンテされ、成長していく。それを運用するスタッフや企業も、そしてビジネスそのものも成長していく。それに合わせて、一度導入したCMSを改善したり、ツールを入れ替える必要も生じるだろう。CMSの導入にあたっては、このような長期的な視野をもって取り組みたい。
■連載の進め方
筆者は現在、規模の異なる3つのCMSプロジェクトを進めている。意図どおりには進まない実際のプロジェクトから得られる知見を、現在進行形に近い形で紹介していく。そのため、実際のプロジェクトと同じように、以下のようなステップで連載を進めながら、要件定義から設計、導入、運用までを幅広くカバーしていく【2】。
【2】CMSプロジェクトの流れ＝連載の進め方
1. 要件定義
課題の整理、RFP作成、製品の評価と選定など。
CMSプロジェクトは、IT系のソフトウエア開発プロジェクトとして扱ってしまいがちだが、前述のように「コンテンツ」「管理」は複雑であいまいであり、ITで通常扱う「データ」と「コンテンツ」は似て非なるものなのだ。このため、コンテンツの制作や管理を熟知した制作部門が中心となって、プロジェクトを進めていくべきだ。本連載はこの視点で、テクノロジーよりもコンテンツのIAやWeb戦略、管理・運用面を重点的に取り上げていく。
2. サイトとCMSの設計
IA、デザイン、CMS、ほかのアプリケーション、運用を組み合わせ、課題をどう解決していくかの方針策定と設計。
世の中に数え切れない数のCMSツールがあることからわかるように、多様なニーズを満たす万能なCMSは存在しないため、小規模でニッチな製品にも目を向ける必要がある。またCMSが通常どのような課題をどう解決しようとするのかを理解したうえで、ツールとしてのCMSを使ってどこまで課題を解決するかを見極めないと、高度なライセンス費やカスタマイズ費、運用や将来のバージョンアップなどの費用（TCO）が膨大に膨らんでしまうことがある。理想と現実の両面から歩み寄ることも必要だ。
3. CMS導入
テンプレートやワークフローの開発と実装、コンテンツ移行、マニュアル作成やトレーニングなど。
CMSの場合、どのツールを選ぶかによって、この部分が大きく異なる。たとえば、同じ「テンプレート」機能でも、デザイナーとの親和性、移行の容易さ、柔軟な管理機能、のどれを重視するかによって、機能や操作性、開発期間が異なってくる。設計や導入の過程でわかったことを要件定義や設計に反映できるような体制・スケジュールにしておく必要がある。
4. 運用
運用、ユーザーサポート、効果測定、改善プランなど。
重要だが、あまり語られることがないのが、この運用だ。コンテンツを「管理」するのは多くの組織にとって未知の領域であるため、それを想像しながら的確な要件定義ができることはほとんどない。運用とは改善である、というコンセンサスを得ておかないと、あのCMS導入は失敗だった、とも言われかねない。
具体的で実践的な情報に
CMSに関する記事や広告が増えてきた。が、結果重視の美しいケーススタディや、特定の製品に偏った記事広告、システムや機能面のみを取り上げた記事、机上の空論などが多いように思える。本連載では、売り手やコンサルタントではなく実際の導入者の視点で、IA、デザイン、運用、IT、体制などを総合的に検討しながら、CMSの最新動向を踏まえて、長期的に破たんしない効果的なCMSを追求していきたい。
■要件定義
では早速、今回から数回に分けて、具体的な要件定義を進めていく。
CMS要件定義の留意点
オーストラリアのStep Two Designs（http://www.steptwo.com.au/）は、2005年に「Top 10 mistakes when selecting a CMS」（CMS選定のまちがいトップ10）を公開した【3】。このリストを参考に、まずはCMSの要件定義における留意点と疑問点をまとめておく。
【3】CMS選定のまちがいトップ10
●解決すべき問題を明確に
言うのは簡単だが、何をどこまで「明確」にしておけばよいのか?
●CMSは機能の有無ではなく問題をどう解決するのかが重要
個々のCMSツールを具体的な事例に当てはめて、課題解決のアプローチやユーザーインターフェイスの違いを明らかにしたい。CMSツールは多いが、本質的なアプローチはそんなに多くないハズだ。であれば、そのアプローチの傾向とパターンを理解したうえで、過去のノウハウに基づく効果的な選定や設計を行いたい。
●どこまでCMSで対応すべきか
課題によっては、CMS以外のユーティリティやデバイスで解決できることもある。ソリューションをCMSに限定しないで、総合的に検討していく。
●CMSの現状を理解したうえで、現実的に要件定義をする
ツールの評価によって得られる知見を生かし、要件そのものを柔軟に進化させていく方法を試したい。
■事例1 企業内の知識共有
まずはシンプルな事例として、企業内の知識共有サイトを取り上げる。
現状の悩み
職務に必要な知識は個人の頭の中にあり、長期休暇や異動、退職が原因で職務の質や効率が下がることがある。知識や情報、マニュアルを共有するための仕組みとしてLotus Notesが昔から使われているが、足りない情報や古い情報が多く、最大限活用されているとはいえない状況だ。情報は増えるほど整理が難しくなっていき、重複したり粒度がまちまち、一貫性がないなどの問題が目立つようになってきた。多くの人によってメンテされ続ける集合知を実現するにはどうすればよいのか?
課題の整理
この事例の課題とその要因を整理してみよう。
●情報が共有されない
・何がすでに公開されているかがわからない
・どこにどう書けばよいかわからない
・公開の方法がわからない
・気軽に更新できない
●情報が更新されずに古くなる
・オーナーが不明確または不在
・まちがいや不足に気づいたり質問があっても、伝える手段がなく放置される
・検索されずに埋もれてしまい、内容が古いことにだれも気づかない
●情報の体系化が難しい
・サイト全体の目次がカオス状態
・情報の粒度がまちまち
・書式や用語が統一されていない
・内容の編集者やモデレータが不在
通常のITプロジェクトであれば、この時点で課題をさらに整理し、優先順位をつけたうえで関係者のコンセンサスや承認を得るところだが、CMSプロジェクトの場合は机上の空論に終わってしまうことがある。CMSを評価したり実際に導入して利用することで、今まで気づかれなかった問題が表面化したり、CMSを導入したために新たに課題が発生することもある。この時点では課題と要因を洗い出す程度にしておき、CMSの選定と設計を進めながら要件そのものを修正し進化させていくことにする。
CMS選定前の初期考察
●Wiki?
このような事例にはWikiによる情報共有が適しているように思えるが、Lotus Notesという既存の仕組みとWikiは考え方が大きく異なるので、慣れるのが難しいだろう。学習のコストを正当化するためには、メリットを明確にして広報していく必要がある。
また、Wikipediaは閲覧や執筆するユーザーが多いため、コミュニティの自浄効果でまちがいや不足が修正されていくが、ひとつの企業や部署という少ない人数の中でうまく機能するだろうか。
●情報の共同所有?
コンテンツを担当者だけのものと限定しないで、全関係者がコラボレートしながら完成度を高めていくためには、まちがえても元に戻せるようなバージョン管理、何がどう変更されたかの更新差分表示、それを関係者へメール通知する機能などが最近のWikiでは一般的だ。他人が書いたコンテンツを直接直すことに抵抗がある人もいるため、コメントや質問を追記できる機能も必要だろう。
●分類が問題?
Lotus NotesはWYSIWYG編集なので、入力が難しいということは考えにくい。コンテンツの一貫性が問題になってきているということは、情報の整理と表現方法が最大の課題かもしれない。情報は増えると分類が難しくなる。情報をいろいろな切り口で分類するためのタクソノミー(分類体系)をつくっておく必要がある。ただし、知識という多様なコンテンツは複雑なため、明確な分類は不可能に近い。フォルダにコンテンツを入れるのではなく、コンテンツに対してその内容を表すタグを複数付けるアプローチが必要だろう。
●フォークソノミー?
このタグ付けを応用して、同じキーワードをもつコンテンツ同士は関連性が高いと見なし、関連リンクを自動生成できるCMSツールもある。わざわざ検索をしなくても埋もれた関連コンテンツを見つけることができれば、重複を避けつつメンテナンスしやすい情報の宝庫を実現できるかもしれない。
となると、タグは多いほどよい。他人が気軽にタグをつけられれば、管理者や著者には思いつかない多様な視点で、コンテンツに関する情報が充実していく。
●ユーザーエクスペリエンスが重要
厚いマニュアルを読まないと活用できないような仕組みは、知識共有というボランティア性が高い用途の場合、使われずに失敗に終わりがちだ。操作性や快適なユーザーエクスペリエンスが重要になるため、ユーザビリティを評価の項目に加えることにする。
次回は、この事例の要件に基づいて、各種のCMS製品を評価しながら、最近のCMS開発者がコンテンツ管理に関する課題をどうとらえ、解決しようとしているかを明らかにしていく。
本記事は『Web STRATEGY』2007年 3-4月号 vol.8からの転載です
この号の特集など、ほかの記事の紹介はこちら！
『Web STRATEGY』最新号の情報はこちら！
Amazon.co.jpでの購入はこちら！
定期購読はMdN Squareで！
