『Agile Meets UX 〜アジャイル開発とユーザエクスペリエンスの遭遇〜』に参加してきた

勉強会 Agile UX


(写真：会場内に揃えられていた関連本の数々。中には絶版・入手不可の書籍も！)

確かAgile関連のメーリングリストだったような気がするけど、以下の内容でトークショーがありますよ。というお知らせを知り、割と早めに申込Doneしてました(電話連絡だったので若干通常と勝手は違ってましたが)。これら分野に携わるお仕事をされている方であれば夢の様な組み合わせですね。

アジャイル・ユーザビリティ ―ユーザエクスペリエンスのためのDIYテスティング―

アジャイル・ユーザビリティ ―ユーザエクスペリエンスのためのDIYテスティング―

樽本徹也・著 『アジャイル・ユーザビリティ』（オーム社） 刊行記念トークセッション
Agile Meets UX 〜アジャイル開発とユーザエクスペリエンスの遭遇〜

■2012年3月10日(土)19:30〜

樽本徹也：『アジャイル・ユーザビリティ』著者
脇阪善則：『ユーザエクスペリエンスのためのストーリーテリング』訳者
角谷信太郎：『アジャイルサムライ』監訳者
【司会】川口恭伸（アジャイルUCD研究会代表）


「アジャイル」と「UX（ユーザエクスペリエンス）」は近年のソフトウェア開発における代表的キーワードです。しかし、それを製品開発に活かす方法については、まだ模索しているという人が多いのではないでしょうか。
2012年2月にオーム社より『アジャイル・ユーザビリティ ―ユーザエクスペリエンスのためのDIYテスティング―』が出版されます。この出版を記念して、本書の著者である樽本氏を中心にアジャイル開発とUXそれぞれの分野から第一線の実務家を迎えたトークショーを開催します。アジャイルとUX、そしてその複合領域であるアジャイルUXについて、ざっくばらんなトークと会場を巻き込んだ活発な質疑応答をお楽しみください。


◆講師紹介◆
樽本徹也（たるもと　てつや）
利用品質ラボ代表。ユーザビリティエンジニア／UCDコンサルタント。ユーザビリティ工学が専門で特にユーザ調査とユーザビリティ評価の実務経験が豊富。著書は『ユーザビリティエンジニアリング』『これだけは知っておきたい組込みシステムの設計手法』。寄稿や講演も多数。


脇阪善則（わきさか　よしのり）
楽天株式会社編成部プロジェクトマネージャー。 スマートフォン系領域の UI設計、サービス企画を推進中。UX TOKYOのメンバーとして、日本でのUX分野の裾野を拡大中。昨年末に、丸善出版から『ユーザエクスペリエンスのためのストーリーテリング（原題：Storytelling for user experience）』を翻訳して出版。


角谷信太郎（かくたに　しんたろう）
株式会社永和システムマネジメント サービスプロバイディング部コミュニティマネージャ。一般社団法人日本Rubyの会理事。Asakusa.rbメンバー。監訳書・訳書は『アジャイルサムライ』『アジャイルな見積りと計画づくり』『アジャイルプラクティス』など。寄稿や講演も多数。


川口恭伸（かわぐち やすのぶ）
アギレルゴコンサルティング所属。金融向けプロダクト企業にて、14年間勤務。社内向けの新規ツールや、新企画のパイロットプロジェクトを中心に、少人数でユーザ調査から製品開発、運用まで行うプロセスを探求。2011年7月より現職。アジャイル開発手法スクラムの研修等を手がける。

会場は当トークセッション主催も兼ねているジュンク堂書店 池袋本店＠池袋。この日は直前に別の勉強会に出ており、終了次第電車を乗り継いで池袋に向かいました。

会場にはイベント告知の張り紙もそこかしこに。


会場は4Fのカフェでしたが、だいぶ横に長い感じの作り。そこに横に並ぶ感じで3〜40名位は(参加者数的には)居たでしょうか。アジャイルやスクラム関連の勉強会でお会いした方もそこそこの割合でいらっしゃいました。


トークショー本編


(写真：左から脇坂さん、樽本さん、角谷さん、川口さん)

まずは各者簡単な自己紹介があり、そのままの流れでトークセッションへと続きました。

