第9回 新横浜ユーザビリティ研究会「アジャイルUX」2012年04月24日

4月24日に開催された、
新横浜ユーザビリティ研究会に参加してきました。

いつもはHCD周りのネタが多いのですが、
今回はアジャイルということで、いつもと若干参加メンバーも違うようです。

■アジェンダ
 16:00 イントロ
 16:10 「アジャイルゲーム」 川口さん
 16:25 「アジャイルUX?その先のためのUX/UCD」 樽本さん
 17:15 ディスカッション
 17:30 終了

「イントロ」

 ・参加メンバー 70名
 ・ほとんどが始めて参加するメンバー
 ・新しい校舎のこけら落とし

「アジャイルゲーム」

 楽天 川口さん

 ▼プランニング・ポーカー

  アイスブレイクもしつつ、
  簡単なワークショップをします。

  アジャイル→ボスがいない。
  チームとしてどう成果を上げるか?(みんなで働く)
   →となりの人がどう働いているか、を共有する。

  ちゃんとやると、夫婦生活と一緒で、上手く行く。

  5人以内のチームを作る。

  アジャイルのワークショップは基本的に
  「タイムボックス」で行う。
 

 ▼プランニングポーカーの目的
  →チームで合意する。

  異なる見解を早めに出す。
  (初期の段階なので、要件がかたまってないこともある)

 ☆課題
  新横浜から個々までの距離は?
  学校の入り口から教室までを1とすると

  プランニングポーカーのカードを一人一人で出してみる、
  検討したあとにまた出す

結局合意しなかった・・・

「アジャイルUX?次の10年のためのUX/UCD」

 樽本さん

