アジャイル UX 特別号—アジャイル UX カード付き！

written by 樽本徹也、川口恭伸

  EM Agile UX 01

 EM Agile UX Special Issue
目次̶Contents
UX（ユーザーエクスペリエンス）とは …………… 2
UCD（ユーザー中心設計）は 尻尾の先 から始めよう！…………… 3
UCDヒストリー …………… 4
そのUCD、間違ってます！ ！…………… 6
アジャイルUXカードの使い方 …………… 6
アジャイルUXカード …………… 7
アジャイル開発とUX（UCD）…………… 15
現実の「痛み」を知るモノづくりが、優れたUXを生み出す ……………15
Agile Conference報告̶UXを中心に ……………16

UIで事態は改善しない
UX（ユーザーエクスペリエンス）とは  UX（User eXperience:ユーザーエクス
ペリエンス）とは？専門家による百家争
アジャイルUX特別号の 鳴の議論はさておき、ソフトウェア開
刊行によせて
発の現場では
「UXとはUI（User Interface：
 本誌はアジャイル界で話題になりつ 画面）
」のことです。実際、開発者の多
つあるUX（ユーザーエクスペリエンス） くは「
（なるべく）良い画面を作ろう」
の特別号です。ユーザーの価値を最大 と日々努力していると思います。しか
化するアジャイルに、ユーザーの使い し、その努力はあまり報われていない
勝手全般の改善をカバーするUXの考え のではないでしょうか。それは、努力
方を導入することにより、一層洗練さ が足りないから？センスが悪いから？
れた開発を実現できます。 それともデザインのスキルが足りない
 UXとその方法論であるUCD（ユー から？
ザー中心設計）の基本を紹介する記事  開発者の地道な努力に水を差すわけ
とともに、UXを手軽に体験できる「ア ではありませんが、そもそもUIを議論
ジャイルUXカード」を掲載しています。 している限り事態はそれほど改善しま
記事を読んだ後は、7から14ページを せん。それは表面的な問題に過ぎない
真ん中のホチキスから取り外して、一 からです。
枚一枚に切り取り、様々なアジャイル  UXの構造を表した有名なモデルがあ
UX活用シーンをシミュレーションして ります。ユーザーから見えるのは表層
いただければ幸いです。 であるUIだけですが、
そのUIを 剥がす
と、そこには骨格が現れます。その骨
格は構造に支えられています。さらに、
その構造は要件から導かれており、そ
の要件は戦略に基づいています。それ
がジェス・ジェームス・ギャレットが提
唱した『The Elements of User Experience̶
User-Centered Design for the Web』
（Peachpit
Press、 （図1）です。
ISBN-13：978-0735712027）
UX全体を見よう
 このモデルを見れば、表層レベルで
あるUIだけで対応できる課題はごく限
られることは明白です。UXに関わる多
くの課題は骨格や構造レベルで検討し
なければいけません。場合によっては
大元（つまり戦略レベル）に立ち返っ
て再設計しなければいけないこともあ
るでしょう。
 UIは 一 見 す ると「1枚 の 絵 」で す。
ちょっと センス のいい人に頼めば、
サラサラと描き上げてもらえそうに思

■アジャイルUX特別号プロトタイピングの様子
（今回のアジャイルUXカードの 開発 もUCDライクに行いました。写真は著者の樽本、川口による
ブレインストーミングセッションの様子です。 ）

02 EM ZERO Vol.5

 ■図2 UCDの基本パターン
（調査、分析、設計、評価、改善、反復）
❶
������� �������（表層） 調査
❷
�������� ��������（骨格） 分析

���������（構造） ❸
��������� 設計
■ 図1  ジェス・ジェーム ス・ギャレットが
�����（要件） 提 唱したユーザーエクスペリエンスの5要素 ❹ ❻ ❺
����� （『ウェブ戦略としての「ユーザーエクスペリエ 評価 反復 改善
ンス」̶5つの段階で考えるユーザー中心デ
�������� ��������（戦略） ザイン』毎日コミュニケーション、ISBN-13：
978-4839914196、より）

うかもしれません。しかし、本来は、 チンのUsage Centered Designも、

アラン
・ きます。初めてUCDに取り組むと、多
そこにはすべての要素（ユーザーニー クーパーのGoal-Directed Designも、い
ズやビジネスゴール、技術要件など） ずれもがUCDの範疇に入ります。ただ、
が凝縮されているのです。決して、シ そこには骨格となるような共通したパ
ステムができあがってから 上 に被 ターンがあります。それは以下のよう
せるものではありませんし、従来のい なものです（図2）
。 ようなものなのです。
わゆる デザイナーさん 一人の手に
負える代物でもありません。
①調査：ユーザーの 利用状況 を把
 冒頭で書いたとおり、ソフトウェア 握する。
開発の現場ではUIとUXは事実上同義語 ②分析：利用状況から 真のユーザー
として扱われています。しかし、UI（表 ニーズ を探索する。
層）だけに目を奪われてはいけません。 ③設計：ユーザーニーズを満たすよう
私たちが議論すべきなのはUX全体なの な 解決案（ソリューション）を作る。
です。 ④評価：解決案を 評価 する。
⑤改善：評価結果をフィードバックし
て、解決案を 改善 する。
UCD（ユーザー中心設計）は
⑥反復：評価と改善を 繰り返す 。
尻尾の先 から始めよう！
UCDの手順 初めてUCDを行う場合
「技術優先の考えや作り手の勝手な  ただ、
これを見て「早速、
次のプロジェ
思い込みを排除して、常にユーザーの クトでは調査から始めなくては」と思っ
視点に立って設計を行おう」
。それが た人は、ちょっと待ってください。あ
『UCD（User Centered Design：ユーザー なたが、これまでUCDとまったく無縁
中心設計）
』です。 であった場合は、いきなり上記①∼⑥
 UCDとは設計思想のひとつであり、 のプロセスをフル規格で導入するのは
個々の手法を指すものではありません。 難しいかもしれません。
ヤコブ・ニールセンのDiscount Usability  何事も最初は試行錯誤の連続です。
も、ジョン・キャロルのScenario Based 「失敗は成功の元」とは言いますが、そ
Designも、カレン・ホルツブラットの うやって時間とコストを消費する間に、
Contextual Designも、ラリー・コンスタン 刻々と期日と予算のリミットは迫って
くの場合はプロセス全体を完了できな
いでしょう。それはたとえるならば、
「最
高の素材を選んで念入りに下ごしらえ
したのに、最後に生焼けで料理を出す」
 そうならないためには、最初は プ
