タツオチップス

最近は https://note.com/tatsuosakurai に書いてるかもです

Agile meets UX ジュンク堂トークセッションメモ

ざっとメモ書き。
@garden_tree さんに教えてもらって参加。とても素晴らしいトークセッションでした。あそこで Agile meets UX を体感した感じ。TokyoRubyKaigi05の発表を去年のデブサミの廊下で @bash07 さんとしにいった時に、樽本さんと川口さんがお話していて、そこから RubyKaigi2011 の「アジャイルUX公開実演」になって、それを受付スタッフやりながら、地下門番をしつつ、ちょこちょこ見ていたのを思い出しました。ストーリーというもの(いろんな文脈のストーリーがあるけど)が好きで、最近買ったユーザエクスペリエンスのためのストーリーテリングの訳者の脇坂さんと、角谷さんがでるっていうので、執筆業を抜けて参加させてもらったのでした。行ってよかった。


 人数的にアジャイルミーツUX。半分ちょい開発者、1/2〜1/3くらいUX
 人間工学。戦闘機のコックピット。操縦ミスをしないように。計器が見づらく墜落した。
 何十人でコストかけてやってた。
 ヤコブ・ニールセン:テストに何十人も不要。5人で85%の効果がだせる。
 実際どうなの?→5人で十分。
 アランクーパー。生粋のエンジニア。インタラクションデザイン。ペルソナを生み出す。
 D・ノーマン。学者。アップルにいた。jobsがいない時。
 ドキュメントを壁越しに投げるのではなくて一緒に作るようになった。
 チーム作りが変わってきた。
 同時多発でいろいろな手法ができてた。
 それらをまとめてアジャイルマニュフェストを作ってから広まった。
 売るために名前をつけたのでは?
 2005年くらいからスクラムが売れてきた。企業で広まり始めた。
 ウィンドウズは2−3年で作る。ウォーターフォールでできた。
 ドキュメントたくさん作った。でも読まないよね?
 いきなりドキュメント渡されても困る。
 最近はエンジニアと一緒に作るようになってきてる。
 15人でテストするなら5人で3回まわした方がよい。
 反復するなかで改善していくのがよい。
 アジャイルの一番の根幹が反復。
 アメリカのアジャイルカンファレンスでUXのセッションができるようになった。
 スーツがくるようになった。
 2002ケント・ベックvsアラン・クーパー
 アラン・クーパー:インタラクションデザインを最初で完璧にしておかないと。
 ケント・ベック:それ、ウォーターフォールじゃない?
 しかしクーパーはその後アジャイルの流れにのる
 2008アジャイルUCD→アジャイルUXと呼ばれるようになってきた。
 アジャイルの波がきて、UXの人たちもアジャイルを取り入れるようになった。
 納期近くでテスト。ダメだけど納期だ!
 今まで総括的評価だけだった。やりながら形成的評価が必要。
 勉強しないで期末試験だけ受けるようなもの。
 ディスカウントテストでも高い。
 ウィンドウズみたいなプロジェクトならできるが、予算のあるプロジェクトがない。
 どんなテストでもやらないよりはマシ。マシよりもっと良いなにかw
 ユーザビリティテストに専門知識は?この本だけあれば大丈夫ですw
 ユーザビリティテストで説明しちゃだめ。ゴールだけ示す。
 それってプログラマーは難しいですねwコンピューターで困っている人を見るとつい教えてしまうw
 UXの人は残酷w放って置くんです。
 1人だけ見て考えない、3人以上見てから何が問題か考える。その人特有かもしれない。
 ライトメソッドは1人テストして直して次へ。→それって問題ないんですか?→難しいところある。ブレないようにコンテキストが必要。
 週一でテストするなどが最近流行り。テストは2種類。スプリントレビューでユーザテスト入れる。その事前に本当に小規模なテストをやっておく。スカイプでスクリーンシェアでテストする。
 開発者が同席するのが流行り。後で報告とかしなくてよい。関係者みんなで見学する。見学のノウハウが必要。地蔵になる必要がある。被験者の顔を見ちゃダメ。モニターを見る。
 プロジェクトにユーザビリティテストいれていきたいんだけど、どうしたらよい?とっかかり、予算の取り方などあれば。→最初は練習が必要。スカンクワーク。自社の製品じゃなくてよい。既存のサービス・アプリでテストしてみる。少しずつ仲間をふやす。
 ユーザビリティテストをするとよいことがある、と認識を持つ人を増やしていくこと。
 ストーリ一つ一つだけでなく、流れをテストする。
 医者とか弁護士をテストに呼ぶにはコストがかかる。
 ストーリーとは。上から順にはできない。バラバラのものが全体としてどうなのかモヤモヤする。ソフトウェアは使ってもらわないとできてるかわからない。ソフトウェア開発には人間が必要。全体図ではわかりにくい。解釈の違いにより事故る。それらをつなげるのがストーリー。
 企画自体、コンセプト自体が間違えている場合の対処法は?→その段階では、止める方向に進めるしかない。もっと最初から一緒にやろうね。みんな一緒にやって、ドキュメントでなく、ストーリーを覚えておこう。



個人的に角谷さんの「上流工程」に対するツッコミがとてもすばらしかったです。なんだかうわーっと感極まって内容覚えてなくて上手く説明できない><