• ホーム
• 購読申込
• ヘルプ
• アーカイブ

CMS導入は誰のため？

～CMS百花繚乱時代に、改めて考える～

Webサイトの制作案件において、クライアントから「今後の運用まで考えて、CMS を導入してほしい」という要望を受けることが多いでしょう。とは言うものの、今や CMS 百花繚乱時代。Movable Type、WordPress、Drupal など、ネット上ではさまざまな CMS が話題となっています。では、どの CMS を選べばいいのでしょうか？

各 CMS サービスの特徴を調べ、自分のスキルに見合ったものや導入しやすいものを選択することも大切ですが、制作後の先にある視点も取り入れることが大切ではないかと思うのです。本記事では、サイト運用ソリューションの現状を俯瞰しつつ、CMS の導入時に必要となる視点について改めて考えてみたいと思います。

クライアントにDreamweaverを覚えていただくのは、ちょっと...

制作会社が Web サイトを受注して制作する案件では、そのまま運用（日々の更新作業）を請け負うケースと、クライアントが運用を担当するケースとに大きく分けることができます。「Web サイトは生もの。新鮮な更新情報が命」というタイプのサイトでは、やはり運用は内部の方が受け持つ方がスピーディな更新が望めます。しかし、一般企業の多くでは、Web 専任の担当者をおくことができないといった事情や、配置換えによって HTML の知識や Dreamweaver の操作などのスキルがない方が担当になってしまうことが多々あり、問題は単純ではありません。

考えてみると、クルマを買ったからといってエンジンなどのメカニック的なところに詳しくなくても運転はできます。Web サイトを運用していくために HTML／Dreamweaver を覚えるのは、一般企業の担当者にとっては過剰な知識とも言えなくもありません。

一般企業の担当者にとってやさしい Dreamweaver のソリューション

読者の中にはご存じの方も多いと思いますが、Dreamweaver には一般企業の担当者がラクに運用をできるように、以下のソリューションが用意されています。

• Dreamweaverテンプレートを活用する。
• Dreamweaverで構築したサイトをContributeで運用する。
• InContext Editing （ICE）を活用する。

それぞれおおまかに復習しておきましょう。

Dreamweaverテンプレートを活用する

「Dreamweaverテンプレート」を使って「ひな形」を管理することによって、「編集可能領域」以外のエリアがロックされます。新着情報、FAQ、商品などのアイテム追加／削除／並び替えなど、更新作業の多くは、定型の項目によって構成されています。これらを適切に「リピート領域」マークアップしておけば、運用する人間はHTMLを意識せずに作業することができます。

Dreamweaver で構築したサイトを Contribute で運用する

Adobe Contribute は、Dreamweaver テンプレートの運用部分のみを切り出したようなアプリケーションです。さらに、ロールバック（過去のバージョンにさかのぼる機能）や、担当者ごとの権限設定など、Dreamweaver ではカバーできない機能もサポートしています。

Contribute は、Web Premium に付属していますが、単体でも販売されています。単純に、単体の価格ベースで Dreamweaver の半分くらいの金額（24,675円）なので、一般企業の「ふところ」にもやさしいソリューションといえます。

InContext Editing（ICE）を活用する

Dreamweaver CS4 から実装されている「InContext Editing（通称ICE）」を使うことで、あらかじめ設定してある編集可能領域に直接ブラウザで手を入れることができるようになります。魅力的なソリューションですが、運用できる環境は限られています。

• InContext Editing - Adobe Labs
• Adobe InContext Editing について

このように Dreamweaver の運用ソリューションにも、一般企業の担当者にとってやさしいものがありますが、ページ数が大量になったり、運用する人数が増える場合など、1,000ページを超えるような案件では、導入コストや作業フローの標準化などがデメリットとして出てきてしまいます。そこで、注目されているのが CMS（コンテンツ・マネジメント・システム）です。

日本における CMS

CMSとして注目されたブログシステムMovable Type

Dreamweaver の運用ソリューションと並行して、日本では Movable Type を CMS として導入しようと試行錯誤されてきました。もちろん、他にもたくさんの選択肢があります。このようなブログシステムの台頭とともに、次のような「気づき」がありました。

• 「タイトルや本文を入力していくだけでコンテンツを追加できる」って、究極の運用だよね。
• RSS フィードを出力することで、サイトの更新情報を利用者に知ってもらうって、お互いにハッピーだよね。
• 外部から参照されることを視野に入れて、記事ごとにアドレスが必要だよね（パーマリンク）。
• 外部のサイトとの関連を高めたり（トラックバック）、ユーザとのコミュニケーションをとったり（コメント）するのも大事だよね。

