「シリコンバレー流UXアプローチ」講演録
Cyta.jpを運営してる有安です。弊社学生インターンの阿部千里さんがUXデザインに関する講演のログを社内用にとってくれたのですが、良い内容だったので社外にもシェアします！
第２回 ONLAB Startup School「シリコンバレー流UXアプローチ」 @ SFC
Open Network Lab (ONLAB) & 慶應藤沢イノベーションビレッジ (SFC-IV） 共同イベント
イベント概要 （詳細）：
ユーザーエクスペリエンス（UX：ユーザー体験）は、提供するサービスに対する印象や、サービスそしてセールスの成長にも大きな影響を与える、インターネットサービスを構成する要素の中でも最も大切なものの一つです。今回のONLAB Startup School@SFCでは、このUXを設計するインタラクションデザインの第一人者としてシリコンバレーで15年間活動してきたJanice Fraser（ジャニス フレイサー）氏を講師として招き、プロダクト開発デザインについてのイベントを開催します。
日 時: 2011年11月8日(火) 18:00開場 ~18:30開始
場 所: 慶應義塾大学湘南藤沢キャンパス τタウ11教室
Janice Fraserさんプロフィール：
起業家、ウェブとモバイルのUXデザイナー。 15年に渡るシリコンバレーでのスタートアップの成功と失敗の 両経験を活かし、アーリーステージと大企業をターゲットとし た経営コンサルタントとして活躍している。ウェブサービスの デザインを手がけるAdaptive Path社の共同創業者で、初代 のCEOを務めた。
在職期間中、Adaptive Path社の収益とスタッフを3倍に増やし、 開発したプロダクトをGoogle社に売却した。「Ajax」という言葉 の命名者でもある。現在、Haas, Kellogg, Stanford, Presido Graduate School of Management等、数多くの大学やカンファレンスで講演を行う。
1. Design+Prod.Mg+development = 1 product team
（デザイナー＋プロダクトマネージャー＋開発者＝1チーム）
ウォーターフォールメソッドは悲惨だ。デザイナーは、開発者やユーザーからのフィードバックもないまま、プロダクトマネージャーが長い時間かけて企画・考案したものを作らなくてはならない。
本来、デザイナーとプロダクトマネージャーと開発者は、一つのチームとなるべきなのだ。
デザイナーとプロダクトマネージャーと開発者が一つのチームになる、この体制は、”Product Strewardship”と名付けられている （Tim McCoyが命名）このチーム体制では、下記の三者それぞれがプロジェクトにオーナーシップを持つことが重要。
- UX ——ターゲットユーザに共感する役目。顧客に一番近い位置で、ユーザのニーズを把握し、課題を共感し開発者に伝える役目。
- Dev——これまではトップダウンでプロダクトマネージャーの要望を形にするばかりだったが、本来は彼らがイマジネーションを生み出すべき人たち。開発者がイノベーションを起こし、天井を高くする役割を担っている。
- Business——優先順位をつけて判断をする人々。
組織が大きくなった際には、リードUX・リードDev・リードBusinessの人々が下の人々に伝えるような体制が望ましい。また、この３者の関係が対等でなければならない。
（有安注・このProduct Stewardshipの部分については同じスピーカーによる別の講演の記録がわかりやすかったので、そこから丸っと引用した図と文章を貼り付けます）
スタートアップに限らず UX 主体のプロダクトマネジメントチームはデザイナー＋プロダクトマネージャー＋デベロッパー（開発者）が1つのチームとして働きます。この体制は Tim McCoy という人が考案したアイディアで"Product Stewardship"と名付けられています。デザイナーはカスタマー・デベロップメント、プロダクトマネージャーはビジネス・デベロップメント、デベロッパーはシステムやアプリケーション・デベロップメントと言うように、それぞれがそれぞれの開発の責任を持って行う体制です。
3者間の関係を図式に表すとプロペラのような形状をしており、Janice さんは『きっとこれは「早く進め！」という意味が込められていますね。』と笑みを浮かべます。UX デザイナーは他の誰よりもユーザを理解している必要があり、ユーザと共感することが役割です。従来、特にウォーターフォール型のデベロップメントではプロダクトマネージャーからの要望を受け入れるだけだったが、本来はデベロッパーがどういう技術を使うのか、ユーザのペイン（不満）をどう解消するのか、を検証していかなければなりません。僕自身も仕事場で「Why？」を繰り返した際に辿り着く答えは、この体制と役割でした。
プロダクトマネージャー（図では Business Stakeholder）は達成すべきビジネス上の目的を掲げることから始まり、最終的な意思決定もこの人が行います。マネタイズする各種ポイントはどこにあるのかを考え、ビジネススキームの全体を設計するケースが多いと思いますが、エンドユーザとのインファーフェースやテクノロジーが限られてしまうことから、この時点ではビジネスゴールのみです。イノベーションのボトルネックはビジネスサイドに存在します。
2. Externalize 実物化して外に発信する
デザイナーはアイデアをスケッチしては消しがちだが、シリコンバレーでは今、思ったことをスケッチにしてとりあえず壁に貼って共有できる状態にするやり方が主流化してきている。
開発者もやるべきことは同様。シリコンバレーの会社では、大きなディスプレイで、開発状況ややるべきことを画面に表示して共有している。
お互いのやるべきことを把握して、コミュニケーションやコラボレーションが生まれる。
3.FLOW :think/make/check 考える/作る/測る の流れが重要
"Lean Startup"の提唱者であるEric Riesによると、開発者は機能やコード行数で満足しがちだが、重要なのは顧客のことをいかに学べたかであって、この考える/作る/測る の流れからサービスを改善することが求められる。
デザイナー達も同様なサイクルが必要であり、企業の進展は、いかにこのサイクルを回せるかにかかっている。
4.Repeatable routinized 繰り返せるルーティンを作る
デザイナーと開発し、フローが出来上がった次に会社が目指すべきはルーティンづくりで、例えば課題を見つけたらフローを用いてルーティンを築くことにより、チームの効率があがる。
ちなみにルーティンワークを作る目的は、会社が大きくなればなるほど新入社員が増えるが、そうした際に、新しくプロジェクトに取り組む人間であってもフローの流れに入れることができる点が挙げられる。
5.Solve the right problem 正しい課題を解決すること
正しいことに集中すること。例えばユーザビリティテストやヒアリングを通じて、ユーザーが一番困っていることに集中して、解決策を提供すること。
課題解決の最終形態がわからない状態で、作って測って学ぶサイクルを繰り返す。さらに新しい課題が生まれ、それを解決していくサイクルを作ることが大切。
6. Goal-driven and outcome-focused
コードをリリース際にもっとも大切なことは、数値化できる目標を立てること。例えばある新機能の使用率が60％達するかに注目する。小さくリリースし、測っては追加して、いらなかったら外すというサイクルが重要である。
7. Generate many options
サイクルの課題を解決するブレインストーミングで最も重要なのは、オプションをたくさん生むこと。プロダクトマネージャーと開発者とUXで10分間でトータル18のアイディアを生む。それぞれの特化した視点によるアイディアを見て、うまく組み合わせること。
8. Decide quickly and hold decisions lightly
18のアイディアを３人で議論し、１つを決める。ここで大切なのは「失敗してもいい」という意識で、ユーザーの視点を学ぶことが重要。従ってこのプロセスに間違いはない。
9. Recognize hypotheses & validate them
アイディアを試して、アイディアが上手くいっているかを検証し、ユーザーの要求を把握した結果、次のアイディアに進むプロセスを繰り返す。
どのアイディアを試すべきかという判断基準は、このプロセスの繰り返しで理解していくだろう。
10.Research with users is the best source of information(& inspiration）
検証の際に真っ先に伺うべきは顧客。実際にユーザーと会話をし、ユーザーが実際に使用するところを観察し、検証することが大切。顧客と会うことで、新しいインスピレーションも生まれる。従って、常にユーザーと距離感を縮めることが大切である。
（Q&A）
Q. 最初のアーリーアダプターを見つけるコツは？
A. 三つの体制で、2週間以内に50人と会話をすればわかるだろう。
ユーザーエクスペリエンスの本で、顧客の会話のポイントがしばしば掲載されているので参考になるだろう。主なポイントとして、
- どのような製品を作っているかを明かさないこと
- 顧客に課題についてのストーリーをたくさん語らせること
が挙げられる。
Q. 作って測って学ぶサイクルで、微妙な改善が見られた時にどうすればいいか？
A. ABCDのような形で同時にテストし、どれが早く改善を見せるかチェックする。
Q. FLOWのサイクルの中でも「チェック」はどういった方法で行い、判断するべきか
A. 検証の際に様々な手法があるが、上手くいったか判断するのは難しい。判断が難しい場合はユーザビリティテストを多くすること。
Q. いいデザイナーや開発者を見つけるコツは？
A. 会って会って会うこと！特に大学という色んな才能に溢れた環境を活かすこと。
（講演録、以上。）
（おまけ・その1）
1で出てきた”Product Strewardship”についてまとめられた資料。
（おまけ・その2）
講演者のJanice Fraserさんが初代CEOだったAdaptive Path社が公開しているチャートで、これも参考になるなーというのがこれです。