RIAシステム 構築ガイド Essential 2

RIA開発の勘所

RIAプロジェクトは一朝一夕で済む問題ではない。いくつもの課題が待ち構えています
RIAシステム 構築ガイド Essential 2

RIAシステム 構築ガイド Essential 2

RIAコンソーシアムが発行したRIAの普及促進や開発に関するガイドライン『RIAシステム 構築ガイド』の2008年版である『RIAシステム 構築ガイド Essential 2』をWeb担向けに特別にオンラインで公開するコーナー。

開発プロセス・ワーキンググループの活動より

RIAプロジェクトを始めるに当たって、未経験者が戸惑う点は多々あります。そもそも、プログラミング言語を独学で学んできた人達にとっては、言語習得と開発能力とは、それほどかけ離れていないものだと思います。が、RIAの場合は少し勝手が違います。その違いを受け入れずに、通常のアプリケーション開発と同じように、検証や納品物を想定すると、泣かされるのが常でしょう。

下表には、RIA開発において常について回るといって良い課題を列挙してあります。そして、残念ながら、これらの課題に対する答えに「標準」はないと思って頂いた方がよいと思います。

大きな理由としては、RIAプロジェクトは未だ未だ始まったばかりで、開発者の数がそもそも足りていません。そして、既存開発チームには、自ずと得意とする分野があり、一般論を語れるほど実績経験がある者が少ないのが現実です。更に、RIAプロジェクトの根幹が「使い勝手」という品質である限り、ユーザを見つめる視点に依存する部分が大きいと言わざるを得ません。従って開発チームという阿吽の呼吸で開発が進められる、属人的な分業体制が鍵となっているとも言えます。例えば「この課題は『彼』に任せれば安心だ」などが、「解」のとなる場合です。

言語仕様を理解しても、
高ユーザビリティ・アプリは構築できないという現実

しかし、既存開発企業は実績を着実に積み重ねています。それは、一般論としての方法論の確立まで至っていないが、現実解としては方法論を持っていることを意味します。先に取り組み始めたという「一日の長」は、この流れの速いWeb(IT)業界の中では、実はかなり重いものです。仕様書を書くのすら迷うのであれば、一度学ぶ姿勢で協業するのは良策です。何もしなければ差は縮みません。

