サイトのレベルに応じた移行方法
A.既存サイトをそのまま移行
既存サイトをContent Serverへ移行する場合は、「FlexImport」という製品を活用する。FlexImportは、既にあるファイル群をContent Serverに読み込むツールだ。
Content Serverの管理下に置くことで、外部に委託するなどして納品されたHTMLなどのファイル群を確認し、公開するまでのワークフローをシステム化できる。
また、コンテンツの世代管理も可能で、配信の際に手動でFTPツールを使う必要はなく、時間指定の公開も可能となる。ただし、コンテンツ制作については従来と変わらないため、すべてのページに同じキャンペーンのバナーを貼るといった要求には応えることが難しい。「制作工程に変更がないため、運用コストの大幅な削減は見込めない」と佐藤氏は語った。
B.既存サイトをアセット化して移行
次に“B.既存サイトをアセット化して移行”を紹介。
アセット化とは、CMSで管理するデータを必要な時に必要なところで引き出せるようにすることを指す。佐藤氏は「アセット化の捉え方は、CMSのベンダーによってもかなり幅があります。私どもでは、ヘッダー・フッター・ナビなど、いわゆるWebサイトの共通コンポーネントの統一化に加え、コンテンツ内部の構造化も含めて捉えています」とした
アセット化移行には「XMLPost」という機能を使い、XML形式のフォーマットでContent Serverに読み込む。企業が提供する製品情報などのPIM（Product Information Managemet／製品情報管理）が必要なコンテンツの構造化が可能となるのだ。
コンテンツの構造化だけでなく、ページのレイアウトを自在に変更できる機能もある。この移行では、前述のAと違って、コンテンツ制作の部分も管理するため、外部の制作会社に依頼することなく、担当者が管理画面のエディタを使って、ワープロのようにウェブページの制作ができる。Aでは難しかった、全ページへのバナー貼付けなども可能となるのだ。
さらに、PC、携帯電話、スマートフォンとテンプレートを用意することで、同じコンテンツを多数のチャネルで出力できるメリットもある。
C.データベースからのダイレクトな移行
続いて“C.データベースからのダイレクトな移行”について解説した。
佐藤氏は「データベースと言ってもいろいろありますが、基本的にはテーブル間にリレーションを持つような複雑な構造体ということになります」と解説。言い換えれば、受け皿のCMSにも、そういった構造体を再現できる機能がないとそもそも移行が不可能ということになる。
また、ウェブへの移行に伴い、SEO施策などで新しい情報も付与する必要を考えると、既存のデータベースの構造に新しい構造を加える機能も必須となる。
佐藤氏は「Content Serverでは、既存データベースにあるコンテンツを、業界標準技術であるREST APIを使って直接取り込めるようになっています。受け皿はFlex Assetという構造体となり、元のデータベースがどれほど複雑なものでも、受け入れることが可能です。また、移行後にウェブから取得した情報を基幹側に返すようなリアルタイムのやり取りも可能です」とその、特長を語った。
D.既存の文書管理との連携
最後の“D.既存の文書管理との連携”は、文書管理システムを活用している場合に、そこで使われているコンテンツをウェブに活用していくという考え方だ。
同社の「CIP（Content Integration Platform）」という製品では、移行元のコンポーネントに1つ1つコネクターを用意して対応する仕組を提供している。CIPと連携できる文書管理のプラットフォームは「EMC Documentum」「Microsoft Office Sharepoint Server」「eBase」などだ。移行期間は、文書管理システム側で定義が確立しているため、さほどの期間はかからないという。
以上が4つの移行方法だが、佐藤氏は、すべてのレベルのサイトを、単一のフォーマット上に集約したうえで、個々のサイトのレベルに応じてこれらの移行方法を使い分けるべきであると主張。
ただ、全てのサイトを一度に移行するというと、壮大なイメージとなるが、Ford Motorが10年前にContent Serverを利用したのは1つのサイトを加工するという役割からだったという。その後、Ford MotorのIT部門は、3つ目のプロジェクトとしてオーナーサイトの移行を行い、アワードを受賞した。そして、次々に各国・関連会社を含めて展開していき、10年をかけて今日のグローバルなマルチサイトができあがったのだ。
佐藤氏は「着実に進めることが大切」とし、セッションを締めくくった。
