CMSの「運用」は導入よりもはるかに期間が長く、CMSの成否を分ける重要なフェーズであるにも関係なく、あまり語られることがない。CMSの導入はリリースして終わり、立ち上げたものを継続するだけ、ではうまくいかないのだ。導入時の設計思想を守りつつ、変化に柔軟に対応しながら、組織やコンテンツを成長させていく必要がある。

今回は、導入や移行が終わった後の「運用」をスムーズに進めていくための秘訣を紹介したい。

• クロスファンクショナルなチームを作れ！
• 社内の信頼を勝ち取れ！
• 変化・変更を歓迎せよ！
• 貯めるべきはコンテンツとプロセス（システムではない）
• エンドユーザーが製品を変える

クロスファンクショナルなチームを作れ

選任チームを社内に作り、強力なエバンジェリストを置こう。エバンジェリストはある程度の知識と経験を持つ専門家であると同時に、課題や困難を乗り越えながら変化に対応していける熱意ある人が望ましい。昔からブログやCMSに興味があり、個人サイトで実験しているような人を社内で抜擢するのもよいが、見つからない場合は手っ取り早く社外で中途採用するという手もある（筆者自身もこうしてエバンジェリストを経験した）。見つからないからといって、エバンジェリストの役割を外部の会社に委託することは避けるべきだ。あくまで内部の社員というスタンスに立たないと、実情を把握した上での長くタフな調整や意思決定、推進ができないからだ。

また、チーム全体をマーケティング・制作・ITから人を集めたクロスファンクショナルチームにすると、各部門間の調整がしやすくなる。この場合も、それぞれの部署に2〜3年は在籍している社員など、課題を部署に持ち帰って調整ができるレベルのスタッフを選出しないと、ただの伝書バトになってしまう。そして、このチームは経営陣のサポートを得てトップダウンで意思決定や推進が行えるようにしておくべきだ。定期的に経営陣へレポートする場も作っておきたい。

米国では、このようなクロスファンクショナルなチームを「CoE（Center of Excellence）」と呼ぶことがある。直訳すると「卓越した技能を持つ集団」であり、組織における研究開発やガバナンス、推進のチームに対して使われる名称だ。少し大げさではあるが、日本語では「コンテンツ管理委員会」「CMS活用プロジェクト」（ただしプロジェクトには本来終わりがある）、「ECMプログラム」（複数プロジェクトの集合という意味で）といったところか。現場スタッフの集まりではなく、業務をスムーズにするための横断的な組織、という位置づけだ。

社内の信頼を勝ち取れ

CMSを実際に利用する社内ユーザーに対して、手厚くサポートや啓蒙活動をしよう。「あのチームは現場の見方だ」と認識され、「何かを良くしてくれるに違いない」という期待をされるようになる必要がある。社内であっても手を抜かず、最高のサービスをするべきだ。

実際のユーザーから信頼されると、「ここが使いにくい」「こうしてほしい」「こういうことはできないか」と、要望や感想が寄せられるようになる。某航空会社でコンテンツ管理のCoEを推進するある人は、この状態を「人々が我々のドアをノックしてくれるようになった」と表現した。これは、設計時にはわからなかったことを吸い上げる良いチャンスだ。CMSを強制的に使わせられる嫌なシステムにしてしまうと、このような貴重な声はデスクの上の独り言やランチでの会話のなかで消えていってしまう。

社内の成功事例を作る、ということも意識したい。特に、何がどう良くなったのかを数値的に示せる事例を作ることができれば、説得力が生まれて多くの納得を得られるようになる。投資に見合う効果があったと経営陣に認識されれば、将来のアップグレードへの承認も得られやすくなるだろう。

変化・変更を歓迎せよ

“CMS導入時に検討した設計内容は叩き台でしかない”と認識しておいたほうがよい。CMSを本格的に導入すると、仕事の方法を多少なりとも変える必要が生じる。人の想像力には限界がある。組織にとって未経験のプロセスについて関係者へのヒアリングを重ねたところで、でき上がった要件は想像に基づく幻でしかないのだ。

