この連載では，RIA開発におけるマネジメント領域の課題とその解決策というテーマでいろいろな面から考察していきます。もちろん，決して「これしかないという答」が存在するわけではありませんから，様々な違う意見も考えられますが，感想やご意見をいただければ幸甚です。
RIAは単なる見た目のかっこ良さではない
連載第1回は，RIA開発プロジェクトにおける企業ユーザー（発注者サイド）とのコミュニケーションに関して，話を進めます。RIAと言わずともWeb制作，システム開発において発注者とのコミュニケーションにまつわる課題は，読者の皆さんもご存じの通りプロジェクトの進行を左右する重要な要素です。RIA開発が，従来のWeb開発と異なる点を踏まえ，発注者とのコミュニケーション上の課題について，要求定義をはじめとするプロジェクトの初期段階に焦点をあてて考察していきます（図1）。
図1：プロジェクト初期段階での検討事項
RIAは，従来のHTMLベースのWebアプリケーションが持っている保守性の高さという利点を確保しつつ，操作性やパフォーマンスの低下といった欠点を解決したものです。単なる見た目のかっこ良さではなく，あくまでインタラクティブで高いユーザビリティを持つアプリケーションを対象にしています。
要求定義において「発注者の要求を見える形に具現化する」という目的は従来のWeb開発もRIA開発であっても変わることはありません。では，これまでのWeb開発とRIA開発ではどのような部分が異なるのでしょう。
発注者，制作者，双方に困難な要因を抱える
RIA開発では，従来のように画面単位ではなく，流れや全体を通しての機能検討が求められます。そのため，一つひとつの画面単位で機能が完結していたこれまでのWeb開発と比べて，作業区分や求められる役割が広範囲にわたるという特徴があります。例えば制作者サイドが行う「要求分析」において，「どのような方法で」「どのような手順で」「どこへデータを渡して」といった機能的な要求のほかに，「どのような体験をさせて」「どのようなユーザーのニーズに応えて」というユーザー体験の部分についても検討する必要が発生します。このように，要求ヒアリングに必要な内容や，ヒアリングの際に求められるスキルが広範囲になっていることが，RIA開発を難しいものと感じさせている原因となっています。
要求を出す発注者サイドにも難しさがあります。RIAの強みはユーザー・インタフェースにおける表現手段が豊富であることです。このことは裏を返せば，どんな表現手段が可能なのか？を理解することが難しいということでもあります。
例えば，筆者たちが以前，発注者の要求内容の大枠を把握するために画面構成のラフスケッチの提出を依頼したときのことです。発注者は，「RIAではどんなことができるのか？ それがわからないと要件を考えられない」と言い，一方，制作者は「どんなことができるかはある程度の要件を把握しないと具体的に説明できない…」と言い，議論が堂々巡りに陥ってしまいました。その結果，要求定義のタスクをなかなか開始できないことがありました。
発注者，制作者が円滑なコミュニケーションを図りながらプロジェクトを成功に導くためにはどんなキーファクターがあるのでしょうか。
ゴールの設定・共有でトラブルを未然に防ぐ
最初に行わなければならないことは，「サイトを構築（またはリニューアル）する目的は何か？」「ターゲットとするユーザーは？」「サイトを訪れたくれたユーザーに期待する行動は何か？」といったことを，プロジェクトのゴールとしてプロジェクトのメンバー全員が共有することです。RIA開発プロジェクトでは，制作者サイドからはデザイナーとシステム・エンジニアが参加し，発注者サイドからはマーケティング担当，プロモーション担当，Webサイト管理担当者等，関係者の職種が参加するなど，参加者の専門領域が多岐にわたることがほとんどです。そのため，プロジェクト・メンバー間における意思疎通に，より多くの注意を払う必要があります。プロジェクト・メンバー全員が迷ったときに立ち戻ることができる共通認識（＝プロジェクトのゴール）を設定することが結果的には仕様変更や認識違いによるトラブルを減らすことになるはずです（図2）。
図2：要件定義で行う作業（クリックで拡大表示）
ユーザーの期待行動に立脚した要件定義を行う
要件定義においては，個々の画面，機能，コンテンツ構成を検討するうえで「ユーザーはどんなシーンで」，「そのページの訪問時，訪問後にどんな行動を期待するのか？」を起点に考えることが重要です。RIAの強みは豊富なユーザー・インタフェースの表現手段によりユーザーのサイト上での行動を支援し，ユーザーをサイトの目的に沿った行動に誘導することにあります。発注者サイドと制作者サイドの間でRIAに対する理解度の差があり，要求が伝わらない，理解できないという認識の差異が生まれる可能が大きいと，「○○○のサイトのようなナビゲーションにしたい」などと他のサイトのイメージを追従する議論をしてしまいがちです。しかしそれは，解決策にはならないことがほとんどです。「サイトがターゲットとなるユーザー像は？」「ユーザーにどのような行動をしてもらいたいのか？」「このページに訪れているユーザーが次に行きたいと思う導線は？」「どんな体験をさせたいのか？」など，ユーザーの期待行動に立脚した議論に基づいて，サイトにおける施策を検討するべきです（図3）。
図3：ユーザーの期待行動に立脚した議論
変更要求を受け入れるタイミングを事前に設定する
発注者がサイトの制作途中で，要件を変更したいと思うのはよくあることです。一方で制作者は，変更を頻繁に受け入れると品質や納期に支障が生じる可能性があるので，途中での変更は回避したいと考え，両者の利害損失が衝突することになります。RIA開発ではユーザー・インタフェース・デザインのクライアントサイド開発と，ビジネス・ロジックのサーバーサイド開発が同時並行で進められます。そのため，一つの変更要求がプロジェクト進行全体に影響を及ぼす可能性を多く含んでいます。
そのため，プロジェクト開始時にお客様と要件の変更について「どういう変更はいつまで許容できていつからは許容できない」「それはなぜなのか」ということを議論し，お互いの共通認識を持つ場を持つこと効果的でしょう。RIAコンソーシアムのマネジメント分科会では，変更を許容できる合理的な要求定義の研究を行い，変更要素と，変更の受け入れを許容する時期を視覚化した要件変更受け入れ時期分析表を作成しています（図4）。
図4：要件変更受け入れ時期分析表（RIAシステム 構築ガイド 2005年度版より一部抜粋，クリックで拡大表示）
一体感を持って協働していけるコミュニケーション環境を作る
連載1回目である今回は，RIA開発において発注者側，制作者側が円滑にコミュニケーションを行いながらプロジェクトを進めるための考慮点を，プロジェクトの初期段階に焦点をあてて述べてきました。初期段階に焦点をあてた理由は，プロジェクトのボトルネックは，発注者との意思疎通が図れていない段階である「プロジェクト編成」「初期ヒアリング」「要求定義時のコミュニケーション」にあると考えるからです。重要な点は早期に発注者側，制作者側の距離を詰め，間違った方向にプロジェクトを進めないようにスタートを切ることです。プロジェクト開始時に，変更要求タイミングの事前設定や，ドキュメント，オブジェクトの管理のルールをプロジェクト内で取り決めておく必要があります。ナレッジの差異によるコミュニケーション・トラブルを防ぐために用語集を作って共有するといったことも効果的でしょう。プロジェクトの目的，ゴール，お互いの役割，進ちょくを共有し，発注者と，異なる専門性をもった同士の制作者が，同じフィールドで一体感を持って協働していけるコミュニケーション環境を作ることが重要です。
RIAコンソーシアムについて
「RIAコンソーシアム」は2003年に，RIAの普及・発展を目標とし，ビジネスへの活用を推進するために作られました。業種を超えた企業が中立の立場で参加し，「クリエイティブ・サイド（デザイナー）」と「システム・インテグレータ（SE）」と「ユーザー」をつなぐための共通のテーブルを作り，ビジネス上競合する各社が忌憚のない意見交換を行っています。RIAコンソーシアムでは常に，新しく発展していく市場に対応できるあらゆる技術に注目しながら活動しています。具体的には，図Aにある三つの分科会にそれぞれのテーマごとのチームを設定して検討しており，セミナーなどで発表するほか，活動内容を毎年度末にまとめた資料を「RIAシステム 構築ガイド」として発表し，希望の方には会員メンバーではなくとも個別に販売しています。詳しくはWebサイトまたは，メール（office@ria-jp.org）でRIAコンソーシアム事務局まで。
図A：RIAコンソーシアムの活動領域
