アジャイルUX物語～ 偉大なPOのスピリットとテクニック ～

＜アジャイル UCD研究会＞

「ユーザビリティエンジニアリング(第２版)」

1章 ユーザ中心設計概論2章 インタビュー法3章 インタビューの実践4章 データ分析法5章 発想法6章 プロトタイプ7章 ユーザビリティ評価法8章 ユーザテスト9章 ユーザテストの準備10章 ユーザテストの実施11章 分析と再設計12章 ユーザ中心設計活動

*無料サンプル版（第2章全文）http://www.slideshare.net/barrelbook/ss‐26183115

全面広告

全面広告

アジャイルマニフェストプロダクトオーナー（PO）は、• 製品の明確なビジョンを持つ。• プロジェクトの成功に全面的に責任を持つ。

• 変化に適応して選択を行う。• 中間成果を受け入れるか、開発チームに差し戻すか決定する。

• いつ、どんな内容の製品をリリースするか決定する。

我々は、• プロセスやツールよりも個⼈と対話を、• 包括的なドキュメントよりも動くソフトウェアを、• 契約交渉よりも顧客との協調を、• 計画に従うことよりも変化への対応を、価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。

早く偉大なPOになりたい～

メソッド1:ゲリラリサーチ

“正規軍（調査の専⾨家）”でなくても調査は出来る！――例えば、⼈脈をたぐってユーザを⾒つけ、Skype でインタビューして、結果は⼝頭でチームに伝える。無駄な製品を作るほど無駄なことはない。「予算が無い、時間が無い」と⾔って調査をしないのが⼀番リスクが⾼い。

まず、製品コンセプト――「誰のために、何を作るのか」――を考えます。

手がかりをつかむために簡易的なリサーチを行います。人脈をたぐって様々な人と会ったり、街頭で人々の行動を観察したり、ちょっとしたアンケートを実施したりします。

その際に一つコツがあります。それは「何が欲しいか？」とは決して聞かないことです。その代わりに「何か困っていることはないか？」を深く探ります。

メソッド2:ゲームストーミング

現代のハイテクビジネスにおけるシリコンバレー流企画発想法。ブレインストーミングを基礎として、そこに「発散→創発→収束」という各プロセスに適した様々なファシリテーション技法を集めた発想法のコレクション。いわば「ブレインストーミング2.0」。

課題が絞り込まれたら、その解決策を考えます。

ありきたりな解決策では、わざわざ新たなプロジェクトを立ち上げる価値はありません。これまでに無いユニークなアイデアを出すためにはブレインストーミングが有効です。

なお、ブレインストーミングには遵守すべき基本原則があります。それは――批判厳禁、自由奔放、質より量、便乗歓迎、視覚化、脱線禁止、１度に１人。

メソッド3:コンセプトテスト

“検証”といっても難しく考えることはない。ちょっとした「お絵かき」や「⼯作」 で⾃分のアイデアを形にして、みんなに⾒てもらう・触ってもらう。そして、横で黙って様⼦を観察していれば、そのアイデアの価値は⾃ずと明らかになる。みんなの（さりげない）意⾒は意外と正しい。

プロジェクトを立ち上げる前にアイデアを検証します。

ストーリーボードやモックアップを作って“投票”にかけたり、ウェブにフェイクの製品広告を出して反応を確かめたります。

そして、ユーザから高い評価を受けるレベルに到達するまで、調査・発想・検証を繰り返します。

スクラムチーム製品コンセプトが固まったら本格的に開発チームを編成します。

アジャイルな開発チームは自己組織化されていて、機能横断的です。

自己組織化チームは、作業を成し遂げるための最善の策を、チーム外からの指示ではなく、自らが選択します。そして機能横断的チームは、チーム外に頼らずに作業を成し遂げる能力を持っています。

スクラムチームは、プロダクトオーナー・開発チーム・スクラムマスターで構成される。

• プロダクトオーナーは、プロダクトの価値と開発チームの作業を最⼤化することに責任を持つ。プロダクトオーナーは、プロダクトバックログの管理に責任を持つ唯⼀の⼈物である。

• 開発チームは、リリース判断可能な「完了」したプロダクトのインクリメントを、各スプリントの終わりに届けることのできる専⾨家で構成されている。インクリメントを作成できるのは、開発チームのメンバだけである。

