Agile development for CMS : CMS化におけるアジャイル開発というアプローチ

最近、自分なりのWebディレクションについての視点をまとめているので興味のある方は長い文章ですが是非一度読んで意見をいただけると嬉しいです。

アジャイル開発とは？

アジャイル開発とはソフトウェア開発手法の一つです。手法として紹介されてから結構経ちますが、最近のWebトレンドであるオープンソースやSaasで実践され、あらためてアジャイル開発に注目が集まっていますが、今回はそういったアプリケーション開発ではなく、一般的な情報閲覧型のWebにもアジャイル開発の考えを取り入れるメリットを考えます。

アジャイル開発は、ウォーターフォールモデルという開発手法と比較されることが多く、現在でもウォーターフォールモデルは多くのプロジェクトで採用されていますし、僕の働いている会社でもWebサイトの開発は基本的にウォーターフォールモデルです。

では、両者の違いを見てみましょう。
まずはウォーターフォールモデルから。（以下は、ZDNet Japanのウルシステムズ一橋さんの記事からの引用です）
-----
ウォーターフォールモデルでは、「要求」「分析」「設計」「実装」「テスト」「運用」といった形にシステムの開発工程を分割し、各工程では後工程の作業のインプットとなる成果物を作成します。成果物は、仕様書や設計書などのドキュメント類で、基準や定義が定められており、各工程の中で時間をかけて厳格に検証され承認されたもののみが用いられます。原則的に各工程の順序を飛び越えて先に進んだり、一度終了した工程に戻るということを許しません。このように開発モデルを滝の水が上から下に落ちることにたとえてウォーターフォールモデルと呼んでいます。

それに対し、アジャイル開発とはどういった開発手法でしょうか。
アジャイル開発では、開発プロジェクトを短期間（１〜６週間）に区切り、この間に上記の「要求」から「運用」までの開発工程を一通り行って、部分的に機能を完成させます。そして、この「短く区切られた期間で動くアプリケーションを開発する」という作業を繰り返すことで段階的にシステム全体を仕上げていきます。

ウォーターフォールモデルは、古くから使われている開発手法ですが、アジャイル開発が登場した背景を見ることで両者のメリットやデメリットが明確になってきます。ウォーターフォールモデルは、スケジュールの立案や進捗管理が直線的に進むためプロジェクト管理が容易であり、段階的な詳細化のため、各工程の工数見積もりや資源の配分が行いやすいことがあります。
ただ、工程に後戻りが許されないため、厳格な分析や設計が必要となり、各工程が長く、ユーザーがシステムの実物を見れるようになるのは最終段階に近い状態です。そのため仮説に基づく設計では洗い出せない要求がその段階で発覚することが多々あります。また、もう一つの問題は現在のビジネスの変化のスピードです。設計段階で完全な仕様が出来ていたとしても、開発期間が数ヶ月に及ぶプロジェクトでは、最終成果物としてのシステムに新たな要件が発生している可能性が十分あります。しかし、ウォーターフォールモデルでは仕様の変更は原則として行うことが厳しく、もし行った場合、改めて上流工程に戻らなくてはいけません。

それに対し、アジャイル開発は短い工程を繰り返し、都度成果物をアウトプットしユーザーがそれを確認することが出来るため、
ユーザーがシステムを体験し、そこで出た要望や変更を次工程で実装していくことが可能になります。また、アジャイル開発ではプロジェクト成功のために価値が少ないドキュメント作成を極限まで省き、ユーザーには文章ではなく動くソフトウェアで確認することを前提としています。また、仕様の変更はビジネス環境の変化に応じて当然発生するものと捉えているためユーザーの満足度の高いシステムを作り上げることが可能です。



ただし、アジャイル開発では事前での工数見積もりが難しく、工数がふくらんだ場合の負担の調整などをどのように契約に盛り込んでいくかといった問題があります。また、開発に伴いプロジェクトのスコープが変化していくため、プロジェクトマネージャーはビジネスゴールを明確にとらえた上でプロジェクト全体の設計管理を行う必要があるため、求められる管理能力はウォーターフォールモデルよりも数段高いレベルが必要でしょう。また、開発メンバーにおいても各工程毎に固定的な役割を行うのではなく、一人が多くの役割を担うことで短期間にユーザーの要望に応えたソフトウェアを提供するため、役割毎に担当者が別れてしまうことによって生じる伝達のための文章化などの負荷やロスを避ける必要があります。


なぜ今アジャイル開発なのか？

では、なぜ今アジャイル開発をWeb開発に取り入れるのでしょうか。
まず、Web開発といっても企業サイトや情報サイトといったWebサイトと、アプリケーション型のサービス型Webサイトに分かれますが、アプリケーション型のサービス提供Webサイトのアジャイル開発の有効性については、既にThink ITでSonicGardenの倉貫さんが言及されているので、今回はCMS化を前提とした前者を対象に話を進めていきたいと思います。

