Agile UX NYC 2012 Redux in Tokyo (#AgileUXNYC_ja)

「AgileUX NYC 2012 Redux in Tokyo」とは？

2012/02/25に、アメリカのニューヨークで開催された「AgileUX NYC 2012」へ参加された＠kawaguti さん(アギレルゴ・コンサルティング株式会社　川口恭伸さん)と＠sprmari0 さん(楽天株式会社　坂田一倫さん)による報告会を兼ねたパネル・ディスカッションです。

私はAgileUX NYC当日の＠kawaguti さんのツイートを見ていて、AgileUX NYCの内容に興味を持ち、ATNDでこのイベントを発見して、すぐに参加登録しました。

AgileUX NYCについての＠kawaguti さんと＠sprmari0 さんのツイートに、一部意訳を交えたものをこちらにまとめています。

AgileUX NYC 2012 #agileuxnyc ほぼ＠kawaguti さんつぶやきまとめ  Yukarin’Note

AgileUX NYC ハイライト

最初の30分は、実際にAgileUX NYC 2012へ参加された@kawaguti さんと@sprmari0 さんが、AgileUXの各セッションの紹介や感想について話されました。

AgileUX NYC 2012について

AgileUX NYCは、今年からはじまったAgileUXにテーマを絞ったイベントだそうです。 参加された方も、アメリカ特にニューヨークを中心とした東海岸から来られた方が多かったそうです。@kawaguti さん曰く「デザインだけで食っていける」ほどニューヨークは、UXへの関心が高くお国柄?らしく、デザイナーの需要が高く、そういった背景からAgileUXが開催されたようです。

AgileUXは、1セッション20分×3セッション、その間にコーヒーブレイクやランチを挟んで、朝8時から夕方5時までぶっ通しの、非常にタフなイベントだったそうです。

登壇された方も興味深いポジションの方が多く、UX デザイナーがいれば、経営者やデベロッパー、そしてデザイナーからマーケティング PR の担当者の方々でした。Early Stage Specialistなんていう、スーパーマンのような方もいらっしゃったようです。

Want to Win with Agile? Pivot Your Culture First

Want to win with agile?
View more PowerPoint from eburd

The Laddersの Vice President of ProductのEric Burdさんのセッションでは、Agileで成功するためには、まず組織文化をピボットする必要性が紹介されていました。

組織へAgileUX/LeanUXのコンセプトを導入するために、以下のポイントを挙げられたそうです。

  1. Find a fire/Start a fire （発端を探す、火を灯す）
  2. Listen to customers （ユーザの声を聴く）
  3. Get sales in to the action （セールスを巻き込む）
  4. Train the executive team （常務陣を教育する）
  5. Words matter （言葉がすべて）
  6. Small wins （小さな成功を）

そして、技術やプロダクトのチームだけでなく、営業などの関係する部署を集め共通の課題を提示することが必要である。

“Small Wins”（小さな成功）に成りうるものを探して、成功させ、そこから得たものを組織に蓄積することが重要、とのことです。

このセッションの内容に付随して、@kawaguti さんが紹介していたのですが、 海外ではBrown Bag Lunch Meetingという、ランチミーティングが盛んに行われているそうです。

Developers Summit 2012のセッションでも紹介のあったFuture Centerの様に、色々なバックグランドを持った人が集まり話し合う機会・場が求められている、ということでしょうか。

Brown Bag Lunch Meetingについては、こちらに紹介がありましたので、参照ください。

Investing in Design: Horsepower vs. RPMs

Agile UX NYC -- 4 keys to success in a design driven company

「スキルセットではなく、マインドセットの問題だ」という言及がありました。

Replacing Requirements with Hypotheses

2012 feb 25 agile ux nyc, seiden, requirements to hypotheses

このセッションで強調されていたことは、「要件を仮説に置き換える」ことです。

ビジネスサイドのニーズがそのまま開発サイドへ要件として伝わってしまうことで、本来の顧客のニーズを把握できなくなるという弊害がおこります。

要件を仮説に置き換えることで、@kawaguti さんのツイートにもあったのですが、

という特性が発揮されます。仮説を検証するサイクルが生まれます。

そしてこういったプロセスが言語化されることが最も評価できると@kawaguti さんも話されていました。

Quick, Visual, Collaborative and Continuous

Quick, Visual, Collaborative & Continuous

このセッションのスピーカーのLane Halleyさんはデザイナーなのですが、「開発サイドを理解するためにプログラミングを独学で学んだぜ！」と言って拍手喝采を浴びた、コミュ力の高い方なんだとか。

ペアインタビューをして、複数の人（デザイナやUX担当だけでなく、エンジニアを含めて）がインタビューを聞き、それをノートに取るようなスタイルが紹介されていました。 そして、部署や役割に縛られず「速く、視覚的に、協調的に、継続的に」行うこのが重要、とのことでした。

Product Ownerチーム(エンジニアも入るがあくまでアーキテクト程度のみ)が大まかな部分を作り、そこから複数のチームに別れ、POチームメンバーだったデザイナがそのまま複数チームに分かれて所属するスタイルが紹介されていました。

Learning to Play UX Rugby

Learning to Play UX Rugby

UXデザイナーはAgileな現場においてもウォーターフォールな働きをしており、それはリレーのように個別に走ってバトンを繋いでいく状態になっている。

AgileUXとは協調中心設計(Collaboration Centerd Design)と紹介されており、ラグビーの様に各々のプレイヤーが走り、縦横無尽にパスが交わされるようになる。

Better. Faster. UXier. AToMIC Design

Better. Faster. UXier.  AToMIC Design

イテレーティブな開発では、機能の開発改善には強いが、デザイン変更に弱さが現れる場合が多い。変更に強いAToMIC Designが必要。 デザインの戦略をはじめに決めることで、共通化されたデザインをアセットとして管理する。

デザイナがプログラミングスキルを（共通言語として）身に付けることで、開発サイドとの会話・意思疎通が迅速になるそうです。

Demystifying Design: Fewer Secrets, Greater Impact

UXデザインは未だブラックボックスな状態になっている。 デザイナ以外の人間にとって、UXデザインは過程が不明であり、このような状態では信頼を勝ち取ることはできない。

デザインは様々な要因(ビジネスとユーザのニーズ、ユーザビリティ、ブランド等)が絡み合っており簡単ではないが、 頻繁に成果物を見せ、学んだことをシェアする必要がある。

そのために、UXデザイナは「医者が話すように、他人が理解できる言葉」で話す必要がある。

まとめ

UXにはメンタルシフトが求められている。

Requirements(要件)はHypothesis(仮説)へ、

Design(デザイン)はExperiment(実験)へ、

Outputs(成果物)はOutcomes(結果）となる。

ここで言われているOutputsは作成されたプロダクトであり、 Outcomesはそのプロダクトをユーザが使うことでもたらされた（得られた）ものを指すそうです。

“We are being invited,but we are not inviting them to ours.”

開発チームはUXを一緒のチームへ招待しているが、UXは開発チームを招待していない、と締めくくられていました。

パネルディスカッション

後半30分は、LeanStartupJapanの和波俊久さん、利用品質ラボの樽本徹也さんをパネラーに向かえ、パネルディスカッションとなりました。

ディスカッションの内容を大まかに紹介します。

樽本徹也さん(以下、樽)：これまでは開発がウォーターフォールだったから、UX・UCDもウォーターフォールだった。だがこれからは、開発がAgileになる、だからUX・UCDもAgileになる。これはUX・UCDが自発的にAgile化したのではなく、開発サイドの変化に強いられた結果だ。今後日本でもAgileへシフトする、だからUXはAgileを学ぶべきた。

和波俊久さん(以下、和)：AgileはProjectの中で完結するものであり、終わりがある。だがStartupは終わらない。終わらせ方を知りたい。

坂田一倫さん(以下、坂)：UXデザイナはエゴで仕事をしていないだろうか？DevelopmentがUXについて学んで来ており、DevelopmentとBusinnessのロールだけで開発が回るようになってきている。UXとして危機感を持っている。現状の職場ではUXはDevとBizと分断された状態になっている。

樽：セクションごとに分けずにプロジェクト単位で、UXもDev,Bizと一緒になってやるべきた。

坂：現状プロジェクト単位に分かれているが、入っていくステージが違う。同時ではない。

樽：同時に入れていればLeanStartupになる。

和：株式会社である以上、決算が必要。決算をするにはどこかで定量的に見せなければいけない。そこがBlackBoxのままではいけない。報告のうまい仕組みが必要。

川口恭伸さん（以下、川）：予算がひずみを生んでいる。予算は結果としてもちろん付いてくるものだが、Beyond Budgeting Modelのようにマイクロな計測をして適宜見直しを行えば良い。経営はDashBoardで確認が取れれば問題ない。

川：Leanにおいては、バーンレ-トがあり、資金が生きているうちにイノベーションを起こせるかが鍵になっている。

Q&A

Q:顧客開発のためのPDCAについて、何かインプットがあれば共有いただきたいです。特に顧客セグメントの仮説立案のTipsや、スケーラビリティを意識した検証方法などありましたら、お願いします。

A: 和：課題をセグメントしていく

川：

坂：Lean Work Shopに参加した際は、 　　　・自分が使うサービスを出す 　　　・ペルソナを4つ作る 　　　・セグメントの人に検証のためのインタビューをする 　　　・セグメントが存在するか検証する？ 　　　 川：開発者でなければわからないこともある。だから壁があったら負け。

樽：インタビューは誰にでもできる。全ての人が常に同席することは難しくとも、インタビューを録音・速記して、全員が見聞きできるようにする。そうすればアイデアは出てくる。

川：ウォーターフォールは科学的根拠を重視する。「統計的に5人以上ヒアリングする必要がある」だとか。Agileではアイデアが出るのなら（体験的に）少人数でも問題ないとわかっている。

樽：データの精度よりもアイデア。アイデアを出し、動かして、検証する。なぜなら結果が全てだから。

川：正にOutputsではなく、Outcomesが重要。

樽：どんなものでも売れなければ意味が無い。だから作りながら売るべき。従来型の作ってから営業が売りに行くでは遅い。売れなければ、途中でピボットすればいい。作りながら売っていればそれが出来る。

和：最初から”学ぶ気持ち”でいることが重要。フィードバックを得ることを前提に動いているからこそうまくいく。

樽：開発者は今後UXを学ぶ。UXだけでは立ち行かなくなる

川：如何にチームに入っていくかが重要。

坂：インタビューに併せて、その人がコアユーザかどうかも見極める必要がある。製品・サービスのコアが何かを見極めて、ピボットの幅を考える。

和：コアじゃないユーザのインタビューはかなしくなる。エバンジェリストユーザを見つけることが大事。

和：インタビューでは、採用障壁を下げるインタビューをしなければならない。インタビューされる側は現状で考えている。採用障壁を下げることですんなり採用されるパターンは多い。

川：「これを他人に勧めたいか？」という質問がいい。

最後に

このイベントを通して、これまでビジネス側にとって開発側がブラックボックスだったように、今までブラックボックスだったUX・デザインが透明化・協調化されようとしている雰囲気が伝わってきました。 私は開発者なので、UX・デザインについての見識が浅いですが、Businness, Development, UXが溶けてバターになれるよう、UXを学ぼうと改めて思いました。