AEMの導入を検討している企業では、多くの場合、現行のCMSが存在し、数千から数万ページのデータ移行が発生します。大規模なデータ移行では、以下の4点がポイントになります。

• 移行方法の検討
• 移行するデータと移行しないデータの選定（断捨離）
• 移行するデータの優先順位付
• お客さまごとに異なるデータ移行自動化ツール（コンバーター）の開発とその活用

Business Architects（以下、BA）のシニアエンジニアの湯澤、フロントエンジニアの高田、システムエンジニアのアラミンの3名が、上記にあげたAEMへの大規模データ移行の課題と対策について語り合いました。

AEMへの大規模データ移行時の留意点

最初のテーマは、AEMへの大規模データ移行の大まかな手順と留意点です。

「データ量が膨大！」なだけではない、大規模データ移行が難しい理由は

はじめに、AEMへの大規模データ移行の大まかな手順について教えてください。

湯澤：細かな手順は、Webサイトの規模や構造などによって異なりますが、一般的には以下の手順で実施します。

1. 移行元のデータ確認
2. 移行するデータと移行しないデータとの選定（断捨離）
3. 移行にあたっての優先順位の決定
4. 移行

この手順は、AEMでも他のCMSの場合でもあまり大きくは変わりませんね。

高田：ただ、大規模なデータ移行となると、どうしてもいったんは現行サイトの更新をストップします。その間に更新されたWebページなどの「差分」データも移行しなくてはなりません。

なので、手順の最後の「移行」の後に「差分取り込み」が入り、以下の手順となります。

1. 移行元のデータ確認
2. 移行するデータと移行しないデータとの選定（断捨離）
3. 移行にあたっての優先順位の決定
4. 移行
5. 差分取り込み

「データの断捨離」や「優先順位の決定」など、それぞれで留意すべきポイントがありそうですね。

湯澤：データの断捨離にしても、優先順位の決定にしても、「どういう基準で決めていくか」といった留意点はいくつもあります。基本的には、お客さまと話し合いながら基準を決めていきます。お客さまごとに対応を検討する必要があるため、きめ細かいフォローが必要となります。そういった点は、データ移行の難しさのひとつです。

「大規模データ移行」という言葉から、ツールを使えば完全自動で移行できる、マニュアル化されたやり方を実践すればうまくいくと思われることもあるかもしれません。しかし、決してそうではなく、お客さまごとに丁寧に対応していく必要があるのです。

とはいえ、いきなり「どういう基準で優先順位をつけようか」などと細かいところばかりに目を向けてもうまくいきません。

そこで、大規模データ移行でまず考えるべきことは、お客さまが移行後にどういうWebサイトを作りたいのかを踏まえたうえでの「データ移行の方法」と「移行先での再現精度」です。つまり、現行サイトをデザインまで含めてほぼ100％再現しなくてはならないのか、内容がきちんと網羅されていれば、デザインや構造などは既存のWebサイト通りでなくても良いのかなどを決めることだと思います。

移行方法には、大きく分けて3つあります。

1. 現行Webサイトの稼働も更新も完全に止める期間を設け、その間に一気に移行する一括移行
2. 段階的に移行させる方法
3. 現行Webサイトは通常稼働させたまま、移行先Webサイトも並行運用していく並行移行

大規模データ移行には、3つ目の並行移行が適していると思います。BAでもこの方法で取り組むことが多いです。移行方法が決まれば、「この方法で移行するなら、優先的に移行するデータはこれになるね」と決まってくることもあります。

一方、移行先での再現精度については、AEMにはAEMなりの見せ方があって、現行Webサイトのデザインを忠実に再現できないこともあります。また、現行Webサイトのデザインの見栄えが良くても、実はアクセシビリティやSEO、いわゆる「htmlのお作法」に則っていなくて「推奨されない作り方」になっていることもあります。こうしたことも含めて「それでもデザインを優先する」のか、「アクセシビリティを重視する」のかなど、お客さまと何を重視するかを話し合い決めることも大切です。

高田：例えば、同じ2万ページのWebサイトでも、同じ構造のページが大半であれば、自動化ツールを使うなどしてデータ移行を効率化できます。ところが、それぞれのページの構造が違う場合には、手動での移行作業が増え、コストも時間もかかります。