ロセスの後半 から始めてください。プ
ロトタイプでテストを行えば、設計の
早い段階で問題点を発見して修正でき
ます。的外れなアイデアを実装して、
ユーザーにとって使い物にならないア
プリケーションを作ってしまうというリ
スクを回避できます。
地道な活動から始めよう
 立派な大人が紙芝居（ペーパープロ
トタイプ）を作成して、オフィスの片
隅でテストを繰り返していると、一見
するとレベルの低い活動を行っている
ように感じるかもしれません。しかし、
こういった地道な活動が具体的な成果
を生んで、UCDの本当の価値がチーム
メンバーや社内に認められるようにな
るのです。
 エスノグラフィやペルソナを導入す
るのは、プロトタイプでテストすると
いう 文化 が社内に根付いてからで
も遅くありません。

  EM Agile UX 03

UCDヒストリー 業効率の向上、事故の防止などが良いMMIの条件でした。

 UCDの始まり̶それは第二次世界大戦までさかのぼり
1980年代中頃∼2000年
ます。戦時中、アメリカでは戦闘機パイロットの操縦ミ
̶UIとユーザビリティの時代
スを減らすための研究をしていました。これが後に「人

間工学」へと発展します。その研究対象は軍事から民生  1988年にドン・ノーマンは、日常の 使いづらいモノ

品へと拡がっていきました。 について認知心理学的な視点で考察したユニークな著書

『誰のためのデザイン？』
（新曜社、ISBN-13：978-47885
1950年代∼1980年代初頭
03625）を発表しました。この本の中でノーマンは「ユー
̶マン・マシン・インターフェイスと
人間工学の時代 ザー中心設計（UCD）
」を提唱しました。

 ひと昔前、
UIは「マン・マシン・インターフェイス（MMI）
」  ちょうどその頃、パソコンが本格的な普及期を迎えま

と呼ばれていました。確かに自動車の計器パネルや生産 す。パソコン（およびPC用ソフトウェア）はそれまで人

機械の制御盤は マシン と言ったほうがしっくりきます。 類が手にした道具の中で、最も操作が複雑なもののひと

それに、当時のユーザーは必ずしも お客様 ではあり つだったかもしれません。ところが、 普通 のユーザー

ませんでした。MMIを操作するユーザーの多くは専門の はあまり勉強熱心ではありません。そこで、製品をなる

オペレータや自社の従業員などだったのです。 べく「初めての人でも使用可能（usable＝use＋able）
」

 当然ながら、MMIは必要最小限̶要するに「人に害を なレベルにするために ユーザビリティ が注目される

及ぼさない」レベルで十分でした。訓練期間の短縮、作 ようになりました。

04 EM ZERO Vol.5

 さらに、1990年代中頃からインターネットが急速に  21世紀に入ってお手本となる成功事例が現れました。

普及します。それまでのPC用ソフトウェアと違ってユー 「iPod」です。この成功をきっかけにして、UXは具体的

ザーはWebサイトを購入・所有しません。使用するだけ に目指すべきゴールとして広く認識されるようになりま

です。もし使いづらいと感じれば、
ユーザーは ワンクリッ した。そして、その仕掛け人としてデザイナー（特にイ

ク で立ち去ってしまいます。そのため、
特に Webユー ンタラクションデザイナー）が注目されるようになりま

ザビリティ の重要性が認識されるようになりました。 した（なお、インタラクションデザインという言葉自体はビル・

モグリッジが1980年代に命名したと言われています）
。
2000年代初頭∼現在
 ほほ同時期にアジャイル開発のムーブメントが起こり
̶インタラクションと
ユーザーエクスペリエンス（UX）の時代 ました。当初は「アジャイルとUXは相反する」との見方

 1990年代中頃、当時、アップルで副社長を務めてい もありましたが、開発現場で試行錯誤を繰り返す中から

たドン・ノーマンが新たに「ユーザーエクスペリエンス アジャイルUX または アジャイルUCD が徐々に認

（UX）
」を提唱しました。個々の製品の使い勝手の改善に められるようになりました。2008年のAgile Conference

とどまらず、
「ユーザーの中長期的な利用体験全体をよ からはAgile UXが独立したステージで開催されるように

り魅力的なものにしよう」というのです。ただ、あまり なっています。2010年代は アジャイルとUXの時代 に

に壮大な理念なので、ノーマンの在職中には大きな成果 なるかもしれませんね。

にはつながりませんでした。

  EM Agile UX 05

「ユ
ーザー中心なんて当たり前！」
。  発想を転換しましょう。すべてのユー
これが事実ならば喜ばしいこと ザーのためにデザインするのではなく
ですが、残念ながら、未だに多くのプ 「一人のユーザー」のためにデザインし
ロジェクトが「使われない製品」を生 ましょう（これが「ペルソナ」の基本
み出しているのも事実です。失敗の原 原理です）
。
因は様々だと思いますが、もしかして、
そもそも「ユーザー」を間違えていま ●ユーザーの声

ユ
せんか？ ーザーの声を重視すると言うの
は、極論すれば単なるユーザー
●自分 任せに過ぎません。プロの開発者の本

あ
なたはユーザーではありません。 場の最前線で部下を指揮管理していま 来の役割とは、ユーザーから提案して
そもそも企画者や開発者である すが、やはり、あなたが作るシステム もらうことではなくユーザーに提案す
「あなた」は普通のユーザーとはかけ離 のユーザーではありません。 ることです。ユーザーから出された「○
れています。それなのに「自分のこと  UCDにおけるユーザーとは「エンド ○が欲しい」といった明示的要求に応
は自分が一番よくわかっている」ので、 ユーザー本人」のことです。オフィス えるだけでは不十分です。ユーザー自
自分のアイデアや価値観を強く主張し で革張りの椅子に座っている人に聞い 身が気づいていないような暗黙の要求
てしまいます。それを開発チーム全員 ても本当のことはわかりません。それ まで満たしてこそ、プロとしての存在
がやったらどうなるか？̶忌まわしい よりも現場に行って直接本人に聞きま 価値があるのです。
「デスマーチ」の序曲の始まりです。 しょう。  そのためには、ユーザーの声ではな
 まず、あなたをユーザーから外しま くユーザーの行動を分析しましょう。