文章中、【】を使った接頭文がある場合、その人が主にトークした内容となっています。あくまでもざっくりですが目安として。
【樽】：樽本さん
【角】：角谷さん
【脇】：脇坂さん
【川】：川口さん
  • 【川】皆さんがどういう方か。
    • (アジャイル系のイベント等で良くやる)自己組織化で一列に並んで…ってのをやりたいけど、この場所でやるとやると破綻を来すので、挙手制で。
      • 開発の人：半分位。
      • UX、デザインの人。(予想に反してこっちが多かった！)
      • また、両方を併せ持つ人もそこそこ居た。
    • 殆ど開発であろうと思っていた、UXってなに？
  • 【樽】UXという言葉が普通に使われるようになったのはここ2〜3年。それまでは『ユーザビリティ』。
    • 1980年代に活動があった。
    • コンピュータが普及、普通の人が使わないといけない状況に。ユーザビリティが必要になってきた、
    • (その前に)人間工学の時代でユーザビリティが関連していた。
      • 戦闘機のコックピットのデザイン：操縦ミスをしないように。
    • ＜80〜90年代＞
      • ニールセン『5人で良いんだ』：85%の成果を5人で出す
        • 現実には、その人数で大体大丈夫。
    • ＜90年代＞
      • 今のUXの元になっていた時代。
      • シナリオベース開発(SBD) by ジョン・キャロル

Usability Engineering: Scenario-Based Development of Human-Computer Interaction (Interactive Technologies)

Usability Engineering: Scenario-Based Development of Human-Computer Interaction (Interactive Technologies)

Making Use: Scenario-Based Design of Human-Computer Interactions

Making Use: Scenario-Based Design of Human-Computer Interactions

誰のためのデザイン?―認知科学者のデザイン原論 (新曜社認知科学選書)