その際に、移行先で現行Webサイトを忠実に再現しないといけないのかどうか、それによってもデータ移行にかかる工数が変わってきます。そう考えると、AEMへの大規模データ移行では、自動化ツールだけでも手動だけでもうまくいきません。他にも忠実に再現するページもあれば、そうでないページもある、というように全体を複合的に判断して、お客さまごとにベストな方法を組み立てていく必要があります。そこが私の感じる難しさです。

移行方法、断捨離、再現精度、そして「移行にかかる時間」がポイント

さまざまな留意点がある中、「データ移行にかかる時間」を短くすることも肝要だと思います。どうでしょうか。

湯澤：現行Webサイトは、閲覧者から常にアクセスできることを期待されています。そのため、顧客獲得の機会を逃さないように、並行移行で現行サイトは稼働したままにしておくことが望ましいと思います。そのうえで、データ移行期間を短くできれば、更新差分の発生も少なくて済みます。その意味では、データ移行にかかる時間を短くすることは重要です。

ただし、考え方としては最初から「データ移行にかかる時間を短くする」ことだけにこだわってもうまくいきません。先ほど話したように、まずは移行方法を決め、全体的な工数をイメージします。それから、再現精度をお客さまと話し合って決めていくことで、データ移行にかかる期間も見えてきます。その期間がお客さまのご要望よりも長い場合には、「どうやって短くするか」を高田さんが話したように、さまざまな方法を組み合わせて複合的に実施していくことが大切です。

高田：そうですね。例えば、優先順位の決め方ひとつでも、データ移行にかかる時間に影響します。移行の優先順位を考えるときに、更新頻度の低いところから移行し、更新頻度が高いところは最後に移行することで、移行後に取り込む差分が少なく済み、データ移行にかかる時間を短くできます。

データ移行にかかる時間とは、サイトの更新を止める期間を指します。その期間が短いほど、差分の発生が少なく、取り込みの量も減ります。そういった意味でも、データ移行にかかる時間を短くすることは大切です。通常、お客さまにWebサイトの更新を止めることを許容してもらえる期間は意外に短く、どんなに長くても1週間以内です。そう考えると、データ移行にかかる時間を短くすることは、やはりお客さまのご要望に応えるという意味でも大切です。

そのためにも、移行を自動化するツールであるコンバーターの開発・活用は必須です。

データ移行の自動化ツール（コンバーター）は、お客さまごとに毎回専用プログラムを制作

2つめのテーマは、AEMに大規模データを移行するときの自動化ツールの活用です。お客さまごとに開発が必要で、その使い方にも工夫が必要です。

大切なのは専用の自動化ツールの開発力！

AEMへの大規模データ移行では、お客さまごとに専用の自動化ツールを開発しています。その開発力が重要ですね。

アラミン：自動化ツールの開発では、はじめに、現行Webサイトのhtml構造を分析し、どのページでもコンバートできる汎用的な自動化ツールを開発することが可能かどうかを判断します。汎用的な自動化ツールを開発できたら、それを使うのが効率的です。検討を含め自動化ツールの開発には、だいたい1〜2週間はかかります。

また、汎用的な自動化ツールを開発できない場合は、例えば、ニュース記事用、ブログ用、個人情報のページなどカテゴリーごとの自動化ツールというように、細分化したコンポ―ネントごとに自動化ツールを開発します。この作業は細分化した数だけコストと時間がかかります。たいていはお客さまごとに自動化ツールを開発します。

湯澤：自動化ツールの開発は、具体的には次のような手順で行います。

1. 全体での移行ページを確定
2. その中で定型化できそうなページを決定
3. 移行元のページの構造を解析
4. 移行元ページと移行先ページの構造に基づいて自動化ツールを開発する

こうした自動化ツールの開発力があることがBAの強みでもあります。ただし、何度もいうようですが、AEMへの大規模データ移行は「お客さまのデータ構造にあわせて自動化ツールを作り、それを使えばうまくいく」というほどに単純なものではありません。自動化ツールを使った後に必ず手作業での検証が必要で、そこにも工数がかかります。