しょう。ついでに、あなたの家族、恋人、 ●すべてのユーザー ユーザーの声は、既にユーザー自身が

「コ
友人も外しましょう。なぜなら、あな ンバーチブルのバンでオフロー 分析した結果なので、もはや新たな発
たは彼らのことを「知ってるつもり」 ド仕様のクルマ」
。もし1台の車 見はありません。一方、行動はまだ分
に過ぎないからです。 ですべてのユーザーのニーズに応えよ 析されていない生データなので、それ
うとすれば、そんなデザインになって を慎重に分析すれば暗黙のニーズを探
●顧客と代理ユーザー しまうかもしれません。もちろん、そ 索することができるのです。

C
IO、情報システム部長、経営企画 んな車は存在しないし、存在したとし  驚くなかれ、
UCDの第1原則とは「ユー
室長̶彼らは大切な お客様 で ても誰も買わないでしょう。すべての ザーの声聞くべからず」なのです。
すが、
あなたが作るシステムのユーザー ユーザーを対象に製品を設計するとい
ではありません。総務課長、営業第一 うのは同様の間違いを犯していると言
課長、マーケティング室長̶彼らは現 えます。

アジャイルUXカードの使い方

 本紙の7∼14ページは、アジャイルUXを簡単にシミュレー
ションするためのアジャイルUXカードになっています。
 カードは、
・アジャイルUXアクターカード（A01∼10）
：10枚
・アジャイルUXカルチャーカード（C01∼05）：5枚
・アジャイルUXメソッドカード（M01∼16）
：16枚
・？（APPENDIX）
：1枚
の4種類、計32枚です
 アジャイルUXカードは、次のような流れでご活用ください。
③カードは全部で32枚。1枚1枚丁寧に切り取ろう。
④メンバーにアクターカード（オレンジ）を割り当てよう。
⑤該当する人がいない場合は誰かが代理になろう。
⑥裏側の説明を見ながら、カルチャーカード（ピンク）から採
用するものを選ぼう。
⑦裏側の説明を見ながら、メソッドカード（グリーン）から採
用するものを選ぼう。
⑧目立つところに選んだカルチャーカードとメソッドカードを
貼り出そう。
⑨時々、採用するカルチャーとメソッドを見直そう。
⑩プロジェクトが終わったらふりかえりをしよう。

①EM ZEROをもらおう！  ほかにも読者の皆さんの力で、活用の仕方をいろいろ考えて

②内側8ページ（7∼14ページ）を取り外そう。 みんなに教えてください！

06 EM ZERO Vol.5

