[読了時間:2分]
今回は学びの消費者間マーケットプレイス「Cyta.jp」を運営するコーチ・ユナイテッド 代表取締役社長 有安伸宏氏にご登場頂きました。同社で学生インターンとして働く阿部千里さんが、Open Network Labと慶應藤沢イノベーションビレッジ が共同で開催したイベントに参加した際のレポートが元になっている記事です。イレギュラーナー寄稿ですが、イベントが示唆に富んでとても素晴らしいのと、阿部さんのまとめが的確だったので転載させて頂きました。
第２回 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の部分については同じスピーカーによる別の( ShibuyaUX さん)講演の記録がわかりやすかったので、そこから丸っと引用した図と文章を貼り付けます）
スタートアップに限らず 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 and routinized
改善のためのルーティンを設計する
デザイナーと開発し、フローが出来上がった次に会社が目指すべきはルーティンづくりで、例えば課題を見つけたらフローを用いてルーティンを築くことにより、チームの効率があがる。
ちなみにルーティンワークを作る目的は、会社が大きくなればなるほど新入社員が増えるが、そうした際に、新しくプロジェクトに取り組む人間であってもフローの流れに入れることができる点が挙げられる。
5.Solve the right problem
ユーザーが一番困っていることに集中して課題を解決する
正しいことに集中すること。例えばユーザビリティテストやヒアリングを通じて、ユーザーが一番困っていることに集中して、解決策を提供すること。
課題解決の最終形態がわからない状態で、think/make/checkのサイクルを繰り返す。さらに新しい課題が生まれ、それを解決していくサイクルを新たに産み出していくことが大切。
6. Goal-driven and outcome-focused
数値化した目標指標によって意思決定する
コードをリリース際にもっとも大切なことは、数値化できる目標を立てること。例えばある新機能の使用率が60％達するかに注目する。小さくリリースし、測っては追加して、いらなかったら外すというサイクルが重要である。
7. Generate many options
解決策のオプションをたくさん生む
think/make/checkのサイクルの中で課題を解決するためのブレインストーミングを行うときに、最も重要なのは、オプションをたくさん生むこと。プロダクトマネージャーと開発者と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. 三つの体制で、2週間以内に50人と会話をすればわかるだろう。
ユーザーエクスペリエンスの本で、顧客の会話のポイントがしばしば掲載されているので参考になるだろう。主なポイントとして、
- どのような製品を作っているかを明かさないこと
- 顧客に課題についてのストーリーをたくさん語らせること
が挙げられる。
Q. 作って測って学ぶサイクルで、微妙な改善が見られた時にどうすればいいか？
A. ABCDのような形で同時にテストし、どれが早く改善を見せるかチェックする。
>Q. FLOWのサイクルの中でも「チェック」はどういった方法で行い、判断するべきか
A. 検証の際に様々な手法があるが、上手くいったか判断するのは難しい。判断が難しい場合はユーザビリティテストを多くすること。
Q. いいデザイナーや開発者を見つけるコツは？
A. 会って会って会うこと！特に大学という色んな才能に溢れた環境を活かすこと。
（講演録、以上。）
（おまけ・その1）
1で出てきた”Product Strewardship”についてまとめられた資料。
（おまけ・その2）
講演者のJanice Fraserさんが初代CEOだったAdaptive Path社が公開しているチャートで、これも参考になるなーというのがこれです。
1981年生。慶應義塾大学環境情報学部卒。大学在学中に株式会社アップステアーズを創業。ベンチャー・インキュベーション事業を展開。2004年に同社をネットエイジキャピタルパートナーズ株式会社（現
ngi group株式会社） へ事業売却。大学卒業後は、外資系消費材メーカーのユニリーバ・ジャパン株式会社へ入社。東アジア市場をターゲットとしたブランド開発・市場調査等のマーケティング業務を経験。同社退職後、慶應義塾大学SFC研究所員等を経て、2007年1月にコーチ・ユナイテッド株式会社を設立、代表取締役に就任。学びの消費者間マーケットプレイス「プライベートコーチのCyta.jp」を運営。