誰のためのデザイン?―認知科学者のデザイン原論 (新曜社認知科学選書)

        • この人、90年代にアップルに居た。（最も景気の悪い時期に）
          • ユーザーエクスペリンス担当。
          • ※企業レベルで言葉が使われ始めた最初。
          • この時代のアップルはUXを交えた製品は販売出来ず。
      • 【樽】：同じ時期、ユーザビリティ方面でも動きが。
        • 売るときに名前があると売りやすいのではないか？(推察)
        • ゴール駆動開発･･･という名のUCD
        • 今テクスチュアルデザイン･･という名のUCD。
        • 人間中心設計という名の(ry
        • ※ISO13407は身がない、共通の部分だけの抽出である。何だかんだで皆UCDをベースにしていた。
    • 【樽】HCD(人間中心設計)／UCD(ユーザー中心設計)という言い方の違いについて(※『アジャイル』は一本化されていた)
        • ヨーロッパ系：HCD（ISOはヨーロッパ発）
        • 米国系：UCD
        • プロダクトデザイン系：HCD
          • 日本もこっち派？
    • Agileは開発のプラクティスとして回す（XP等を中心としつつ）：出来る人達の良いやり方
      • 2005年：スクラムなど
        • 『企業の中でどうすんのよ』→急に色んな企業がやりはじめる 2005年位から
        • その頃、UCD/HCDの人達はドキュメントを書いていた
        • 【樽】樽本さん：WF出身。
          • ドキュメント過多は、WFだからやっていた。
          • 標準的な活動として、当たり前の事としてやっていた。WFだったから。
          • Windowsは2〜3年掛けて開発している。※当時はそれで良かった。
          • でも、あんまりドキュメント役には立たんわな、という雰囲気ではあった(やっぱり)
          • 『報告会やってください』だいたいの人はここでの内容を頼りに開発を行う。ドキュメントは見ない。(やっぱり)
    • 【脇】いきなりドキュメント渡されても読めない。
      • エンジニアリングの方の資料を読むのも難しいよね、いきなりは
      • 断絶があった。職能的にも、組織的にも。
      • モバイル等は、動きをデザイン：仕様を決めるというのは当たり前の話であった。
        • 過程を何回もグルグル回す。
        • 『15人でやるなら、5人でグルグル回す方が良いよ』
        • 反復して開発続けられるのなら、名前は何でも良い。
        • ユーザテストの環境は変わってきている。（PC→スマホ）
    • ＜2008年＞

    • 日本では、XXXX XXXXという人(※名前聞き取れず。)が有名

アジャイル・ユーザビリティ ―ユーザエクスペリエンスのためのDIYテスティング―

アジャイル・ユーザビリティ ―ユーザエクスペリエンスのためのDIYテスティング―

      • どっちで検索しても上位に入ってくるようにした
      • 正しくは『アジャイル・ユーザビリティ・テスト』なニュアンス。
      • テストをサブタイトルの方に持って来た。
        • 【角】『ユーザビリティテストをアジャイルにしたいのは何故？』
          • 【樽】アジャイルの波がやってきたから。（切実な理由）
          • 【角】来たから、ではないのではないか？
          • 伝統的なユーザテストは1ヶ月近くやってたりした。
          • 6週間後にレポート出します：アジャイルの人は拒否る。『3スプリント分じゃないか！』→しょうがないからアジャイルに合わせ始める事にした
    • 【脇】：QA（品質保証）と同位置に
      • ダメだったら･･･ダメだね〜で(ホントは良くない)：リリースする前に多少は治りますよ、位の感じで
      • QA的（総括的評価）なテスト
        • タスク達成度、満足度を収集
        • 評価：総括的評価、という概念。
        • 形成的評価：改善するために、問題点を見つけて徐々に改善。
        • (本来は)形成的評価を繰り返して、最後に総括的評価を経ないと行けない。
          • 従来、往々にして総括的評価のみ行われてしまっている。
          • 勉強しないで期末試験を受けるのと同様。悪くて当たり前
          • だから日々小さな試験を繰り返している。
      • ライトなテスト
        • ディスカウントユーザビリティ：どの位ディスカウントなのか？
        • 1回幾ら？：200万くらい？→100〜120万くらい→全然安くないじゃん！現実的にはない。世界中探しても余裕のあるプロジェクトはない
        • 【角】MSでWindows的なプロジェクトはそんなにない（かくたに）
        • 私達下々の者とは考え方がちがう！
      • そんなに予算のあるWebの開発は無かった。
        • ホールウェイテスト/カフェテリアテスト
        • 他部署の人達にちょっと顔を出してテストしてもらう
        • ※これだけでもかなりのフィードバックを得られる
        • 【脇】：そういう予算があるプロジェクトは無かった。やらないよりも全然ましなので実施していた
        • 【樽】：『ユーザビリテストは、どんなものであってもやらないよりは全然マシ』
          • 仮説の検証が、テストを行うことで間違っている事が分かる
          • 思考発話法を使うので、行動の意図が分かる。
          • →良くなる。使えるようになる。
        • 【脇】：よっぽどで無い限りやるべき。ペルソナを意識してインタビューとかしないとミスリードする場合もあるが･･･
        • 【樽】：リクルート条件にこだわり過ぎないこと。
          • 大抵が自分の友人周りで見つかる場合も多い。
          • 会社の中で探して、その人の友人をリクルーティング。
        • 【川】開発者の視点で行くと、どっから手を付けて良いか分からない場合がある。
          • 心理学の学位がなくても大丈夫。
          • 【角】『本を買えば大丈夫！』
      • テストやるときに何が一番開発者が良くないか（作業として）：『ユーザに説明して理解して貰っている』
        • 一切説明しちゃダメ。ゴールだけ説明する。そして悪戦苦闘する様子を観察する。
        • 【角】プログラマは難しいかも。デモする際に『あ、コレはですね〜』と、コンピュータ使う人に親切心から説明してしまうので。
          • 『今すぐ直します』→ライトメソッド。
          • これまで3人目まで見てから、その内容を推理して問題を洗い出す
          • ライト：ユーザーが困っている→その場でUIを変更する→直す→2人目の試験
        • 【角】：【1人を見てその場で直してたら、軸ぶれちゃうんじゃないの？】→【樽】『そこが難しい所なのです』
          • 行動がたまたまだった場合もある。ライトでやる場合は1人の行動で判断。
          • 同じような前提でテストした経験があれば、それをやってもいい。
          • 評価する側にコンテキストが存在しないと出来ない（やっちゃダメな）手法。
    • 【樽】提案 / アジャイルチーム：
      • 木曜の午前中をテストにします：等と予めスケジュールを決めてしまっている。
      • みんなでお昼を食べながら。
      • 【角】『それはやりましょう！』
    • スプリントレビューにユーザテストを組み込む（定期的になる）
      • 大問題が出てくるとムダになる→（ホントに）小規模なテストを自分の力でやっておく必要がある
      • タスクが達成出来るまでやっておいて、顧客に見せる（ちゃんと使える）
      • 小規模自前なテストは『スカイプでスクリーンシェアしてやってしまう』
      • ユーザーストーリーを提示して、ゴロンと渡す→【角】『やりましょう』
      • 開発者も同席するのが流行り？
      • 1回辺りの時間が短ければ、同席した方が効率良い。
      • 関係者みんなで見学：見学のノウハウも必要。※お地蔵さんになる
        • 関係者みんなで見るので、レポートが必要無くなる。
      • 【角】：そういった手法をやりたい、インクリメンタルな開発に盛り込みたいんだけど。どうする？10年やったら行ける、では難しい。取っ掛かり方が知りたい。
        • 【樽】：最初から実プロジェクトでやるのは大変。現実的には難しい。
        • 最初は練習が必要。スカンクワークス。まずは自分でやる。
        • テスト対象は自社の製品じゃ無い方がいい。
          • 何でもいいから選んで、被験者を見つけて増やしていく。
          • ユーザテストをやると、問題点が見つかる、理由も分かる。改善案も思いつく。
          • →そういう基盤が出来てくると、やれるようになる。
          • 『専門的な会社に頼んだ方が･･･』となる事を避けられる
    • 【川Ｉ イトイ新聞：宮本さんの紹介　出来かけたゲームがある 
岩田：でも、宮本さんと仕事するようになってから
だんだんわかっていくんです。
なにが自分に足りなかったかというと、
ひと言でいえば、自分は、
「ものをつくる側からしか見てなかった」んですね。
宮本さんって、
「こうやったら、こうなるはずや」
っていうふうにつくって、
もちろんその時点で、ほかの人よりは
はるかに打率が高いんですけど、
神様じゃないので、それなりに間違うんです。
それをどうやって補正してるかというと、
社内から、そのゲーム触ったことのない人を
ひとり、さらってくるんですよ。
さらってきて、なにも説明せずに、
いきなりポンとコントローラーを握らせて
「さあ、やれ」って言うんですよ。
それはまだ、宮本さんがいまみたいに
世界的なゲームデザイナーとして評価される前、
係長とか課長だったころから。
    • 【脇】：興味ある人を巻き込んで、レビューをやる事もある
      • ある程度ユースケースは用意しておく
      • ユーザストーリー単位では小さすぎる
        • →エピックはデカ過ぎる･･･
        • ワークフローのタイトル＝ユーザから見たタスク（ストーリーの上）くらいで書くとユーザタスクとして成立。
      • 見学してもらうのは難しいかも。
      • 写真とかビデオとか見せることでも対応が出来る


この後は質疑応答等を交えて、更にトークが進みます。

  • Q.ユーザビリティテスト：同じ人に何度もしてもらうのは？
    • 何度も繰り返しでは良くない。
      • それよりはその人の友達を紹介して貰った方がよい。
    • テストする対象にもよる。
      • 同じ人ならどれ位の期間を？
      • フロー系では難しいのでは。
  • Q.ユーザテストで：大学で被験者を集めるのはいかんのか？
    • 良いと思う。ただバイアスは多目に掛かっているかも。
    • 出来ればもうちょっと幅広くが必要。
    • 特殊な仕事をしている人は数千円では難しいかも。例）医者とか
    • BtoBの場合はそれなりに必要だったりするかも（それなりのオペレーションとか必要なので）
  • ストーリーテリング：ストーリーを作る本。
    • アジャイル開発でのストーリー（ユーザストーリー）とは違う。
    • ユーザ要求を効率良く伝える。
    • 開発者が捌くためのもの。
    • 開発していくと、ユーザーストーリーだけでは足りない。
      • 【角】『本の宣伝得意なんで』
    • 誰かに使って貰わないと、何が良いのかどうか分からない。
      • ドキュメントを渡したってどうせ見てくれない。
        • 別の方法で、ソフトウェアを伝える。
    • 親子関係
  • Q.企画そのものが間違ってる場合はどうする？
    • 止める話をしていく。
    • 撤退戦/あまり正面からやっても勝てない。
    • 開発者がいないところから始めてもしょうがない。『最初に呼べ！』って話だよね
    • UXが上流工程に入るように、
    • 本当のユーザの声を聞く(realy listen)
    • 以下の本がオススメ。エスノグラフィの入門本として。

聞く力―心をひらく35のヒント ((文春新書))

聞く力―心をひらく35のヒント ((文春新書))

    • 最初に中核メンバーを全員揃えてやるべきだ。

アントレプレナーの教科書

アントレプレナーの教科書

ビジネスモデル・ジェネレーション ビジネスモデル設計書

ビジネスモデル・ジェネレーション ビジネスモデル設計書

    • トークで出て来たフレーズについて
      • 【角】：まだまだやってない（流行ってるって事はみんなやってない、って事だ）。色々やる価値はある。


…と言った感じで、トーク自体はまだまだ収まる気配は無かったのですが、会場の撤収時間が迫ってきていたのもあってこの辺りでお開きに。一応書籍も一通り読んでから今回のトークショーに臨みましたが、書籍以外の内容もふんだんに盛り込まれていた、非常に中身の濃いトークショーだったと思います。可能であれば各者にサインを頂きたかったのですが、撤収時間の都合もある事を考慮しそのまま退散致しました。(角谷さんのつぶやき曰く、大団円な締めだったようです。)

いやぁ〜、やはりアジャイル/UX周りは奥が深いというか、まだまだ勉強しなければならない所だらけですな。学ぶ事は多いです。(｀・ω・´) ｸﾜｯ

(※追記)ご指摘があり、幾つかの箇所に関して修正致しました。


その他関連：