バーンダウンチャート／ スクラムボード／ プランニングポーカー／ 朝会（デイリースクラム）／
Burn Down Chart Scrum Board Planning Poker Asakai（Daily Scrum）
期間中の残作業量をプロットしたグラ タスクの状態を
「To Do（未着手）
」「Do チームで規模を見積もるカードゲー 毎日決まった時間に行う短いミーティ
フ。縦軸に残作業、横軸に残り日数。 ing（着手）
」「Done（完了）
」に分類 ム。2002年にジェームズ・グレニン ング。チーム全員が参加し、メンバー
作業を進めるごとに残作業は減ってく して表示するボード。現在の進行状況 グが最初に紹介し、マイク・コーンが の状況を相互確認する。次の3点を全
ため、グラフは通常、右下がりになる。 が共有でき、滞留しているタスクがあ 有名にした。各プロダクトバックログ 員が一人ずつ報告する。
「1．前回以
初日の残作業量から最終日の残作業 ればすぐわかる。朝会の報告では、こ （M05）項目の見積もりに使う。まず 降の進捗（完了したこと）
」「2．次回
量0まで引いた直線が理想線。理想線 のタスクを見ながら行うとよい。チー 基準となる項目を決め、規模を2とす までに終えること」
「3．実施上で障害
からプロットが離れたら、計画と進捗 ムごとに工夫して自分なりのタスク る。他の項目について、各プレイヤー になっていること」
。報告内容に対す
がずれた可能性を示すサイン！チーム ボードを作っていく。付箋紙を使う場 が基準項目に対する相対的な規模に る議論は行わず、別にフォローアップ
メンバーで状況を話し合おう。 合は強粘着タイプがオススメ。 対応するカードを選び、一斉に場に出 ミーティングを設ける。
す。選んだ数値に差があれば、その
数値に決めた理由を説明する。スピー
ディに繰り返すことで、認識の差異を
埋めていく。
ペルソナ／ Personas ユーザーストーリー／ スプリントレビュー／ プロダクトバックログ／
設計を支援するために設定する仮想
User Story Sprint Review Product Backlog
のユーザー像のこと。名前や顔写真も 顧客やユーザーにとって、システムを スプリントの終了時点で、プロダクト 要件を優先度順に並べたリスト。項目
用意して、実在の人物であるかのよう 使って何を成し遂げたいのか、わかり オーナーをはじめ顧客や関係者に集 として、
「説明」
「優先度（重要度）
」「規
に描く。アラン・クーパーが著書の中 やすい文章で表現したもの。形式は
「○ まってもらい、スプリントレビューを 模」
「完了の定義（デモ方法）
」を記述
で紹介して以来、徐々にその価値が認 ○として、 をする」で、○○は操作 行う。チームメンバーが報告を行い、 する。説明はユーザーストーリーなど
められ、現在ではWebサイト開発か や実行の主体であるペルソナ（M08） 参加者のフィードバックをもらう。成 で、開発チームによって実現可能なも
らマーケティングまで幅広く用いられ など。マイク・コーンによると、良い 果物は「リリース可能」である必要が のである必要がある。優先度はプロダ
るようになっている。ただし、
「ペル ユーザーストーリーが持つ条件は、
「一 あり、実装やテストなど、リリースに クトオーナーが顧客価値に基づいて決
ソナを作って、それからどうするのか」 つひとつのストーリーは相互に独立し 必要な品質を備えている必要がある。 定する。規模はチームがプランニング
という確かな戦略を持っていないと、 て実現できること」
「詳細に書き過ぎ 報告の準備に時間をかけてはならない ポーカー（M02）で見積もる。完了の
宝の持ち腐れに終わる。 ないこと」
「顧客やユーザーにとって し、パワーポイント資料を使ったプレ 定義はプロダクトオーナーや顧客が受
価値のあることを書くこと」
「チーム ゼンテーションは行わない。プロダク け入れる条件を示す。バックログへの
にとって実現可能で見積もることがで トバックログに基づき、チームの状況 項目の追加や優先度変更はいつ行って
きること」
「十分に小さいこと」
「テス をなるべく正確に伝える必要がある。 もよいが、当該スプリントの終了まで
ト可能であること」
。 は、原則、有効にならない。
スクラムマスター／ プロダクトオーナー／ 顧客／ Customer ユーザー／ User
Scrum Master Product Owner サービスを購入決定する。お客様。利 製品を実際に利用する。ユーザー中心
プロセスの調整役であり、陰の推進役。 製品のコストと収益に責任を持つ。高 用者であるユーザー（A01）とは区別 設計では、ユーザーにとって使いやす
チームのメンターとして、メンバーを い価値を持つ製品を定義し、それを する。アジャイル開発手法では最重要 い製品を提供するための様々な手法や
励まし、メンバー自身による問題点の 妥当なコストで実現するために、優 の利害関係者（ステークホルダー）と 哲学が定義されている。ユーザーにつ
認識と解決を促す。
「マスター」と言 先度を決定し、プロダクトバックログ 定義されており、ユーザー中心設計で いて知ったかぶりをせず、ユーザーが
うと偉そうだが、製品に対しては、何 （M05）で表現する。プロダクトオー もステークホルダーとして考慮する。 本当に求めていることは何か？製品を
の権限も持たない。従来のリーダーの ナーは、2つの説明責任を持つ。チー 法人向け製品や受託開発では、顧客で 使ったときにどう感じるか？を真摯に
役割を、プロダクトオーナー（A03）
、 ムメンバーに対しては、製品のコンセ あるIT部門や企画部門と、ユーザーの 探求し、真に必要とされる、満足度の
チーム、スクラムマスター（A04）の プトやプロダクトバックログの内容に 利害が一致しない場合もある。 高い製品を目指したい。なお、製品を
3つの役割に分散した点が、スクラム ついて説明する。ユーザー（A01）お 購入する人は顧客（A02）として、
ユー
の特徴の1つ。 よび顧客（A02）に対しては、製品の ザーとは区別する。
実現するメリットとコストや不確実性
について説明する必要がある。
インタラクションデザイナー／ テスター／ Tester プログラマー／ ビジネスアナリスト／
Interaction Designer 品質保証（QA）のためのテストを行う。
Programmer Business Analyst
デザイナーというよりは「設計士」
。 製品のリリースのためには多種多様な 製品の設計や実装を担う。製品の見 顧客のニーズ（ビジネスニーズ）を
VisioやOmniGraffleといった 現 代 の テスト̶例えばユニットテスト、結合 積り、設計、実装、品質に責任を持つ。 分析してシステム要件に落とし込むの
製図機 を駆使して、ビジネスフロー テスト、パフォーマンステスト、負荷 積極的にプロダクトオーナー（A03） は「要求分析屋さん」と同じだが、ビ
やコンセプトを図式化したり、UIの設 テスト、セキュリティテスト、ユーザ やユーザー（A01）と対話し、製品に ジネスアナリストの守備範囲はもっと
計図である画面フロー図やワイヤー ビリティテストなど̶が必要で、適切 求められる要件の本質を理解し、実 広い。いわゆる「 超 上流工程」か
フレームなどを作成する。インタラク に設計できるスキルを持つ。テストの 現する。日本の旧来のシステム開発で ら参加して、プロジェクトを立ち上げ
ションデザイナーという名称は多少バ 自動化を進め、
TDD（テスト駆動開発） は、プログラマーは定められた仕様を るかどうかの判断に寄与し、さらにプ
ズワーズ（流行語）のきらいがあるが、 やCI（継続的インテグレーション）な コード化するだけの単純労働者だった ロジェクト終了後は成果の検証まで行
本当に優秀なインタラクションデザイ どを利用し、より早期に問題が発見で が、スクラムをはじめとするアジャイ う。ただし、ナントカ総研の「○○ア
ナーはUXチームで中心的役割を果た きるようにしたい。チーム内で完結す ル開発プロセスでは、システムを実現 ナリスト」の仕事の尻ぬぐいをさせら
す。なお、
ウェブデザインの場合は「情 るテストの比率を高めることで、より することによって解決する課題に着目 れた経験がある開発者からは、ちょっ
報アーキテクト」と呼ぶことが多い。 変化に対応しやすくなる。 する、能動的な改革者にならなければ と疎まれる傾向がある。
ならない。
イテレーティブで ユーザー中心／ ユーザビリティエンジニア／ UIデザイナー／ UI Designer
インクリメンタル／ User Centered Usability Engineer ちょっと古い言い方をすれば、いわゆ
Iterative and Incremental ソフトウェアの設計思想のひとつ。端 UX特有の職種。元々はできあがった る「デザイナーさん」
。通常、Photosh
イテレーティブとは、
「繰り返し」作 的に言えば「靴に足を合わせる」の 製品の検査業務を担当していたが、そ opとIllustratorのかなりの使い手であ
業を行い、徐々に高めていくこと。作 ではなく「足に合う靴を作る」という れでは「もはや手遅れ」なので、現在 る。ただし、現代では単なる 絵描き
業を大きな単位で一度に行う代わり ことになる。経営やマーケティングの では設計の上流工程から参加するよう では務まらない。芸術やプロダクトデ
に、作業を分割して細かい単位で繰り 「マーケットイン」や「アウトサイドイ になった。ソフトウェア開発における ザインの専門教育をベースに、UIデ
返し行う。繰り返すことで、徐々に製 ン」も類似した概念。いずれにしても、 「テスター」の役割と似ているが、 生 ザインガイドラインやデザインパター
品やプロセスに関する学習が進み、不 至極当たり前の理念である。しかし 身 のユーザーを扱う点が大きく異な ンに精通し、HTML/CSSに加えJava
確実性が低減し、予測性が向上する。 ながら、言うは易く行うは難し。強い る。ユーザーと対話する高いスキルを ScriptやAction Scriptなどのプログ
インクリメンタル（漸進的）とは、少 意志とちゃんとした技術がないと、単 有しており、人間工学や認知心理学の ラミングスキルを有する。
しずつ積み重ねるように機能実装して なるスローガンで終わってしまうので 専門知識をバックボーンに持つ人も多
いくということ。自動化テスト技法や ご注意を。なお、
「人間中心（Human い。
バージョン管理システムを取り入れる Centered）
」は同義語。
ことで、手戻りの少ない開発を行う。
タイムボックス化／ 全員同席／ Sit Together 早期失敗／ Fail Fast 見える化／ Visualization
Time Boxed チームを構成する全員が同じ場所で 「私は失敗したことはない、何万通り 「見える化」はトヨタ生産システムで使わ
アジャイル開発では、一定期間（1週 作業をすること。コミュニケーション のうまくいかない方法を発見しただけ れている用語。カンバンや付箋紙などを
間から4週間）ごとに、リリース可能 を促進し、チームの自己組織化とチー だ」
（エジソン）
。未知のものに対して 使って、状態を「いつでも」
「誰にでも」
「簡
なソフトウェアを提供する。この一定 ムワークを促進する。また、見える化 精度の高い予測を行うことは不可能 単に」見えるように保つ。コミュニケーショ
期間のことを、スプリントないしイテ （C03）をローコスト、ローテクで実 で、無理に計画に織り込もうとすれ ンロスを減らし、手戻りのリスクを下げ、
レーションと呼ぶ。想定よりも早く進 現しやすくなる点も重要。同じ場所に ば、大きな不確実性バッファが必要に ユーザーや製品ビジョンを確認できるよう
めば、次の優先度の作業に取りかかれ いることで、壁に状況を書いた紙を貼 なる。早めに試し、その後に計画を動 にする。具体的な手法は、スクラムボード
るかどうか検討する。想定より遅れた るだけで、みんなが好きなタイミング 的に変更するのが科学の心。一方で、 （M03）
、バーンダウンチャート（M04）
、
場合は、間に合わない作業を分割する で確認でき、更新もタイムリーに行え 重大な問題事象を早期に発見すること プロダクトバックログ（M05）
、ペルソナ
か、行わないことの了承を得る。日々 る。 で、プロジェクト全体の失敗の可能性 （M08）
、ペーパープロトタイプ（M10）
の作業もタイムボックス化し、遅れた を減らすことができるので顧客価値も など。
分を残業でカバーする、ということは 高い。壮大な実験や失敗にユーザーを
行わない。タイムボックス化によって、 巻き込まないようにする。利害関係者
チームの作業条件が安定し、生産能力 への説明責任を果たすことも重要。
を計測しやすくなる。
 ユーザーテスト／ インスペクション／ ペーパープロトタイプ／ 本質的ユースケース／
