ここから本文です

CMS Watch : ビジネス部門を巻き込んで - CMSプロジェクトを成功させるための実践アイデア

2005年2月21日 掲載

ヤヌス・ボワイエ（Boye ITマネージング・ディレクター）

あまりにも多くのCMS（コンテンツマネジメントシステム）プロジェクトが、目的を達成できなかったり、単にまったくの敗北という結果に終わっている。よく指摘される原因のひとつは、上級管理職の熱意と理解が欠けているという点だ。経営陣と担当部署（マーケティング、広報、営業、人事など）は、コンテンツマネジメントには長けているかもしれないが、残念なことに、経験と知識が不足しているために、コンテンツマネジメント・プロジェクトのオーナーとなることは少ない。

その結果、適切な目標が設定されず、目的があやふやになり、プロジェクトの舵取りが自然とIT部門に委ねられるようになるケースが多い。

今日では大企業のほとんどが、CMS（おそらく自前のもの）について何らかの経験を持っているが、多くの企業でそれは、セルフサービス・プロジェクトやポータル・プロジェクトといった仮面を着せられている。現在導入されているCMSの多くは、単にまったく利用されていないか、利用されているとしても十分ではない、あるいはもしかすると、新しいものに取り替えられる寸前の状態にある（後者の場合は明らかに、その企業は、次回こそ正しいやり方で導入しようと思っている）。このような状況だから、上級管理職がコンテンツマネジメントとはいったい何なのかをきちんと理解できずにいるのも、不思議ではない。そしてそのために、非現実的な期待を持ってしまうのである。

さらに、こうした問題点は、測定可能な目標設定や共通のボキャブラリーが存在しなかったり、社内のさまざまな専門家がCMS内で果たすさまざまな役割についての理解が不足していたりすることで、いっそう大きな事態となる。

実践的なアイデア

これから紹介する実践的なステップを踏むことによって、初期導入プロジェクトだけでなく、価値の高い長期的なプロセスについても、成功の可能性を高めるられる。以下のリストは、すべてを網羅したものではないが、良い出発点になるだろう。

プロジェクトの成否を見きわめるため、コンテンツマネジメントのKPIを導入すること

プロジェクトの進捗度を定義・測定するために、KPI（キー・パフォーマンス・インディケータ）を使ってみよう。KPIは、数量化できる指標で、プロジェクトの成功に欠かせない要因を反映したものでなければならない。

従来のCMSプロジェクトでは、多くの場合、予算や期限、あるいは新しいCMSへの移行といった、単純な要因を成功の指標としてきた。しかし、プロジェクトの期間が長かろうと短かろうと、これだけでは不十分だ。

どんな組織にも、合理的なビジネス要件とテクニカル要件がある。このなかには、数量化が不可能で、要件が満たされるか満たされないかのどちらかしかないものもある。もちろん、こうした要件も無視すべきではない。しかし、プロジェクトの成功を測る重要な要因としては使わないことだ。

より詳細なKPIを使えば、パフォーマンス・マネジメントにもつながるし、プロジェクトの参加者には「目の前のニンジン」として機能することにもなる。週単位、あるいは月単位で進捗状況は測定され、これに基づいて、プロジェクトの成功率を高めるための根拠ある行動を取ることができる。

例えば、コンテンツマネジメントのKPIには次のようなものが考えられる。

• パブリッシングおよびマーケティング・コストの削減
• プロダクション・サイクルのスピードアップ
• 顧客満足度の向上
• コールセンターにかかってくる電話件数の減少
• 顧客やパートナー企業による重要情報へのアクセスの簡略化
• 平均発注量の増加

理想的には、会社全体のKPIとしても使えるようなKPIを探すのがベストだ。そうすれば、CMSプロジェクトに対する関心が高まり、上級管理職がプロジェクトを理解したり参加したりするのも容易になる。

最後に、測定するものとコンテンツマネジメント・プロジェクトがどのようにつながっているかを、徹底的に検証することが重要だ。そして、「測定できないものはマネージできない！」という事実を忘れないこと。

プロジェクトのオーナーシップをビジネス部門に預けること

KPIの達成を目指すのであれば、ビジネス部門にいる商業プロジェクトのオーナーが、CMSプロジェクトのオーナーシップも持つ必要があるだろう。

このコンセプトは、多くの企業でIT部門がCMSプロジェクトのオーナーになっている、という標準的なアプローチに相反している。しかし、ITがオーナーになるべきではない正当な理由は、いくつも考えられる。