• スクラムマスターは、スクラムの理解と成⽴に責任を持つ。そのためにスクラムマスターは、スクラムチームにスクラムの理論・プラクティス・ルールを守ってもらうようにする。

スクラムチームは、プロダクトを反復的・漸進的に届ける。これは、フィードバックの機会を最⼤化するためである。「完了」したプロダクトを漸進的に届けることで、動作するプロダクトが常に利⽤可能な状態にしている。

（引⽤元：スクラムガイド2011）

メソッド4:プラグマティック・ペルソナ

アジャイル流の臨時ペルソナ。⼀般に臨時ペルソナの安易な利⽤は避けるべきだが、ユーザストーリーを書くためのツールと割り切って使う分には全く問題ない。「正式なペルソナではない」ことが⼀⽬瞭然である点がミソ。デビッド・ハスマンが流⾏らせた。

開発チームが固まったら、プロジェクト計画を立てます。

まず、ユーザの視点で議論を進めるためにペルソナを作ります。ただ、通常のアジャイルUXプロジェクトでは正規のペルソナを作るだけの十分な調査データはありません。

そこで、既知の情報からユーザロールを定義した上で、それらを擬人化して臨時のペルソナを仕立てます。

メソッド5:ユーザストーリー

アジャイル流の要件定義（書）。ハガキ⼤のカードに「誰々として何々したい（および、その理由）」と書き出していくだけ。そんないい加減な要求定義でこの先⼤丈夫か？と⼼配になるかもしれないが、不明な点が出てくれば、その時点で直接聞けばいい、直接答えればいい。ユーザストーリーは対話のきっかけに過ぎない。

次に、ユーザストーリーを使って要求定義を行います。

ペルソナを主語とした「誰々として何々したい（および、その理由）」という短い文章で、要求を小さなフィーチャー単位でカードに記述していきます。

アジャイル開発ではこのユーザストーリー単位で実装します。

メソッド6:プランニングポーカー

⾒積のためのカードゲーム。各プレイヤーはストーリーポイントが書かれたカードを選んで⼀⻫に出す。提⽰したカードに差があれば、そのカードを選んだ理由を説明する。これを何度か繰り返すことで認識の違いを埋めて合意を形成する。なお、カードに書かれているストーリーポイントの数字は「フィボナッチ数列」。

それぞれのユーザストーリーがどれくらいの作業規模なのかを見積ります。

作業時間（人月）ではなく相対的な大きさを示すストーリーポイントという指標を使うのが特徴です。そしてプランニングポーカーというゲーム形式で見積作業を行います。

なお、見積は開発者全員で行いますが、開発に直接携わらない第３者は無責任な口出しをしてはいけません。

メソッド7:ストーリーマップ

⼆次元のプロダクト・バックログ。ワークフロー（横軸）と優先度（縦軸）の２軸にユーザストーリーを配置することでシステムの全体像が把握しやすくなる。さらに⽔平⽅向に”スライス”すると中・⻑期のリリース計画にも使える。アジャイルUX の旗⼿であるジェフ・パットンが考案した。

ユーザストーリーをどんな順番で実装して行くのかを決めます。

このデリバリーシーケンスは単にワークフロー順や費用対効果だけで決めるのではなく、機能の相互依存性や市場の変化など製品に関わる多様な要因を考慮して決めます。デリバリーシーケンスの決定はプロダクトオーナーの最も重要な仕事です。

順序化したユーザストーリーはリストとして管理しますが、単なる一次元のリストではストーリーの関連性が失われ、製品の全体像を見失いがちです。そこでユーザストーリーマップという二次元のリストが用いられるようになりました。

メソッド8:スクラムボード

ソフトウェア開発現場の「カンバン」。タスクの状態を「未着⼿」「着⼿」「完了」の３段階で表⽰する。開発の進⾏状況が⼀⽬瞭然になり、問題が起きればすぐわかる。タスクが全部終わったらストーリーマップから追加のストーリーを持ってくる。タスクが残ったら次のスプリントに回す。スクラム版は決して「ノルマ達成表」ではない。

ファーストリリースに向けて開発を始めます。

