4月24日に開催された、
新横浜ユーザビリティ研究会に参加してきました。
いつもはHCD周りのネタが多いのですが、
今回はアジャイルということで、いつもと若干参加メンバーも違うようです。
■アジェンダ
16:00 イントロ
16:10 「アジャイルゲーム」 川口さん
16:25 「アジャイルUX?その先のためのUX/UCD」 樽本さん
17:15 ディスカッション
17:30 終了
「イントロ」
・参加メンバー 70名
・ほとんどが始めて参加するメンバー
・新しい校舎のこけら落とし
「アジャイルゲーム」
▼プランニング・ポーカー
アイスブレイクもしつつ、
簡単なワークショップをします。
アジャイル→ボスがいない。
チームとしてどう成果を上げるか？（みんなで働く）
→となりの人がどう働いているか、を共有する。
ちゃんとやると、夫婦生活と一緒で、上手く行く。
５人以内のチームを作る。
アジャイルのワークショップは基本的に
「タイムボックス」で行う。
▼プランニングポーカーの目的
→チームで合意する。
異なる見解を早めに出す。
（初期の段階なので、要件がかたまってないこともある）
☆課題
新横浜から個々までの距離は？
学校の入り口から教室までを1とすると
プランニングポーカーのカードを一人一人で出してみる、
検討したあとにまた出す
結局合意しなかった・・・
「アジャイルUX?次の10年のためのUX/UCD」
■UX屋さんの物語
▼ウォーターフォール時代
→デザイナーやリサーチャーがそれぞれ集まった部署があり、
UX屋が企画しても
提案したうちの2割ぐらいしか実現しない。
（炎上したり、ステークホルダーで止まったり？）
▼アジャイルの時代
・機能別や役職別のグループは作らない、全員同じ部屋で仕事をする。
（エンジニアとデザイナーのペアプロ）
アジャイルのスプリントは２週間が基本
→２週間のうちに終わらないといけない（タイムボックス）
週か日が単位（月単位ではない）
ほぼ全部実装される。
▼リーン時代
Build → Measure → Learn の繰り返し
不況が来たため、数億円の規模の案件はなくなっていった。
そのため、小さな規模の製品をすぐに作り、
ユーザーの元に届けて、フィードバックを貰い、修正する。
※UCDとそっくり
彼らはUXの専門家ではないので、
ユーザーリサーチなどは稚拙、でもできている。
※「UX Biz Dev」の要素がやっと揃うようになった。
▼アジャイルUXの潮流
アジャイルとUCDを統合したもの。
▼UCDの流れ
（１）調査
（２）分析
（３）設計
（４）評価
（５）改善
（６）反復
▼アジャイルの基本的な流れ UX/UCD in 201X View more presentations from Tarumoto Tetsuya
３ヶ月間で製品を出す、
大きな輪っかは30日、
小さな輪っかは24時間。
アジャイルでは要件定義を書かないことが多い、
ユーザーストーリーとして書くことが多い（スプリントバックログ）
それを６回繰り返すことで製品としてリリース
※両方ともなんな似ている
→フィードバックループをかけている
▼Agile meets UX!
果たして「お似合い」の相手なのか？
2002年ぐらいから一緒にやり出した。
→現実に色々やってみると、問題が出てきた。
（UX側に）
▼UXの習慣 その１
UXだと６ヶ月ぐらいが普通だが、Agileだと長過ぎる！！
（アジャイルだと3ヶ月でリリースするため）
▼UXの習慣 その２
ユーザリサーチャー
IA
インタラクションデザイナ
ユーザーインタフェースデザイナ
ユーザビリティエンジニア
▼UXの習慣 その３
ドキュメントが大好き
・調査報告書
・テストレポート
・画面仕様書
→従来のUCDは典型的なウォーターフォール
Agileとウォーターフォールは水と油
▼Agile
The New New Product Development Game by Takeuchi, Nonaka(PDF)
→この論文をもとにスクラムが作られた。
Agileはシステム、設計、テスト、コーディングを同時にスタートする。
▼インクリメンタルとイテレーティブ
“User Story Mapping” by jeff Patton
Agile
UCD
▼アジャイル宣言
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
▼ケント・ベック VS アラン・クーパー
「Extreme Programmingu vs Interaction Design 勃発！」
アランクーパー
→ユーザーエクスペリエンスを小さな単位で作ったら、
一貫性がなくなるのでは？
ケント
→じゃあどうすんの？
アラン
→ユーザーを調査して、ペルソナを作って、
ケント
→どれぐらい時間がかかるの。
アラン
→３ヶ月ぐらいあれば十分だよ。
※決裂したように思えた。
→開拓者が現れた。
▼AgileUXの考え方
内から外へーー中核部分から始めて、徐々に周辺部分へ
例：デコレーションケーキ
UX→下のホールから作る。
▼パラレルトラックアプローチ
UXがちょっと先行する。
▼ユーザーリサーチ
軽い手法で行うーー「ゲリラリサーチ」手法
▼AgileUXの潮流から２年たった
→2年前のhcd-netでセミナーを行った。
↓
リーンスタートアップの潮流がやって来た！
▼リーンスタートアップ
開発→製品→販売→
もし、その製品を誰も欲しがらなかったら？
→それは営業、マーケの責任では？という人がいる。
確かに営業やマーケを強化するのも作戦の一つだが、
製品が開発できなくて潰れたスタートアップは一つもないが、
製品が売れなくて潰れたスタートアップは山ほどある。
▼リーンの考え方
（１）正確にまとを狙って矢をいる
→時間がかかる
（２）討った矢を軌道修正できるとしたら・・・
→物理的な矢は無理だが、ソフトウェアでは可能。
（Ruby on やクラウド）
▼製品開発をしながら、顧客開発をする。
ユーザー調査をして、プロトタイプを作って、
ユーザーに聞いてみる
→作りながら売る
▼MVP
Minimum Viable Product
・ダミー広告
・ペーパープロトタイプ
・動画
・コンシェルジュMVP
・オズの魔法使い
etc・・・
スタートは本当に小さいサービスやユーザーでいい。（５０人や１００人）
ただし、急速に成長する必要性がある。
→だが、ある段階で成長が止まるときがある。
▼Pivot
どんなに「チューニング」しても目標が達成できない時はPivotを検討する。
▼「Build – Measure – Lean 」
IDEAS → BUILD → PRODUCT → MEASURE → DATA → LEARN
このサイクルを高速回転させる。
▼201X年のUX/UCD
ユーザー中心にデザインして、アジャイルに開発して、
リーンにマネジメントする。
これができないと今後は辛くなる。
※だが、これができても必ず成功するわけではない。
▼リレー競争モデル
Bizが企画、UXが調査して、Devが実装。
バトンを渡しているのでウォーターフォール
▼ラグビーモデル＝リーン / アジャイル
「UX・Biz・Dev」複数のことをこなす必要がある（クロスボーダー）
→チームとして必要な能力を発揮する。
※これからは「チームのために」がキーワード。
質問タイム
▼実際にやっているが２点苦労していることがある。
（１）Pivotしたり作り替えたりすると、品質を確保するのが難しい
→テストの技法が進化しているので、それを取り入れて行く
・ユニットテスト（自動化できる）
・受け入れテスト
→ユーザーから見た振る舞い（だいぶ自動化は進んでいる）
※ただ、受け入れテストを実施するためには、
仕様が決まってないといけない。
（２）受注だと、アジャイル的に契約が難しいことがある。
→相見積もりとかだと難しいので、
お客さんとの信頼関係を作るしかない。
※Pivotした時のコードは捨てることが多い。
▼パラレルトラック
ユーザーリサーチに一ヶ月かかると言われているが、
それはやるべきなのか？
それともその人のことは信用しないべきなのか？
→案件にもよるけど、一ヶ月ならやるべきでは。
▼サービス開発
色んな人へのサービスになりがちだが、
ペルソナを作ってるが、上手く行ってない、
ペルソナが信用されていない。
→ペルソナは使われない
うさんくさいから。
ステークホルダーと一緒に作らないからそうなる。
開発者やステークホルダーをペルソナ作りに巻き込む。
これからはUXを教えることが重要になるのでは。
コメント