依頼内容を自分ごととして理解し、本当のニーズをが分かるまで、一切システムを作らない

お客様がお使いの Adobe Experience Manager に対してパッケージのカスタマイズや、運用によるカバーでもビジネス貢献、生産性の向上は可能です。その為、なぜ移行が必要なのか。ライセンス料の問題なのか、機能が不足しているのか。オペレーションに無駄や問題がないか。単純に置き換えるのではなく、そういったことを理解したうえでどのようなシステムが利益につながるかまで検討し、提案させて頂きました。そこからさらに、Java/JSP で構成された大量のコード郡、リソース群を いかに効率よく Ruby/ERB に変換するかという点、 また、JUnit のテストを Rspec に移行する点で 自動で変換できる箇所と、エンジニアが手動で変換するべき箇所を 区別する方法を確立させるまでに苦労しました。

OSSの変換ツールではお客様を満足させられない、それなら作ればいい

当初は移行期間中はコンテンツが増えないということでしたが、お客様のビジネスを止めることは我々の望むところではありませんでした。移行期間中にコンテンツが増えた場合でも自動で移行対象に含められるよう、変換ツールをゼロから作り上げることにしました。sling:resourceType ごとに変換するための独自変換ルーチンを書き上げ、OSS の gorgeous にカスタマイズを加えることで、コンテンツ XML を YAML 化するような変換ルールの確立とツールを作成することで、作業がスムーズにししました。

お客様と一緒にリリースの喜びを噛みしめ、さらなる提案を

全てのページを移行し終え、移行箇所すべてについて品質保証のテストを実施した結果、最終的に大きな市場不具合もなく、無事にリリースすることができました。 Adobe Experience Manager から Rails に移行したことで、自動テストやCIツールによる監視も柔軟に行えるようになりましたので、そういった改善提案を次々させていただきました。もしAdobe Experience Manager からの移行でお困りの方が居れば、FITSにご依頼、お問い合わせください。