つまり、自動化ツールを開発する工数、それを使ってデータを移行する工数、さらに移行後に検証する工数を含めて、手作業でやるよりも効率化できると判断した場合に自動化ツールを作ります。AEMを導入しようというWebサイトは大規模ですが、規模がそれほど大きくないWebサイトなら手作業で移行してしまったほうが早い場合もあります。

アラミン：確かに、現行Webサイトのページがコンバートされた後には、手作業による検証が必要ですね。とはいえ、やはり全ページを手作業で移行するよりは、はるかに少ない労力で済むと思います。その意味では、やはり自動化ツールは有効です。

お客さまごとに専用の自動化ツールを開発することも重要ですが、もっと大切なのは、現行サイトの構造全体を把握したうえで、自動化ツールと手動での移行を「どう組み合わせて移行するか」を決めることだと思います。つまり、自動化ツールをどう活用するかが重要です。

高田：BAは大規模サイトの制作やリニューアルを多く手掛けています。そのため、昔からコンポーネント単位でページを制作する風土が整っています。リニューアルなどのデータ移行時にも、コンポーネントごとにコンバーターを作っていました。その蓄積された知見や経験によって、AEMなどのCMS導入の際にも同様に適応できているのは、BAの強みかなと思います。

そのうえで、アラミンさんがお話ししたように、自動化ツールと手動移行を組み合わせた複合的な方法でデータ移行に取り組むのが大切だと思います。

現行サイトのデータ取得と、制作したテンプレやコンポーネントを指定して取り込む方法

技術的な話になりますが、現行サイトからのデータの取得、その解析、そして移行（コンバート）までの流れを教えてください。

アラミン：現行Webサイトからのデータ取得は、単純なクローリングで行いますよね。

湯澤：そうですね。あとは、pythonのhttp取得ライブラリであるrequestsとhtml解析ライブラリであるBeautifulSoupを使用して解析しています。

取得したデータを自動化ツールでコンバートするときには、AEM側のAPIを使ってAEMに投入するのですが、AEMのAPIにはいろいろな種類が用意されています。ただ、その解説ドキュメントが分散しているために、APIの仕様を調べるのには苦労します。このあたりも、AEMによる大規模Webサイトの構築や大規模データ移行を経験してきたことで、ノウハウや知見が蓄積されてきています。

通常はAEM側のAPIを活用し移行しますが、時には、AEM側の移行先にちょうどいいコンポーネントが存在しない場合もあります。ようは、現行Webサイトのデザインなどを踏襲できないケースがでてくるということになります。
その場合は、コンポーネントをBAで独自に作るか、AEM側で用意されている別のコンポーネントを使い、デザイン変更を許容するか、方針をお客さまと話し合って決める必要があります。

アラミン：AEMにテンプレートやコンポーネントを指定して取り込む方法では、ACS AEM Commons Data Importerツールを使う方法があります。ExcelファイルからAEMにコンテンツを取り込むことができ、データ移行が効率的に実施できます。お客さま側が移行するデータをExcel形式でご用意が可能な場合、この方法は非常に有効です。

通常、多くのお客さまはExcel形式でデータを管理されていません。その場合は、AEMのOOTBで利用可能なSlingPostServletを使用します。SlingPostServletを使えば、JSON、XMLなどのファイルからのデータ移行が可能になります。なお、ACS AEM CommonsはAEMのOOTBでは利用できません。

データ移行は「次もまたある」ことを意識する

Webサイトのリニューアルのタイミングが3〜5年とされている中、次回リニューアルでも発生する大規模データ移行を視野に、あらかじめ準備しておいたほうが良いことはどのようなことでしょうか。

お客さまは「何を求めていらっしゃるのか」を考える

「次もまたある」大規模データ移行に向けて、どのような準備が大切だと思いますか。

湯澤：AEMへの大規模データ移行とはいえ、お客さまが最終的に求めているのは「単純にデータを移行すること」だけじゃないはずです。アクセシビリティ、正しいhtmlの構造、SEOの視点などを含めたWeb全体のことを、きちんとリニューアルというかバージョンアップして欲しいとお考えのはずです。