表. RIA開発プロジェクトにおける一般的課題/疑問点
大分類中分類小分類備考
契約一括方式1段階要件定義から開発まで一つの契約
多段階方式2段階要件定と開発を別契約
3段階要件定義、設計、開発が別契約
プロジェクト計画見積りエモーショナルな領域仕様/タスクに落とせない
クライアントの要望の言語化感覚的には理解するが...
リスクヘッジどこまでが「修正」で、どこまでが「追加要件」か
要件の増減を交渉できるのか
どこまでのリスクを織り込むべきか
作ってみないと分からないことだらけなのだが...
体制/主導権エンジニア?/デザイナ?エンジニア会社?/デザイナ会社?
仕事の指示の仕方どう伝えればよいのか....
責任分解点どう切り分ければよいのか...
リスクヘッジ開発中の仕様変更に対応可能な開発体制の維持
実装技術ファイルサイズ分割基準(ユーザの体感速度と言われても)
データ処理フロントとバックのどちらに、どのように決めるのか適切な開発比重のかけ方が分からない
提案ROI客観的説明ユーザビリティの効果が数値として表せない
効果測定RIAの費用対効果
見せ方作るしかない?
要件定義機能要件洗い出し時期実装機能はどのレベルまで事前に洗い出しておくか
リスクヘッジ想定では実装できなかった場合は?
実装要件どの技術を選定するか選定基準/確定時期
どのFrameworkを使うか選定基準/確定時期
どのツールを使うか選定基準/確定時期
マッシュアップ?選定基準/確定時期
OSS系の利用は?選定基準/確定時期
ユーザビリティ要件ヒアリングポイント何が優先度として高いのか?
仕様変更/機能追加(非常に仕様が流動的に見えるのだが....)
ユーザビリティの指標(ビジネスゴールとずれたりしないか)
ユーザビリティの専門家が必要か
基準お客さまの要件が利用者の使いやすさにつながっていないことがある(どう闘う?)
コンセンサスユーザビリティ論共通理解基盤の構築哲学的議論?
アニメーション仕様 絵コンテ? ワイヤーフレーム、モックアップ?
「完成」という認識 事前のすり合わせ?/検収方法の確定方法
担当者誰の合意が必要なのかステークホルダ、有権限者が出てこない
UI設計基準ユーザビリティ「人による」という言葉から先に進めない
デザイン「好みによる」という言葉から先に進めない
対象ユーザ調査方法事前に調査する経験がない/何に着目すべきか
共通認識チーム内で共通意識を持ち続けられない
ドキュメント画面仕様書どのレベルのインタラクションまで書くべきなのか
ページ数が多くなり、メンテナンスも大変
必須記述項目とは何か
状態遷移図どの粒度で記述すべきかが分からない
使い易さ「仕様」として、どのように記述し、検証するのか
UI部品UI部品の動きのドキュメント方法(スピード、タイミング等)
絵コンテ実は一番有用だったりするが、公式ドキュメントとして有効?
設計画面レヴュー意見が発散し易く、まとめにくい
指標化できるかサーバとの通信回数/頻度/データ量
情報デザインどのタイミングで固めるべきか
画面の論理設計画面分割/画面遷移/モジュール分割/インタラクション設計の順序と方法
エフェクト上手い記述方法が不明/伝え方すら分からない
パフォーマンス設計順序と方法、未達の場合の対処方法
データの持たせ方フロント/バック/通信方法
性能の担保C/S性能
要求定義時における性能要件の定義
エラーチェックタイミング/ロジック
メンテナンスビリティメンテナンスビリティをどこまで担保/確保しているか。(後で変更可能な箇所が精査できているか)
プロトタイプ契約方法回数指定?
範囲C/S間のデータの受け渡しまで?、GUIのみ?
実装形態実装方法プロトタイプをどのような形で制作するか?
進め方変分の記録方法/証跡の残し方/頻度/検証者/ゴール設定
テスト仕様書作成時期/検証方法/スケジュール
レベル有識者/素人/期間/人数
負荷テスト自動化/人力...
パフォーマンステスト自動化...
テスト範囲ユーザビリティテスト/機能テスト...
検収方法どうすればOKもらえるのか/どう見ればOKが出せるのか...
RIAコンソーシアム
開発プロセス ワーキンググループ
『RIAシステム 構築ガイド』について

▲ページ先頭に戻る

RIAシステム 構築ガイド Essential 2

この記事は、RIAコンソーシアムが発行した『RIAシステム 構築ガイド Essential 2』の内容を、Web担向けに特別にオンラインで公開しているものです。※掲載されている内容は2008年12月発行時点のデータに基づいています。

RIAコンソーシアムの活動記録とも言える本ガイドは、RIAの普及促進、開発に関するガイドライン、課題解決などについて、マネージメント、ユーザーインタフェース、テクノロジーの3つの視点からみた、それぞれのテーマについてまとめています。

冊子のご購入や「無料お試し版」ダウンロード、過去の構築ガイドに関してはこちらをご覧下さい。
https://www.ria-jp.org/about/guide.html

この記事が役に立ったらシェア!
メルマガの登録はこちら Web担当者に役立つ情報をサクッとゲット!

人気記事トップ10(過去7日間)

今日の用語

DRM
「DRM」は主に以下2つの略語のこと。 ■ダイレクトレスポンスマーケティン ...→用語集へ

インフォメーション

RSSフィード


Web担を応援して支えてくださっている企業さま [各サービス/製品の紹介はこちらから]