1. アジャイルUX物語
～ 偉大なPOのスピリットとテクニック ～
＜アジャイル UCD研究会＞

2. 全面広告
「ユーザビリティ
エンジニアリング(第２版)」
1章 ユーザ中心設計概論
2章 インタビュー法
3章 インタビューの実践
4章 データ分析法
5章 発想法
6章 プロトタイプ
7章 ユーザビリティ評価法
8章 ユーザテスト
9章 ユーザテストの準備
10章 ユーザテストの実施
11章 分析と再設計
12章 ユーザ中心設計活動
*無料サンプル版（第2章全文）
http://www.slideshare.net/barrelbook/ss‐26183115
全面広告

3. •
•
•
•
•
プロダクトオーナー（PO）は、
製品の明確なビジョンを持つ。
プロジェクトの成功に全面的に責任を
持つ。
変化に適応して選択を行う。
中間成果を受け入れるか、開発チー
ムに差し戻すか決定する。
いつ、どんな内容の製品をリリースす
るか決定する。
早く偉大なPO
になりたい～
アジャイルマニフェスト
我々は、
• プロセスやツールよりも個⼈と対話を、
• 包括的なドキュメントよりも動くソフトウェアを、
• 契約交渉よりも顧客との協調を、
• 計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを認
めながらも、私たちは右記のことがらにより価値をおく。

4. まず、製品コンセプト――「誰のため
に、何を作るのか」――を考えます。
メソッド1:ゲリラリサーチ
手がかりをつかむために簡易的なリ
サーチを行います。人脈をたぐって
様々な人と会ったり、街頭で人々の行
動を観察したり、ちょっとしたアンケート
を実施したりします。
その際に一つコツがあります。それは
「何が欲しいか？」とは決して聞かない
ことです。その代わりに「何か困ってい
ることはないか？」を深く探ります。
“正規軍（調査の専⾨家）”でなくても調査は出来る！
――例えば、⼈脈をたぐってユーザを⾒つけ、Skype でイン
タビューして、結果は⼝頭でチームに伝える。無駄な製品を
作るほど無駄なことはない。「予算が無い、時間が無い」と
⾔って調査をしないのが⼀番リスクが⾼い。

5. 課題が絞り込まれたら、その解決策を
考えます。
メソッド2:ゲームストーミング
ありきたりな解決策では、わざわざ新
たなプロジェクトを立ち上げる価値はあ
りません。これまでに無いユニークなア
イデアを出すためにはブレインストーミ
ングが有効です。
なお、ブレインストーミングには遵守す
べき基本原則があります。それは――
批判厳禁、自由奔放、質より量、便乗
歓迎、視覚化、脱線禁止、１度に１人。
現代のハイテクビジネスにおけるシリコンバレー流企画発想法。
ブレインストーミングを基礎として、そこに「発散→創発→収
束」という各プロセスに適した様々なファシリテーション技法を
集めた発想法のコレクション。いわば「ブレインストーミング
2.0」。

6. プロジェクトを立ち上げる前にアイデ
アを検証します。
メソッド3:コンセプトテスト
ストーリーボードやモックアップを作っ
て“投票”にかけたり、ウェブにフェイク
の製品広告を出して反応を確かめたり
ます。
そして、ユーザから高い評価を受ける
レベルに到達するまで、調査・発想・検
証を繰り返します。
“検証”といっても難しく考えることはない。ちょっとした「お絵か
き」や「⼯作」 で⾃分のアイデアを形にして、みんなに⾒てもら
う・触ってもらう。そして、横で黙って様⼦を観察していれば、
そのアイデアの価値は⾃ずと明らかになる。みんなの（さりげ
ない）意⾒は意外と正しい。