アジャイル開発では１～４週間単位のイテレーションという開発期間を定めます。そしてデリバリーシーケンスに従って、その期間内に可能な限りのユーザストーリーを次々と完了していきます。

開発チームの作業の進捗状況はタスクボードで絶えず“見える化”されています。

メソッド9:スケッチボード

超特急のデザイン⼿法。インタラクション設計を１枚の巨⼤な紙の上で終えて、さらに壁から剥がしてクルクルと丸めて持ち運び、関係者によるレビューも出来るという優れもの。⽶国の著名なデザインファーム Adaptive Path 社で考案された。

UIデザインもイテレーションの中で開発と平行して進めます。それに適した手法がスケッチボード法です。

デザインを１枚の巨大な紙の上で行って、さらに壁から剥がしてクルクルと丸めて持ち運び、関係者によるレビューも出来るという優れものです。

レビューが終わったスケッチボードは簡易の画面仕様書になります。

メソッド10:ペーパープロトタイプ

紙で作ったローファイなプロトタイプ。紙とペンしか使わない“超”ローテクなソフトウェア開発⼿法で、主に⼿書きで作成する。紙製ではあるが、少しばかりの芝居⼼を発揮して「指でクリック」したり、フィールドに「鉛筆で⼊⼒」すれば擬似的にソフトウェアの動作を再現可能。

重要かつ複雑な操作を必要とする画面についてはプロトタイピングします。

「バグは設計の初期段階で潰す」というのはソフトウェア開発の鉄則です。

ペーパープロトタイプのような簡便な手法を用いれば、従来ならば到底不可能であったような設計のごく初期段階からユーザテストが実施できるので、開発チームはリスクを大幅に低減できます。

メソッド11:ユーザテスト

ユーザテストの基本はとても単純。ユーザにタスク（作業課題）を提⽰して、その実⾏過程を横で観察するだけ。社内の廊下を歩いている他の部署の社員を捉まえてテストに協⼒してもらうという簡便な”ホールウェイ・テスト”であっても、かなり効果はある。

プロトタイプを作ったら、すぐユーザテストで検証します。

ユーザテストの最大の特徴は、ユーザに“考えていることを話しながら操作してもらう”ことです。これを思考発話法と言います。 そして、 ５人のユーザでテストすれば約８５％の問題点が見つかります。

ただ、正規のユーザテストではイテレーションの期間内に収まらないので、Do-it-yourself方式の軽量なテスト手法を使います。

Demo or Die!

「デモか死か」――⽶MITメディアラボの理念の１つ。理論構築だけではなく、実際に動く試作品を作ってデモを⾒せなければ、その研究は評価されない。メディアラボは1985年にニコラス・ネグロポンテによって設⽴され、2011年には第4代所⻑として伊藤穰⼀が選出された。

各イテレーションの終わりには、実際に製品を動かすデモを行って、関係者からフィードバックを得ます。

POは関係者のフィードバックと開発の進捗状況を勘案して、ユーザストーリーを追加・削除・修正したり、デリバリーシーケンスを変更したりします。 そして次のイテレーションを始めます。

このようなイテレーションを繰り返すことで製品リリースに到達します。

そして、おおよそ３ヶ月から６ヶ月単位でリリースを繰り返しながら、製品とビジネスを成長・拡大させていきます。

樽本徹也 ‐ 利用品質ラボ代表

• UXリサーチャ/ユーザビリティエンジニア• 認定人間中心設計専門家• 認定スクラムプロダクトオーナー（CSPO）• NPO  人間中心設計推進機構 評議員• アジャイルUCD研究会 共同代表

◎人机交互論 ‐ユーザビリティエンジニア的HCI論http://www.usablog.jp/◎アジャイルUCD研究会 ‐リーン/アジャイルUX 新Newshttp://groups.google.com/group/agileucdja?hl=ja◎Facebook ‐樽本徹也https://www.facebook.com/tetsuya.tarumoto

UX/UCDの講演・研修 UX/UCDの社内導入支援 UX/UCDによる製品開発支援

Keep in touch!

簡単・便利なコトづくり応援します。

UX/UCDの講演・研修UX/UCDの社内導入支援UX/UCDによる製品開発支援

東京都台東区下谷1‐11‐15ソレイユ入谷4F