User Testing Usability Inspection Paper Prototyping Essential Use Case
ユーザーテストの基本はとても単純。 別名「専門家による評価」
。要するに 紙で作ったローファイ（低忠実度）な UI設計を支援することを意図した2列
ユーザーにタスク（作業課題）を提示 鑑定士 による 目利き 。ユーザー プロトタイプ。紙とペンしか使わな の表形式のユースケース。ユーザー
して、その実行過程を横で観察する インタフェースやユーザビリティのプ い 超 ローテクな手法で、主に手描 とシステムの対話を高レベル（抽象
だけ。ヤコブ・ニールセンが「5人の ロが自らの知識や経験に基づいて行う きで作成する。紙製ではあるが、指で 的）なシナリオで記述する。このシ
ユーザーでテストすれば約85％の問 評価手法の総称。UIデザインの原理 クリックしたり、鉛筆でフィールドに ナリオを分析することで、対話に必
題点が見つかる」という法則を提唱し 原則を引用しながら評価する「ヒュー 入力することで擬似的にソフトウェア 要な画面要素を論理的に定義できる。
て以来、UIをテストするための最も強 リスティック評価」と、操作ステップ の動作を再現可能。類似した手法は 元々はレベッカ・ワーフス・ブロック
力で効率的な手法となった。なお、最 ごとのユーザーの行動を推測して評価 何十年も前から存在しているが、キャ がシステム設計のために発案したも
近は「RITEメソッド（Rapid Iterative する「ウォークスルー」の2つの手法 ロリン・スナイダーが専門書（
『ペー のを、ラリー・コンスタンチンがUIデ
Testing and Evaluation)」と呼 ば れ が代表的。 パープロトタイピング 』オーム社、 ザインに応用して発展させた。詳し
る、さらに高速反復型のテストが主流 ISBN-13：978-4274065668）を著 くは『使いやすいソフトウェア̶より
になっている。 したことがきっかけで、ソフトウェア 良いユーザーインタフェースの設計
開発の現場でも広く認知されるように を目指して』
（共立出版、ISBN-13：
なった。 978-4320097469）を参照のこと。
アジャイルUCD研究会／ UIデザインパターン／ ストーリーボード／ 師匠と弟子／
AgileUCDja UI Design Pattern Storyboards Master/Apprentice Model
アジャイル開発とユーザビリティの UIをデザインする上で共通するような 製品のコンセプトやアイデアを 見え いわゆる 要件獲得 のために行う
プロがコラボレーションして生まれ 課題に対するベストプラクティス（お る化 するためのドキュメント。映画 ユーザーインタビューの手法。ただし、
た『アジャイルUCD研 究 会 』
。メン 手本となるような解決策）を集めたラ やアニメーションを製作する際に用い 従来のやり方ではうまくいかないこと
バーは、日本におけるアジャイルUCD イブラリー。
「課題」
「解決例（UI例）
」 る「絵コンテ」と同じ。UIの細部には はご存じの通り。そこで、ユーザーを
活動をリードすべく、知識と技術の 「適用場面」
「デザインの根拠」など 言及せず、ユーザーとシステムのおお 師匠に見立てて「ユーザーに弟子入
研鑽に励んでいる。読書会、ワーク が 簡 潔に記 述され ている。
「Yahoo! まかなやり取りの様子を数コマのイラ り」するつもりでインタビューすると
ショップ、懇親会などオフラインイベ Design Pattern Library」など複数の ストを使って表現する。なお、製品の いう、エスノグラフィ（文化人類学）
ントも開催。興味のある人はサイト ライブラリーがネット上で公開されて 基本概念を簡潔に表現する場合は「コ 由来のテクニックを使う。正式名称を
（http://groups.google.co.jp/group/ いる。書籍ではジェニファー・ティッ ンセプトマップ」を使う。 「Contextual Inquiry（現 場調査 法）
」
agileucdja/）
にアクセス、
または「Agile ドウェルの『デザイニング・インター と言う。カレン・ホルツブラットが開
UCD」で検索！ フェース』
（オライリー、ISBN-13： 発した。
【代表者】川口恭伸（認定スクラムマ 978-4873113166）が有名。
スター）
、樽本徹也（ユーザビリティ
エンジニア）
アジャイル開発とUX（UCD）
ユーザーエクスペリエンス （UX）は
Agile Conferenceでもホットなテーマ
「アジャイル開発」という単語は2001
年、先進的な開発手法の主導者が集
まって発明されました。
「人間中心設計」
がISOで制定されたのは1999年。2つと
も、製品開発手法のコンセンサスとし
て徐々に認知度が高まってきました。
 アメリカで毎年行われているアジャ