後者の2つは、CMS と直接は関係ないのですが、「ブログが SEO に効果的」という事実が後押しとなり、ブログシステムである Movable Type を CMS として利用するという動きが進みました。発注者から（よくわからないまま）「Movable Type でお願いします」と指定されるケースも増えています。

DreamweaverとMovable Type

Movable Type を CMS として利用する際に課題となったのは、デザインのカスタマイズです。オンライン上でテンプレートを管理し、独自タグでコーディング、最終的な表示を確認するには再構築する必要がある。こうした Movable Type の作業フローは、制作現場のワークフローに融合しにくいものでした。そうした中、Dreamweaver は Movable Type に早い時期から注目していました。Dreamweaver MX 2004 の時代（2005年7月）に、「Dreamweaver 拡張機能 for Movable Type 3」という拡張機能をリリースしています（その後、MT4対応版にアップデート）。

この拡張機能により実現されているのは、主に入力支援とリファレンス機能です。

• コードビューでのMTタグ、属性の入力支援。
• タグ選択ボタンによるタグ挿入。
• 詳細なリファレンス。

ただし、これらの拡張機能を入れていても、［HTMLのクリーンアップ］コマンドを実行すると<が<になってしまったり、マークアップの検証では MT タグがエラーの対象となってしまったりといった面もあり、ガッツリとサポート、というより、支援機能といったニュアンスです。

とはいえ、「Dreamweaver 拡張機能 for Movable Type 3によるテンプレートカスタマイズについて | デベロッパーセンター」で解説されているように、Dreamweaver を使って、Movable Type テンプレートを編集するというワークフローは、当時、CSS レイアウトに取り組んでいた Dreamweaver ユーザに大いに受け入れられました。

その後のMovable Type

その後、Movable Type はバージョン4（2007年7月リリース）、バージョン5（2009年秋にリリース予定）と、さらに CMS にフォーカスした開発が行われています。バージョン3の時代でもリファレンスがないと苦労する状況だったものが、バージョン4では大きな機能拡張が行われ、Movable Type の全容を理解し、制作フローに落とし込むハードルはさらに上がってしまいました。

また、テンプレートを構成する要素がモジュール管理されることにより、各テンプレートの整合性を保つことが容易になった反面、バージョン3の時代に可能だった「Dreamweaver を使って Movable Type テンプレートを編集する」というワークフローは不可能になってしまいました。

<MTSetVar name="body_class" value="mt-main-index">
<MTSetVar name="main_template" value="1">
<MTSetVar name="main_index" value="1">
<MTSetVar name="sidebar" value="1">
<MTSetVarBlock name="title"><$MTBlogName encode_html="1"$></MTSetVarBlock>
<$MTInclude module="ヘッダー"$>
<MTEntries>
    <$MTEntryTrackbackData$>
    <$MTInclude module="ブログ記事の概要"$>
</MTEntries>
<div class="content-nav">
    <a href="<$MTLink template="archive_index"$>">アーカイブ</a>
</div>
<$MTInclude module="フッター"$>

Movable Type 4.1 でのメインページのテンプレート：当然ながら Dreamweaver でこのソースコードをみても「">アーカイブ」という文字列しか表示されない

新興CMSとその可能性

Movable Type の他には、海外の「WordPress」や「Drupal」など、機能的に優れているだけでなく、ユーザ数も多く、実績も豊富なものがあります。しかし、「WordPress」や「Drupal」のディープなカスタマイズには、PHP の知識が不可欠。今どき、PHP は必須のスキルとも言えなくはないですが、小規模案件ではトゥー・マッチだったりします。

一方で、最近、日本発の CMS がアツくなってきました。私が主宰している「CSS Nite」では、先月、「LP6：CMSリベンジ編」というイベントを開催し、300名弱の方にご参加いただきました。 「SOY CMS」「a-blog cms」「Web Release2」「RCMS」「CMS Designer」「bingo!CMS」など、「国産 CMS って、こんなにあったの？」と驚かれた方も多いようです（他にも「NetCommons」「CMONOS」など、いくつかの国産 CMS が存在しています）。

特に、SOY CMS と a-blog cms は、Dreamweaver との親和性を意識した作りになっています（詳しくは、6月号）。例えば、Movable Typeで記事の一覧を表示するとき、

<MTEntries>
<ul>
<li><$MTEntryTitle$></li>
</ul>
</MTEntries>

のように書いても、Dreamweaver のデザインビューでは何も表示されないため、スタイル設定を行うのは困難です。

