RIA開発の勘所
RIAシステム 構築ガイド Essential 2
RIAコンソーシアムが発行したRIAの普及促進や開発に関するガイドライン『RIAシステム 構築ガイド』の2008年版である『RIAシステム 構築ガイド Essential 2』をWeb担向けに特別にオンラインで公開するコーナー。
開発プロセス・ワーキンググループの活動より
RIAプロジェクトを始めるに当たって、未経験者が戸惑う点は多々あります。そもそも、プログラミング言語を独学で学んできた人達にとっては、言語習得と開発能力とは、それほどかけ離れていないものだと思います。が、RIAの場合は少し勝手が違います。その違いを受け入れずに、通常のアプリケーション開発と同じように、検証や納品物を想定すると、泣かされるのが常でしょう。
下表には、RIA開発において常について回るといって良い課題を列挙してあります。そして、残念ながら、これらの課題に対する答えに「標準」はないと思って頂いた方がよいと思います。
大きな理由としては、RIAプロジェクトは未だ未だ始まったばかりで、開発者の数がそもそも足りていません。そして、既存開発チームには、自ずと得意とする分野があり、一般論を語れるほど実績経験がある者が少ないのが現実です。更に、RIAプロジェクトの根幹が「使い勝手」という品質である限り、ユーザを見つめる視点に依存する部分が大きいと言わざるを得ません。従って開発チームという阿吽の呼吸で開発が進められる、属人的な分業体制が鍵となっているとも言えます。例えば「この課題は『彼』に任せれば安心だ」などが、「解」のとなる場合です。
言語仕様を理解しても、
高ユーザビリティ・アプリは構築できないという現実
しかし、既存開発企業は実績を着実に積み重ねています。それは、一般論としての方法論の確立まで至っていないが、現実解としては方法論を持っていることを意味します。先に取り組み始めたという「一日の長」は、この流れの速いWeb(IT)業界の中では、実はかなり重いものです。仕様書を書くのすら迷うのであれば、一度学ぶ姿勢で協業するのは良策です。何もしなければ差は縮みません。
大分類 | 中分類 | 小分類 | 備考 |
---|---|---|---|
契約 | 一括方式 | 1段階 | 要件定義から開発まで一つの契約 |
多段階方式 | 2段階 | 要件定と開発を別契約 | |
3段階 | 要件定義、設計、開発が別契約 | ||
プロジェクト計画 | 見積り | エモーショナルな領域 | 仕様/タスクに落とせない |
クライアントの要望の言語化 | 感覚的には理解するが... | ||
リスクヘッジ | どこまでが「修正」で、どこまでが「追加要件」か | ||
要件の増減を交渉できるのか | |||
どこまでのリスクを織り込むべきか | |||
作ってみないと分からないことだらけなのだが... | |||
体制/主導権 | エンジニア?/デザイナ? | エンジニア会社?/デザイナ会社? | |
仕事の指示の仕方 | どう伝えればよいのか.... | ||
責任分解点 | どう切り分ければよいのか... | ||
リスクヘッジ | 開発中の仕様変更に対応可能な開発体制の維持 | ||
実装技術 | ファイルサイズ | 分割基準 | (ユーザの体感速度と言われても) |
データ処理 | フロントとバックのどちらに、どのように決めるのか | 適切な開発比重のかけ方が分からない | |
提案 | ROI | 客観的説明 | ユーザビリティの効果が数値として表せない |
効果測定 | RIAの費用対効果 | ||
見せ方 | 作るしかない? | ||
要件定義 | 機能要件 | 洗い出し時期 | 実装機能はどのレベルまで事前に洗い出しておくか |
リスクヘッジ | 想定では実装できなかった場合は? | ||
実装要件 | どの技術を選定するか | 選定基準/確定時期 | |
どのFrameworkを使うか | 選定基準/確定時期 | ||
どのツールを使うか | 選定基準/確定時期 | ||
マッシュアップ? | 選定基準/確定時期 | ||
OSS系の利用は? | 選定基準/確定時期 | ||
ユーザビリティ要件 | ヒアリングポイント | 何が優先度として高いのか? | |
仕様変更/機能追加 | (非常に仕様が流動的に見えるのだが....) | ||
ユーザビリティの指標 | (ビジネスゴールとずれたりしないか) | ||
ユーザビリティの専門家が必要か | |||
基準 | お客さまの要件が利用者の使いやすさにつながっていないことがある(どう闘う?) | ||
コンセンサス | ユーザビリティ論 | 共通理解基盤の構築 | 哲学的議論? |
アニメーション仕様 | 絵コンテ? ワイヤーフレーム、モックアップ? | ||
「完成」という認識 | 事前のすり合わせ?/検収方法の確定方法 | ||
担当者 | 誰の合意が必要なのか | ステークホルダ、有権限者が出てこない | |
UI設計 | 基準 | ユーザビリティ | 「人による」という言葉から先に進めない |
デザイン | 「好みによる」という言葉から先に進めない | ||
対象ユーザ | 調査方法 | 事前に調査する経験がない/何に着目すべきか | |
共通認識 | チーム内で共通意識を持ち続けられない | ||
ドキュメント | 画面仕様書 | どのレベルのインタラクションまで書くべきなのか | |
ページ数が多くなり、メンテナンスも大変 | |||
必須記述項目とは何か | |||
状態遷移図 | どの粒度で記述すべきかが分からない | ||
使い易さ | 「仕様」として、どのように記述し、検証するのか | ||
UI部品 | UI部品の動きのドキュメント方法(スピード、タイミング等) | ||
絵コンテ | 実は一番有用だったりするが、公式ドキュメントとして有効? | ||
設計 | 画面レヴュー | 意見が発散し易く、まとめにくい | |
指標化できるか | サーバとの通信回数/頻度/データ量 | ||
情報デザイン | どのタイミングで固めるべきか | ||
画面の論理設計 | 画面分割/画面遷移/モジュール分割/インタラクション設計の順序と方法 | ||
エフェクト | 上手い記述方法が不明/伝え方すら分からない | ||
パフォーマンス | 設計順序と方法、未達の場合の対処方法 | ||
データの持たせ方 | フロント/バック/通信方法 | ||
性能の担保 | C/S性能 | ||
要求定義時における性能要件の定義 | |||
エラーチェック | タイミング/ロジック | ||
メンテナンスビリティ | メンテナンスビリティをどこまで担保/確保しているか。(後で変更可能な箇所が精査できているか) | ||
プロトタイプ | 契約方法 | 回数指定? | |
範囲 | C/S間のデータの受け渡しまで?、GUIのみ? | ||
実装形態 | 実装方法 | プロトタイプをどのような形で制作するか? | |
進め方 | 変分の記録方法/証跡の残し方/頻度/検証者/ゴール設定 | ||
テスト | 仕様書 | 作成時期/検証方法/スケジュール | |
レベル | 有識者/素人/期間/人数 | ||
負荷テスト | 自動化/人力... | ||
パフォーマンステスト | 自動化... | ||
テスト範囲 | ユーザビリティテスト/機能テスト... | ||
検収方法 | どうすればOKもらえるのか/どう見ればOKが出せるのか... |
- RIAコンソーシアム
- 開発プロセス ワーキンググループ
この記事は、RIAコンソーシアムが発行した『RIAシステム 構築ガイド Essential 2』の内容を、Web担向けに特別にオンラインで公開しているものです。※掲載されている内容は2008年12月発行時点のデータに基づいています。
RIAコンソーシアムの活動記録とも言える本ガイドは、RIAの普及促進、開発に関するガイドライン、課題解決などについて、マネージメント、ユーザーインタフェース、テクノロジーの3つの視点からみた、それぞれのテーマについてまとめています。
冊子のご購入や「無料お試し版」ダウンロード、過去の構築ガイドに関してはこちらをご覧下さい。
https://www.ria-jp.org/about/guide.html
ソーシャルもやってます!