情報閲覧型Webサイトの開発における期間はここ数年で著しく伸びています。これは単純にサイトのボリュームが増加しているということが最も大きな要因ですが、Webに求められるビジネス上の目的が増えたため複雑化していることも原因でしょう。これまでのサイト規模であれば、１ヶ月から３ヶ月前後での構築レベルのものが多かったため、定期的なリニューアルなども柔軟に行うことが可能でしたが、数千、数万ページを抱えるサイトで、かつ構造設計を伴うリニューアルは一度の作業負荷が高いため少なくとも３年〜５年は利用出来るものを想定しなくてはいけません。

しかしながら、実際にその規模のサイトは運用に関わる人数が多く、リニューアルにあたり運用者の要件をとりまとめることが非常に難しくなります。また、現在のビジネスのスピードを考えると、期間が長くなればなるほど設計時に含まれていなかった要件が運用時に発生しているということが考えられます。これは、どれだけ事前にリサーチやコンサルティングに時間をかけても、解消されるものではありませんし、そのフェーズに時間をかけすぎると、設計時と運用時とのギャップが更に広がるという結果を引き起こしかねません。また調査や設計段階で多くの時間をドキュメント化に費やすこともプロジェクトの期間とコストの増加に繋がるため、必要以上のドキュメント化はなるべく省略化していくべきではないでしょうか。

それよりも出来るだけ早く実際の運用に乗せてみて、その中で出てくる課題や新たな要求に対応していく方が精度も高く、ユーザーの満足度が高いサイトが出来上がるのではないでしょうか。
私がこのように考えるのは、Webサイトは新規、リニューアル共に公開段階では未完成であるという前提があるからです。雑誌媒体などと異なり、Webは運用によって成長していくものですし、アクセス解析などによる数値化された目標に対し、常にビジネス成果を求められ、またそのための対応を求められるものだからです。

そのため、初期の設計段階で膨大な時間とコストをかけて公開をゴールとするのではなく、初期費用を抑え、その分をアジャイル開発の反復作業に振り分けることで、公開後に実際の運用を行った上での修正、チューニングを行うことが出来、結果的に満足度の高いサイトが構築出来ると考えます。
また、プロジェクトのゴールを公開とした場合、その後の予算取りが非常に難しく、結果としてなかなか不満点が改善出来ないなどという問題もよく見受けられることからもアジャイル開発を前提としたプロジェクト設計はおすすめ出来ます。

CMS化でのアジャイル開発のフロー

まずこのアジャイル開発を行うにあたり前提としてサイトのCMS化が必要となります。CMS化には様々なメリットがありますが、ここではWebサイトを高い頻度で最適化させることが出来るという考え方が出来ると思います。
これまでのHTMLで作成していたWebサイトは、デジタルながら実はアナログの本と変わらないレベルの構成変更しか出来ませんでした。つまり、情報の組み替えや、再構成を行う場合の柔軟性が低く、情報単位でなく、ページ単位での継ぎ接ぎレベルでしか対応が出来ませんでした。そのため大手企業などのサイトを見てみると、表面上はあたらしいサイトですが、深部に行くにつれ過去のページのままといった継ぎ接ぎサイトが出来上がります。

それに対し、CMS化を一度行うことで情報をDBに各要素単位で格納出来るため、ページという概念ではなく、要素単位での組み替えが可能になります。それにより、スタイル変更によるレイアウトの変更はもちろん、ナビゲーション設計変更や、ディレクトリ構造、コンテンツブロック、カテゴリーなどのグルーピングといった情報構成の変更も可能です。CMS化はアジャイル開発を行うための必須条件と言えるでしょう。

ただし、CMSによっては上記の様な改編が難しいものもあります。そのため、現状サイトをCMS化する場合、アジャイルに適したCMSを選ぶことと、コンテンツの要素定義をアジャイルを前提とした設計をすることが大切です。CMSの選定においては、テンプレートだけでなくモジュール単位での定義が可能なもの、サイトの階層構造を変更出来るもの、スタイル（テーマ）の一括適用が可能なものがベターでしょう。CMSの選定を誤るとCMSの変更はとても大変な作業となってしまうため、ここは慎重に信頼出来るパートナーを選びプロジェクト内容を共有した上でCMSを決定しましょう。

コンテンツの要素定義においては、各コンテンツ毎の要素定義を複雑に差別化せず、可能な範囲で共通化していくことと、メインコンテンツであるテキストを分割したレコードで持たないことがあげられます。
また、デザインにおいても画像に文字を記載するようなグラフィックパーツを減らすことでより柔軟な変更が可能となります。

