the principal of Lean UX

Lean UXの本が出た

Lean UX: Applying Lean Principles to Improve User Experience

ここに乗っている"原則"が以下のとおり。

1. Cross-Functional Teams
2. Small, Dedicated, Colocated
3. Progress = Outcomes, Not Output
4. Problem-Focused Teams
5. Removing Waste
6. Small Batch Size
7. Continuous Discovery
8. GOOB: The New User-Centricity
9. Shared Understanding
10. . Anti-Pattern: Rockstars, Gurus, and Ninjas
11. . Externalizing your work
12. . Making over Analysis
13. . Learning over Growth
14. . Permission to Fail
15. . Getting Out of the Deliverables Business

よく見ると、アジャイル開発でよく言われているもの、リーンスタートアップで言われているものを合わせただけのようにも見える。

UXは、デザイナーだけがつくるものじゃない。みんなでつくるものだ。だからこそ、僕らは一緒に同じ方向を向いて、行動しなきゃならない。

Lean UXはまだまだこれから読み進めている段階で、ちゃんと自分のものにしたいですね。きっとどなたかが日本語化作業を進めてくれていると信じている。

デザイナーと開発プロセス

もともとデザイナーとエンジニアのチームとしての協業というところには興味があったのだけど、そのあたりのインプットが急に増えてきているので、この辺りでまとめておきたいと思う。

きっかけ

きっかけはDeverlopers Summit 2013 での 秋葉ちひろさん( @tommmmy )のプレゼン。

Developers Summit 2013【14-E-4】デザインをするときにデザイナーが考えること〜デザイナーの頭の中〜 from Chihiro Akiba

最近は特にコードを書いていないこともあって、デザイナーと一緒に働くシーンはあまりないのだけど、コンセプトメイキングをちゃんとやろうよというエンジニアに向けたメッセージはとてもよかった。いくつかのスクラムチームと接していても、チームとして一緒になるまでにはどうしてもエンジニアとデザイナーの間の絶妙な距離感は感じていたからだ。（ので、"みんなでコンセプトメイキングしてみようよ"って呼びかけたいなって思っている）

その次はスクーさんの授業

スクーというのは、WEBでいろんな人のプレゼンを見ることができるサイト。TEDのような新しい時代というよりは、教育系のコンテンツが並んでいる。たまたま、坂本貴史さん( @bookslope )の「WEBサイトの価値を高める」というプレゼンを見ていたのだけど、そこでは、"リーンUX"やら"アジャイル開発"やら、自分のフィールドにある言葉が並んでいた。

Schoo the user experience of web site from Takashi Sakamoto

デザイナーとして現場で活躍されている方から"リーン"まわりの単語を聞くことはなかった。あまり参加できていないけれども、CSSniteに代表されるデザイナーのコミュニティって、コンセプトの話だったり、手法の話をすることはあっても、プロセスの話をする人はあまりいないイメージが強い。

パーフェクトのズレ

今日たまたま見つけたのが Janice Fraser氏のインタビュー記事。彼女はリーンUXについてこう述べている(記事)；

私たちはUXの観点では、「パーフェクトではない段階でローンチすることに抵抗を感じないように」とデザイナーに伝えてあります。ただ、これは本当に難しいことなんです。「自分がパーフェクトではないと感じるもの」をローンチすることに対して、私も以前は文字通り胃が痛くて仕方ありませんでした。

アジャイル開発って、実装したい機能を一次元に優先順位順に並べて、それを少しずつ実現していく、という繰り返しで行われる。一方、コンセプトメイキングだったり、ユーザー体験を考えることって、とても完成されているものを考えるという感じがある。この辺りにもしかして気持ちのギャップがあるのかもしれない。

でも、あなたにとって"パーフェクト"なものはあくまであなたの仮説であって、赤ペン先生であるユーザーに触ってもらうしかないのだ。

エンジニアとデザイナー、そしてディレクターが一体になったスクラムチームを増やしていけば自ずと転換する場面が来るのか、そうではないのか、しばらく続けてみるしかないかもしれないな。どこかにプロセスを語るのが好きなデザイナーさんいたらぜひ語ってみたい。

サービスを作る上で大切なこと

SGT2013(長いので省略) で気になっていた、DeNAの資料がアップされていたのでご紹介

http://www.slideshare.net/TakeshiKaise/denascrumcomm-fixver/51

DeNAは大きくScrum Master編とProduct Owner編に分かれていて、SM編は「ちゃんとプラクティスができていなかったのをがんばってできるようにしました。やっぱり型が大切でした」って内容だったんだけど、@tsubotax さんが発表されたPO編にとても注目している。

ところで、PO編のスライド、一部間違いがある。 55ページ目。プロダクトオーナーはScrumチームの中のメンバーだ。

http://www.slideshare.net/TakeshiKaise/denascrumcomm-fixver/55

でももっと注目すべきなのは58ページ目。

http://www.slideshare.net/TakeshiKaise/denascrumcomm-fixver/58

この"開発プロセス"の中でスクラムに定義されているのは、ストーリー策定からレビューまでの部分。つまり、リリースしてそこから何らかのフィードバックをもらって新しいストーリーに落とすという部分は定義されてない。

そしてここが一番重要で一番難しいところだって考えている。

アジャイルUCDマップというものがある(リンク)。ユーザーがあるサービスを使うことによって発生する課題や疑問を、すばやくフィードバックに回して開発って実現させる。そのループが、一番大切なところなんじゃないかな。そういうことに気づきつつあるからこそ、 Build - Measure - Learn が特徴のリーンスタートアップが注目を浴びつつあるのだと思うし。

「クソプロダクトをいい方法論でつくってもクソはクソ」なのだ(by ryuzee)