SCENARIOS, STORIES, USE CASES 10章
- 1. SCENARIOS, STORIES, USE CASES 10章 筑波⼤大学 ⼤大学院 ビジネス科学研究科 経営システム科学専攻 斎藤 祐⼀一郎
- 2. 10 コンテクストデザインシナリオの役割… ユーザ観測を⽤用い業務の再設計を⾏行行うユースケース pp.179 209 2 Yuichiro Saito
- 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
- 30. おわり 30 Yuichiro Saito