一方、SOY CMS を例に取ると、

<ul>
<!-- block:id=”news”-->
<li cms:id=”title”>その1</li>
<!-- /block:id=”news”-->
<!-- cms:ignore -->
<li>その2</li>
<li>その3</li>
<!-- /cms:ignore -->
</ul>

のように記述します。これを Dreamweaver のデザインビューは、次のように表示します。

<ul>
<li cms:id=”title”>その1</li>
<li>その2</li>
<li>その3</li>
</ul>

つまり、「その1」「その2」「その3」をアタリ文字としてスタイル設定を行うことができます（実際には、<li>その2</li><li>その3</li>は出力されず、<li cms:id=”title”>その1</li>の部分が、格納されているデータに応じて書き換わります）。

CMS にがっちり組み込む前に細部までの仕様をカッチリ決め、スタイル設定も完了していれば話は別ですが、仕様が固まらない状態で見切り発車しているプロジェクトや、途中からの仕様変更に対応しなければならない場合には、Dreamweaver でデザインのカスタマイズが行いやすいかどうかは制作者にとって無視できないポイントです。

また、Movable Type 4 のテンプレートのようにモジュール管理を突き詰めると、Dreamweaver のデザインビューでは、ページとしての体裁を確認することができません。a-blog cms では、外部ファイルを SSI のインクルードと同じ記述（例：<!--#include file=" header.html" -->）で扱うため、デザインビューでプレビューしながら作業を進めることができます。

忘れてならないのは運用する人、そして、サイトの利用者

ここまでは、主に制作者視点での運用ソリューションとしての CMS を見てきましたが、制作後の先にある視点も大切です。運用者目線の使いやすさ、サイト利用者目線でのベネフィット提供を忘れてはなりません。

運用する人にとってやさしいか

一般企業の担当者にとっては、Movable Type の管理画面でさえ難しく感じるという声をよく聞きます。Movable Type には「Power CMS for MT」をはじめ、見たまんま編集プラグインやブログ記事編集画面をウィザート形式にするプラグインなど、管理画面をカスタマイズするソリューションは存在していますが、 面倒だったり、費用対効果に見合わなかったりするため、現実的ではありません。

現状では、Movable Type だけでなく、他の新興 CMS も制作者主体の管理画面となっているため、一般企業の担当者には、たくさんの見慣れない用語、運用上必要でない情報、入力フローや出力画面と異なる画面構成など、CMS を運用していくという面では、あまりやさしいとは言えません。

運用する人にとってやさしい管理画面を提供できるかは、CMS が生き残っていく際の大きなポイントになるはずです。

最終的にはサイト利用者へのベネフィット

もう一つ大切な視点は、サイト利用者の視点です。導入する CMS によって、サイト利用者に対して何らかのベネフィットを与えることができるのか。例えば、昨今のブログでは、よく読まれている記事を TOP10 化したり、関連する記事をリストアップしたりするなど、時系列では追いにくい記事を可視化し、リンクを促す手法がよく使われています。

これらを実現するのは、アクセス解析や「タグ」（tagging）によるコンテンツのメタ情報管理です。ブログ的な作りでないサイトでも、サイト利用者の利便性を高めるために、単に静的なサイトを用意するだけでなく、マイクロコンテンツ、つまり、コンテンツを小さい単位に分け、それぞれのつながりを利用して、サイト利用者に適切な情報をアウトプットしていくことがより求められつつあります（この点では「RCMS」に注目しています）。

この他、コメントを通して「もの言わぬ」ユーザからのフィードバックをすくい上げるのに最適な記事の評価システム（レーティング）、単純なマッチングだけでなく、誘導したいコンテンツへの重み付けを変えるサイト内検索の最適化など、単にコンテンツをアウトプットするだけでなく、より利用者にコミットするサイト作りのために、チョイスするCMSが適しているか、という視点も忘れずにいたいものです。

まとめ

今回は、最適な構築／運用フローのためのソリューションという観点で Dreamweaver や CMS を俯瞰しました。製品の完成度だけでなく、開発者や書籍、セミナーなど、情報やノウハウの流通量が多い、いわば「エコシステム」が強力な Movable Type を極めるのもよいでしょう。その一方で、案件規模に応じて、適切な CMS を選択していくにもよい時代となりました。

サイト利用者によって、そのサイトがどのように構築・運用されるのかはどうでもよい問題。運用者にとって、その CMS の都合や制約は突っぱねたい問題。制作者の視点だけでなく、サイト利用者、運用者の観点でバランスのよい選択を行っていきましょう。

‹ 戻る