■UX屋さんの物語
 ▼ウォーターフォール時代
  →デザイナーやリサーチャーがそれぞれ集まった部署があり、
   UX屋が企画しても
   提案したうちの2割ぐらいしか実現しない。
   (炎上したり、ステークホルダーで止まったり?)

 ▼アジャイルの時代
  ・機能別や役職別のグループは作らない、全員同じ部屋で仕事をする。
   (エンジニアとデザイナーのペアプロ)

  アジャイルのスプリントは2週間が基本
  →2週間のうちに終わらないといけない(タイムボックス)
   週か日が単位(月単位ではない)

   ほぼ全部実装される。
  
 ▼リーン時代
  Build → Measure → Learn の繰り返し
 
  不況が来たため、数億円の規模の案件はなくなっていった。
  そのため、小さな規模の製品をすぐに作り、
  ユーザーの元に届けて、フィードバックを貰い、修正する。

  ※UCDとそっくり

  彼らはUXの専門家ではないので、
  ユーザーリサーチなどは稚拙、でもできている。

  ※「UX Biz Dev」の要素がやっと揃うようになった。

 ▼アジャイルUXの潮流
  アジャイルとUCDを統合したもの。

 ▼UCDの流れ
  (1)調査
  (2)分析
  (3)設計
  (4)評価
  (5)改善
  (6)反復

 ▼アジャイルの基本的な流れ UX/UCD in 201X View more presentations from Tarumoto Tetsuya

  3ヶ月間で製品を出す、
  大きな輪っかは30日、
  小さな輪っかは24時間。

  アジャイルでは要件定義を書かないことが多い、
  ユーザーストーリーとして書くことが多い(スプリントバックログ)

  それを6回繰り返すことで製品としてリリース

  ※両方ともなんな似ている
   →フィードバックループをかけている

 ▼Agile meets UX!
  果たして「お似合い」の相手なのか?
  
  2002年ぐらいから一緒にやり出した。
   →現実に色々やってみると、問題が出てきた。
    (UX側に)

 ▼UXの習慣 その1
  UXだと6ヶ月ぐらいが普通だが、Agileだと長過ぎる!!
  (アジャイルだと3ヶ月でリリースするため)
  
 ▼UXの習慣 その2
  ユーザリサーチャー
  IA
  インタラクションデザイナ
  ユーザーインタフェースデザイナ
  ユーザビリティエンジニア

 ▼UXの習慣 その3
  ドキュメントが大好き

  ・調査報告書
  ・テストレポート
  ・画面仕様書

  →従来の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 勃発!」

  アランクーパー
   →ユーザーエクスペリエンスを小さな単位で作ったら、
    一貫性がなくなるのでは?

  ケント
   →じゃあどうすんの?

  アラン
   →ユーザーを調査して、ペルソナを作って、

  ケント
   →どれぐらい時間がかかるの。

  アラン
   →3ヶ月ぐらいあれば十分だよ。

  ※決裂したように思えた。
   →開拓者が現れた。

 ▼AgileUXの考え方
  内から外へーー中核部分から始めて、徐々に周辺部分へ

  例:デコレーションケーキ
    UX→下のホールから作る。

 ▼パラレルトラックアプローチ
  UXがちょっと先行する。

 ▼ユーザーリサーチ
  軽い手法で行うーー「ゲリラリサーチ」手法

 ▼AgileUXの潮流から2年たった
  →2年前のhcd-netでセミナーを行った。
   ↓
  リーンスタートアップの潮流がやって来た!

 ▼リーンスタートアップ
  開発→製品→販売→

  もし、その製品を誰も欲しがらなかったら?
   →それは営業、マーケの責任では?という人がいる。

  確かに営業やマーケを強化するのも作戦の一つだが、
  製品が開発できなくて潰れたスタートアップは一つもないが、
  製品が売れなくて潰れたスタートアップは山ほどある。

 ▼リーンの考え方
  (1)正確にまとを狙って矢をいる
     →時間がかかる
  
  (2)討った矢を軌道修正できるとしたら・・・
     →物理的な矢は無理だが、ソフトウェアでは可能。
      (Ruby on やクラウド)

 ▼製品開発をしながら、顧客開発をする。
  ユーザー調査をして、プロトタイプを作って、
  ユーザーに聞いてみる
   →作りながら売る
 
 ▼MVP
  Minimum Viable Product
  ・ダミー広告
  ・ペーパープロトタイプ
  ・動画
  ・コンシェルジュMVP
  ・オズの魔法使い
   etc・・・

  スタートは本当に小さいサービスやユーザーでいい。(50人や100人)
  ただし、急速に成長する必要性がある。
  →だが、ある段階で成長が止まるときがある。

 ▼Pivot
  どんなに「チューニング」しても目標が達成できない時はPivotを検討する。
 
 ▼「Build – Measure – Lean 」
   IDEAS → BUILD → PRODUCT → MEASURE → DATA → LEARN
   このサイクルを高速回転させる。

 ▼201X年のUX/UCD
  ユーザー中心にデザインして、アジャイルに開発して、
  リーンにマネジメントする。
  これができないと今後は辛くなる。

  ※だが、これができても必ず成功するわけではない。

 ▼リレー競争モデル
  Bizが企画、UXが調査して、Devが実装。

  バトンを渡しているのでウォーターフォール

 ▼ラグビーモデル=リーン / アジャイル
  「UX・Biz・Dev」複数のことをこなす必要がある(クロスボーダー)
   →チームとして必要な能力を発揮する。

  ※これからは「チームのために」がキーワード。

質問タイム

 ▼実際にやっているが2点苦労していることがある。
  
  (1)Pivotしたり作り替えたりすると、品質を確保するのが難しい
     
     →テストの技法が進化しているので、それを取り入れて行く
       ・ユニットテスト(自動化できる)
       ・受け入れテスト
        →ユーザーから見た振る舞い(だいぶ自動化は進んでいる)

    ※ただ、受け入れテストを実施するためには、
     仕様が決まってないといけない。
   

  (2)受注だと、アジャイル的に契約が難しいことがある。

    →相見積もりとかだと難しいので、
     お客さんとの信頼関係を作るしかない。

     ※Pivotした時のコードは捨てることが多い。

  ▼パラレルトラック
   ユーザーリサーチに一ヶ月かかると言われているが、
   それはやるべきなのか?
   それともその人のことは信用しないべきなのか?

    →案件にもよるけど、一ヶ月ならやるべきでは。

  ▼サービス開発
   色んな人へのサービスになりがちだが、
   ペルソナを作ってるが、上手く行ってない、
   ペルソナが信用されていない。

    →ペルソナは使われない
     うさんくさいから。
     ステークホルダーと一緒に作らないからそうなる。

     開発者やステークホルダーをペルソナ作りに巻き込む。
     これからはUXを教えることが重要になるのでは。

参考資料

  ・「Scrum in 10 minits」

  ・アジャイルUX物語

コメント

タイトルとURLをコピーしました