7. 製品コンセプトが固まったら本格的に
開発チームを編成します。
アジャイルな開発チームは自己組織
化されていて、機能横断的です。
自己組織化チームは、作業を成し遂
げるための最善の策を、チーム外から
の指示ではなく、自らが選択します。そ
して機能横断的チームは、チーム外に
頼らずに作業を成し遂げる能力を持っ
ています。
スクラムチーム
スクラムチームは、プロダクトオーナー・開発チーム・スクラムマ
スターで構成される。
• プロダクトオーナーは、プロダクトの価値と開発チームの作
業を最⼤化することに責任を持つ。プロダクトオーナーは、
プロダクトバックログの管理に責任を持つ唯⼀の⼈物であ
る。
• 開発チームは、リリース判断可能な「完了」したプロダクト
のインクリメントを、各スプリントの終わりに届けることのでき
る専⾨家で構成されている。インクリメントを作成できるの
は、開発チームのメンバだけである。
• スクラムマスターは、スクラムの理解と成⽴に責任を持つ。
そのためにスクラムマスターは、スクラムチームにスクラムの
理論・プラクティス・ルールを守ってもらうようにする。
スクラムチームは、プロダクトを反復的・漸進的に届ける。これ
は、フィードバックの機会を最⼤化するためである。「完了」し
たプロダクトを漸進的に届けることで、動作するプロダクトが常
に利⽤可能な状態にしている。
（引⽤元：スクラムガイド2011）

8. 開発チームが固まったら、プロジェクト
計画を立てます。
メソッド4:プラグマティック・ペルソナ
まず、ユーザの視点で議論を進める
ためにペルソナを作ります。ただ、通常
のアジャイルUXプロジェクトでは正規
のペルソナを作るだけの十分な調査
データはありません。
そこで、既知の情報からユーザロール
を定義した上で、それらを擬人化して
臨時のペルソナを仕立てます。
アジャイル流の臨時ペルソナ。⼀般に臨時ペルソナの安易な
利⽤は避けるべきだが、ユーザストーリーを書くためのツールと
割り切って使う分には全く問題ない。「正式なペルソナではな
い」ことが⼀⽬瞭然である点がミソ。デビッド・ハスマンが流⾏
らせた。

9. 次に、ユーザストーリーを使って要求
定義を行います。
メソッド5:ユーザストーリー
ペルソナを主語とした「誰々として
何々したい（および、その理由）」という
短い文章で、要求を小さなフィー
チャー単位でカードに記述していきます。
アジャイル開発ではこのユーザストー
リー単位で実装します。
アジャイル流の要件定義（書）。ハガキ⼤のカードに「誰々
として何々したい（および、その理由）」と書き出していくだけ。
そんないい加減な要求定義でこの先⼤丈夫か？と⼼配にな
るかもしれないが、不明な点が出てくれば、その時点で直接
聞けばいい、直接答えればいい。ユーザストーリーは対話の
きっかけに過ぎない。

10. それぞれのユーザストーリーがどれく
らいの作業規模なのかを見積ります。
メソッド6:プランニングポーカー
作業時間（人月）ではなく相対的な大
きさを示すストーリーポイントという指標
を使うのが特徴です。そしてプランニン
グポーカーというゲーム形式で見積作
業を行います。
なお、見積は開発者全員で行います
が、開発に直接携わらない第３者は無
責任な口出しをしてはいけません。
⾒積のためのカードゲーム。各プレイヤーはストーリーポイント
が書かれたカードを選んで⼀⻫に出す。提⽰したカードに差
があれば、そのカードを選んだ理由を説明する。これを何度か
繰り返すことで認識の違いを埋めて合意を形成する。なお、
カードに書かれているストーリーポイントの数字は「フィボナッチ
数列」。

11. ユーザストーリーをどんな順番で実装
して行くのかを決めます。
メソッド7:ストーリーマップ
このデリバリーシーケンスは単にワー
クフロー順や費用対効果だけで決める
のではなく、機能の相互依存性や市場
の変化など製品に関わる多様な要因
を考慮して決めます。デリバリーシーケ
ンスの決定はプロダクトオーナーの最も
重要な仕事です。
順序化したユーザストーリーはリストと
して管理しますが、単なる一次元のリス
トではストーリーの関連性が失われ、製
品の全体像を見失いがちです。そこで
ユーザストーリーマップという二次元の
リストが用いられるようになりました。
⼆次元のプロダクト・バックログ。ワークフロー（横軸）と優先
度（縦軸）の２軸にユーザストーリーを配置することでシス
テムの全体像が把握しやすくなる。さらに⽔平⽅向に”スライ
ス”すると中・⻑期のリリース計画にも使える。アジャイルUX
の旗⼿であるジェフ・パットンが考案した。