イル開発の国際会議「Agile Conference」
に、
「ユーザーエクスペリエンス（UX）
」のトラックが作られたのは2008年の
こと。翌年、2009年には、ユーザビリ
ティの国際会議「UPA」に「アジャイ
ルUX」のトラックが作られ、アジャイ
ルとUX（UCD）のクロスオーバーは近
年のソフトウェア開発のなかでも最も
ホットなトピックのひとつとなりまし
た。
 アジャイル開発技法は、ソフトウェ
ア工学の領域とビジネス領域を、より
うまく連携させる仕組みです。見える
化や実測駆動で、品質と価値の高いソ
フトウェアを安定的に生み出すことを
目指しています。一方で、ユーザー中
心設計(UCD)は、ビジュアルデザイン
領域とソフトウェア工学領域をうまく
連携させ、より高いビジネス価値を妥
当なコストで生み出すための取り組み
といえます。この2つを組み合わせる
ことは、
「動作する、手放せないほど価
値の高い、ソフトウェア」を生み出す
ための必然といってよいのではないで
しょうか。
多様化するニーズに
自己組織的に対応する
 個人の時代̶̶インターネットや、
消費者の趣向の多様化によって、ネッ
ト上のクチコミやニッチ情報でモノが
売れる時代になってきました。企業の
販売戦略や組織戦略も1990年代とは大
きく変わり、組織的販売戦略から、個
人への権限委譲が進んでいます。個人
ないし小規模なチームに主導権を渡す
ことで、多様化するニーズに自己組織
的に対応する、というトレンドが生ま
れています。
 これからの10年、ソフトウェア開発
を担う私たちは、アジャイル開発によっ
て、変化に対応できる「モノを作る力」
を養う必要があると思います。同時に、
ユーザー中心設計の知見を学び「作る
べきモノを探求する力」を高めていく
ことが、未来を切り開くアイデアにつ
ながっていくのではないか、と考えて
います。
現実の「痛み」を知るモノづくりが、
優れたUXを生み出す
作り手の痛み、利用者の痛み
 筆者（川口）は2009年12月に認定
スクラムマスターセミナーを受けてき
ました。その中で最も印象に残ったの
は「痛みを知る」というフレーズです。
チームを良い状態に保ち、良質なアウ
トプットを出し続けていくには、作り手
の痛みを知り、利用者の痛みを知らな
ければなりません。
 世界的に優れたUXを実現している
企業の経営者といえば、アップルのス
ティーブ・ジョブズ氏が有名ですが、
現役の日本人経営者にも、優れたモノ
づくりを実践されている方がいます。
●ユニクロの柳内正さん
 ユニクロの服をご存じない方はいな
いでしょう。社名の「ファーストリテ
イリング」の意味するところは「速い（即
断即決の）小売」だそうです。社長の
柳内正さんは、
自著『一勝九敗』
（新潮社、
ISBN-13：978-4101284514）のあとが
きの中で、
「全社員の全ての仕事は現場・
現物・現実から始まり、終結点に至る
まで同様に現場・現物・現実を直視し
て仕事をするべきだ」と述べています。
 また、
「洋服は、ファッション性のあ
る工業製品」であるとし、決してクリ
エイターに任せきりにしない経営姿勢
を貫いています。
●任天堂社長の岩田聡さん
 任天堂社長の岩田聡さんは、初期の
ファミコンゲームを生み出したプログ
ラマーでもあります。作り手の痛みや、
ゲームが売れないことの苦しみを直接
的に経験しています。彼はインタビュー
でこう述べています。
 
「物事って、やった方がいいことの方
が、実際にやれることより絶対に多い
んです」
（ほぼ日刊イトイ新聞、http://
www.1101.com/iwata/2007-09-05.
html）
。だからこそ、自分たちの得意な
こと、すなわち他社よりうまくできるこ
とに注力するよう、優先度をつけるこ
とが大事だと言っています。
●MITメディアラボの石井裕さん
 MITメディアラボの石井裕さんは、
未来のユーザーインターフェイスを研
究し続けています。MITの教授は、研
究者であり、かつ経営者でなければな
りません。コンピュータ言語から電子
工作まで自らこなし、一方で企業と渡
り合って研究資金を確保しなければな
りません。
 
「解かなきゃいけない問題がこれだけ
複雑になって、
（中略）それをデザイン
するときに、ひとつの学問だけでやっ
ていく時代はもう終わっている。もち
ろんすべての学問でNo.1にはなれませ
んけども、それぞれの言語を流暢に話
し、深く尊敬し、そういうチームをま
とめられるリーダーでないと、これか
らやっていけない、というふうに思い
ます」
（2005年6月14日、中京大学主
催の講演にて）
。
大事なのは自ら解決しようという姿勢
 現実の「痛み」を知り、決して無視
したり丸投げしたりせず、自ら解決し
ようという姿勢が、優れたUXを生み出
していくのではないか、と思うのです
が、いかがでしょうか。
  EM Agile UX 015
 Agile Conference報告̶UXを中心に

ユーザーエクスペリエンス(UX)への （http://www.rosenfeldmedia.com/ 品の現状をメンバー間で共有・確認す

関心の高さ books/prototyping/）というオンライ
 2009年9月にアメリカのシカゴで行 ン出版の書籍になっています。
