イベント詳細: http://atnd.org/events/21153
ユーザーエクスペリエンス（UX：ユーザー体験）は、提供するサービスに対する印象や、サービスそしてセールスの成長にも大きな影響を与える、インターネットサービスを構成する要素の中でも最も大切なものの一つです。今回のONLAB Startup School@SFCでは、このUXを設計するインタラクションデザインの第一人者としてシリコンバレーで15年間活動してきたJanice Fraser（ジャニス フレイサー）氏を講師として招き、プロダクト開発デザインについてのイベントを開催します。
≪Janiceプロフィール≫ 起業家、ウェブとモバイルのUXデザイナー。 15年に渡るシリコンバレーでのスタートアップの成功と失敗の 両経験を活かし、アーリーステージと大企業をターゲットとし た経営コンサルタントとして活躍している。ウェブサービスの デザインを手がけるAdaptive Path社の共同創業者で、初代 のCEOを務めた。
在職期間中、Adaptive Path社の収益とスタッフを3倍に増やし、 開発したプロダクトをGoogle社に売却した。「Ajax」という言葉 の命名者でもある。現在、Haas, Kellogg, Stanford, Presido Graduate School of Management等、数多くの大学やカンファ レンスで講演を行う。
日 時: 2011年11月8日(火) 18:00開場 ~18:30開始
場 所: 慶應義塾大学湘南藤沢キャンパス τタウ11教室
参加費: 無料
定 員: 100名 (主に学生）

以下、講演概要です。
演題： 10 principles of Lean UX
- Design + Prod. Mg. + development = 1 product team
- Externalize!
- FLOW: think/make/check
- Repeatable and routinized
- Solve the right problem
- Gobal-driven and outcome-focused
- Generate many options
- Decede quickly and hold decisions lightly
- Recognize hypotheses & validate them
- Research with users is the best source of information ( & inspiration)
1. Design + Prod. Mg. + development = 1 product team
これが最初であり、もっとも大切なこと。アジャイル開発はスタートアップにとって大事なものたくさんの開発者が集まって開発する。
従来の開発のモデルは以下のようなもの。
|Rest of World | Product owner | development team |
Rest of Worldとはmarketing etc.Product ownerはみんなのことを考えなければならない。マーケティング、投資家、開発チームに何を作らせるか。これはウォーターフォール型の開発。ニーズ聞いてからやり直す。product manager は悲惨な状況。仕様書作って流す。ユーザからのフィードバックも開発チームのフィードバックも得られない。
今の開発はアジャイル。これからスタートアップをやる人は以下のようにやるべき。みんな同じ権限を持つ。
|Design | Manager | Developer |
UX, DEV, Businessそれぞれの共通部分がある。みんながownershipを感じる。
"Product Stewardship" by Tim Mc Coy
UX: ユーザを見て問題を認識し、ニーズを知ることが最も大切。ターゲットユーザと共感することが仕事。
DEV: 屋根を上げるような人(by J. D. サウンジャー)。今まではプロダクトマネージャーが出した要望に答えていた。しかし、これからは、どういうふうにどういう技術を使って最大限UXから与えられた課題に答えられるかを考える人。Developerがinnovationをおこす。
Business: Scale of Justice。難しい決断をする人。ユーザはこう言っている、しかし、ユーザの言うことを聞き過ぎるとよくない。また、開発するときに機能の優劣をつける。
この体制はバランスを重要視した体制。組織が大きくなっていくと、各部門のリードが責任の重なる部分を担当する。どの部分が偉いとかはない。３つの部門が平等に責任を感じながら、各々のスキルを活かしてユーザの課題を解決していく。
2. Externalize!
外に出す！実物にして外に出す。デザイナーにありがちなのはスケッチ書いて捨て、また書いて捨てること。そうじゃなくて、書いたことをすぐに壁に貼る。とりあえず壁に貼って、チームの他のメンバーの眼に見えることにおく。
開発者もやるべきことは一緒。シリコンバレーのスタートアップは現在の開発の進捗状況を全て表示する大きなディスプレイがある。自分の状況をみんなに共有できるようにする。そうするとチームでコミュニケーションが進む。そしてよりコラボレーションが生まれる。
3. FLOW: think/make/check
Developer: build - measure -learn
流れ。流れを作ることが大事。エリックリースの本に書いてある。（※日本でも翻訳版が2012年出るとのこと。）Build - Measure - Learn、この流れが大事。「こんなにいっぱい機能作ったから進んだ！」は嘘。そうじゃなくて、会社の進展は開発者が書いたコードの行数じゃなくて、どの程度その開発者が学んだかで測るべき。開発者が学んで、よりよいプロダクトになっていく。
Designer: think - make - check
デザイナーにもこの流れがある。デザイナーの成長も測るべき。prove - improve。証明して、良くする。Janiceさんがコンサルするときにもこれを行なっている。なぜそれが必要かを証明して、良くなるのであれば実際につくる。
4. Repeatable and routinized
繰り返し可能にする。ルーチンにする。作って測って学ぶフローができたら、routineを作る。チーム内で、課題を見つけたら、フローを通して課題を検証しよう。作って検証しよう。というroutineを作ることが大事。これをすることでチームの効率が上がっていく。
繰り返しのルーチンができたら、会社が大きくなって新しい人が入ってきてもすぐに会社のフローに入れることができる。日本に企業はルーチンとかプロセスを作るのが得意だからたやすくできるかもしれない。
5. Solve the right problem
適切な問題を見つける。正しいことに集中して適切な問題を解く。ユーザヒアリングやユーザテストを通して、自分の製品を使って抱えている困難について解決していく。
今まではプロダクトロードマップみたいなものに基づいて開発していた。けれど最後どうなるかわからない状態で模索していく中で、ユーザの課題を知ることで新しい課題がどんどん生まれてくる。このプロセスの中で新しい課題を解決していくというサイクルをつくることが大切。
6. Gobal-driven and outcome-focused
コードをリリースするときに重要なことは、目標を立てることと、数値での計測対象を作ること。ユーザの課題を解決するために作った機能がちゃんとそれを解決できているかどうかを測る。もし解決できていたら次のサイクルへ。解決できていないなら機能を外して、もう一度作りなおす。ユーザの動向を見つめる。そうすることで、スタートアップがモノを作るときに出てくるムダを省ける。小さくリリースして、いらなかったら外す、というサイクルを取るべき。
7. Generate many options
課題を解決するオプションをたくさん、素早く生み出すことが大事。Janiceさんは実際にUX, Developer, Businessの人が10分間で18のアイデアを出すということをやっている。それぞれの立場で課題が解決できないかアイデアを出す。３人でアイデアを出すことで良い案が出てくる。
8. Decede quickly and hold decisions lightly
18個のアイデアから1つを決める。失敗してもいい。間違える前提で決めたほうがいい。一番大事なのは、ユーザについて学ぶこと。一つのアイデアをとってうまく行かなかったら次の、と3人で決めることが大事。このプロセスに間違いはなく、重要なのは学ぶこと。
9. Recognize hypotheses & validate them
リーンスタートアップで重要なプロセスなのは、いろいろ試すこと。アイデアを試して、そのアイデアがあってるかどうかを検証すること。結果ユーザのことを学んで、次にやることを決めるというのがものすごく重要。どの仮定を検証するかを見定めるのは難しいけれど、たくさん回数をこなせばわかってくる。デザインの分野では仮説検証をするのは新しい。けれどやるべき。
10. Research with users is the best source of information ( & inspiration)
ものを検証するときに真っ先に行くべきなのがユーザのところ。analyticsを使って検証することもできるが、実際にユーザがサービスを使っているところを見て、うまくいっているかどうかを検証することが大事。ユーザのところで実際に話すことで得られるインスピレーションもある。常にユーザと距離を縮める事が大事。
講演はここで終了でした。
聴いていた感想としては、ああ、やはりそうだよなぁと納得することが多かったです。プロダクトを少人数で作っていると、アジャイル開発は必須だとして、その次の段階としてユーザを見るということが意外にうまく行かず、気がついたら大きすぎるフェーズの話をしていたり、なんとなく良さそうなデザインにしてみよう、という話になりがちです。僕は講演の中での話の核は２つあると感じていて、１つはUX / Business / Developmentで責任を平等にチームとして働くという点、もう１つは仮説検証を徹底しチーム全体で学ぶという点です。まずチームとしてUXをメインに据えているのは、Lean Startupならではなのかもしれません。でもこれは本当に大事です。実際にプロダクトを作っていると、なぜこのプロダクトを作るのか、誰のためにどのように使ってもらうことを僕らは期待しているのか、実際にちゃんと意図した通りに気持ちが遷移して誘導できるだろうか、といったことをチームで話し合います。それ自体は良くても、作り始めてからは各々がバラバラに動いてしまい、反省の機会を得ずに止む無くリリースする、ということが大いにあります。要するにちゃんとサイクルを回すことができていないのです。確かにこのサイクルを回すのは大変なのです。全員がちゃんと集まって、プロダクトについて話しあい始めるとなかなか終わらないですし、そこで決まったfeatureを実装してリリースすることにはまたbusiness面での次のフェーズの話に進んでしまいがちです。
一開発者としては、ソリューションとしての技術をもっと磨かなければならないなと、背筋の伸びた一日でした。知らないことはわかっているのに、調べ尽くして、試しきれていないことがあって、それらを今すぐに１つ１つ取り組んでいきたいです。学びながら、プロダクトを作るということを継続していきます。
運営のOpen Network Labと慶應藤沢イノベーションビレッジの皆様、貴重な機会を提供していただいたことに感謝しております。あと、やっぱりSFCはいいキャンパスだなぁと思いました。SFCで学部４年間過ごしたら、かなり価値観が変わりそうです。
