Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

アジャイルUX物語

10,250 views

Published on

アジャイルUX物語

  1. 1. アジャイルUX物語 ~ 偉大なPOのスピリットとテクニック ~ <アジャイル UCD研究会>
  2. 2. 全面広告 「ユーザビリティ エンジニアリング(第2版)」 1章 ユーザ中心設計概論 2章 インタビュー法 3章 インタビューの実践 4章 データ分析法 5章 発想法 6章 プロトタイプ 7章 ユーザビリティ評価法 8章 ユーザテスト 9章 ユーザテストの準備 10章 ユーザテストの実施 11章 分析と再設計 12章 ユーザ中心設計活動 *無料サンプル版(第2章全文) http://www.slideshare.net/barrelbook/ss‐26183115 全面広告
  3. 3. • • • • • プロダクトオーナー(PO)は、 製品の明確なビジョンを持つ。 プロジェクトの成功に全面的に責任を 持つ。 変化に適応して選択を行う。 中間成果を受け入れるか、開発チー ムに差し戻すか決定する。 いつ、どんな内容の製品をリリースす るか決定する。 早く偉大なPO になりたい~ アジャイルマニフェスト 我々は、 • プロセスやツールよりも個⼈と対話を、 • 包括的なドキュメントよりも動くソフトウェアを、 • 契約交渉よりも顧客との協調を、 • 計画に従うことよりも変化への対応を、 価値とする。すなわち、左記のことがらに価値があることを認 めながらも、私たちは右記のことがらにより価値をおく。
  4. 4. まず、製品コンセプト――「誰のため に、何を作るのか」――を考えます。 メソッド1:ゲリラリサーチ 手がかりをつかむために簡易的なリ サーチを行います。人脈をたぐって 様々な人と会ったり、街頭で人々の行 動を観察したり、ちょっとしたアンケート を実施したりします。 その際に一つコツがあります。それは 「何が欲しいか?」とは決して聞かない ことです。その代わりに「何か困ってい ることはないか?」を深く探ります。 “正規軍(調査の専⾨家)”でなくても調査は出来る! ――例えば、⼈脈をたぐってユーザを⾒つけ、Skype でイン タビューして、結果は⼝頭でチームに伝える。無駄な製品を 作るほど無駄なことはない。「予算が無い、時間が無い」と ⾔って調査をしないのが⼀番リスクが⾼い。
  5. 5. 課題が絞り込まれたら、その解決策を 考えます。 メソッド2:ゲームストーミング ありきたりな解決策では、わざわざ新 たなプロジェクトを立ち上げる価値はあ りません。これまでに無いユニークなア イデアを出すためにはブレインストーミ ングが有効です。 なお、ブレインストーミングには遵守す べき基本原則があります。それは―― 批判厳禁、自由奔放、質より量、便乗 歓迎、視覚化、脱線禁止、1度に1人。 現代のハイテクビジネスにおけるシリコンバレー流企画発想法。 ブレインストーミングを基礎として、そこに「発散→創発→収 束」という各プロセスに適した様々なファシリテーション技法を 集めた発想法のコレクション。いわば「ブレインストーミング 2.0」。
  6. 6. プロジェクトを立ち上げる前にアイデ アを検証します。 メソッド3:コンセプトテスト ストーリーボードやモックアップを作っ て“投票”にかけたり、ウェブにフェイク の製品広告を出して反応を確かめたり ます。 そして、ユーザから高い評価を受ける レベルに到達するまで、調査・発想・検 証を繰り返します。 “検証”といっても難しく考えることはない。ちょっとした「お絵か き」や「⼯作」 で⾃分のアイデアを形にして、みんなに⾒てもら う・触ってもらう。そして、横で黙って様⼦を観察していれば、 そのアイデアの価値は⾃ずと明らかになる。みんなの(さりげ ない)意⾒は意外と正しい。
  7. 7. 製品コンセプトが固まったら本格的に 開発チームを編成します。 アジャイルな開発チームは自己組織 化されていて、機能横断的です。 自己組織化チームは、作業を成し遂 げるための最善の策を、チーム外から の指示ではなく、自らが選択します。そ して機能横断的チームは、チーム外に 頼らずに作業を成し遂げる能力を持っ ています。 スクラムチーム スクラムチームは、プロダクトオーナー・開発チーム・スクラムマ スターで構成される。 • プロダクトオーナーは、プロダクトの価値と開発チームの作 業を最⼤化することに責任を持つ。プロダクトオーナーは、 プロダクトバックログの管理に責任を持つ唯⼀の⼈物であ る。 • 開発チームは、リリース判断可能な「完了」したプロダクト のインクリメントを、各スプリントの終わりに届けることのでき る専⾨家で構成されている。インクリメントを作成できるの は、開発チームのメンバだけである。 • スクラムマスターは、スクラムの理解と成⽴に責任を持つ。 そのためにスクラムマスターは、スクラムチームにスクラムの 理論・プラクティス・ルールを守ってもらうようにする。 スクラムチームは、プロダクトを反復的・漸進的に届ける。これ は、フィードバックの機会を最⼤化するためである。「完了」し たプロダクトを漸進的に届けることで、動作するプロダクトが常 に利⽤可能な状態にしている。 (引⽤元:スクラムガイド2011)
  8. 8. 開発チームが固まったら、プロジェクト 計画を立てます。 メソッド4:プラグマティック・ペルソナ まず、ユーザの視点で議論を進める ためにペルソナを作ります。ただ、通常 のアジャイルUXプロジェクトでは正規 のペルソナを作るだけの十分な調査 データはありません。 そこで、既知の情報からユーザロール を定義した上で、それらを擬人化して 臨時のペルソナを仕立てます。 アジャイル流の臨時ペルソナ。⼀般に臨時ペルソナの安易な 利⽤は避けるべきだが、ユーザストーリーを書くためのツールと 割り切って使う分には全く問題ない。「正式なペルソナではな い」ことが⼀⽬瞭然である点がミソ。デビッド・ハスマンが流⾏ らせた。
  9. 9. 次に、ユーザストーリーを使って要求 定義を行います。 メソッド5:ユーザストーリー ペルソナを主語とした「誰々として 何々したい(および、その理由)」という 短い文章で、要求を小さなフィー チャー単位でカードに記述していきます。 アジャイル開発ではこのユーザストー リー単位で実装します。 アジャイル流の要件定義(書)。ハガキ⼤のカードに「誰々 として何々したい(および、その理由)」と書き出していくだけ。 そんないい加減な要求定義でこの先⼤丈夫か?と⼼配にな るかもしれないが、不明な点が出てくれば、その時点で直接 聞けばいい、直接答えればいい。ユーザストーリーは対話の きっかけに過ぎない。
  10. 10. それぞれのユーザストーリーがどれく らいの作業規模なのかを見積ります。 メソッド6:プランニングポーカー 作業時間(人月)ではなく相対的な大 きさを示すストーリーポイントという指標 を使うのが特徴です。そしてプランニン グポーカーというゲーム形式で見積作 業を行います。 なお、見積は開発者全員で行います が、開発に直接携わらない第3者は無 責任な口出しをしてはいけません。 ⾒積のためのカードゲーム。各プレイヤーはストーリーポイント が書かれたカードを選んで⼀⻫に出す。提⽰したカードに差 があれば、そのカードを選んだ理由を説明する。これを何度か 繰り返すことで認識の違いを埋めて合意を形成する。なお、 カードに書かれているストーリーポイントの数字は「フィボナッチ 数列」。
  11. 11. ユーザストーリーをどんな順番で実装 して行くのかを決めます。 メソッド7:ストーリーマップ このデリバリーシーケンスは単にワー クフロー順や費用対効果だけで決める のではなく、機能の相互依存性や市場 の変化など製品に関わる多様な要因 を考慮して決めます。デリバリーシーケ ンスの決定はプロダクトオーナーの最も 重要な仕事です。 順序化したユーザストーリーはリストと して管理しますが、単なる一次元のリス トではストーリーの関連性が失われ、製 品の全体像を見失いがちです。そこで ユーザストーリーマップという二次元の リストが用いられるようになりました。 ⼆次元のプロダクト・バックログ。ワークフロー(横軸)と優先 度(縦軸)の2軸にユーザストーリーを配置することでシス テムの全体像が把握しやすくなる。さらに⽔平⽅向に”スライ ス”すると中・⻑期のリリース計画にも使える。アジャイルUX の旗⼿であるジェフ・パットンが考案した。
  12. 12. ファーストリリースに向けて開発を始 めます。 メソッド8:スクラムボード アジャイル開発では1~4週間単位の イテレーションという開発期間を定めま す。そしてデリバリーシーケンスに従っ て、その期間内に可能な限りのユーザ ストーリーを次々と完了していきます。 開発チームの作業の進捗状況はタス クボードで絶えず“見える化”されていま す。 ソフトウェア開発現場の「カンバン」。タスクの状態を「未着 ⼿」「着⼿」「完了」の3段階で表⽰する。開発の進⾏状況 が⼀⽬瞭然になり、問題が起きればすぐわかる。タスクが全 部終わったらストーリーマップから追加のストーリーを持ってくる。 タスクが残ったら次のスプリントに回す。スクラム版は決して「ノ ルマ達成表」ではない。
  13. 13. UIデザインもイテレーションの中で開 発と平行して進めます。それに適した 手法がスケッチボード法です。 メソッド9:スケッチボード デザインを1枚の巨大な紙の上で 行って、さらに壁から剥がしてクルクル と丸めて持ち運び、関係者によるレ ビューも出来るという優れものです。 レビューが終わったスケッチボードは 簡易の画面仕様書になります。 超特急のデザイン⼿法。インタラクション設計を1枚の巨⼤ な紙の上で終えて、さらに壁から剥がしてクルクルと丸めて持 ち運び、関係者によるレビューも出来るという優れもの。⽶国 の著名なデザインファーム Adaptive Path 社で考案された。
  14. 14. 重要かつ複雑な操作を必要とする画 面についてはプロトタイピングします。 メソッド10:ペーパープロトタイプ 「バグは設計の初期段階で潰す」とい うのはソフトウェア開発の鉄則です。 ペーパープロトタイプのような簡便な 手法を用いれば、従来ならば到底不可 能であったような設計のごく初期段階 からユーザテストが実施できるので、開 発チームはリスクを大幅に低減できま す。 紙で作ったローファイなプロトタイプ。紙とペンしか使わない “超”ローテクなソフトウェア開発⼿法で、主に⼿書きで作成 する。紙製ではあるが、少しばかりの芝居⼼を発揮して「指 でクリック」したり、フィールドに「鉛筆で⼊⼒」すれば擬似的に ソフトウェアの動作を再現可能。
  15. 15. プロトタイプを作ったら、すぐユーザテ ストで検証します。 メソッド11:ユーザテスト ユーザテストの最大の特徴は、ユー ザに“考えていることを話しながら操作 してもらう”ことです。これを思考発話法 と言います。 そして、 5人のユーザで テストすれば約85%の問題点が見つ かります。 ただ、正規のユーザテストではイテ レーションの期間内に収まらないので、 Do-it-yourself方式の軽量なテスト手 法を使います。 ユーザテストの基本はとても単純。ユーザにタスク(作業課 題)を提⽰して、その実⾏過程を横で観察するだけ。社内 の廊下を歩いている他の部署の社員を捉まえてテストに協 ⼒してもらうという簡便な”ホールウェイ・テスト”であっても、か なり効果はある。
  16. 16. 各イテレーションの終わりには、実際 に製品を動かすデモを行って、関係者 からフィードバックを得ます。 Demo or Die! POは関係者のフィードバックと開発の 進捗状況を勘案して、ユーザストーリー を追加・削除・修正したり、デリバリー シーケンスを変更したりします。 そし て次のイテレーションを始めます。 このようなイテレーションを繰り返すこ とで製品リリースに到達します。 そして、おおよそ3ヶ月から6ヶ月単位 でリリースを繰り返しながら、製品とビジ ネスを成長・拡大させていきます。 「デモか死か」――⽶MITメディアラボの理念の1つ。理論 構築だけではなく、実際に動く試作品を作ってデモを⾒せな ければ、その研究は評価されない。メディアラボは1985年に ニコラス・ネグロポンテによって設⽴され、2011年には第4代 所⻑として伊藤穰⼀が選出された。
  17. 17. 樽本 徹也 ‐ 利用品質ラボ代表 • • • • • UXリサーチャ/ユーザビリティエンジニア 認定 人間中心設計専門家 認定 スクラムプロダクトオーナー(CSPO) NPO  人間中心設計推進機構 評議員 アジャイルUCD研究会 共同代表  UX/UCDの講演・研修  UX/UCDの社内導入支援  UX/UCDによる製品開発支援 Keep in touch! ◎人机交互論 ‐ ユーザビリティエンジニア的HCI論 http://www.usablog.jp/ ◎アジャイルUCD研究会 ‐ リーン/アジャイルUX最新News http://groups.google.com/group/agileucdja?hl=ja ◎Facebook ‐ 樽本徹也 https://www.facebook.com/tetsuya.tarumoto
  18. 18. 簡単・便利なコトづくり応援します。  UX/UCDの講演・研修  UX/UCDの社内導入支援  UX/UCDによる製品開発支援 東京都台東区下谷1‐11‐15 ソレイユ入谷4F

×