そのことをまずは、BAがしっかりと理解しておくことは大切だと思います。極端な言い方になりますが、データを移行するだけなら、できるWeb制作会社は数多くあるでしょう。しかしWeb全体を考えて、お客さまのWebサイトの将来像を考えて、例えば「このデータは残しておいたほうがよい」、「ここのページのデザインは、見栄えは良いがSEOで考えると推奨されない構造です」といった先を見据えたご提案ができるのがBAの強みだと思います。そこをきちんと考えたうえで、今後、またある大規模データ移行に備えたほうが良いと思います。

高田：不要なページ、ファイルの整理をしておくと良いと思います。あとは、例えばニュースページなら「過去3年分は移行するが、それ以前のものは移行しない」といった社内で運用ルールを決めるのも、時間がかかるものなので、早いうちから準備をしておくのがベターだと思います。

湯澤：あとは、お客さまが運用することを視野に入れたご提案をするようにしています。ある大学のお客さまの大規模なデータ移行事例では、教員の情報、学部・学科の情報など頻繁に使われる情報は部品化してデータベースのように作っておいて、アクセスされるたびにデータベースから表示されるようにするなど、単純にデータを移行するだけではなく、運用がしやすいサイト構造になるようなご提案をしています。

こういったサイト構造全体にかかわるようなご提案をすることで、お客さまのWebサイトがすっきりとして、次なる大規模データ移行では自動化ツールの適用範囲が広がるなど、効率的なデータ移行が可能になるでしょう。
運用がしやすいようなご提案をするのとあわせて、お客さま側では運用ルールやガイドラインを決めておいていただきたいですね。

AEMへの大規模データ移行を成功させるために

最後のテーマは、AEMへの大規模データ移行を成功させるために必要なこと。どのようなことでしょうか。

自動と手動のハイブリッドでデータ移行のQCDのバランスを取る

AEMへの大規模データ移行を成功させるためにどんなことが大切だと思いますか。

高田：基本は手動でデータ移行することだと思っています。コストも時間もかかります。自動化ツールでのデータ移行は、ツールの開発コストはかかりますが、移行のコストと時間はそれほどかかりません。ようは一長一短あるのです。まずは、納期や費用を踏まえて、移行しないページを切り分け（データの断捨離）、そこから自動で移行できるページを検討することが重要だと思います。

そのうえで、さらにコスト・時間を削減する必要があれば、リニューアル後のページレイアウトではなく、「現行データのまま移行するページ」を検討します。これは、現行Webサイトのデザインのまま移行して残しますが、「内容の更新はできない」ページになります。移行しないページと、この「現行データのまま移行するページ」はお客さまとの協議を重ねて決めていく必要があります。

つまり、手動での移行を基本としながらも自動化ツールを活用し、コストと納期を勘案して「現行データのまま移行するページ」も作る、こうしてQCDのバランスを取ることが成功の秘訣だと思っています。

アラミン：自動化ツールでの移行を成功させるためには、現行Webサイトのデータ構造を統一化しておく、大部分のページを同じデータ構造にしておくといったことが大切です。現行Webサイトが、そういった構造であれば自動化ツールを開発して活用できます。

湯澤：AEMへの大規模データ移行を検討するお客さまは、たいていは大企業です。コーポレートサイトにも社内でかかわる部署・部門が多く、ステークホルダーが多いのです。だからこそ、お客さま側での社内調整もとても重要になります。

• お客さま側のどういったWebサイトにリニューアルしたいのか
• どういった方針やルールでデータ移行をするのか
• そのルールに基づいて移行する・移行しないを判断して本当に問題ないのか

上記のようなことは、本来、お客さまの社内でお決めいただくことです。そして、この大枠の方針をしっかりとお決めいただくことが、大規模データの移行でじつはもっとも重要なことかもしれません。

とはいえ、ステークホルダーが多く決定に時間がかかるため、外部有識者を入れて進めたいなどの要望や、お客さまのご担当者が「なぜ移行しないという判断にいたったのか」や「なぜこのページのデザインは現行Webサイトと変わってしまうのか」といったことに対して把握できていないケースもあります。

BAは、そういったお客さまからのご相談にも柔軟に対応することができます。ご相談いただければ、どのページを残すか残さないかを含めて詳細な要件をお客さまとご一緒に詰めていくところから伴走します。