Webサイトのアジャイル開発におけるメリットは、公開側サイトだけを対象としたものではありません。CMS化においては運用者の業務フロー改善が大きな目的の一つですので、その部分を改善することもアジャイル開発を取り入れる目的の一つです。
通常のCMS化を伴うサイト開発（リニューアル）は、３ヶ月から６ヶ月程度のプロジェクトを１つの単位として契約締結を行い、プロジェクトは成果物としてサイトをデータ納品し、公開した地点でプロジェクト終了となります。
しかしながら、CMS化を行うにあたり事前のヒアリングやリサーチを元にした業務フロー設計を行っていたとしても、実際の運用を行っていくにあたり不具合や、変更が必要になってくる箇所が必ず発生してきます。そういった前提をあらかじめプロジェクトに組み込んでおき、反復開発を経ることで改善することを計画しておくことが大切です。

アジャイル開発におけるWebディレクターの注意点

さて、ではアジャイル開発を行うにあたりWebディレクターはどのような点に注意すべきでしょう？

まず、通常のウォーターフォールモデルと異なり、改編を前提としたプロジェクトであるためプロジェクトのスコープ定義、ゴール設定、見積もりが難しくなります。この点はアプリケーション開発におけるアジャイル開発と同じ課題です。とはいえ、情報閲覧型のWebサイトのCMS化におけるアジャイル開発ではアプリケーション開発に比べ、都度の工程での成果物が最終形に近いことや、CMS開発の場合は作業対象が明確化しやすいことなどから失敗しにくいアジャイル開発と言えるかもしれません。

具体的には、全体の作業ボリュームから一次フローの期間を明確化します。この段階で一通り公開可能なレベルのサイトまで持っていく必要があります。その後の反復作業の期間設定ですが、少なくとも二次フローまでを想定し、公開後1ヶ月を運用、1週間で追加、改修の要件定義、その後の改修作業に1ヶ月程度というのが理想でしょう。
二次フローの作業範囲としては、初期に設定するテンプレート数の1割〜2割、もしくは作業期間として1ヶ月以内を対応可能範囲として設定し、その中で可能な修正範囲にスコープを絞ります。
それ以上に改修要望が出たとしても作業範囲が伸びれば要望も増えるだけと考え、一度の改修ボリュームを増やすのではなく、反復回数を増やし最適化を行っていく方が良いという認識を事前の説明でクライアントとしっかり共有することが大切です。
まずは二回で一区切りとし、3回目以降の改修要望があればそれ以降は改修プロジェクトとして組むか、複数回をアジャイルとして設定してプロジェクト化しても良いでしょう。

なお、アジャイル開発は決して要件定義を曖昧なまま作業を進めるということでは無いことを理解しておいてください。初期の要件定義で１００％のものを作ろうとするのではなく、初期の設計地点では想定出来ない部分があるということを認識した上で設計を行うということで、反復作業によりその不明箇所を洗い出し埋めていくことを前提としているのです。
ドキュメント化においても必要なものについては確実に作成しアップデートしていくべきですが、機能などを持たない通常のページにおいては、実データでの修正、確認を行うことで作業を簡易化出来ます。ただし、サイトデータは常にリビジョン管理し、各フェーズ毎の作業状態は把握するようにしておきましょう。

また、ゴール設定においては自社の専門性をよく理解した上で設定を行いましょう。アクセス解析やSEOに強い会社であればそれらの数値をゴール設定とするのも良いですが、開発がメインの会社であればユーザビリティやフロー改善をゴールとし、クライアントからのレビュー時にはそれらをヒアリング出来るシートなどを用意しましょう。でないと、運用段階でのレビュー時にクライアントの確認範囲が広がりすぎてしまい適切なレビューが得られない可能性があります。

さて、みなさんはCMS化におけるアジャイル開発をどう思いましたか？それって別に開発は開発としてプロジェクトを組み、後は改修プロジェクトを組んでいけばいいんじゃないの？という声も聞こえそうですが、事前に反復作業までをプロジェクト化することではじめて期間やコストの削減も実現出来ると考えていますし、クライアントとの良好なコミュニケーションを維持しながら満足度をアップさせられると考えています。
実際、私のこれまでの経験の中でクライアントがサイト構築やリニューアル直後から不満を抱き、それをなかなか改善出来ずにようやくリニューアルの機会を得たというパターンを耳にすることが少なくありません。
現状のWebサイトの重要性を考えると、そういった期間が延びると運用負荷によるコスト増や、多くのビジネスの機会損失を引き起こしてしまいます。そして結果的に次のリニューアルにおいて大幅な変更を施す大手術を実施しなくてはならなくなります。そうならないためにも、Webサイトの構築方法と開発会社との付き合い方を変えていくべきでは無いでしょうか。