12. ファーストリリースに向けて開発を始
めます。
メソッド8:スクラムボード
アジャイル開発では１～４週間単位の
イテレーションという開発期間を定めま
す。そしてデリバリーシーケンスに従っ
て、その期間内に可能な限りのユーザ
ストーリーを次々と完了していきます。
開発チームの作業の進捗状況はタス
クボードで絶えず“見える化”されていま
す。
ソフトウェア開発現場の「カンバン」。タスクの状態を「未着
⼿」「着⼿」「完了」の３段階で表⽰する。開発の進⾏状況
が⼀⽬瞭然になり、問題が起きればすぐわかる。タスクが全
部終わったらストーリーマップから追加のストーリーを持ってくる。
タスクが残ったら次のスプリントに回す。スクラム版は決して「ノ
ルマ達成表」ではない。

13. UIデザインもイテレーションの中で開
発と平行して進めます。それに適した
手法がスケッチボード法です。
メソッド9:スケッチボード
デザインを１枚の巨大な紙の上で
行って、さらに壁から剥がしてクルクル
と丸めて持ち運び、関係者によるレ
ビューも出来るという優れものです。
レビューが終わったスケッチボードは
簡易の画面仕様書になります。
超特急のデザイン⼿法。インタラクション設計を１枚の巨⼤
な紙の上で終えて、さらに壁から剥がしてクルクルと丸めて持
ち運び、関係者によるレビューも出来るという優れもの。⽶国
の著名なデザインファーム Adaptive Path 社で考案された。

14. 重要かつ複雑な操作を必要とする画
面についてはプロトタイピングします。
メソッド10:ペーパープロトタイプ
「バグは設計の初期段階で潰す」とい
うのはソフトウェア開発の鉄則です。
ペーパープロトタイプのような簡便な
手法を用いれば、従来ならば到底不可
能であったような設計のごく初期段階
からユーザテストが実施できるので、開
発チームはリスクを大幅に低減できま
す。
紙で作ったローファイなプロトタイプ。紙とペンしか使わない
“超”ローテクなソフトウェア開発⼿法で、主に⼿書きで作成
する。紙製ではあるが、少しばかりの芝居⼼を発揮して「指
でクリック」したり、フィールドに「鉛筆で⼊⼒」すれば擬似的に
ソフトウェアの動作を再現可能。

15. プロトタイプを作ったら、すぐユーザテ
ストで検証します。
メソッド11:ユーザテスト
ユーザテストの最大の特徴は、ユー
ザに“考えていることを話しながら操作
してもらう”ことです。これを思考発話法
と言います。 そして、 ５人のユーザで
テストすれば約８５％の問題点が見つ
かります。
ただ、正規のユーザテストではイテ
レーションの期間内に収まらないので、
Do-it-yourself方式の軽量なテスト手
法を使います。
ユーザテストの基本はとても単純。ユーザにタスク（作業課
題）を提⽰して、その実⾏過程を横で観察するだけ。社内
の廊下を歩いている他の部署の社員を捉まえてテストに協
⼒してもらうという簡便な”ホールウェイ・テスト”であっても、か
なり効果はある。

16. 各イテレーションの終わりには、実際
に製品を動かすデモを行って、関係者
からフィードバックを得ます。
Demo or Die!
POは関係者のフィードバックと開発の
進捗状況を勘案して、ユーザストーリー
を追加・削除・修正したり、デリバリー
シーケンスを変更したりします。 そし
て次のイテレーションを始めます。
このようなイテレーションを繰り返すこ
とで製品リリースに到達します。
そして、おおよそ３ヶ月から６ヶ月単位
でリリースを繰り返しながら、製品とビジ
ネスを成長・拡大させていきます。
「デモか死か」――⽶MITメディアラボの理念の１つ。理論
構築だけではなく、実際に動く試作品を作ってデモを⾒せな
ければ、その研究は評価されない。メディアラボは1985年に
ニコラス・ネグロポンテによって設⽴され、2011年には第4代
所⻑として伊藤穰⼀が選出された。

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. 簡単・便利なコトづくり応援します。
 UX/UCDの講演・研修
 UX/UCDの社内導入支援
 UX/UCDによる製品開発支援
東京都台東区下谷1‐11‐15 ソレイユ入谷4F