WebCenter Sites案件に携わって

 これまでに複数のWebCenter Sites案件に携わり、感じたことをお話したいと思います。

 WebCenter Sites(以下 WCS)は、Webサイトのコンテント管理だけを行う単純なCMS(Content Management System)のみならず、エンドユーザーのWeb体験全体を管理できるWeb Experience Management(WEM)としての機能を有する高機能な製品です。
今回は、弊社のこれまでの導入実績として多かった、Webサイトを構築する開発案件についてお話します。(WEMのお話は、また別の機会に。)

 その導入の目的はサイトを閲覧するユーザに対して快適で見やすい環境を提供することと、その運用を行うクライアント様に対して、快適に運用できる環境を提供することです。
どちらか一方でも十分に実現できないということは絶対に避けなければなりません。

 WCSは、さまざまなニーズに応える高いポテンシャルがありますが、それを使いこなすための多くの準備が必要になります。
その作業はクライアント様と、我々開発ベンダーとの緻密な共同作業になります。

 まずは、従来行っていた製品や商品の管理方法、サイトへの出力方法を理解した上で、WCSを導入することで、何が変わるか?何が便利になるか?を十分整理し、説明します。
WCSの案件が他のサイト構築案件に比べ、要件定義に多くの時間を費やすのは、このように従来の業務を整理し、新しい業務体系を提案するところから始まるからです。
時にはクライアント様の職場にお邪魔して実際に1日でどのような業務が発生しているのか、その流れがどのようになっているのか見学させていただくこともありました。

 開発手法としては、従来型のウォーターフォールモデルを基本にしますが、特に製品や商品の登録、管理、出力部分に関しては、プロトタイプを先行して作成し、クライアント様に成果物を確認していただきながら部分的に反復して進めるアジャイル開発風の手法を使うことが効果的だということがわかってきました。
早めに入力のUIや、出力パフォーマンスなどを確認していただき、問題点があれば解決します。
それに合わせて、要件達成のゴールイメージ、スコープを明確にしておくことも重要になります。

development_process

 製品や商品を扱うページの表示ロジックは複雑になりがちです。
多くのデータがリレーションを行い表示されるため、表示速度など出力パフォーマンスは重要な課題となります。
WCSには高性能なキャッシュの仕組みがありますが、基本的な表示ロジックが高速でないと、キャッシュの生成に膨大な時間がかかる結果になり、ユーザビリティの低下に繋がります。
複雑なロジックを伴う部分に関しては、とりあえず作ってみた的な開発の進め方は多くの手戻りが発生するため、 運用方法と、その運用頻度と、閲覧する側のユーザビリティのバランスを考え、適切なパフォーマンスが得られるように設計段階から十分に考慮する必要があります。
パフォーマンス向上のための施策は、このようにそのサイトやコンテンツの運用方法、閲覧側の要求に則したものを実現しなくてはいけません。

 通常の案件に比べ、大規模な構築になるので時間もかかり苦労も多いですが、構築したサイトが様々なところで事例紹介されていたり、クライアント様から「掲載している製品や商品に関する問合せが増えた」「運用が楽になった」「良いサイトが出来上がった」とお言葉をいただいたりすることが、我々開発ベンダーの次への原動力になっています。

 余談ですが、WCSは旧製品名をFatWire Content Serverといいます。
WCS案件に携わる度に何故かFatになっていく自分をなんとかすることが目下の最重要課題です。