Successfully reported this slideshow.
Your SlideShare is downloading. ×

アジャイルUX物語

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Upcoming SlideShare
リーンUX入門
リーンUX入門
Loading in …3
×

Check these out next

1 of 18 Ad

More Related Content

Slideshows for you (20)

Similar to アジャイルUX物語 (20)

Advertisement

More from Tarumoto Tetsuya (20)

アジャイル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

×