• コンテンツマネジメントは、単なる技術プロジェクトではない。初期の段階ではテクニカルな面に焦点が当てられるかもしれないが、実際には、有能な編集チームを育成し維持して、常に質の高いコンテンツを作成していくといったビジネスプロセスこそが、コンテンツマネジメントの本質だ。
• ビジネスユーザー（エディターなど）に受け入れられることは、どんなCMSプロジェクトでも重要となる。早い段階で彼らを巻き込み、オーナーシップを与えることで、CMSがもたらす変化に対する抵抗感や敵意は、必ず軽減されるだろう。
• IT部門はプロジェクトの成功に欠かせない。しかしその一方で、コンテンツマネジメントのニーズを抱えているビジネス部門は、さまざまな顧客に目を向けていることから、IT部門とは異なる目標やインセンティブを持っている場合がある。

上級管理職のレベルは、リソースの使用と全体的なプライオリティの両方に関して、最終的な決定権を持つ必要がある。とどのつまり、適当な量のリソースと予算を投じたり、数々の要件に対して重要な優先順位を付けたりするのは、経営陣の仕事だ。そしてこうした状況を作り出すには、技術部門の予算がビジネス的なプロジェクトに割かれる場面では必ず、上級管理職が正式なITガバナンスのプロセスに積極参加することが必要となるかもしれない。しかし、こうすることにより、CMSプロジェクトの予算がIT部門から出ているという理由だけでプロジェクトのオーナーシップをIT部門に渡してしまうよりも、ずっと良い結果が生まれるだろう。

このプロセスの一環として、現在のCMSプロジェクトのオーナーシップにかかっているコスト総額を計算してみることが重要だ。これによってまず、通年で必要な予算について貴重な見通しが立つ。しかしもっと重要なのは、IT部門とビジネス部門で将来のコストをどう分担していくかについて、実際的な目安が得られることだ。コストのうちどれだけが、本当に技術的なコスト（ソフトウェア、ハードウェア、ホスティング、開発、システム管理、システム統合など）で、どれだけがビジネスプロセス（要件、編集プロセス、コンテンツ監査とコンテンツ移行、ワークショップ、プロジェクト・プランニング、研修など）に関するものなのか。後者のコストはほぼ確実に前者を超える（特に後々の段階で）ということを考えれば、CMSプロジェクトはますます、ITプロジェクトというよりもビジネス・プロジェクトの様相を呈してくる。

プロジェクトのオーナーシップをビジネス部門に移すにあたって、ひとつの実践的なアプローチとなるのが、部門横断的な統括センターを設置して、IT部門をはじめ、関係する全ビジネス部門のメンバーを取り込むことだ。この「コンテンツマネジメント統括センター」とは、プロジェクト・マネジメントやプロジェクト開発を手がける中央機関で、そのなかでは1つのチームが担当となって、必要な技術やプロセス、ウェブサイトやアプリケーションを所有、保守、開発、サポートしていく。このチームは、知識ベースを構成し、確立したベスト・プラクティスやマニュアル、一貫性のあるコミュニケーションや標準化などを活用していく。

用語の意味を定義すること

プロジェクトで使われる共通のボキャブラリーを確立するよう、努力することも重要だ。これでかなり時間が節約できるし、混乱も防げるようになる。例えば、「CMS」「ワークフロー」「テンプレート」「ドキュメント」「コンテンツ・フラグメント」「ロール」といった用語を考えてみよう。プロジェクトにおいて、これらの言葉はいったい何を意味するのか。おそらく、プロジェクトの参加者によって意味は違っているだろう。しかも、外部のコンサルタントやベンダーといったリソースが入ってくると、事はさらに悪くなる。外部の人は、まったく異なる独自の定義を持っていると思ったほうがいい（例えば、CMS Watchの「ワークフロー」の定義を見てみてほしい）。

用語の定義に役立つひとつのアプローチとして、プロジェクトの初期段階で、プロジェクトの主な参加者に簡単な用語集を作成してもらい、カギとなる用語の定義を出してもらうことが挙げられる。これは「ライブ」のドキュメントである必要がある。つまり、社内の学習が進むにつれて、用語が追加されていく。そして、このドキュメントは、他の重要なドキュメント（要件やプロジェクト計画など）とともに、プロジェクト担当部で保管するといい。Wikiを使ってもいいだろう。

用語集が出来上がったら、それに忠実に従って用語を使うよう、時間と労力をかけるのも重要なことだ。プロジェクトには常に人が出入りしているから、旧式の紙の用語集と同じように、そこに書かれている語義が時間とともに変わっていくのは避けられない。これは特に、ハイテク用語や新しく登場した用語に言えることだ。常時更新することに加えて、6カ月ごとなど定期的に用語集を見直すことを習慣にするといいだろう。

