本連載ではリッチ・インターネット・アプリケーション（RIA）開発におけるマネジメント領域の課題とその解決策というテーマで，RIAコンソーシアムのマネジメント分科会における研究結果をもとにいろいろな面から考察してゆきます。今回はRIAの開発プロセスについて考えてみたいと思います。

スパイラル・アプローチと並行開発

　RIA開発は第1回，第2回の連載でも述べた通り，異業種混合（デザイナー，システム・エンジニア，…）の分業体制の開発スタイルをとることになります。このような開発スタイルにおいて，プロセス上どのような点を考慮すればよいのでしょう。まずはRIA開発プロセスの特徴をとらえるところから考えてみたいと思います。

　RIA開発プロセスの特徴として，次のことが考えられます。

(1)画面設計のプロトタイピングにおけるスパイラル・アプローチ 　クライアントサイドのユーザー・インタフェースの開発については画面遷移，操作性についてユーザーの確認を早期にまた確実にとっておきたいため，Flashなどでプロトタイプを作成し，スパイラル・アプローチで要求事項の実装イメージを固めていく進め方が一般的となります。

(2)クライアントとサーバーは別々に並行開発 　クライアントサイドとサーバーサイドは別々に開発できるので，たとえサーバーがウォータフォール型の開発方式でもクライアントサイドは並行してスパイラル・アプローチの開発が可能となります。

　この点は従来のWebシステム開発においても，サーブレット開発（サーバーサイド）とJSP開発（クライアントサイド）を切り分けて進めるのと同じだと思います。HTMLでモックアップを作成し，ユーザー・インタフェースの実装イメージをユーザーと固めて行くアプローチです。

RIA開発では要求変更が多発する

　このような開発スタイルはユーザーが早い段階で画面のイメージや操作を確認できることから，開発途中の変更要求があがってくる機会も多くなるということでもあります。クライアントサイドはサーバーサイド開発の影響を受けることなくスパイラル・アプローチで進めているので変更要求を受入れやすいスタイルであると言えるでしょう。

　クライアントサイドとサーバーサイドが，お互い影響なく並行して作業を進められるRIA開発。クライアントサイドでユーザーの様々な変更要求を受入れながら進行している中，サーバーサイドは結合テストまで，何の影響も受けずに開発を進められるのでしょうか。

　当然そのようなことはありません。サーバーサイドを担当するシステム・エンジニアの中には，Webシステムの開発に最初に取り組んだ際，実装から結合テストの過程でユーザー・インタフェースの変更の多さに面食らう経験をされた方も多いのではないかと思います。ウォータフォール型の開発スタイルで育った方ならなおさらでしょう。

　RIA開発では異業種混合の分業体制，本連載第2回にでも挙げたMVCモデルのViewの中にさらにMVCモデルが存在するという機能の複雑性から，変更要求を受入れるタイミングを誤ると作業全体への影響，プロジェクトスケジュールへの影響度合いが従来のWebシステム開発よりも大きいという認識を持たなければなりません。

情報共有ポイント，変更要求の受け入れタイミングを明確にする

　図1は従来のWebシステム開発のプロセスとRIA開発プロセスを比較したものです。クライアントサイドの開発者とサーバーサイド開発者の情報共有を密にしなければならないポイントを明示してあります。

図1●開発プロセスから見た比較（RIAシステム構築ガイド2005年度版より引用）
図1●開発プロセスから見た比較（RIAシステム構築ガイド2005年度版より引用）
[画像のクリックで拡大表示]

　RIA開発では確かに，分業体制が可能で，お互いに影響少なく並行開発が可能です。とはいえ，要求変更が発生した際に，それぞれの開発領域への影響を早期に確認できるよう，開発プロセスの中でクライントサイド，サーバーサイドの情報共有ポイントをあらかじめ設定しておくことが重要になります。

　本連載第1回で紹介した，「要件変更受入れ時期分析表」をプロジェクト内で作成し，変更要求の受入れ可能時期を，全体スケージュールの中で予め設定しておくことも必要でしょう（図2）。

図2
図2
[画像のクリックで拡大表示]

開発者同士のインタフェースがポイント

　プロジェクト・スケジュールでクライントサイドとサーバーサイドの情報共有ポイント，変更要求受け入れ可能時期を明確にするとともに，プロジェクト内でのコミュニケーション・ルールを設定しておくことも混乱の予防策となります。

以下はコミュニケーションルールの一例です（表1，図3）。

表1●コミュニケーションルールの一例
要件変更ルール要件変更内容，変更の背景，影響可能性機能範囲，変更履歴を管理する
設計変更ルール要件変更だけでなく，開発者が設計の詳細化を行う過程で発生する変更も管理する
構成管理ルールプログラムや設計書のバージョンを管理し，クライアントサイドとサーバーサイドのバージョンが常に整合性が取れているようにする。

進ちょく管理ルール自己の遅れが，他者の期待値を裏切らないように，最低限の進ちょく状況が図れるようにする
品質管理ルール品質確保状況，テスト済み状況の記録，結合テスト開始条件など

図3●開発者同士のインタフェースが重要（RIAシステム構築ガイド2005年度版より引用）
図3●開発者同士のインタフェースが重要（RIAシステム構築ガイド2005年度版より引用）

　これまで述べてきた通りRIA開発は，異業種混合の分業体制，並行開発というスタイルをとることになります。それぞれ各担当においてどこで，どのような情報共有をしておけばよいか，どこで予定外の変更が発生する可能性があるのかを，プロジェクト全体で予め共有しておくことが重要となります。システム間のインタフェースもさることながら開発者同士のインタフェースが重要なポイントとなるのです。