Weitere ähnliche Inhalte
Ähnlich wie SCENARIOS, STORIES, USE CASES 10章
Ähnlich wie SCENARIOS, STORIES, USE CASES 10章 (20)
Mehr von Yuichiro Saito (17)
SCENARIOS, STORIES, USE CASES 10章
- 3. 序論 (pp.179)
(本章は事例が豊富ですが、同時に物量もありますのでど
うかおつきあいください。)
コンテクストデザイン(CD)とは顧客中⼼心の設計プロセス
製品とシステムの概念を識別する
特定のシステム定義の詳細を詰めて⾏行行く
プロセスの中⼼心
ユーザシナリオ
シナリオベースの推論
よい設計(⾼高品質な設計)のためには、モデルベースとシ
ナリオベースを交互に使う。というのも、単独でのスト
ラクチャルビューでは、細部はあまり扱わないためであ
る。
実装の設計は、ユースケースシナリオと⾔言う直列表現と
なる。
3
Yuichiro Saito
- 4. 適⽤用可能性 (pp.180)
CDは次の分野で適⽤用可能。
ビジネスアプリケーション
コンシューマ向けアプリケーション
製品携帯は次のもので利⽤用可能。
エンタープライズソフトウェア市場
Webページ
ポータル
無線アプリケーション (携帯向けアプリの事?)
などなど。
あらゆる規模に使える。
他のツールやテクニックを簡単に追加可能なバックボーンと
なる。
ISO 9000やSEI準拠プロセスを置く組織に適している。
RUPを使っている企業では、ビジネスモデリングやソリュー
ションデザインの設計⼿手法を拡張できる。
4
Yuichiro Saito
- 5. ライフサイクル (pp.180)
Work practice redesign は、要件の発⾒見見と検証の間
を橋渡しする重要なものである。ちゃんと切り分け
ないと、失敗の元である。
表10.1に、ライフサイクルのどこにマッピングされ
ているかを⽰示している。
(⼤大きいので直接⽂文献をご覧ください)
イテラティブにやる⼿手法なので、ウォーターフォー
ルのようにきれいな流れと⾔言う訳ではない点に注意。
5
Yuichiro Saito
- 6. 強み (pp.181)
実顧客データをもとに各デザインプロセスを確実に駆動させ
られる
UML, ユースケース, ペルソナ法, ラボベースユーザビリティ
テスティング, X-Programming 等を統合する⾜足場として簡単
に使える。
デザインからコードに落とす際に完全なステップバイステッ
プで進められる。
視覚的な表現や図で顧客と読み合わせられる。
⼤大規模だったり、焦点が狭まったプロジェクト、両⽅方で扱え
る。
仕事を分けるための優先順位付けをサポートできる。
変更管理が容易。
リスク軽減が出来る。明確に定義されたニーズに基づきソフ
トウェアの評価とプラットフォームが決められる。
クロスファンクショナルチームの体制を敷く事が薦められる。
6
Yuichiro Saito
- 7. 弱み (pp.185)
⼤大規模で⾰革新的なプロジェクトに置ける単体のタスク分析は
推奨されない。
作業が遅く感じられると思われる。内容が固まるまでコード
に⼿手を付けられないからである。
紙に依存し、管理が煩雑。ツールを作ったから使ってね!(っ
てことですかね。)
開発組織の改編を要する可能性がある。
不慣れな⼈人は、トラブルが最⼩小化するポイントに⾄至る時に初
めて理解が可能となる。
システムを定義する段階で、紙のプロトタイプを顧客から得
る事を忘れる時がある。
これが定性的なプロセスなので、定量的な事をやってきた⼈人
の中には不慣れな⼈人がいる。
チームベースのプロセスであるため、古い組織だとチームで
集まる部屋を確保できない場合がある。
7
Yuichiro Saito
- 8. ⼿手法 (pp.185)
顧客が主体で、チームで作成する、フロントエンド
の設計プロセス。
シナリオベースの推論は、設計の詳細が正常である
事を保証する。
構造、ビュー、モデル推論は、⾰革新的なデザインと
プロセスソリューション駆動でやります。
表 10.2 に⽐比較表があります。
(⼤大きいので直接⽂文献をご覧ください)
8
Yuichiro Saito
- 9. やりかた (pp.186)
トレーニング⽤用の問題を⽤用いて解説します。
“Shopping Design Problem”
買い物をする家族を技術でサポートしたい
技術はたくさんある。⾰革新的なデザインを開発したい。
⽂文脈の問い合わせ (Contextual Inquiry:CI)
チームは、真のお客様のニーズを満たすために、まずお
客様と⾃自分の仕事の習慣を理解する必要がある。
仕事が習慣になってしまうと、それを表現する事は困難。
これまでのインタビュー⼿手法では、設計に必要なシナリ
オ・模式を知る事は困難。
そこで、CIを通じて本当の moment-by-moment の流れ
を知るインタビューを⾏行行う。
9
Yuichiro Saito
- 10. やりかた (pp.187)
⽂文脈の問い合わせ (CI)
チームメンバーは、⼈人々を観察する。
観察中は、仕事の内容を明確にする必要は無い。
CIは、システムがサポートする必要のある作業の実例を
集められるのである。
オンライン⾷食品店の設計では、ターゲット市場を表すお
客様とCIを通じ、⾃自宅や⾷食料品店で観察をした。
どうやって店を選ぶか
どうやって何を買うかを決めるか
お店で1回やる事とは何か
その後、解析セッションのチームで分析を⾏行行った。
10
Yuichiro Saito
- 11. やりかた (pp.187)
解析セッション
CIの成果物はチームで共有する。
登場⼈人物: UIデザイナ, エンジニア, ドキュメントライ
ター, ユーザビリティの専⾨門家, 内部のビジネスユーザ,
マーケティング担当者, ビジネスアナリスト。
旧来の共有⽅方法(メールとか)だと失敗する。
クロスファンクショナル設計チーム(3 4⼈人)が、設計上
の問題に関連した洞察とデータをあぶり出す。
チームは、これをつうじて顧客のニーズと共通の理解を
⾒見見つけ出している。
オンライン⾷食品店の事例では、5つのワークモデルに記録
する事によって、データをキャプチャして顧客のインタ
ビューを解析していた。
11
Yuichiro Saito
- 12. やりかた (pp.188)
業務モデル
図中の個⼈人や組織の仕事をキャプチャする。
インタビューの物語中に改編されている間に明らかにさ
れている関連データは各図に記録される。
次の5モデルは、実際の様々な”表情”を表し、業務とそれ
に関する問題の構造の異なる側⾯面を明らかにする。
1. フローモデル – ⼈人の責任や業務をサポートするために必要な
コミュニケーションと協調を表す。全体的な組織やグループ
を再設計するために重要。
2. カルチュアルモデル – 企業(法律など), 社内ポリシー(標準)が
外部のユーザ・グループ・組織にどのような影響を及ぼすか
を明確にする。⽂文化的環境を明らかにする。
12
Yuichiro Saito
- 13. やりかた (pp.188)
業務モデル (続き)
5モデル (続き)
1. 物理モデル – 物理的なレイアウトを⽰示す。グループ作業を再
設計する際のキーモデル。
2. 直列モデル – タスク分析に相当。タスクを実⾏行行するために必
要な各ステップを⽰示す。タスク⾃自体のシナリオベースの推論
と設計の基礎。
3. ⼈人⼯工モデル – ⼈人⼯工物の構造やタスクで利⽤用されている⽅方法を
⽰示す。⽬目的・使⽤用⽅方法・構造・および情報を識別。
プロジェクト計画時、スコープに対処する必要なモデル
を定義する。
Fig 10.1 を⾒見見てください。何故、ユーザはこのタスク
を全て実⾏行行するのでしょう?
13
Yuichiro Saito
- 14. やりかた (pp.190)
業務モデル (続き)
細かいのは顧客の意図である。適切なキャプチャは、作
業再設計に⽋欠かせない。
ケースモデラーを利⽤用し、ユースケースアーティファク
トとCDシーケンスモデル間の類似性を認識すべきである。
⼀一般的なユースケース表現(これをプログラムで⾔言うクラ
スと考える?)を達成するためのインスタンスであると認
識しておくと便利です。
要は、現象からモデリングして⾏行行きましょう、って事ですかね。
14
Yuichiro Saito
- 15. やりかた (pp.190)
結合
⼀一般化である。
アフィニティダイアグラムは、壁のサイズに解析セッ
ションでキャプチャされた問題や洞察⼒力力をもたらす。
階層図は、問題の範囲を明らかにする。
⾮非常に複雑で豊富な情報である。
これにより、チームメンバーは技術の導⼊入による作業モ
デルの変更・再設計されたタスク・役割・責任・⽂文化的
価値を議論できる。また、同時にプロジェクトのスコー
プとビジネスのゴールに応じた枠内で議論できる。
Fig 10.2 は、買い物リストを作った全ユーザを表す連結
シーケンスモデルである。
(⽂文中のURIをクリックしましたがHTTP 403でした…)
15
Yuichiro Saito
- 16. やりかた (pp.190)
結合 (つづき)
シーケンス群は、活動を表すチャンクにグループ化され
ている。
⽬目的・ステップ・分岐・戦略・およびブレークダウンが
単⼀一の定義としてまとめられている。
業務の再設計は、最終的に連結シーケンスの再設計であ
る。
これは、絵コンテづくりのために⼤大切。
16
Yuichiro Saito
- 17. やりかた (pp.192)
Visioning
顧客全体に対する⾼高次元の「新世界」である。
再設計: シーケンスモデル…タスクの意図, アーティファクト
モデル…そのもの, フローモデル…役割, カルチュアルモデル…
⽂文化的な⼒力力, 物理モデル…問題、それぞれを克服している。
今の⽣生活を考慮しない、全体像の再設計である。
これはグループでの絵本の読み聞かせと同じ…キャンプファイ
アーを囲んで怪談話をする友⼈人同⼠士のように、互いのアイディ
アを追加して⾏行行く。
フリップチャート上に、アイディアをリアルタイムにキャプ
チャして⾏行行く。その上で、視覚的に進化させる。
アイディアの評価は、後でやる。
オンライン⾷食品店の例では、Fig 10.3 の通りに結実。
(時間があればじっくり読んでみましょうか…)
17
Yuichiro Saito
- 18. やりかた (pp.194)
ストーリーボーディング (絵コンテ)
ビジョンだけで、それぞれのタスクは詰めて⾏行行く事は無
い。
絵コンテは、シーケンス群から導かれたシステムがサ
ポートしなければならない重要なタスク群から表現する
と、うまくいく。
Fig 10.4 のようにUMLのような形で表現できるかも。
しかし、これではシステムのステップを⾒見見逃す可能性が
ある。
UIのモックアップは、業務実践の再設計上の会話に集中
すること。UIの「美しさ」は横に置いておく。
Fig 10.4 10.7 はオンライン⾷食品店での実例。UMLと絵
コンテを併⽤用している点に注⽬目。
18
Yuichiro Saito
- 19. やりかた (pp.199)
環境デザイン (User Environment Design:UED)
(このあとに⼤大きく響く⼤大切なプロセスになります)
⾃自然なワークフローをサポートするために、適切な機構と構造
を持っている必要がある。
システム設計は3層に分かれる。
UI
UED ← 今回はここ
実装
UEDは…
システムの重要分野や場所のセットを表す。
機能仕様と実装レベルのユースケースを駆動する。
システム構造と昨⽇日に関するモデルベース推論をサポート。
Fig 10.8 は主要部分を⽰示している。⽬目的・機能・およびその場
所からアクセスする作業オブジェクトを定義。
19
Yuichiro Saito
- 20. やりかた (pp.199)
環境デザイン (つづき)
顧客データは、複数のタスクを実⾏行行する複数のロールが
システムを使⽤用する事を⽰示している。
家庭で「周りのものを移動させる」「経験から学ぶ」よ
うに、再設計して⾏行行く。
UED制作の過程は、システム提供の意味を絵コンテと抽
象の間で⾏行行き交う。最終的に、⾸首尾⼀一貫した定義ではな
い。結果のモデルベースの思考を駆動する。
UEDはシステムの作業モデルと機能的なシステム要件の
簡単な定義でもある。⾸首尾⼀一貫したリリース(?)に焦点部
分を掘り下げて展開を計画していく。
20
Yuichiro Saito
- 21. やりかた (pp.201)
環境デザイン (つづき)
Fig 10.9 は買い物リストを作る話を表現している。どん
な状況下はわかってきたけど、細部を作成するまでには
まだ⾄至っていない。
Fig 10.10 は⽜牛乳のバーコードをスキャンしている様⼦子。
バーコードを読むと「ぴっ!」と⾔言う⾳音を⽴立立てることが
ここからわかる。
Fig 10.11 では、全て⾃自動で動いている様⼦子を表す。
(時間があれば、図をじっくり読んでみます…)
21
Yuichiro Saito
- 22. やりかた (pp.202)
ペーパープロトタイピング, モックアップインタビュー,
そしてUIデザインの初期段階へ
初期のUED(先節)は、システムが顧客の業務をどのように発展
させるかを⽰示す事が出来た。しかし、ちゃんとこれで出来るの
か、確認が必要となってくる。
そこで、ペーパープロトタイピング。
まず、ペーパーモックアップ、ペーパーモックアップインタ
ビュー。古典的な⼿手法。
コンテクチュアルデザインは、顧客の実業務をウォークスルー
しながら、その内容を同意させて⾏行行く。
そのため、やっている最中で、機能追加や変更が出来る。仕様
が試されているということである。
インタビューとテストの(複数回の)イテラティブなラウンドは、
細部の構造をより鮮明にして⾏行行く。
この結果、インタラクションデザイン、ビジュアルデザイン、
オブジェクトモデリングの最終的な形が⽤用意できる。
22
Yuichiro Saito
- 23. やりかた (pp.204)
CDの成果物を⽤用いてユースケースと実装モデルを作
成する
(だんだんとシステムの設計らしくなって参りました)
UEDは機能仕様の基礎となっている。
ペーパープロトタイピング(先節)で、機能の定義ができ
ている。
⾮非機能要件はUEDの制約としてキャプチャされている。
また、UEDは通常のユースケースを記述する事で達成し
た、システム設計の次のステップの元となる資料である。
(それほどまでにUEDが重要である)
(おまけ:第2節のカッコの深さに誤植あり)
各ユースケースは、単⼀一のシステムタスクに焦点を当て
る事が出来る。
23
Yuichiro Saito
- 24. やりかた (pp.204)
(つづき)
ユースケースは、シナリオベースの推論を⽤用いて作られ
ている。
その上で、モデルベース推論による分析を介してシステ
ム実装を表すオブジェクトモデルの開発を駆動して⾏行行く。
その基がUEDである。
デザイン思考プロセス・シナリオ・モデルベース推論を
平⾏行行に考えて⾏行行く。
ユースケースの前提条件は、機能定義・シナリオからは
制してきている。
設計チームは、UEDとストーリーボードに対し、ユース
ケースの完全性を確認する事が出来る。これらの全ての
状況は、ユースケースの1つとして反映されるべきである。
24
Yuichiro Saito
- 25. やりかた (pp.205)
(つづき)
この流れで実装に進むと、顧客中⼼心のデザインである焦
点がぶれる事は無い。
おかしな(無駄な)実装をしていないか、追跡する事が出来
る。
顧客のデータに縛られる事は、作業の実践⽅方法を発明し
再設計する事が出来つつも、正直に顧客に焦点を当て続
けられるのである。
Fig 10.13 にて、ショッピングリストのシーケンス図を
作成する。
ストーリーボードとUEDによって、順次かつ構造的にコ
ラボレーション図・アクティビティ図をモデリングでき
る。
CDをもとに、UMLやRUPに⾃自然に持って⾏行行きやすい。
25
Yuichiro Saito
- 26. レッスンで学んだ事 (pp.205)
(ここは筆者が⼤大いに語る節)
CDはCDによって設計されている!
継続的に改善してきたんです、との弁。
時間・⼈人的資源等、組織環境の違いに対応できるCDプロ
セスを作ってきました。
既存の開発ライフサイクルにCDを統合できるよ。
顧客フィールドのデータは、トレードオフに出来な
い。
痛みを伴う経験を通じて、議論する⽅方法を学んだ。
実地でデータを集める事が⼤大切なのです!
(まるで社会科学の研究のようですね)
26
Yuichiro Saito
- 27. 他の⼿手法との⽐比較 (pp.206)
(アジャイル開発⼿手法に対する批判になります)
参加型デザイン…XPをはじめとしたアジャイル開発⼿手法
との⽐比較をしていく。
アジャイルは…
フルタイムで顧客を1名以上はりつける。
しかし、その張り付いた顧客以外からも情報を集めないと⾏行行け
ない事は、技術者は知っているはず(経験談:実際そうでした)。
短期間の反復開発(注:Scrumだとスプリントと⾔言います)に注
⼒力力しているため、基本となるパターンや構造変化を検出しては
ならない(注:こうなる場合はそもそもの前提条件がおかしい)。
CDは、チーム内に顧客を取り込んで、インタビューを⽤用
いて情報を収集し、真実をストーリーから導く。
27
Yuichiro Saito
- 28. 他の⼿手法との⽐比較 (pp.207)
アジャイルの場合…
顧客の役割は、要求や設計の業務をやるのではなく、声
の発信者として捉えている。すなわち、機能実装の意思
決定者である。
(注: 実装の問題点を顧客に転嫁できてしまう…)
XPは要求やUXに関与しない開発プロセスを定義している。
プロセス中に、新システム・新しい部分のストーリー
ボーディングを作りながらやっているようなもの。
XPを今後実践する場合、スコーピングしてからやっ
た⽅方がおすすめ。
28
Yuichiro Saito
- 29. 他の⼿手法との⽐比較 (pp.207)
CDとアジャイルの共通点
(ここだけ共通点についての議論)
⾃自⼰己主導
チームワークを⼤大切にする
CDは他の参加型設計⼿手法とは異なる
定義の⼿手法に多くの形式がある
5章のように別の点でユーザのための作業として存在
RUPで構造化できなかった部分を補完する
時間があれば、感想を話します。
29
Yuichiro Saito