自社の社員を知ること（ベンダーは知らないのだから）

ソリューションのなかには、製品デモの際に非常に簡単に見えるものがあるかもしれない。しかし実際には、そのユーザビリティは、デモが行われているサイトでのみ実現していることだ。ユーザビリティとは、エディターにとって使いやすいというだけでなく、チーム全体にとって使いやすいということを意味する。

自社の組織に特有の人物やシナリオを使ってみると、CMSプロジェクトにおける主なロールの違いが明らかに分かるだろう。例えば、次のような違いが考えられる。

• エディター：コンテンツ作成やパブリッシングの容易さに関心を持っている。CMSのヘビーユーザーである。
• システム管理者：ユーザー管理やロール管理など、CMSの管理全般に関心を持っている。
• 開発者：テンプレートの作成に関心を持っている。マニュアルがしっかりしていて、学習しやすいものを求めている。
• たまに使うユーザー：CMSが標準的な構造になっていて、すべてが直観的で、しばらく使っていなくても再学習が簡単なものを求める。
• スーパーヘビーユーザー：クリック数を減らし、1つのメニューボードでなるべく多くのことをしたいと考えている。

ほぼすべてのソフトウェア会社に共通することだが、CMSベンダーも、自社の製品については詳しい知識を持っている半面、その実装計画となると理解度が比較的低いことが多い。ベンダーが提供するマニュアルは、製品中心のものになっていて、開発者やシステム管理者には役立つかもしれないが、情報アーキテクトやプロジェクト・マネジャー、トレーナーなどには使いにくいこともある。

どのCMSプロジェクトにも、ビジネスユーザーが答えるべき一連の質問がある。どのようなタイプのコンテンツを管理するのか。どのようなロールがあるのか。ワークフローに関する規則はどのようなものか。アーカイブ化されたコンテンツはその後どうなるのか、といった質問だ。CMSの初期導入時にこれらに対してどのような答えができるかは、CMSの機能にもよる。しかし最終的には、これらの質問は、ビジネス部門の担当者が回答しなければならないビジネス上の質問であって、現場でとにかくサイトを立ち上げようとしているCMSベンダーの実装チームが答える質問ではない。

ほかの人と経験を分かち合うこと

CMSよりも成熟したマーケット（ERPやCRMなど）では、地域内のユーザーが集まって、他社と情報交換することも珍しくない。こうした会合は、システムやベンダーの区別なく開かれ、経験を分かち合うのが目的とされている。

もちろん、CMSベンダーも、グローバルまたはインターナショナルなユーザーグループを作っていて、そのなかには役に立つものもある。私の経験では、ベンダーが主催するユーザーグループの会合は、製品に特有のテクニカルな知識を交換するうえでは価値がある。しかし、IT担当者やビジネスユーザー、上級管理職は、地域内の他のユーザーと会って、自分と同じようなロールを持っていながら必ずしも同じCMSを使っていない人と情報交換するほうが、役に立つと思えるかもしれない。

「コンテンツマネジメント・プロフェッショナルズ（CM Pros）」は、コンテンツマネジメントの改良と成長を目指すグローバルな会員組織だ。新しくできた野心的な組織で、すでにCMS業界をリードする多数の人材がメンバーになっている。CM Prosの会員は、当初コンサルタントが多かった。このプロジェクトが将来どう発展していくのかは、興味深いところだ。

地域レベルでも、ベスト・プラクティスの情報交換を育もうという組織が多数存在している。例えば、地元の企業や政府機関を数多くメンバーに抱える「デンマーク・コンテンツマネジメント・フォーラム」だ。メンバーはさまざまなCMS製品を使っていて、年に4回会合を開いて、学んだ教訓や貴重な経験を交換しあっている。

同じような地域プロジェクトは、ヨーロッパ、オーストラリア、北米でも広がっていて、なかには非常にオープンなものもある。このコラムでは、役に立つ実践アイデアをお届けしようと試みたが、もっと良いアドバイスは、意外に身近なところで見つかるかもしれない。

ヤヌス・ボワイエは、ベンダーに依存しないコンテンツマネジメント・コンサルティングを提供するデンマークの会社、Boye ITのマネージング・ディレクターを務めている。かつては、ヨーロッパ各地に顧客を持つCMS会社に勤務し、さまざまな役職を経験した。

この記事の原文「Involving the Business - Practical Ideas for CMS Project Success」は、2004年11月4日、「cmswatch.com」に掲載された。

トラックバック

このページのトラックバックURL
http://www.designit.jp/mt/mt-tb.cgi/103