われた、アジャイル開発技法の国際会
議「Agile Conference 2009」
（http:// ヒュー・バイヤーのセッション
agile2009.agilealliance.org/） に 参 加 し  ヒュー・バイヤーは、ユーザ中心設
てきました。数多くのユーザーエクス 計
（UCD）
方面で有名な『Contextual Desi
ペリエンス（UX）のセッションが開催 gn̶Defining Customer-Centered
され、また、晩餐会での基調講演に、 Systems』
（Morgan Kaufmann、ISBN-13
UX界の重鎮であるジャレッド・スプー ：978-1558604117）の共著者です。ユー
ルを呼ぶなど（写真1）
、UXに対する関 ザーインタビューで陥りやすい失敗に
心の高さを窺わせました。 ついての説明を行いました。アジャイ
ル開発ではコミュニケーションを重視
トッド・ザキ・ウォーフェルの しますので、質問技法やユーザー調査
セッション 技法を高めることは、間違ったソフト
 トッド・ザキ・ウォーフェルは、ユー ウェアを作らないために役に立つと感
ザー調査／ペルソナ作り／プロトタイ じました。
ピングを行う3つのワークショップを  ジェフ・パットンは、
「Agile Usability」
行いました（写真2）
。与えられた時間 というコミュニティを立ち上げたア
が短いときにも、あきらめず、調査か ジャイルUXの開拓者です。実践的な
らプロトタイピングまで行うことを目 ペルソナ作りについてのセッションと、
指しています。簡単なプロトタイプを ペルソナからユーザーストーリーまで
作ることで、アイデアが見えるように 一貫して見える化する手法「ユーザー
なり、参加者の具体的な意見を引き ストーリーマッピング」のセッションを
出して改善する、というアプローチで 行いました（写真3）
。ユーザーにはど
す。プロトタイピングに手間をかけず ういう人がいて、どういう業務があり、
効率的に行うテクニックについては、 どういう機能を提供しようとしている
『A Practitioner's Guide to Prototyping』 かを一枚絵として表示する手法は、製
るための優れた技法であると感じまし
た。
ジャレッド・スプールの
セッション
 晩餐会の基調講演を行ったジャレッ
ド・スプールはユーザビリティ界では
ヤコブ・ニールセンと並ぶ重鎮だそう
です。彼の講演では、優れたユーザー
エクスペリエンスをもたらした製品と、
そうでない製品の実例を挙げ、それぞ
れのビジネス的な結果がどうであった
かをユーモアたっぷりに説明し、会場
に爆笑の渦を起こしていました。
2008年の基調講演には
アラン・クーパーが登壇
 ちなみに2008年の基調講演にはUX
で有名な『About Face 3̶インタラク
ションデザインの極意』
（アスキー・メ
ディアワークス、ISBN-13：978-4048672
450）
、『コンピュータは、むずかしすぎ
て使えない！』
（翔泳社、ISBN-13：978-
4881358269）の著者であるアラン・クー
パーが登場しており（写真4）
、アジャ
イル開発にとってUXはホットなトレン
ドのひとつになっていると感じました。

■写真3 ユーザーストーリーマッピングの
ワークショップ（左からジェフ・パットン、
デヴィッド・ハスマン）

■写真4 アラン・クーパーのプレゼンの様子
（撮影：トム・ポッペンディーク氏）

■写真1 ジャレッド・スプールの基調講演

■写真2 トッド・ザキ・ウォーフェルのプロト
タイピングのワークショップ（活発な参加者が
プロトタイプを見ながら議論を繰り返す）

016 EM ZERO Vol.5

 ◎株式会社マナスリンクについて
リーダーはメンバーの
「0.5 歩先」を歩こう！  株 式会社マナスリンクはEM ZEROの
運営を目的として設立された会社です。
先に行かない。 マナスとはサンスクリット語でマインドを
離れ過ぎない。 意味します。良いマインドを持った人々
をEM ZEROを通じて結び付け、良い人
の流れ良い情報の流れを作り出し、ソフ
トウェア業界を盛り上げていくお手伝い
をいたします。
柴田浩太郎
（gkohtaro@gmail.com）
� イラストレーター：メーパンさん ◎EM ZERO配布のお願い
 EM ZEROはイベ ントで の 配 布＆EM
ZEROに共感してくださる方の草の根配
布を拠り所としています。よろしければ
本誌を何冊かお持ちいただき、周囲の方
に紹介していただけると嬉しく思います。
利用品質ラボ 株式会社QUICK
樽本徹也 TARUMOTO Tetsuya 認定スクラムマスター
川口恭伸 KAWAGUCHI Yasunobu ◎広告出稿のお願い
 EM ZEROでは広告を掲載してくださる
 日本では数少ないユーザビリティ工学  社内業務アプリ開発、社外向けクライ クライアント様を募集しています。企業、
の専門家。特にユーザー調査とユーザビ アントアプリ開発を経て、現在は社内業 団体、個人は問いません。EM ZEROの
リティ評価の実務経験が豊富。現在はプ 務アプリ開発、構成管理／デプロイ基盤、 存続にご協力していただける方、広告効
ロのコンサルタントとして、Webサイト サーバ基盤設計・運用を担当。よく使う 果の可能 性を感じていただける方がい
から携帯電話まで幅広い製品のユーザ 言語は、JavaScript/DHTMLとRuby。 らっしゃいましたら、ぜひご相談させて
インターフェイス開発プロジェクトに携  趣味は勉強会と米国（都市部）旅行。 ください。
わっている。ユーザビリティに関する寄 VM World 2007、Agile Conference 2009
稿や講演も多い。著書は
『ユーザビリティ に私費参加。すくすくスクラムスタッフ、
エンジニアリング̶ユーザー調査とユー 勉強会勉強会スタッフ、AgileUCD研究 ■個人広告のお申し込み
ザビリティ評価実践テクニック』
（オー 会(AgileUCDja)共同発起人、ustfreaks共
http://www.manaslink.com/
ム社）
。 同発起人、XP祭り2010実行委員。
ad_personal
 法政大学大学院ITプロフェッショナル  北陸先端科学技術大学院大学(JAIST)
コース修了（工学修士）
。人間中心設計 情報科学研究科修了(工学修士)。
推進機構（HCD-Net）理事。  愛知県田原市出身。
東京都江東区在住。 ■企業・団体広告のお問い合わせ
 大阪府堺市出身。東京都台東区在住。  Twitter: kawaguti http://www.manaslink.com/
