2012/03/14に行われた『AgileUX NYC 2012 Redux in Tokyo』のノート。これは前半のAgileUX NYレポート分。非常に濃かったです。
◆Eric Burd
◇same problem statement
1. アジャイルやリーンはテクノロジやデザインというチームにフォーカスを当てがち。
2. だが、HRやマーケティング・セールスなどの関係部署にもアプローチする。
3. 全社的にみて共通の課題はなんだったかということを重視し、定義する。
◇ステークホルダーをどう巻き込むか？
1. ステークホルダーは忙しいのでなかなかプロジェクトに巻き込めない。
2. ランチはあるので、このランチ時間を借りる。
3. ユーザを呼んでその一時間でセッションをする。
4. これを週一で行ない、ユーザのフォローをしている。
◇スモールウィンを探す
・小さな成功を社内に探し、成功させ、エッセンスを社内に確立する。
・どこまでいったらこれサクシードだよねっていうのを見極めて探す。
・顧客やらビジネスプロジェクトやら、どこから導き出されたものかって言うのを整理する。
◆Phin Barnes
◇investing in design
デザインに投資するという、インベスターによる話。
・社内に導入するには、果たして私達にできるのだろうかというハードルや壁がある。
・アジャイルという言葉になじみがある人達にそういう壁がある。
・スキルセットではなくマインドセット。
・デザインはカスタマーデベロップメント（顧客開発）という原点をリードする立場にならないといけない。
・じゃあ組織を動かすものってなんだろう？定性データ？定量データ？
・データを見据えるだけではなくて、どのようなインサイトが組織内に成果をもたらし動かすのかっていうのを考えていく必要がある。
・（単なる）成果をもたらすものとしてではなく、持続的な文化として発信していく。
・リーンスタートアップでいうところの、カスタマーディスカバリー・バリデーション・クリエーション・ビルディングっていうのを回していくというのを我々の作業に落とすと、課題定義・スケッチ・プロトタイプ・ソリューションの改善・最適なソリューションの開発っていうのを回していく。そういったことを推奨していた。
※ Phin Barnes の発表について、坂田氏が気になった点
共通課題をどう見せていくかというのでダッシュボードが採用されていた。
・数字は継続的にアップデートされていて、全社員で見れるようになっている。
・ダッシュボード化 = tamgible（触れるようになっている）
・この数字をカスタマーデベロップメントサイクルで改善していく
・↑が結果的に１つの文化になっていく。
◇定量データは、もはや遅れている
・我々はデザインドリブンの会社であり、もはや遅い。全然響かないし新しくない。
・次は、定性的な要素を加え、コンテキストを導入することが人を動かす力になるのではないか？
※アジャイルではダッシュボードが流行っている。リーンスタートアップでも最後のメトリクスが重要視されていて、定性定量も含めてインフォグラフィックスのような一枚絵、しかも自動で更新されるものをみなで見て判断を下す。そういう文化である。
◆Josh Seiden
◇要件を仮説に置き換える
1. アジャイルやリーンのコンセプトを社内に導入するにはそもそも要件という考え方じゃ駄目。
2. 要件は断固たるもので、いくら我々がUCDプロセスとか回したとしても変えることは不可能or困難。
3. 仮説はもちろん仮説なので正しくない。検証していく必要がある。
4. これにより不確実性がエッセンスとして取り込まれる。
5. それゆえにテストしたり学ぶ姿勢をチーム全体が保ってくれる、という力がある。
◇要件について
1. ビジネス責任者のこれがやりたい、というニーズはそのまま要件として認識される。
2. それを元に作業する人達は、その背景にあるユーザやマーケットニーズを知るすべが無い。
3. 要件ではビジネス側が要件を考えて、それを開発やデザイナが作るという風になる。
4. フェーズが完全に切り分けられてしまうが、それはウォーターフォールではないか？
◇ケーススタディ - アプリのインストーラー
1. 我々の顧客は無料で提供されているインストーラに価値を見出すのではないか？という仮説。
2. 具体的に何を造ればいいかを頭に浮かべる。
3. それをいくつかのsub-hypothesisにブレイクダウン。
4. テストを早く回せる感じのミニシナリオを作る。
5. インストールのプロセスが早ければ、顧客は無料のアプリをダウンロードするのでは？となる。
6. 仮説は検証するため、mbpで最小限にこれを達成する方法を考える。
7. インストーラをサポートするような画面や機能が必要なのではないか？となる。
8. 結果として、最初の要件とは全然違っている。
※mbp - minimum variable product。リーンスタートアップの概念。
◆Lane Halley
もともとデザイナー。どうやったらアジャイルと一緒にやれるのか？を考えてきた人。
デザインの立場になってアジャイルやリーンスタートアップをとらえてみた、という話。
◇デザインのアプローチが変わってきている
・デザインをチーム全体の責任にする必要がある。
・デザインというロールが変わってきている。
・部署や役割という垣根を越えたデザインが必要 = cross functional pairingを使う。
・デザイナーはプロジェクトのファシリテーターになるのではないか？
・デザインしているプロダクトやサービスの担当・責任を任せることができるチーム（プロダクトオーナーチーム）を作る。
◇cross functional pairing
1. デザイナ（特にフロント・ミドルエンドと呼ばれる場所のエンジニア）とペアで開発の人が実際に一緒になって作っていく。
2. 結果的に、クイックにビジュアルにすぐに形になる。
3. で、協力的・持続してcontinueousというのが可能になった。
※crossやコラボレーションがキーワード。
※ステージの最初からペアで行うなら、チーム体制を意識する必要がある。
◇インタビュー法
・early provisional persona - 本当に影も形も無いような、雑な仮説ベースを作る。
そういうセグメントがいるのでしたっか？というのをインタビューする。
・pair interviewing - インタビューはデザイナーだけではなく全員でやる。
・mutliple note takers - 1人に任せてノートを取らせない。あらゆる視点からノートをとり、気づきをシェアするという、
UXだけじゃなくてデベロッパも一緒にやる。同じ cross function paring の人もいれる。
◇プロダクトオーナーチームとcross functional paring は彼女達が作った仕組みに密接に関連している
1. プロダクトサービスの担当とコアのUXの人達と、開発者はアーキテクトくらいしか入っていない。
2. そのチームが製品全体を設計している。
3. デザインの骨格共通のデザインの部分も設計している。
4. ↑のフェーズが終わったら、各モジュールを作る。
l※デザインのコアをやった人がそのまま降りて、チーム（開発者）の横にいるようなペアを組む。
※ペアプログラミングはアジャイルでは良く言われるが、ここは、開発者同士ではなくてデザイナとやるという新しいやり方でやっている。
◆Anders Ramsay
アジャイルが良くするものは何かを突き詰めたものは、UXRagbyという表現になるのではないか。
◇リレー
1. トラディショナルな開発式、WaterFall。
2. 一人一人が走って、次の人にバトンを渡してじゃあどうぞって感じで、ハンドオーバーをしている。
◇ラグビー
1. 数人単位でボールを追いかけていて、トライをして、またトライを狙いにいくみたいな感じで連続したプレイを続けるスポーツ。
2. まさにアジャイルってそれなんじゃないか？と。
3. ラグビーのパスは言ったりきたりするが、まさにチームでもそう。
4. ペーパープロトから開発、というプロセスもバックアンドフォースのパスといった感じで、やっていくべきでは。
◆Jennifer Gergen
仕事をするためにプログラミングを自分で学んだということで拍手喝さいを浴びていた。
アジャイルUXをUXあるいはデザイナー側から対面している人。
◇デザイナーとプログラミング
・全部のプログラムを組めるようなスキルがあるわけではない。
・自分が少しプログラムを組めることで、会話がすごく円滑になる。
・ものすごく早くアウトプットが出る。
◇開発とデザイナのクロスファンクショナルペアリングをどうやってやっていくべきか
・イテレーションは機能とかページの開発には優れている。
・イテレーションは影響範囲が測定しづらい大きなデザインの変更には向いていないのでは？
・策としてAToMICデザイン（asset to markUp iterate colaboration）を提案する。
◆まとめ
◇UX/UXデザインはどう振舞うべきか -> demystifyする
1. 現在のUXデザインは、中で何が行われているかわからないブラックボックス状態である。
2. チームメンバーUXデザインってマジックみたいだよね、と考えている。
3. デザインは一筋縄ではいかない。いろいろ考えながら一本の縄を歩いているような状態。
4. だからこそ、ブラックボックス状態では納めない。
5. 頻繁に成果物を見せながら学んだことをプラスアルファしてシェアしていく必要がある。
◇共通言語で話す
・医者のように、他人が理解できる言葉で話すということを推奨。
◇要件と仮説
・要件は仮説になるべき。
・デザインは仮説を検証する実験になるべき。
・成果物は実験の結果。
◇その他
・UXにはメンタルシフトが必要。
・我々が日々していることを、スキルセットではなくマインドセットへのメンタルシフトを通して現場レベルに落とし、実行していく時代なのではないか？
◆補足
話の中に出てきたけど、放り込む場所が無かったものをここに記載。
◇アウトプット（成果物）とアウトカム（結果）の違い
・アウトプットはできたもの。
・アウトカムはそれを使ってユーザが何を得たか。
◇Jennifer Gergenがプログラムを学んだという件について
・デザイナーがプログラミングを学んでいるということに対して需要が高まってきている。
・デザイナーがプログラミングにシフトしつつある。
◇デザイナーは開発から招待されているが、デザイナーは彼らを招待していないのではないか？
・プロセスやコンセプトを理解して一緒に作業しよう、という風に招待をしていないので、コラボレーションが難しくなっているのではないか？
坂田一倫様、川口恭伸様、お疲れ様でした。
0 件のコメント:
コメントを投稿