また、Webの運用そのものが急激に変化している。Webが単なる広報ツールではなくビジネスそのものに影響を与えるようになった今では、ブラウザのバージョンアップ、新デバイスの登場、SEO手法の変化、コンテンツの成長、サイト増大、管理プロセスの進化、組織変更、業界再編、法令改正など、コンテンツ・プロセス・システムに求められる要件の変動要因が数多く存在する。

そういう意味で、CMSの運用は運用というよりも改善プロセスであるといえる。この継続的な改善をいかに簡単に実現できるかが、導入後の成否を分けることになる。

たとえば、ソフトウェアはいつも最新版にしておこう。新機能追加やバグ解消などのメリットを早く享受できるだけでなく、アップデートを溜めると後で大変になり、次第にアップデートがおっくうになってしまう。システムを気軽かつ安全に変更できるような手順をふだんから確立しておく必要がある。

CMS製品のバージョンだけでなく、その上で開発したテンプレートやワークフロー、カスタマイズ機能なども定期的に見直せる体制とスケジュールにしておきたい。筆者の場合、リリースした後も開発者のリソースを薄く残しておき、毎月決められた時間内で小さな改修や機能追加を行えるような契約を行った。OSやブラウザでさえ、毎月のようにアップデートされるのだ。立ち上げチームを完全に解散してしまい、改修が必要になったときにその都度見積もりや発注をするようでは、きめ細かい継続的な改善が実現できなくなってしまう。

貯めるべきはコンテンツとプロセス（システムではない）

初期投資をしたシステムを長い間使っていると、システムそのものを資産として大事に扱ってしまいがちだ。通常のシステム開発であれば、これは当然であり、経理的にもソフトウェア資産として減価償却される。ところが、まだ枯れていないCMSの場合は想像に基づくプロトタイプ的な意味合いが強く、それに固執すると変化への対応が遅れることになる。

継続的な改善を繰り返しながら貯めていくべきなのは、コンテンツそのものと、人的な管理プロセスだ。システムはそれを簡単にするだけのものでしかなく、大胆に変える・捨てるという勇気が必要になる。そういう意味では、最初はASPや安価なものを導入し、コンテンツが整理されて増え、同時に管理プロセスも確立されてスムーズに運用できるようになった後に、改めて要件定義を行い、理想的なCMSを導入する、という方法も効果的だ。

このため、CMSは初めから乗り換えを想定しておいた方が良い。CMS製品は規模も種類も幅広いため、要件が変われば最適な製品も変わるものだ。採用した製品が他の企業に買収されたり、経営判断で方向性が大きく変わったりすることもある。特定の製品やベンダーに依存（ロックイン）しないようにしておきたい。

CMSの選定時には、乗り換え時に必ず必要になるコンテンツの取り出し方法についてもRFPに含めておくべきだ。構造化されたコンテンツは、その構造を保ったままエクスポートし、他のCMSへ取り込めるのか？メタデータとコンテンツ（ドキュメント）はどのように結び付けてエクスポートできるのか？　ワークフローの設定は書き出せるのか？…

また、導入後もCMSの新製品や業界動向をウォッチし続ける必要がある。導入済みのCMS製品が打ち切りになっても、半年以内に別の製品に乗り換えられるくらいの状態をキープしておきたいところだ。

エンドユーザーが製品を変える

CMS製品の場合、比較的エンドユーザーの声が重視される傾向がある。ベンダーによっては、ユーザー会が定期的に開催されている。筆者も、米国で開催される「EMC Documentum」のユーザー会に3年連続で参加し、日本での事例を講演したこともあるが、エンドユーザーが自らの事例をオープンに話し、それに対して質問や議論が交わされるのを経験し、非常に刺激を受けた。

コンテンツの管理に関しては、コンテンツに投資してビジネスに活かしている事業者自らがもっとも理解をしている。コンテンツ管理のプロとして、製品ベンダーに対して意見や要望を出していこう。こういったエンドユーザーの声を吸い上げ、それを製品に反映することで初めて、CMS製品は育っていくのだ。それができない製品やベンダーに将来性はない。

そして、CMS製品、さらにCMS業界全体が活性化することが、最終的に自社の利益につながるのだ。