生きたサイト運営を実現するための
実践CMS導入・運用ガイド
文＝清水 誠
実践系Webコンサルタント。DTP・印刷・ネットビジネスの分野を中心に、ITとIAによる業務カイゼン を手がける。印 刷物とWebへ画像をシングルソースするためのカラーマネジメント、文字情報をシングルソースするECM・XML・自動組版、ビジネスを加速するITイノ ベーションが最近のテーマ。1995年国際基督教大学卒
第7回
複雑化するサイト配信
CMSにはいろいろな機能があるが、実際のところどう役に立つのか?
これまでにテンプレート、ナビゲーション、入力方法などについて解説してきた。
今回は、今後もっとも進化と差別化が進むと思われるコンテンツの配信機能について、
違いの本質を徹底解剖していく。
■分散が進む制作環境
複数サーバへのファイル転送
Webがビジネスに直接的に影響を与える今日では、アップロードやテストの手順が複雑化しつつある。コンテンツ公開のトラブルを減らすためだ。
たとえば、自分のPCでテストを行い、次にテスト環境へアップロードしテスト、OKなら最後に本番サーバにアップロードし最終テストを行う。負荷分散のために本番サーバが複数台ある場合もある【1】。
【1】増えつつあるWebサーバ
各サーバにファイルを手でアップロードするのは手間がかかるだけでなく、ミスも増えてしまう。そこで、複数サーバへの配信を管理する機能が発達した。
制作の同時進行
サイトの規模が大きくなると、制作スタッフも増えてくる。別々のチームが同じサイトで更新作業を行う場合、まだ作業中のページをアップロードしてしまうことがないように、運用を工夫する必要がある【2】。
【2】制作が同時進行し、コンフリクトすることも
システム開発の場合、個人のPC上で各種のサーバを構築し、この自分専用の開発環境で開発とテストが終わったファイルのみをアップロード（コミット）するという手法がとられるが、制作においても同じ考え方が必要になってきた。
動的なページの増加
Webやビジネスの進化に伴い、動的に生成されるコンテンツが増えてきた。ランダム表示、リンク自動生成、ログイン後のパーソナライズなどの機能をどう実装すべきか? 最近ではPHPやRubyのようなサーバ側で動作する言語やブラウザ側で動作するJavaScript、FLASH、JAVAアプレットなど、選択肢がいろいろある。静的ファイルとプログラムでアップロードするディレクトリを分けてアクセス権限を変える、というような単純な制御ではすまなくなってきた。
■複数サーバ間のコンテンツを同期するために
トラフィックが多いサイトで負荷分散のために複数のサーバを稼働させている場合、すべてのサーバが過不足なく同じファイルをもつことをどのようにして実現するか、が課題になる。
1. フォルダごと上書き
たとえばWindows XPでフォルダを上書きコピーすると、フォルダ構造を保ったまま内包するファイルが上書きコピーされる【3】。上書きなので、コピー元のフォルダに削除されたファイルがあっても、コピー先のそのファイルが残ってしまうため、削除を反映することはできない。
【3】手作業でフォルダを同期するのは手間がかかり、ミスも避けられない
また、コピーする方法によっては、変更していないファイルもタイムスタンプが更新されてしまうことがある。
2. フォルダごと差し替え
上書きではなくフォルダごと全ファイルを差し替えれば、削除にも対応できるようになる【3】。ただし、サーバ上のフォルダを無条件で削除するため、サーバ側で追加されたファイルがあっても削除されてしまう。また、すべてのファイルを転送するため、大量のコンテンツを頻繁に同期するとネットワーク帯域を圧迫するだけでなく、同期に時間がかかるようになってしまう。
3. 差分を検知し個別処理
配信元と配信先のファイルの更新日やサイズを比較して、更新や追加されたファイルのみを転送すれば、転送に必要なCPU負荷やネットワーク帯域を最低限に抑えることができる【3】。削除に関しては、別途削除処理が必要になる。
ふたつのフォルダを同期するアプリケーションはいろいろ存在するが、単純化すると、このように動作する。
ただし、これではWebコンテンツに特有のタイミングという問題に対処することができない。サーバが何台もある場合、公開タイミングのずれが大きいと、ページは開けたのに画像が表示されない、JavaScriptのエラーが発生するなど、ユーザーにとっての不具合が発生してしまう。
4. 公開タイミングを合わせる
では、タイミングを合わせて配信するために、どのようなステップが必要になるのだろうか?
1. 変更されたファイルやフォルダを特定
2. 差分のみをサーバに仮転送
3. 配信先フォルダを一時フォルダに複製
4. 差分を3の一時フォルダへ上書き
5. 3のフォルダに1の削除を反映
6. 全サーバがこの状態になるまで待つ
7. 全サーバで一斉にフォルダを差し替える
8. 差し替えに失敗したサーバがあれば、全サーバのフォルダを元に戻す
要件としてまとめると、たとえば下記のようになる。
・ファイルとフォルダの削除や追加を複数のサーバに反映させたい
・タイムスタンプやパーミッションなどの属性を保持したまま配信したい
・CMS管理下にないファイルはサーバ上に残したい
・全サーバの公開タイミングを1秒以内の誤差で同期したい
・全サーバが同じ状態になるように失敗時はロールバックしたい
費用を抑えるため、それぞれに優先順位をつけて絞り込む必要があるだろう。
■分散化した制作体制をサポートする
ファイル単位でライフサイクルを管理する
本番サーバ間でファイルを同期するという前項で取り上げた問題は、公開ファイルをアップロードしたあとにその状態をどうほかのサーバに反映させるか、という問題であった。それよりも、更新作業を終えてテストやレビューを行い、OKならアップロードする、という公開前のプロセスのほうが要件が複雑になる。
まず、作業環境では公開タイミングが異なる作業が同時進行することがあるため、単純に更新されたファイルを無条件でアップロードするわけにはいかない。公開企業が株価に影響を与えるような情報を非公式に一部のユーザーにリークしてしまうと、裁判ざたにもなりかねない。
このため、ファイルごとにライフサイクル（公開状態）をもたせ、明示的にその状態を昇格・降格させる必要がある【4】。
【4】制作の過程で降格と昇格を繰り返す
作業環境とテスト環境を分離する
本番サーバと同じ状態のテストサーバを用意し、次に公開するコンテンツのみをそのテストサーバにアップロードするようにすれば、公開後の未来の状態が再現されるため、コンテンツだけでなくリンクチェックや検索エンジンのテストなど、機能面も含めてサイト全体をチェックすることができるようになる。
つまり、ライフサイクルは、最低でも「作業中」→「レビュー中」→「公開」というような3段階が必要になる【4】。
ファイルをグルーピングして管理
ページは画像やCSSファイルなど、複数のファイルで構成される。複数のページを同時に公開する場合もあるため、公開のジョブ単位で複数のファイルをまとめられると便利だ。ファイルをひとつずつ選びながらライフサイクルを昇格すると順次サーバにアップロードされてしまうようでは、人的ミスで漏れが生じたり、タイミングのずれにより表示や機能に支障を来す、などのリスクがある。
そこで、ファイルをグルーピングするという手法が生まれた。「変更セット」を作成しておき、対象ファイルを追加していく。これをライフサイクルの昇格やアップロードの単位として使えば、対象に漏れが生じることはなくなる【5】。
【5】変更セットは仮想的なエイリアス
ワークフローでライフサイクル管理
複数の作業が同時進行する場合、スムーズな運用のためには「レビュー中」のファイルをほかのスタッフが更新しないようにし、なるべく早く「公開」するか「作業中」に戻す必要がある。そのためにも、何をどのようなスケジュールで進めてだれがかかわっているか、今どこで止まっているか、などの進捗を管理することが重要になる。
ここで、ワークフロー機能が活躍する。作業の進捗だけでなく、過去の作業履歴を調べることができるようになる。関係者が数人しかいない場合でも、ワークフローで作業を管理することには意義があるのだ。
サイトの仮想化
ところが、他人が「作業中」のファイルは更新しない、という消極的な方法には限界がある。ある時点のサイトを自分用につくっておき、自分の作業が終わったらCMS上の最新コンテンツとマージする、という手法も発達した。オープンソースのCMSであるAlfrescoは、この機能が優れている。コンテンツ編集者がそれぞれ自分の「ワークスペース」を持ち、自分が編集したファイルのみが変更セットのように抽出されて管理される。自分の変更セットは、つねにその時点での承認された最新版のサイトに重ねてプレビューできる。ある時点のサイト全体をコピーするのではなく、日々更新される最新コンテンツと自分の変更分を合わせてサイト全体を仮想的に再現できるのだ。
この機能と関連して、個別のファイルだけでなく、サイト全体でバージョンを管理できるCMSもある。
■動的配信と静的配信の違いを知る
動的配信から静的配信へ
さて、このようにいろいろな機能を駆使してWebコンテンツを管理するわけだが、最近は動的なサイトが急増しつつある。CMSも動的配信への対応が必須になっていくのだろうか?
答えはNOだ。実はサイトが高度化するほど、CMSが担うべき機能はコンテンツの編集と保管のみに特化していく。コンテンツの動的配信は不要になり、ほかのWebアプリケーションやデータベースへコンテンツを静的に配信する機能が必要になってくるのだ。
何を何へ配信するのか
配信の仕組みは、どのようなフォーマットのコンテンツを何に対して配信するのかを明確にする必要がある【6】。
【6】コンテンツの生成と配信におけるCMSの位置づけ
コンテンツの動的配信
ブラウザからURLの接続要求があった時点で、HTMLを動的に生成してブラウザへ配信（送信）する。つまり、CMS自体がWebアプリケーションなのである。オープンソースのCMSやWikiは多くがこのタイプであり、ページの動的生成方法をプラグインやモジュールなどの仕組みで拡張可能にしている。
CMSという統一されたプラットフォーム上で手軽に開発や運用ができる、コミュニティで公開されたモジュールを再利用できる、などのメリットがある。
コンテンツの静的配信
コンテンツを静的なファイルに書き出すタイプ。静的配信の本当の意義は、パフォーマンス向上やSEO対策ではない。CMSから配信された静的ファイルを別のアプリケーションが読み取り、ページの動的処理を行うことで、拡張性や自由度が広がるのだ。つくり込んだ既存のWebアプリケーションがある場合、それを特定のCMS用につくり替えるのはコストの無駄になる。また、規模が大きくなると、CMSだけでは負荷に耐えられなくなる。
最近は、個別機能をあまり依存し合わないようにし（疎結合）、機能間の連携のインターフェイスを標準化するのがITのトレンドだ（SOAやWebサービスなど）。コンテンツ管理も、編集、管理、生成、配信などを分離して部品化し、いろいろなシステムと組み合わせる方向に進化しつつある。たとえば、EMC DocumentumはコンテンツをXMLで保管することで、編集機能を任意のXMLエディタに置き換えることを可能にした。FatWireをはじめ「高価な」CMSは、コンテンツの編集と保管の機能を「コンテンツサーバ」としてWebアプリケーションとは独立させた。Interwovenは、高度な配信機能を「Open Deploy」としてコンテンツサーバの「Team Site」から分離した。
このような本質的な違いを知らずに使い勝手やパフォーマンスの比較をしてしまうと、判断を誤ることがあるので注意したい。CMSで統一することによる開発・運用の手軽さと、規模や自由度のどちらを優先すべきか、を見極めて適切な選定や設計を行うとよいだろう。
最後に、コンテンツの動的配信をCMS以外の仕組みで実装する場合に役立つCMS側の機能を紹介しよう。
転送前後の自動処理
テストと本番環境とで設定ファイルを差し替える、検索エンジンのインデックスを再構築するなど、配信時に処理が必要なことがある。このような処理は、定期実行よりも配信直後に開始したほうがタイムラグが減り、効率も良い。
そこで、配信の前や後、失敗時や成功時に特定のプログラムやスクリプトを実行できるCMSが生まれた。また、ワークフローの途中にカスタムプログラムの実行を組み込む方式のCMSもある。
メタデータの配信
CMSやDAM（デジタルアセット管理システム）で保管しているメタデータを、HTMLファイルの中に反映させるだけでなく、XMLファイルやデータベースに格納することができると、Webアプリケーション側でできるコンテンツ処理の幅が広がる。特に、最近はPHPやJavaScriptから直接XMLコンテンツを読み込むことが容易なため、XMLでの配信は便利だ。
さて、本連載はこれまでCMSの個別機能について紹介してきた。次回からは応用編として、総合的で実践的な内容を紹介していきたい。
本記事は『Web STRATEGY』2008年3-4 vol.14からの転載です
この号の特集など、ほかの記事の紹介はこちら！
『Web STRATEGY』最新号の情報はこちら！
Amazon.co.jpでの購入はこちら！
定期購読はMdN Squareで！
実践CMS導入・運用ガイド
文＝清水 誠実践系Webコンサルタント。DTP・印刷・ネットビジネスの分野を中心に、ITとIAによる業務カイゼン を手がける。印 刷物とWebへ画像をシングルソースするためのカラーマネジメント、文字情報をシングルソースするECM・XML・自動組版、ビジネスを加速するITイノ ベーションが最近のテーマ。1995年国際基督教大学卒
第7回
複雑化するサイト配信
CMSにはいろいろな機能があるが、実際のところどう役に立つのか?
これまでにテンプレート、ナビゲーション、入力方法などについて解説してきた。
今回は、今後もっとも進化と差別化が進むと思われるコンテンツの配信機能について、
違いの本質を徹底解剖していく。
■分散が進む制作環境
複数サーバへのファイル転送
Webがビジネスに直接的に影響を与える今日では、アップロードやテストの手順が複雑化しつつある。コンテンツ公開のトラブルを減らすためだ。
たとえば、自分のPCでテストを行い、次にテスト環境へアップロードしテスト、OKなら最後に本番サーバにアップロードし最終テストを行う。負荷分散のために本番サーバが複数台ある場合もある【1】。
【1】増えつつあるWebサーバ
各サーバにファイルを手でアップロードするのは手間がかかるだけでなく、ミスも増えてしまう。そこで、複数サーバへの配信を管理する機能が発達した。
制作の同時進行
サイトの規模が大きくなると、制作スタッフも増えてくる。別々のチームが同じサイトで更新作業を行う場合、まだ作業中のページをアップロードしてしまうことがないように、運用を工夫する必要がある【2】。
【2】制作が同時進行し、コンフリクトすることも
システム開発の場合、個人のPC上で各種のサーバを構築し、この自分専用の開発環境で開発とテストが終わったファイルのみをアップロード（コミット）するという手法がとられるが、制作においても同じ考え方が必要になってきた。
動的なページの増加
Webやビジネスの進化に伴い、動的に生成されるコンテンツが増えてきた。ランダム表示、リンク自動生成、ログイン後のパーソナライズなどの機能をどう実装すべきか? 最近ではPHPやRubyのようなサーバ側で動作する言語やブラウザ側で動作するJavaScript、FLASH、JAVAアプレットなど、選択肢がいろいろある。静的ファイルとプログラムでアップロードするディレクトリを分けてアクセス権限を変える、というような単純な制御ではすまなくなってきた。
■複数サーバ間のコンテンツを同期するために
トラフィックが多いサイトで負荷分散のために複数のサーバを稼働させている場合、すべてのサーバが過不足なく同じファイルをもつことをどのようにして実現するか、が課題になる。
1. フォルダごと上書き
たとえばWindows XPでフォルダを上書きコピーすると、フォルダ構造を保ったまま内包するファイルが上書きコピーされる【3】。上書きなので、コピー元のフォルダに削除されたファイルがあっても、コピー先のそのファイルが残ってしまうため、削除を反映することはできない。
【3】手作業でフォルダを同期するのは手間がかかり、ミスも避けられない
また、コピーする方法によっては、変更していないファイルもタイムスタンプが更新されてしまうことがある。
2. フォルダごと差し替え
上書きではなくフォルダごと全ファイルを差し替えれば、削除にも対応できるようになる【3】。ただし、サーバ上のフォルダを無条件で削除するため、サーバ側で追加されたファイルがあっても削除されてしまう。また、すべてのファイルを転送するため、大量のコンテンツを頻繁に同期するとネットワーク帯域を圧迫するだけでなく、同期に時間がかかるようになってしまう。
3. 差分を検知し個別処理
配信元と配信先のファイルの更新日やサイズを比較して、更新や追加されたファイルのみを転送すれば、転送に必要なCPU負荷やネットワーク帯域を最低限に抑えることができる【3】。削除に関しては、別途削除処理が必要になる。
ふたつのフォルダを同期するアプリケーションはいろいろ存在するが、単純化すると、このように動作する。
ただし、これではWebコンテンツに特有のタイミングという問題に対処することができない。サーバが何台もある場合、公開タイミングのずれが大きいと、ページは開けたのに画像が表示されない、JavaScriptのエラーが発生するなど、ユーザーにとっての不具合が発生してしまう。
4. 公開タイミングを合わせる
では、タイミングを合わせて配信するために、どのようなステップが必要になるのだろうか?
1. 変更されたファイルやフォルダを特定
2. 差分のみをサーバに仮転送
3. 配信先フォルダを一時フォルダに複製
4. 差分を3の一時フォルダへ上書き
5. 3のフォルダに1の削除を反映
6. 全サーバがこの状態になるまで待つ
7. 全サーバで一斉にフォルダを差し替える
8. 差し替えに失敗したサーバがあれば、全サーバのフォルダを元に戻す
要件としてまとめると、たとえば下記のようになる。
・ファイルとフォルダの削除や追加を複数のサーバに反映させたい
・タイムスタンプやパーミッションなどの属性を保持したまま配信したい
・CMS管理下にないファイルはサーバ上に残したい
・全サーバの公開タイミングを1秒以内の誤差で同期したい
・全サーバが同じ状態になるように失敗時はロールバックしたい
費用を抑えるため、それぞれに優先順位をつけて絞り込む必要があるだろう。
■分散化した制作体制をサポートする
ファイル単位でライフサイクルを管理する
本番サーバ間でファイルを同期するという前項で取り上げた問題は、公開ファイルをアップロードしたあとにその状態をどうほかのサーバに反映させるか、という問題であった。それよりも、更新作業を終えてテストやレビューを行い、OKならアップロードする、という公開前のプロセスのほうが要件が複雑になる。
まず、作業環境では公開タイミングが異なる作業が同時進行することがあるため、単純に更新されたファイルを無条件でアップロードするわけにはいかない。公開企業が株価に影響を与えるような情報を非公式に一部のユーザーにリークしてしまうと、裁判ざたにもなりかねない。
このため、ファイルごとにライフサイクル（公開状態）をもたせ、明示的にその状態を昇格・降格させる必要がある【4】。
【4】制作の過程で降格と昇格を繰り返す
作業環境とテスト環境を分離する
本番サーバと同じ状態のテストサーバを用意し、次に公開するコンテンツのみをそのテストサーバにアップロードするようにすれば、公開後の未来の状態が再現されるため、コンテンツだけでなくリンクチェックや検索エンジンのテストなど、機能面も含めてサイト全体をチェックすることができるようになる。
つまり、ライフサイクルは、最低でも「作業中」→「レビュー中」→「公開」というような3段階が必要になる【4】。
ファイルをグルーピングして管理
ページは画像やCSSファイルなど、複数のファイルで構成される。複数のページを同時に公開する場合もあるため、公開のジョブ単位で複数のファイルをまとめられると便利だ。ファイルをひとつずつ選びながらライフサイクルを昇格すると順次サーバにアップロードされてしまうようでは、人的ミスで漏れが生じたり、タイミングのずれにより表示や機能に支障を来す、などのリスクがある。
そこで、ファイルをグルーピングするという手法が生まれた。「変更セット」を作成しておき、対象ファイルを追加していく。これをライフサイクルの昇格やアップロードの単位として使えば、対象に漏れが生じることはなくなる【5】。
【5】変更セットは仮想的なエイリアス
ワークフローでライフサイクル管理
複数の作業が同時進行する場合、スムーズな運用のためには「レビュー中」のファイルをほかのスタッフが更新しないようにし、なるべく早く「公開」するか「作業中」に戻す必要がある。そのためにも、何をどのようなスケジュールで進めてだれがかかわっているか、今どこで止まっているか、などの進捗を管理することが重要になる。
ここで、ワークフロー機能が活躍する。作業の進捗だけでなく、過去の作業履歴を調べることができるようになる。関係者が数人しかいない場合でも、ワークフローで作業を管理することには意義があるのだ。
サイトの仮想化
ところが、他人が「作業中」のファイルは更新しない、という消極的な方法には限界がある。ある時点のサイトを自分用につくっておき、自分の作業が終わったらCMS上の最新コンテンツとマージする、という手法も発達した。オープンソースのCMSであるAlfrescoは、この機能が優れている。コンテンツ編集者がそれぞれ自分の「ワークスペース」を持ち、自分が編集したファイルのみが変更セットのように抽出されて管理される。自分の変更セットは、つねにその時点での承認された最新版のサイトに重ねてプレビューできる。ある時点のサイト全体をコピーするのではなく、日々更新される最新コンテンツと自分の変更分を合わせてサイト全体を仮想的に再現できるのだ。
この機能と関連して、個別のファイルだけでなく、サイト全体でバージョンを管理できるCMSもある。
■動的配信と静的配信の違いを知る
動的配信から静的配信へ
さて、このようにいろいろな機能を駆使してWebコンテンツを管理するわけだが、最近は動的なサイトが急増しつつある。CMSも動的配信への対応が必須になっていくのだろうか?
答えはNOだ。実はサイトが高度化するほど、CMSが担うべき機能はコンテンツの編集と保管のみに特化していく。コンテンツの動的配信は不要になり、ほかのWebアプリケーションやデータベースへコンテンツを静的に配信する機能が必要になってくるのだ。
何を何へ配信するのか
配信の仕組みは、どのようなフォーマットのコンテンツを何に対して配信するのかを明確にする必要がある【6】。
【6】コンテンツの生成と配信におけるCMSの位置づけ
コンテンツの動的配信
ブラウザからURLの接続要求があった時点で、HTMLを動的に生成してブラウザへ配信（送信）する。つまり、CMS自体がWebアプリケーションなのである。オープンソースのCMSやWikiは多くがこのタイプであり、ページの動的生成方法をプラグインやモジュールなどの仕組みで拡張可能にしている。
CMSという統一されたプラットフォーム上で手軽に開発や運用ができる、コミュニティで公開されたモジュールを再利用できる、などのメリットがある。
コンテンツの静的配信
コンテンツを静的なファイルに書き出すタイプ。静的配信の本当の意義は、パフォーマンス向上やSEO対策ではない。CMSから配信された静的ファイルを別のアプリケーションが読み取り、ページの動的処理を行うことで、拡張性や自由度が広がるのだ。つくり込んだ既存のWebアプリケーションがある場合、それを特定のCMS用につくり替えるのはコストの無駄になる。また、規模が大きくなると、CMSだけでは負荷に耐えられなくなる。
最近は、個別機能をあまり依存し合わないようにし（疎結合）、機能間の連携のインターフェイスを標準化するのがITのトレンドだ（SOAやWebサービスなど）。コンテンツ管理も、編集、管理、生成、配信などを分離して部品化し、いろいろなシステムと組み合わせる方向に進化しつつある。たとえば、EMC DocumentumはコンテンツをXMLで保管することで、編集機能を任意のXMLエディタに置き換えることを可能にした。FatWireをはじめ「高価な」CMSは、コンテンツの編集と保管の機能を「コンテンツサーバ」としてWebアプリケーションとは独立させた。Interwovenは、高度な配信機能を「Open Deploy」としてコンテンツサーバの「Team Site」から分離した。
このような本質的な違いを知らずに使い勝手やパフォーマンスの比較をしてしまうと、判断を誤ることがあるので注意したい。CMSで統一することによる開発・運用の手軽さと、規模や自由度のどちらを優先すべきか、を見極めて適切な選定や設計を行うとよいだろう。
最後に、コンテンツの動的配信をCMS以外の仕組みで実装する場合に役立つCMS側の機能を紹介しよう。
転送前後の自動処理
テストと本番環境とで設定ファイルを差し替える、検索エンジンのインデックスを再構築するなど、配信時に処理が必要なことがある。このような処理は、定期実行よりも配信直後に開始したほうがタイムラグが減り、効率も良い。
そこで、配信の前や後、失敗時や成功時に特定のプログラムやスクリプトを実行できるCMSが生まれた。また、ワークフローの途中にカスタムプログラムの実行を組み込む方式のCMSもある。
メタデータの配信
CMSやDAM（デジタルアセット管理システム）で保管しているメタデータを、HTMLファイルの中に反映させるだけでなく、XMLファイルやデータベースに格納することができると、Webアプリケーション側でできるコンテンツ処理の幅が広がる。特に、最近はPHPやJavaScriptから直接XMLコンテンツを読み込むことが容易なため、XMLでの配信は便利だ。
さて、本連載はこれまでCMSの個別機能について紹介してきた。次回からは応用編として、総合的で実践的な内容を紹介していきたい。
本記事は『Web STRATEGY』2008年3-4 vol.14からの転載です
この号の特集など、ほかの記事の紹介はこちら！
『Web STRATEGY』最新号の情報はこちら！
Amazon.co.jpでの購入はこちら！
定期購読はMdN Squareで！
