AgileUX NYC 2012 Redux in Tokyoに参加してきた #AgileUXNYC_ja

勉強会 Agile UX

先日のトークショーに引き続き、AgileUX関連のイベントに参加してきました。

今回のイベントの内容は、以下にあるようにイベント参加報告＆ディスカッションな形となっております。

2012年2月25日にアメリカはニューヨークにて開催されました、「AgileUX NYC 2012」に参加してきた @kawaguti と @sprmari0 による報告会を兼ねたパネル・ディスカッションを行います。

開催場所は楽天タワー内 カフェテリア＠品川シーサイド。カフェルームの一角、細長い部屋になっている部分を貸し切って会場としておりました。オシャレな感じでとても雰囲気も良かったです。(※写真は後ろの方で掲載)

AgileUX NYC ハイライト

川口さん、坂田さんによるイベントのふりかえり。以下メモ。(※スライドの内容が非常〜に濃い内容でしたが、駆け足で紹介していた部分もありメモが取り切れない部分も。スライド資料がUPされれば、そちらの内容を熟読される方がより詳しく把握出来るかと思われます。それまでは写真等でイメージ・雰囲気だけでも･･･)

  • まずは謝辞を。
    • 会場提供頂いた楽天様、ありがとうございます。
    • 楽天ではジョナサン(『アジャイルサムライ』原著者)も現在(昨日今日で)話しているらしい。日本のアジャイル人口の半分が(ry

  • イベントについて
    • AgileUXをテーマとした初めてのカンファレンス。
    • 朝8時〜5時半までの長丁場
    • 時差ボケは応えた･･･
    • 会場は結構広い。2〜300人位か
    • 世界のどこから来ているか、出身地・分布図
    • 圧倒的に米国・ニューヨークが多い。
    • 国内も2人(川口さん・坂田さん)の他にもう1人居たらしい。
    • 開催地：スクールオブビジュアルアーツ(School of Visual Arts Theatre)
    • 朝8時開始、最初はモーニングブレイク的な時間
    • プレゼン自体は1人20分
    • 定期的にコーヒーブレイクを挟む形で進行
  • スピーカー
    • Jef Gothelf(主催者)
    • その他著名な人が続々と
    • 会場内では主催者等が身近に居るような、近い距離での雰囲気だったらしい

  • セッションハイライト
    • What to Win with Agile? (組織内にAgileUX/LeanUXのコンセプトを導入するには？)
      • チーム以外にも関係部署にアプローチして共通の課題を抽出・定義する
      • 意志決定けんのある多忙な人でもランチ時間を抑えて顧客との定期ランチを開催。
      • Small Winsの候補を探し、成功させ、エッセンスを組織内に拡充。


    • Investing in Design(デザインに投資する)


    • Replacing Requirements with Hypothtsis(要件を仮説に置き換える)
    • 進め方
      • 1.前提条件を定義する
      • 2.前提を仮説として表現する
      • 3.最もリスクのある前線を最初に検証する
      • 4.仮説を検証可能なレベルに落とし込む
      • 5.MVPのコンセプトを用いて仮説を検証
      • 6.ビルから出る
      • 7.十分に泡立て、漱いでから繰り返す
    • ビジネス責任者のニーズがそのまま要件として捉えられてしまい、ユーザーやマーケットニーズ等の経緯を把握する術がない。
    • 結果としてビジネス側が考え、デザイン・開発側が創るフェーズと切り分けられてしまう。
    • 仮説思考を取り入れる事で、不確実故に学ぶ・テストする姿勢をチーム全体で保ってくれる
    • ※こういったことが概念化されている事が良い。


    • Quick Visual, Collaborative, and Continuous(デザインの役割が変わってきている)
      • デザインをチーム全体の責任とする
      • 部署や役割の垣根を超えたペアリング
      • デザイナーはファシリテーターへ
      • 対象のプロダクト・サービスの担当・責任を負うチームの構築


    • Leaning to play UX Rugby(Agile UXはUX Rugbyそのもの)


    • Better.Faster.Uxier - AToMIC Design


    • Demystifying Design(UXデザインはブラックボックス/ミステリー状態にある)
      • 透明性を維持しなければ信頼は勝ち取れない
      • 汚いラウンジのような状態にするのではなく、チームメンバーを我々の作業に受け入れる
      • まずは一緒に描ければ良い。＊＊＊さえかければ誰でも書ける
      • UXデザインはマジックのようだよね
      • 医者のように他人が理解できる言葉で話す


    • まとめ
      • アウトプット：できたもの
      • アウトカム：アウトプットを使ってユーザが何を得たか



パネル・ディスカッション

  • 和波俊久 氏(LeanStartupJapan)
  • 樽本徹也 氏(利用品質ラボ)
  • 川口恭伸 氏(アギレルゴ・コンサルティング株式会社)
  • 坂田一倫 氏(楽天株式会社)

このタイミングで和波さん、樽本さんの両名が加わりパネルディスカッションへと続きます。

  • 今日は開発者の方が多い？(Dev:UX=2:1の割合)
    • 外(の視点)から見ている分には、まずアジャイル開発がある、という認識
      • UX/UCDはアジャイルでやらざるを得ない
      • 決してUXからAgileを仕掛ける、という形にはなっていない。
      • 今までのやり方が通用しなくなる段階が来るのではないか。
  • リーンスタートアップ・アジャイルは親和性が高い。
    • メインはスタートアップやってます、という人も会場内には2人程居た。
    • スタートアップとアジャイルの決定的な違い
      • アジャイル：プロジェクト。いずれ終わる
      • スタートアップ：絶対に終わらない。
      • 中身の動かし方は一緒。非常に親和性は高い。
      • どうやって終わっていくのか、という点に興味がある。

Agile Experience Design: A Digital Designer's Guide to Agile, Lean, and Continuous (Voices That Matter)

Agile Experience Design: A Digital Designer's Guide to Agile, Lean, and Continuous (Voices That Matter)

    • 冒頭：『エゴで仕事してないか？』Uxerに向けて発された言葉。
    • 取り残されたビジネス・デベロッパーが一緒になってやってこうぜ
    • ビジネスの価値を高める方法論として出てきたのがアジャイル
    • 依頼をもらう：価値を出す：uCDを回す
      • それってブラックボックス
      • 最後のアウトプットがアウトカムになってないのではないか？
    • 私たちはそっちに近付いていかなければならない、勉強しましょう。
  • 社内でもアジャイル勢が増えている。
    • むしろ私たちが居なくても出来ちゃうのではないか・・
    • カードソート、ストーリーマッピング等
    • SM/POが居れば回る
    • デベロッパーとビジネスだけで回るプロジェクトも。
      • 危機感を感じている部分がある。
    • 最近ではユーザビリティテスト（被験者を呼んでテスト）なども
  • 編成部はUX/デザインを。開発部は開発を。では･･･ビジネスの人達はどこに？
  • ビジネス/開発/デベロッパー･･･まさにリーンスタートアップの形に近付きつつある。
    • 何で3つに分けてるの？→分けているけど入るステージが異なるので･･･同時ではない。
    • 同時にしちゃえばリーンに。全員集めてよーいドン、で出来るじゃない。
    • 部署間の問題・キャッシュフローの問題があるので･･･
  • 大企業でリーンが出来るのか、という勉強会をｙはった。
    • 株式会社である以上、決算を迎えないと行けない。定量的な報告をしないと行けない。
    • どうやって定量的に計れば良いんですか？
      • →ああ、辛そうだなぁ
      • その辺を報告出来る仕組みが出来れば、だいぶ楽になるんじゃないか。


この後に続いた質疑応答コーナーでは以下の様なやり取りが。

  • Q:顧客開発のためのPDCAについて、何かインプットがあれば共有いただきたいです。特に顧客セグメントの仮説立案のTipsや、スケーラビリティを意識した検証方法などありましたら、お願いします。
  • アジャイルの人はスゴイ。
    • ドキュメントに完璧さを求めない。
    • それよりも人とのコミュニケーションを重視。
  • インタビューを全員で聞くのが一番良い。アイデアが出てくる（その方が）。コストは掛かるけどね。
    • 録音/速記録をUPしてみんなで見回す
    • そんなのでもボッコボコ出て来ますよ
  • アイデアが得られるなら少ない人数でも良いじゃん
    • 精度よりもまずアウトプットを出し、実ユーザで検証する
    • どんなに素晴らしい調査資料があったって、アイデアが出ないとしょうがない。
  • 作りながら売る＝リーンスタートアップの考え方
    • 作りながら売ったらどう？そしたらすぐ売れるかどうか分かるから。
  • UXの人、大変ですよ。開発者はみんなUXを身に付けるから。
    • UXだけでは食っていけない。
    • (追記)上記コメントは以下の文脈・背景があってのものでした。御指摘コメントを頂きましたので追記しておきます。

    • (更に追記)インタビューの内容をUstreamの音声を元に文字起こししてみました。若干聞き取れなかった部分などもありますが、流れはこれで追えるかと。
※質問の内容を受けてからのやりとり、Ustremの時間で言うと49:30〜58:35辺りの音声を文字起こししています。
　聞き取れなかった部分、曖昧な部分に関しては＊＊＊としてます。文中敬称略。

坂田：たぶんこれLeanとか多分意識されやすいと思うんですけど･･･

和波：そうですね、あのLean Startupが実際に進めてみるとデモグラだとかジオグラだとかでも本当に関係無くなっていて、
      とにかく課題というようなものでセグメントしていく以外無いとは思っているんですけど･･･そういう事ですかね？

川口：あと、今回の話では出て来ませんでしたけど、その37signalsという、Ruby on Railsを作っている
      有名な会社の人達が出している「＊＊＊Work？」、「＊＊＊Work？」って何でしたっけ、小さなチーム
      大きな仕事、あそこに出ているのは基本的には自分、えと仮説･･･
      要はユーザとペルソナをガーッてデータで集めるよりは自分がペルソナになるのが一番早いので
      自分が使いたいと思うものからまず仮説を立脚する、ってのが早い。

坂田：で、後は去年ですね、ちょうどそのラクサ？の（人名）っていうファウンダーの一人が
      まぁ和波さんもセッションされてましたけど、日本に来られた時にちょっとイベントがありまして
      LeanWorkShopっていうのがあったんですけど、そこでやられてた方法としては
      まさにペルソナを作って、仮説を検証していくという方法をずっと、6時間位やってたんですけど
      そこでやられていた方法としてはまず自分が使って貰いたいサービスを考えてください。
      そこでサービスを使うであろうセグメント、プラグマティックペルソナで4つの枠で切って＊＊＊＊で書いてください。
      で、そのユーザーが本当に居るかどうかっていうセグメントの検証のためにインタビューをしに行ってください、というのを仰ってました。

      で、そのさっきの（人名）のペアインタビューでもあったんですけどそこでペルソナをどんどん進化させていって
      本当に我々が、これ使って欲しいユーザーがセグメントいるんでしたっけ？っていう所がそもそも入るっていう、
      そのペルソナが合っているか合ってないか、本当に実在しているか実在していないかっていう
      考えではなく、そのセグメントって本当にいるんですか？っていう所が入ってくる、ってのがポイントでしたね。

川口：ペアインタビューの時に、あの、スライド、今日はちょっと載って無いんですけど、実は（人名）とジェフパットン
      が2人でインタビューしてる写真とかが出て来て、あの僕的にはすごいウキウキして見てたんですけど、
      あの、開発者、でないと分からない、アイデア・解決・問題もあるんで、UXの人だけでインタビューするんじゃなくて、
      でやっぱその方が早いんですね。それを持って帰ってきて、その場で･･･後でトークする方が解決が早い。
      何と言うか･･･壁があると負けですね。
	
      アジャイルの人達ってなんか凄くて、元々アジャイルの考え方の一つが"完璧なドキュメントを求めない"というのがあるんですけど
      それは何故かっていうと、求めない代わりに人と人とが話してコミュニケーションする、ってのを重要視している。
      その方が100倍はやい。っていうのを言っていて、でみんなそっち側に吸い寄せられている感じはしますね。
      別にどっちが偉いとかでは無いと思うんですけど･･･

樽本：それで、インタビューがね、あれ実はUXの専門家で無くても出来るんですよ。
      コンテクスチュアル****って。
      ちょっとやり方教えてあげれば、開発者、自分でも出来ちゃうんですね。
      ん〜それで、多少ねインタビューのテクニックがひどかろうとね、大体データ取れるんですよ。
      んで一番大事なのは、だから出来ればそのね、インタビューをさっきみたいに全員で聞くのが一番良い。
      誰がインタビューしても構わないけど、他の関係者も全員そのインタビューを聞くと。そうすると色んな所で
      アイデアが出てくるんですよ。製品のアイデアが。
      で、勿論ね、全てのセッションにチーム全員を同席させる･･･これはかなりのコストになってくるので、
      後、時間の都合も付かなくなるのでね。
      良くやるのが、録音するか、それかもうその場で、みんな＊＊＊出来るでしょ？
      ＊＊＊しちゃうんですよ。テキストぱーっと、適当に。でその速記録をだーっとみんなに渡して、あとその録音と一緒にセットにして
      イントラネットか何かに上げといて、みんなで自由に見れるようにしといてあげる。
      で、そのインタビューの記録を読んで、でそのインタビューの様子をビデオとか音声で聞いて、でブレインストーミング。
      そうするとボッコボコアイデアが出てくる。エンジニアから。

川口：ユーザテスティングとか観察に関しても、アジャイル以前のウォーターフォールを目指してたときは
      どっちかというと科学的な根拠・対数の法則だったり、5人･･･まぁ5人は減って5人なんですけど
      5人調査しないと、それは知見にならない、みたいな･･･考え方からもっと少ない人数でもう良いじゃないかと。
      アイデアが得られるなら少ない人数でもどんどん定期的にやっていこうよ、みたいな流れがありますね。
	
樽本：そうですね。あのアジャイルUXとかアジャイルUCD、LeanUX等は全てその考え方ですね。
      あの精度、よりも、まずアウトプット出してしまう。
      データの精度上げるよりは、まずアウトプットを出して、はやく、それをユーザで実際に検証する。
      だからとにかくアイデアの数勝負なんですよ。
      だから、どんなにね、素晴らしい調査データがあったって、アイデア出なきゃしょうがないじゃないですか。
      それで、アイデアなんてどの瞬間に出るかなんて分からないんだから、一人の話を聞いている、頭の5分で
      アイデアが出た、それで十分役に立つ訳だから。
      ま、それでね、あの必ず成功するって訳では無いけれども、でもアイデアをまず出す事が大事で、そのアイデアを
      紙のまま置いといたって、それユーザには使えないんだから、はやくコードにして、動く形にして、ユーザに見せて
      試して貰って、それでそれが受けるかどうか。それ検証した方が早いじゃないですか。

川口：アウトプットからアウトカムってのはまさにそれで･･･
      アウトプットってのは精度の高い、すごく品質の高いもの。
      でも、品質は高くたって、使われないんなら意味無いじゃん。
      っていう、そのムダを減らして、リーンにしていこう、と。
	
樽本：結果が全て、なんですよ。今は。
      どんな立派な調査やったって、製品売れなきゃしょうがないでしょ？って。だからリーンスタートアップなんですよ。
      製品作る、これはもうスティーブ＊＊＊も書いてるし、マーティンケイラーも全部書いているんだけれども、
      製品作ったよね、って。でそれ売れなかったらどうすんだって。売れなかったら貴方の苦労全部ムダになるでしょ。
      だったら作りながら売ったらどうかって。売れるものをちゃんと考えながら作ったらどうって。それがリーンスタートアップの考え方ですよね。
      だから、製品開発に対して、カスタマーデベロップメント、顧客開発って言葉使ってるんです。
      今までは製品開発が終わってから営業するって言ってた･･・それじゃ間に合わん。
      その製品もしかしたら間違ってるかもしれないよ。お客さん欲しいと思ってないかもしれないよ。
      だから作りながら売ったらどうかって。売れるかどうかすぐ分かるから。売れなかったらPivotしちゃえ。
      だからデータ集めてるよりは作れ。はやくコード書いた方が良いんだ。

和波：最初からそのつもりでいるっていう･･･のが良いですよね。
      そうすれば良いんですよね。
      インタビューとかも、最初から、何か学びに行くんだっていう気持ちがちゃんとセットされていると、
      まぁどんな人でもちゃんとインタビュー出来てしまえるんですよね。

樽本：その通りです。
      もう、インタビュー誰でも出来る。コンテクスチュアル＊＊＊＊＊なんて、エンジニアに教えればみんな出来るようになるの。
      僕今どんどんそれ教えてるの。
      だからね、UXの人これから大変ですよ。開発者がみんな、UXの技術身に付けちゃうから。
      だからさっき、坂田さん言ってたよね。「彼等だけで出来るんじゃないか？」と。出来るようにもう、なってきてるんですよ。
      UXだけじゃ食っていけないです、絶対に。

川口：	で、すごいその話が、すごい僕リアルに感じるのは、アジャイルUXの最初の頃って、UXの部署、専門家の人達と、開発の専門家の人達
      をどうやって組み合わせるか、っていうのが最初、パラレルトラックアプローチってのが割と言われていて、
      どうやるかっていうと、スプリント、イテレーションって期を合わせて、クロスに、前の成果、ユーザ調査の成果が出たらそれは次の
      スプリントで開発に渡って、で開発が終わったらそれが次のスプリントでユーザのテストするUXチームに渡す。
      これを組み合わせるとメッシュ状にこう、仕事を受け渡して仕事が上手く一緒に出来るよ、と。
      これが当初言われていたパラレルトラックなんですけど、
      今回のカンファレンスでは誰もパラレルトラックを言って無いんです。アジャイルUXのカンファレンスでは。
      みんな言ってるのはチームの中にどうやってUXが入るのか。とチームの人達、UXの人達がどうやってプログラムを学ぶか。
      どうやってビジネスラウンドと一緒にやっていくか、っていう話をしていて、もう全然、こう何かくっつき具合がだいぶ進んできたな〜と。
      それはこの3年位でだいぶ感じましたね。変化が出て来た気がします。
  • ピボットする軸の幅、コアを見極める。
    • 間違った人にインタビューすると悲しい気持ちになる･･･
      • 何分聞こうが意味がない瞬間なんてもう
  • 何を採用したら採用障壁が下がるのか、という部分に気付かない恐れ

ディスカッションの時間ははあっという間に過ぎ、懇親会へ。時間的にはそこまで長くはありませんでしたが、普段自分が勉強会で参加してる分野以外の方々が多い印象で、新鮮でした。

この分野については座学も大事ですがまずは実践！回せる部分から回してフィードバックを得て･･･という事をして行かないとな感じですね。UX然りユーザビリティ然り、自分の中でも関連本は結構購入している(んであまり読み進められてない...^^;)ので、情報を整理しつつ、実践的な作業が出来るように勉強を進めていきたいな〜と思う次第です。


その他関連：