ad_company

◎お取り寄せ
EM ZERO [イーエム・ゼロ] Vol.5 発行元：株式会社マナスリンク
  最新号3部を送料無料でお取り寄せ
アジャイルUX特集号  〒162-0012
いただくことができます。また、イベント
2010年4月9日発行 東京都中野区本町4-48-17-803
http://www.manaslink.com/ や社内での配布用に、4部以上での送付
お問い合わせ先：contact@manaslink.com も送料をご負担いただければ承ります。
著者：樽本徹也、川口恭伸
部数に限りがございますので、お早めに
デザイン：ミヤムラナオミ 印刷所：昭栄印刷株式会社
イラスト：中村収 http://www.shoei-p.net/ お申し込みください。
編集：EM ZERO編集部
Copyright ManasLink
Printed in Japan ■EM ZEROお取り寄せフォーム
http://www.manaslink.com/
send_req

秋葉原駅クリニック
□診療時間
総合内科、神経内科 頭痛外来、 10：00∼13：00、14：30∼19：00
＞頭痛』
メタボリック症候群、花粉症など （土曜、日曜、祝祭日は休診） 『＜新版 た薬の中身』
飲 んでい
ず に
『知ら 売中！
好評発

03-5207-5805 東京都千代田区外神田 1-18-19 秋葉原駅前ビル 4F URL ： http://www.ekic.jp/

  EM Agile UX 017

018 EM ZERO Vol.5
  EM Agile UX 019
 アジャイル開発を通じて
株式会社ディアイスクエア
チームがユーザー指向になった システム開発本部
ビジネスソリューション部
̶チームコンサートを活用したアジャイル開発事例 オープン技術グループ
永瀬美穂様

 東京笹塚にある株式会社ディアイスク などのワークロードが発生することを伝え A：アジャイルという名目があるとフット

エアに、アジャイル開発を実践している てあります。短納期の開発を従来型の方 ワークが軽くなります。それからユーザー
チームがあります。どのようにアジャイル 法で行っていると、仕様を決めているうち さんのことを考えるようになります。
「こ
開発を進めているのか、グループ長の永 に納期が過ぎてしまいますので、必然的に ういう機能があったほうがいいんじゃない
瀬美穂氏にお話を伺いました。 アジャイル的な進め方になるのではないで か」と。それからチームに工夫が生まれ
しょうか。 ました。見積もりポーカーというカードを
●受託開発にアジャイルを導入！ Q：ワークロードについてはどのような反 使って見積もりを行ったり、カードやくじ
Q：最初にアジャイル開発を始めたきっか 応がありましたか。 でペアを決めたり、それからミーティング
けを教えてください。 A：今までも一定のやりとりをしながら開 の時間とゴミ出しの時間を知らせてくれ
A：開発プロセスが好きなこともあり、ア 発をしていましたので、それほど違和感は るパトランプをメンバーが作ってくれまし
ジャイル開発は10年前にXPが出てきた頃 なかったようです。協力的なユーザーさん た。
から知っていました。直接のきっかけは、 なので助かっています。 ■ 写 真3  今 や
プロジェクト運
昨年になって社内にアジャイル開発導入 Q：ユーザーさんとの関係作りはどのよう 営に不可欠の
カード達
の機運が出てきたことです。InfoQのサイ になさっていますか？
トに出ているオンライン書籍『塹壕より A：今回は要求定義書を作ってからプロ
ScrumとXP』
（Henrik Kniberg 著、http:// ジェクトが開始するまでに時間が空いた
www.infoq.com/jp/minibooks/scrum-xp- こともあったので、ユーザーさんと一緒に
from-the-trenches）を読んで勉強しました。 要求定義書の読み合わせ会を行いました。 ■ 写 真4  メン
バーが工夫して
Q：どのようにアジャイル開発を実践して 引っかかるところはだいたい同じで、だい 作ったパトラン
プ（特別点灯中）
いますか。 ぶ要求の整理ができました。ユーザーさん
A：XPのペアプログラミングや、スクラム の不安はかなり払拭されたようです。
のデイリースクラムなど、XPとスクラム両 Q：開発はどのように進めていますか。
方のプラクティスを取り入れています。ス A：開発は、ワークフローを串刺しにして
プリントは1週間で回しています。1週間だ 最小限の入力項目でデータを流すための
と計画がしやすい上、問題があればすぐに 一通りの機能を作り、流れに沿って串刺し ●チームコンサートを活用中！
対応することができます。 用の機能をリッチにしていきます。いつど Q：プロジェクト運営にはチームコンサー
の作業をするかをユーザーさんに伝えて トを使っているそうですね。
●ユーザーとの関係作り あり、変更の必要があったら教えてくださ A：はい。Express-Cという無償版を使っ
Q：ユーザーさんにはアジャイル開発をど いと言ってあります。今のところ大きな優 ています。Subversionとどちらを使うか悩
のように説明なさったのですか。 先順位変更は出ていません。 んだのですが、見積もりポーカーを使って
A：
「アジャイル」という言葉は使っていま （笑）導入を決めました。10人まで無償で
せん。ユーザさんには開発を反復型で行 ●アジャイル開発でチームが変わった 使えるので、私のチームには十分です。
うということ、レビューやフィードバック Q：アジャイル開発を始めてチームにはど Q：どのようなところが魅力ですか。
んな変化がありましたか。 A：一番気に入っているのが計画のしやす
さです。スクラムテンプレートが最初から
■写真2 永瀬氏と相談中 入っていてリリース計画やスプリント計画
がツール上でできるのが便利です。ビルド
機能も便利ですね。
Q：これからのユーザーにメッセージをお
願いします。
A：チームコンサートは10人まで無償で使
えます。操作に難しいところはなく、直感
で使えるはずです。無償ですから、合わな
■写真1 ペアで開発を進めるチーム。ペアは毎日変わります ければやめればいいだけです。気軽に使っ
てみてはいかがでしょうか。

チームコンサートのサイト 2010年4月
http://www-06.ibm.com/software/jp/rational/ 『デスマーチ対策ツール̶チームコンサート超入門』
products/scm/rtc/ 発売予定！（技術評論社）

020 EM ZERO Vol.5