Curiosity

骨とワニが好きなデザイナーです

【勉強会】「UX Sketch」vol.1：事業企画とUXのコンセプト設定について

UXデザイン 勉強会

本日も勉強会メモです。事業計画とUXという非常に渋めなタイトル！事業会社でのお話から受託のお話まで、幅広く伺うことができました。戦略的になんでもやるのが大事なんだなあ。

開催概要

プロダクトオーナーの隣でUX導入した話（竹中哲 ランサーズ）

なぜUXを考えるのか

  • 入社時に「今よりサービスをかっこよくして！」といわれてはいった
  • だが実際のニーズは「今よりサービスを使いやすくして！」だった
  • そういうことならとUXを導入
  • 当時の組織が抱えていた課題：
    • 増えるメンバー、増えるコンテンツ
    • つぎはぎリニューアル
    • いつのまにか追加される新規機能
  • デザイナーに与えられた課題：
    • 中長期含めて、成果を生むプロダクト
    • 統一されたプロダクト品質を保つ
  • そこでやったこと
    • Coineyのデザイン指標「3つのE」を参考に、Lancersのデザイン指標を考えてみた
      • Capitalize　使えるか？
      • Communicable　伝わるか？
      • Charm　魅力的か？
    • そしてこれに当てはまらないものは作らない、と宣言した
  • UX原則策定前は、新規機能のLPでは淡々と機能を説明していた
  • UX原則制定後は、「モノ」より「コト（体験）」を説明する文言にした
    • 「顔の見えない取引から顔の見える取引へ」
  • そうして「ユーザーが何が起きるか理解でき、使いたくなる」、魅力的なプロダクトを作れるようになった

どうUXを考えたのか

  • UXの社内浸透のためにやったこと
  • 発言の回数を重ね、価値観・目線を合わせる
    • 呼ばれて無くても反応する
    • 社内勉強会
    • 前者懐疑で低減・宣言
    • ユーザーインタビュー
    • ワークショップ
  • 小さなことから、だんだんできることが増えていった
  • そんな中で一つ、うちのPMの特徴を発見した。それは「バズった施策に飛びつきやすい」ということ

  • 通常、UXフローは、開発の最初と最後に導入しやすい（逆に言うとチャンスを逃すと挽回がむずかしい）

  • トリガーが外部要因（世間でバズってた、みたいな）でタイミングが急でも、始まってしまえばこっちのもん

  • 様々なバズワードに乗っかり、かたっぱしから実践していった
    • ペルソナ策定
    • UX指針
    • ポジション分析
    • ペーパープロト
    • DesignSprint
    • などなど
  • このうち、ペルソナはマストでやるべき。なぜなら開発者は主観に陥りやすいから
    • ランサーズではペルソナは20個位つくってる
  • そしてデザイナーはポジション分析がマスト。その目的は、オーナーとの認識合わせ
    • これも10種くらいつくった
  • どれが効果的だった、とかは正直あまりなく、どれもやらないよりはやった方が効いた
  • UXがあればなんとかなる、は幻想。上流と開発サイドの認識合わせと、時代に合わせた課題設定は常に必要です

すぐできるUX実践

  • これまでの状況
    • 定量分析：GAは全社員が見に行ける状態
    • 定性分析：
      • 問い合わせ内容は、サポートチームなど一部の人のみが見れる状態
      • サポートがとりまとめ、依頼として上がってくるものを対応
  • そこで、「疑うわけじゃないんですが、生の声が見たいです」と言ってみた
    • → お問い合わせの内容がチャットで随時流れてくるという状況ができた
    • → ディレクタ・デザイナ・エンジニアが、内容を見て、即座に改善に動ける世界になった
  • ただしこういう試作は、時期とリソースと対応者次第では形骸化しちゃう場合もある
    • なのでサービスの特性に合わせてやっていくとよい
  • ほかにもこんな分析をしています
    • ユーザーと同居（！？）
    • インターンや新人研修でサイトを操作してもらう

まとめ

  • 事業の魅力を正しく伝えるのがUX
  • まず事業主の価値観・目線を理解する
  • 身近なユーザーとの対話でUXは良くなる
  • サービスに関わる人はみんなUXデザイナー！

質疑応答

  • （司会）ペルソナが20あるということですが、それだけの数が必要だったということですか？
  • （竹中）たまたま10だったということで、数に意味はないですね。性別、年齢、職業などの属性を洗い出して行ったら10は簡単に超えて、そこから特に重視したいところを選ぶと10になったという感じです。作る機能毎に、どこのターゲットにたいして作るのかという認識を合わせるためにペルソナを使っています
  • （司会）ポジションマップもたくさんありますね
  • （竹中）マップは本当にずっと作っていました。社長が暇そうにしていたらすぐ捕まえて作ってたので、嫌われました（笑）
  • （司会）ポジションマップの更新頻度は？
  • （竹中）うちでいうと、1年に1回くらい。あと気をつけているのは、役員やオーナーが変わるタイミングでぜったいやるという点です
  • （会場質問）お問い合わせをチャットに流すことについて、形骸化しないための施策ってなにかありますか
  • （竹中）お問い合わせの中でも気になるものをリスト化して、それを常に更新するようにしていました。すでにサポートチームにそういうリスト化のフローがあったので、自然とできるようになっていきました
  • （会場質問）UXのガイドラインって、他社さんと組むときにはどうしているの？
  • （竹中）あんまり外部の方に押し付けるようなことはしないように考えています。とはいえこれまでの外部連携は単発のキャンペーンが多くて、一緒にサービスをつくるところまで（＝UXについて議論するところまで）はあまりなかったです。ただ今後は、そこまで踏み込んでやりたいなと考えています

事業とUXデザイン（馬場沙織 リクルートテクノロジーズ）

事業とUXデザイン

  • UXとUXデザイン
  • エクスペリエンスのデザインプロセス
    • 人間中心設計
      • ユーザーからのフィードバックを得てPDCAを回す
      • ユーザーと組織、両方の要求を満たすようにする
  • 事業フェーズにより、UXデザインの目的（ビジネスニーズ）が変わる
    • 一番大きな分岐点はスケール可能なビジネスモデルが成立しているかどうか
  • ビジネスモデル成立後のUXデザインの目的：成長
    • ビジネスモデルからブレークダウンした各種指標向上が中心
  • ビジネスモデル成立前のUXデザインの目的：探索・検証
    • ビジネスモデルとサービス・プロダクトコンセプトの同時探索・検証が中心

事業フェーズとUXデザイナーの役割

  • mixiの事例紹介

    • 関わった時期：2007〜2012年
    • 会員1000万人前後、ガラケーシフトとソーシャルゲームで成長
    • この時のビジネスニーズ：成長
      • 各種指標向上のため新規機能追加したい
      • 各種指標向上のためユーザビリティ向上させたい
    • カスタマーニーズが大きく変化した時があった（メインユーザーが大学生から高校生へ、とか）
      • その変化に合わせて、プロダクトのコンセプトの設計・評価を行った

  • ノハナの事例

    • 関わった時期：2012年〜2014年
    • 社内企業精度で初期メンバーとして参加
    • リリース前のビジネスニーズ：事業計画立案
      • ターゲット市場のカスタマーニーズを把握したい
      • サービス・プロダクトの初期コンセプトの設計をしたい
    • これに対応するため、野良ユーザーインタビューみたいなことをやっていた（予算があるわけではなかったので）
    • リリース後のビジネスニーズ：ビジネスモデル探索
      • 運用コスト削減のためにサービス・プロダクト改善をしたい
      • アップセル・クロスセルのために、サービス・プロダクトコンセプトの設計・実装・評価
    • 詳細はこちら → http://www.slideshare.net/SaoriBaba/uxer

  • 勉強サプリの事例

    • 関わった時期：2015年4月〜
    • ビジネスニーズ：追加投資獲得
      • 追加投資獲得のために各種指標向上させたい
    • 成果を上げるための環境づくりをいまやっているところ

UXよもやまばなし

  • ビジネスニーズを分かるためには、ビジネスのお作法をしらなければならない
    • とくにビジネスシーンでは数字をメインに語るので、デザイナーとして自分たちのビジョンを語るためにちょっとずつ数字を使うようにしてきた
  • カスタマーだけ見ていても、サービス全体のパフォーマンスは上げられない
    • 外側のシステムと内側のシステム、両方のパフォーマンス向上が必要
    • UXデザインをサービスデザインに使おう！
  • UXとブランドデザイン
    • UXはフロー（一時的UX）とストック（エピソード的UX、累積的UX）の両方を含む概念
    • ストックの評価：満足度評価→ブランド評価
    • ストックを向上させて、継続・獲得につなげよう！（予期的UX）

質疑応答

  • （司会）最初に出てきた人間中心設計の考え方のなかに、事業企画要件とユーザー要件の両方を満たすと書いてあったんですが、それらは両方共ちゃんと満たしきれていると感じますか？
  • （馬場）そこが難しいからUXデザイナーの仕事があるんだと思います（笑）
  • （馬場）事業でも組織でも、まず何をするにも目標設定が必要になりますよね。組織では目標達成が体制の問題であったりリソース管理の問題であったりで複雑になりがちです。でも、そういうところにも働きかけるようにしないと最終的にユーザーまで価値を届けることはできないので、UXデザイナーとしてできることはなんでもやろうと思ってやっています。最近はUXという言葉も一般的になってきているので、経営陣もそのへんを良くしたいというのは当然考えるようになってきています。ただ具体的になにをすればいいかというのは当然わからないので、そこに対して働きかけていっています

事業企画とデザイン（西村和則 root inc.）

  • よくある意思決定者とデザイナーのやりとり
    • 言ってることが抽象的で絵に起こしづらい
    • 言われたまま作ると修正の回数がやたら多い
    • 意思決定者の意見がころころ変わる
    • 見栄えはすごくいいけど結果がでない
  • いまもとめられているデザイナー像
    • サービス開発におけるデザイン：表面的な制作デザインだけでは成り立たない
    • ユーザー体験の設計も含めたデザインスキルというものが求められている
  • 今日のゴール：事業企画をプロダクトに変換する第一歩を身につけること。その考え方を伝えます

課題解決のアプローチについて

  • rootでやっていること
    • 「デザイン＝設計」と考え、わかりやすく使いやすいサービスやウェブサイトを設計すること
    • 事業としてはコンサルティングと制作がある。今回は前者について紹介
  • とあるクライアント（ベンチャー企業）さんと、事業立案フェーズからフロントエンド開発までいっしょにやっていった
  • 当然ながら、課題は山積み
  • 制作の前にまずは、解決すべき問題を定義する必要があった
  • そこでまずは、問題を整理してみた
    • 組織課題：やりたいことが多い、ソリューションばかり考えて実行に落ちない（創りたいプロダクトがあるので、それをつくってくれと言われるとか）、などなど
    • プロダクト課題：既存ユーザーの意見に引っ張られる（本当にやりたいことが実現できなくなってしまう）、競合プロダクトを参考にアイデアを考える、などなど

  • それぞれの解決に向けたアプローチについて詳しく見ていきます

  • 組織課題に対してのアプローチ：

    • ビジネスと開発、双方の計画には大きな乖離があり、これらは対立しがち（ビジネス側の要望だといつまでに公開したい…とか、一方開発側はできないとか）
    • この状況で機能要件を考えたりすると、議論がいつまでも終わらないということになる
    • なのでデザイナーは、ビジネスと開発との中立的なポジションでコミュニケーションを取っていく必要がある ＝ 両者の橋渡し的な役割を担う
      • 具体的には、事業フェーズごとに解決すべき問題にプライオリティをつけていった
  • プロダクト課題に対してのアプローチ：
    • 機能要件は、実現すべきユーザー体験を定義することから始まる
    • プロダクト課題の解決に向けた流れ
      1. 実現すべきユーザー体験の設計
      2. ユーザー体験にそって必要なソリューションをピックアップする
      3. それに対して何を機能化するのかを定義（ここで機能要件の策定）
      4. 実現すべきユーザー体験にプライオリティをつけ開発計画に落とす
      5. ユーザーとのコミュニケーションの最適化（ビジュアルデザインやライティング）
  • 実現したいユーザー体験から逆算して、「常に立ち返るべき問題を定義しておく」ことが大切

今日からできる「問」の定義

  • ○○をデザインしてほしいと言われたら「なぜ？」を繰り返す
    • 事業企画者の「これをつくりたい！」に対して、なんでこれを創りたいのか？というのをしつこく問うていく
  • 創りたいものを考える前に、実現したい提供価値（UX）を定義しなければならない
  • デザイン思考のプロセス（共感 → 問題定義 → 想像 → 試作 → 検証）も、まずは対象を深く知ることから始まる
  • 「誰のためのデザイン？」を読んでみよう
  • ハイブリッド型デザイナー「デザインディレクター」が必要とされる時代です！

質疑応答

  • （司会）クライアントから依頼がきた時点で、「そこで認識されている課題は違うものだ」という前提で進めていくのがいいんですかね
  • （西村）そうですね、そのパターンが圧倒的に多いですね。UXデザイナーが入ってる状況で依頼がきたのであればそのままでもいいのかもしれませんが…。「なぜ」を考えないで進めた場合は、表面的なデザインが評価されたとしても、事業的には評価できないということになりがちだと思います

【勉強会】達人たちから学ぶ。グロースハックとUI/UX

勉強会

グロースハック。難しげだけど大事…と思って聞きに行ってみました。というわけで本日の勉強会メモです。

概要

  • 達人たちから学ぶ。グロースハックとUI/UX
  • 「どのようにサービスの成果を上げていくか、また自社のサービスにグロースハックの手法をどのように取り入れていけばいいのか、といった辺りを中心に、今回もグロースハックの達人たちをお招きし、明日からすぐに使える実践的な内容をお届けします。」
  • 日時：2015年6月24日 19:30〜
  • 場所：DeNA さくらCAFE

VASILY 梶谷健人さん

  • 梶谷健人氏（株式会社VASILY グロースハッカー）
  • あなたがグロースハックで抱えている問題は？
  • よくある答え
    • マクロ：フェーズ・順番（どういうステップでやっていけばいいか）
    • ミクロ：実務プロセス（具体的になにをすればいいか）
  • それぞれについて詳しく答えていきます↓

マクロ：グロースハックのロードマップについて

  • グロースハックとは
    • 数値やユーザーの声を分析し、ユーザーの数や質をグロースさせる
  • 有名なグロースのモデル：AARRRモデル
    • Acquisition, Activation, Retention, Referral, Revenue
    • これでグロースしようとすると、ほぼ失敗する
    • 失敗する理由：着手すべき順番になっていないから
    • この順番はあくまで、顧客視点での順番である
    • この順番でやってしまうと、ニーズ検証や体験の最大化よりも、細かい最適化のほうに目がいってしまう
  • いまVASILYで採用しているモデル：ARRRAモデル
    • Activation：そもそも製品の価値は顧客が求めるもの？
    • Retention：使い続けてくれるくらい製品の価値に満足してる？
    • Referral：友人に伝えたくなるほど製品の価値に満足してる？
    • Retention：お金を払ってくれるほど満足してる？
    • Acquisition：製品の価値を広めるために、正しいチャネル・訴求軸を選べてる？
    • ARRRAは種々のスタートアップの概念と対応している！
      • Lean Analytics
      • Growth Pyramid
      • Customer Development
    • ActivationとRetentionがイケてれば、以降はあまり難しく無いと思っている

ミクロ：具体的な実務プロセスについて

Activationについて

  • Activationとは：ユーザーにサービスの価値を感じてもらうこと
  • 具体的には、以下の二点
    • そもそもサービスに価値があるか：Problem Solution fit
    • その価値が初回体験時に伝わるか：User Ongboarding
  • ほとんどのサービスは「顧客、課題、解決法」という構造を持っている
  • Problem Solution Fit：アイデアの前提となるユーザーの課題が本当に存在するか、アプローチが間違った前提に立脚していないかを確認する
  • スタートアップが死ぬ理由
    • 存在していない課題にアプローチしている、顧客から求められていないものをつくっている
    • 失敗した例：Snapchatのカスタマーサービス
  • 死なないためにはどうすればいいか
    • きちんと課題が存在している、顧客が存在していることを確認
    • うまくグロースした例：Zappos
      • 静的な表側（HTML）だけのサイトだけで裏側のシステムはほぼつくらずに、ECサイトをローンチした
      • 注文が来たら、一つ一つの商品を起業家自らが発送・梱包した
      • 次第にたくさんの注文がくるようになって、価値が検証できた
  • 「スタートアップのアイデアの99％は間違っている」
  • Javelin Boardというフレームワークでアイデアを検証する
    • 間違いに早く気づいて修正するためのツール
  • Javelin Boardの具体的な流れ
    • サービスについて次のことを考えてみる：顧客、課題、解決策、もっともリスクの高い想定、検証方法と達成基準
    • 事前に建物の外へ出てインタビューする：結果と判断、検証方法と達成時基準
    • 結果をうけて、顧客や課題などを変更していく
    • これを繰り返し、もう変更がない（＝サービスアイデアが妥当であると判断できる）というところまで持っていく

User Onboardingについて

  • User Onboardingとは：初回のプロダクト体験で「このサービスめっちゃいい！」と思わせること
  • 具体的には以下の三点
    • Value Proposition：プロダクトがどのような価値を提供するのか、代替品が存在する中でなぜこのプロダクトを使うべきなのか、というのを示す
    • 利用方法の理解：どんなにいいと思ったサービスでも、利用方法がわからなければ二度と使ってもらえない！
    • AHAモーメント：このサービスを良いと思ってもらえる体験を早い段階でしてもらう
      • 悪い例：登録した後に誰もフォローしていないので何もコンテンツが流れてこない
      • 良い例：Twitterでは、はじめに必ず5人以上フォローする強制している
  • それぞれについて、「何を」「いつ」「どうやって」ユーザーに伝えるかを考えていく
  • 具体的なプロセス
    1. 今いるフェーズでKPIを定める：Onboardingであれば翌日再訪率
    2. ファネルに明らかなすぼみがないか探る
    3. 定性／定量調査でパターンを探す：翌日に再訪したユーザーとしていないユーザーにインタビューする、再訪している人／していない人についてLocalyticsで定量調査
    4. 改善か所を特定
    5. 改善箇所のファネルに明らかなすぼみがないかを探す
    6. パターンを増加させる施策を打つ
    7. パターンが増加したかを検証する（Noなら6に戻る）
    8. パターン増加が①のKPIに寄与しているかをチェック（Noなら6or3にもどる）
  • VASILYではオリジナルのシートを作成して、上記のプロセスを回している

まとめ

  • グロースハックでやるべきこと：ニーズ検証や体験の最大化 ＞ 細かい最適化
  • 実現方法：ARRRAモデル
  • 各フェーズの進め方：フェーズの理解→プロセスマップ＆フレームワーク
  • より詳細な情報は、10月出版予定の書籍にて！

シロク 石山貴広さん：実践的なUXデザインとグロースハック

  • 石山貴広氏（株式会社シロク 取締役/CCO）
    • Design Lightning Talksという勉強会を不定期開催中！
  • 今回のゴール
    • グロースハックの意義を感じる
    • サービスにハマる仕組みを作る方法を知る

グロースハックの意義

  • サービス事業者あるある
    • ①重要なのはユーザー獲得まで、という認識
    • ②機能MECE：使ってくれない理由を理由に機能追加してしまう死のサイクル
  • 改めて、ユーザーの継続性に着目しよう
    • 時代の主導権はとっくに顧客に移っている
      • 顧客中心時代の到来：ユーザーが自分に合わせたものを手に入れやすい時代である
    • ユーザー獲得後の活性化・継続性に力を入れる必要がある
    • サービスの利用価値を定めて、機能MECEから脱却する
  • 一方、UXに必要な要件は、顧客の的確なニーズを満たすことと楽しさを生み出すことの二点である（by D.A.ノーマン）
  • サービスにハマり続けるしかけをつくろう！

ユーザーアクションサイクルの設計

  • ユーザーが、サービスに戻ってくる理由を設計できていますか？
  • UXの策定プロセス
    • 顧客の問題を知る
    • 問題→解決の手法を構築
    • 妥当性を検証する
    • 整理する
  • ユーザーアクションサイクルとは？
    • ユーザーが何の行動を経て価値を感じ、能動的に帰ってくるかを表した行動フロー図
  • ユーザーアクションサイクルの特徴
    • サービスの核が明確になるため共通認識を得られる
      • MVP的な話
      • ユーザーのサービス内で取る行動をプロットする≒UIFlows
    • 継続率向上のためのKPIが理解しやすい
      • 長期的な利用価値（能動的に変える理由）と短期的な利用価値（使う楽しさ）を設計する
    • 定量的な指標（KPI）に転換して、成果検証しやすい
      • どんな行動をするユーザーが継続しているか定量的にはかる
  • 重要なこと
    • 何が継続利用に響くかを開発者が理解している状態
    • UACやHookedなどのフレームワークを活用して、行動と結果を定量的に測る

My365で実際に取り組んでいた施策

  • やったこと
    • 多変量DLボタン
    • 初投稿
    • 過去写真の選択
  • Androidファーストでテストを実施
    • Androidだと審査期間がないので開発サイクルを早くできる
    • 「継続」を軸にKPIを追って改善していった
  • 大事なのは打席に立つ数であり、三振を恐れないマインド
    • 施策は数を打つ！

まとめ

  • ユーザーがサービスに価値を感じ続ける仕組みが大事
  • UACやHookedを活用してサービスの継続理由を設計
  • 打席に立つ数が大事

DeNA 真崎達也さん：サービスを成長させるための開発について

  • 真崎達也氏（株式会社ディー・エヌ・エー デザイン戦略室UXデザイングループ デザイナー）
  • 今回は、エブリスタ（小説投稿プラットフォーム）の事例を元に詳しく見ていきます

サービスの成長に必要なもの

  • 高いエクスペリエンスの設計
  • 徹底した定性・定量データ分析
  • 高速のPDCAの実現
    • → まとめると、ユーザーの感情を動かすものをつくること
  • ユーザー感情主導開発：ユーザー感情とデータ分析を行い、ユーザーにとっての価値＆体験の最大化

ペルソナの作成

  • エブリスタではふたつのペルソナを設定している
    • データ＆調査ベースのペルソナ
    • プラグマティックペルソナ（チーム認識用）
  • ペルソナ作成時の大切なポイント
    • どのような判断をする人なのか可視化する
    • 利用のゴールは何であるのかを明確にする
    • ユーザー行動の軸（チームの共通認識）をつくる

ジャーニーマップの作成

  • 作成プロセス
    • フェーズを分ける
    • 行動を出し、グルーピングする
    • ユーザーの思考（thinking）
    • ユーザーの感情（feeling）
      • positiveもnegativeも出し尽くす！
      • positiveをいかに高めるか／negativeをいかに抑えるかを考え、ユーザーのエンゲージメントを高めるため
    • 課題や重要ポイントをまとめる
  • 作成時の注意点
    • ペルソナの視点で書き出す
    • 願望や個人の意見で書かない
    • 行動に対するハードルの高低を意識する
      • 施策の重要度／優先度を見分けるため

ユーザーシナリオの作成

  • ジャーニーマップの時系列順にシナリオ化
    • 「○○として▼▼したい（できる）。なぜなら□□だからだ。」
      • ユーザーとしてFacebook認証したい。なぜなら登録がカンタンだからだ、とかとか
  • シナリオの効果を見積もる
    • 定性＆定量データや主要KPIから判断
    • 優先順位を決定する
    • 提供機能を決定する
    • シナリオのゴールを明確にする
    • 実施可否判断

仮説の設定とUI/UX

  • 例：投稿機能改修の設計方法
  • 課題
    • ex.「ユーザーとしてカンタンに投稿したい。なぜなら入力が難しいと挫折するから」
  • 課題から仮説の設計
    • 何が難しいと感じるのか？
      • ex.「入力項目が投稿後にどこに表示されるかわからない」
    • ユーザーにとってカンタンとはなにか？
      • ex.「見たことのあるUIに近いほうが直感的である」
    • エラーはあるか
      • ex.「下書き保存したいのに入力中はキーボードがじゃまでできない」
  • ペルソナやジャーニーマップを用いて仮説を作り上げる
    • ex. 仮説：「読書画面に近いUIを採用してみる」
  • テスト／現状分析を行う

リリース＆分析

  • ユーザー認識をブラッシュアップする
    • 継続的に定性＆定量分析を行う
    • → ユーザーを可視化するための仮説を検証し、ペルソナ＆ジャーニーマップを修正する
  • アダプティブなPDCAを行う
    • 変化を常に受け入れる
    • ユーザーシナリオを常に見直す
    • テストまでの一連の流れを高速化する：チームの共通認識をつくっていくことで、無駄をなくす

まとめ

  • ユーザー感情の最大化からものを考える
  • ユーザーを理解するための仮説＆検証を行う
  • ユーザーにとっての高い価値発見に注力する
  • 変化に素早く対応する

パネルディスカッション

  • （会場質問）グロースハックがなかなかうまくいかず、答えが見つからない時にはどうしたら良いでしょうか
  • （梶谷）二点あると思っていて、ひとつは、そもそもいまいるフェーズが正しいかを疑って、上流に遡るべきかを検証すること。もうひとつは、とにかくユーザーと話すこと。数字が伸びない時に社内で話しても突破口はなかなか見つからないので、ユーザーと話すことが大切
  • （会場質問）ニーズの検証について、具体的な方法はどういうものがあるのか
  • （梶谷）今回話したJavelin Boardはまさにそれかなと思う。ここで「だれが」「なにを」「どうやって」のいずれもがズレていないことが、ニーズがあるということだと思います
  • （会場質問）今回、それぞれがそれぞれの話を聞いて、どう思ったか（うちとは違うなとか）を伺いたいです
  • （石山）DeNA真崎さんの話を聞いていて、組織的な体力があるんだなあと感じました。プロセスがしっかりしている印象
  • （梶谷）うちはスタートアップなので石山さんの話はわりと近いなあと思いましたが、逆に真崎さんとは結構異なっているなと感じました。真崎さんの丁寧なUX設計プロセスの話を聞いて、今回その重要性に気付かされたので、実際にやってみたいと思いました
  • （真崎）DeNAのプロセスは小難しくいろいろやっているように見えたかもしれませんが、私としてはVASILYさんとシロクさんお話のほうが、ロジカルなところや進捗が分かりやすいところをしっかりやっているという印象を受けました。「それって需要がないんじゃない？」というような根本的な課題が少なそうというか。そこがうらやましいなと思いました。ちなみにうちは、会社全体としては体力はあると思うが、実際のチームの規模感としてはそんなに違いはないのかなと思います

  • （会場質問）定性調査のためにユーザーを集めてくるにあたって、どんな観点でユーザーを集めてくるのか、また、ユーザーインタビューの時に気をつけていることはなにかをお聞きしたいです

  • （石山）My365の開発時は、Prottみたいなモックアップツールはないような時だったので、実際のプロダクトを渡してテストをするというスタイルでした。テスターを集めるときにはローンチコミュニティをつくったりして、そこに50名ほどが集まったのでそこへアプローチするかたちになりました。インタビューの時に気をつけていた点は、「未来形で質問しないこと」。仮定の話はしないで、今手にしているプロダクトについて実際に使うかどうかを判断してもらう、ということが大事だと思っています

  • （梶谷）選定のところでいうと、二つのフェーズがあると思います。ひとつめは、まだプロダクトがない時。この時はざっくりとした区切りで（それこそ○○な大学生とかのざっくりした属性で切り出したりして）いいので聞いちゃう。ふたつめはプロダクトがあって、ユーザーがいる状態。この場合たとえばVASILYでは、「iQonがもし百人の村だったら」という仮定でベン図を作ってみて、どんなタイプのユーザーが多いかをというのを可視化してたりしている。そしてそのなかのマジョリティからユーザーをピックアップするようにしています。実際のインタビューの場面で気をつけていることとしては、ちゃんと台本をつくるということと、リハーサルをきちんとするということ。そうしないと、その時々の聞き方によって答えが変わってしまって、後からまとめられなくなってしまうので。あとは、未来のことをちゃんと聞くこと。過去にどういうことで困ったのか、どうやって解決しようとしたのか、を聞いています（ちなみにそこで解決しようとしていなければほんとは困っていないと言えます）。インタビュー手法に関してはこの他にもいろんなポイントがあるので、勉強していいなと思ったものをかたっぱしから試したりしています。
  • （真崎）チラシルのときは、2週間のアルバイトで主婦を雇う、みたいなことをやっていたりしましたね。インタビューの場で気をつけていることとしては、「事実を聞く」ようにするということです。表面的なところではなく、その深層の意図（精神的なところとか）を聞くようにしています
  • （会場質問）メディア系やコミュニティ系のアプリだと継続的に使うものになるので指標を追いやすいのかなと思うのですが、toB系のツールのようなユーザーが毎日使わないようなアプリではどうしたらいいと考えますか
  • （石山）うちのスタンスとしては、継続性がないものはあまり追わなくていいんじゃないかというのもありますが……。一度しか来ていないという人に対しても、しばらく立ってもう一度DMをだすとか、そういった施策は打てるかなと思う。やりようはいろいろあると思うので、後ほどお話できればと…
  • （会場質問）会社のビジョンとサービスのコンセプトがずれたりした場合は、どう修正していけばいいのでしょうか
  • （梶谷）おそらくサービスのコンセプトやニーズをピボットをしても、ビジョンレベルでズレることはそうないかなと思うのですが、そこからズレるとしたら、対応は二つ考えられると思います。ひとつは、ビジョンが狭すぎるということなのでビジョンを拡張する。あるいは、ビジョンそのものをピボットする。大体は前者でなんとかなると思いますが…
  • （会場質問）ビジョンを一番優先するということ？
  • （梶谷）というより、一番優先すべきはサービスがユーザーに求められるものなのかどうかであると思います

【読書メモ】「方法序説」を読んで「深く考える方法」についてまとめた

読書

本日の読書メモは、デカルト著「方法序説」。古典です。表紙の「すべての人が真理を見いだすための方法を求めて、思索を重ねたデカルト」という文言に惹かれ、手にとりました。こういう哲学的な本って視座をぐっと引き上げてくれるような感じがするのですきです（雰囲気）。

方法序説 (岩波文庫)

方法序説 (岩波文庫)

本書はほんとに短くて、本文が六部構成で100ページに満たないくらいでした。

知識と実践

数年を費やして、世界という書物のなかで研究し、いくらかの経験を得ようと努めた後、ある日、わたし自身のうちでも研究し、とるべき道を選ぶために自分の精神の全力を傾けようと決心した。このことは、自分の国、自分の書物から一度も離れなかった場合にくらべて、はるかにうまく果たせたと思われる。【第一部 p18】

デカルトはあらゆる書物を読んで大量の知識を身につけた後に旅に出て、自分の足で各所を見て回りながら身分の異なる様々な人々と交流したという人です。そんな人が、知識を仕入れるだけでなく自分で体験して考えることの大切さを説いています。

各人が自分に重大な関わりのあることについてなす推論では、判断を誤ればたちまちその結果によって罰を受けるはずなので、文字の学問をする学者がめぐらす空疎な思弁についての推論よりも、はるかに多くの真理を見つけ出せると思われたからだ。【第一部 p17】

そうしてたくさんの知見を得たことで彼は、ある考えを何の疑いもなく受け入れたり、思い込みによって判断したりすることの危うさを学んだとのこと ↓

他の人びとの習俗を考察するだけだった間は、わたしを確信させるものはほとんど見いだされなかったし、そこにも、前から哲学者たちの意見のあいだに見られたと同じくらいの食い違いがみとめられた。したがって、そこからわたしが引き出した最大の利点は次のことだった。つまり、われわれにはきわめて突飛でこっけいに見えても、それでもほかの国々のおおぜいの人に共通に受け入れられ是認されている多くのことがあるのを見て、ただ前例と習慣だけで納得してきたことをあまり堅く信じてはいけないと学んだことだ。【第一部 p18】

論理的に考える

第二部では、論理的な思索を行うためのデカルトなりの「規則」が4つ、示されます。

論理学を構成しているおびただしい規則の代わりに、一度たりともそれから外れまいという堅い不変の決心をするなら、次の四つの規則で十分だと信じた。 第一は、わたしが明証的に真であると認めるのでなければ、どんなことも真として受け入れないことだった。言い換えれば、注意ぶかく速断と偏見を避けること、そして疑いをさしはさむ余地のまったくないほど明晰かつ判明に精神に現れるもの以外は、何もわたしの判断のなかに含めないこと。 第二は、わたしが検討する難問の一つ一つを、できるだけ多くの、しかも問題をよりよく解くために必要なだけの小部分に分割すること。 第三は、わたしの思考を順序にしたがって導くこと、そこでは、もっとも単純でもっとも認識しやすいものから始めて、少しずつ、階段を昇るようにして、もっとも複雑なものの認識にまで昇っていき、自然のままでは互いに前後の順序がつかないものの間にさえも順序を想定して進むこと。 そして最後は、すべての場合に、完全な枚挙と全体にわたる見直しをして、なにも見落とさなかったと確信すること。【第二部 p28】

第一と第四（最後）はだいぶ難しそう。でも第二と第三は意識していきたいと思いました。

そして第四部では有名な、「方法的懐疑」や「コギト・エルゴ・スム（我思う故に我あり）」についての記述が出てきます。

ほんの少しでも疑いをかけうるものは全部、絶対的に誤りとして廃棄すべきであり、その後で、わたしの信念のなかにまったく疑いえない何かが残るかどうかを見きわめねばならない、と考えた。 -（中略）- しかしそのすぐ後で、次のことに気がついた。すなわち、このようにすべてを偽と考えようとする間も、そう考えているこのわたしは必然的に何ものかでなければならない、と。そして「私は考える、ゆえに私は存在する〔ワレ惟ウ、故ニワレ在リ〕」というこの真理は、懐疑論者たちのどんな途方もない想定といえども揺るがしえないほど堅固で確実なのを認め、この真理を、求めていた哲学の第一原理として、ためらうことなく受け入れられる、と判断した。 【第四部 p45】

どれだけ疑っても「疑っている私」という存在は疑いえない。この気付きについて、学校の授業かなにかで初めて聞いた時は、超衝撃でした。

知識を自分だけに留めない

ところでわたしは、これほどに重要不可欠な学問の探究に全生涯を当てようと企て、わたしの見いだした道が、人生の短さと実験の不足とによって妨げられさえしなければ、その道をたどって間違いなくその学問が発見されるはずだと思われたので、この二つの障害に対して次のこと以上によい策はないと判断した。それは、自分の発見したことがどんなにささやかでも、すべてを忠実に公衆に伝え、すぐれた精神の持ち主がさらに先に進むように促すことだ。その際、各自がその性向と能力に従い、必要な実験に協力し、知り得たすべてを公衆に伝えるのである。先の者が到達した地点から後の者が始め、こうして多くの人の生涯と業績を合わせて、われわれ全体で、各人が別々になしうるよりもはるかに遠くまで進むことができるようにするのである。【第六部 p83】

ここはまさに「巨人の肩の上に立つ」。感動的。

さらに、人の目に触れることを意識しながらアウトプットしつづけることの大切さについても書かれています。

多少とも重要だと判断するすべてのことを、その真理の発見に応じて書きつづける、しかもそれを、印刷させようとする場合と同じくらいの周到な注意をもって書きつづけることが本当に必要なのである。一つには、こうしたことを十分に検討する機会をそれだけ多く持つためで、多くの人に見られるにちがいないと思うものは、自分のためだけに書きとめておくものよりも、つねにいっそう丹念に見るのは明らかだし、また考え始めたときには真実だと思われたことが、紙に書こうとするときには虚偽に見えることもしばしばだったからだ。

私自身、ブログでのアウトプットを習慣化したことで、思考の流れを追ったり考えを整理したりする力がついてきたなーと感じております。ほんとに筆不精でブログとか絶対ムリ！というタイプだったんですが、こうしてブログを続けることができているのは、この「できることが増えてる」感がいいんだろうなと思います。

ということで、このように人の目に触れるようにすることを重要視していたデカルトですが、彼が生きたのはガリレオ・ガリレイの宗教裁判が行われたのと同じ時代だったので、公表を諦めたものがいろいろあったそうです。

けれども、わたしの生存中それが公表されることにはいっさい同意してはならないと考えた。わたしの書いたものはおそらく反駁や論争を免れないだろうし、それがわたしにもたらす名声がどんなものであっても、そうしたことが、自分を導くために使おうと予定している時間を失うきっかけになることは絶対に避けたいからである。

こんな状況にあっても学びを諦めない精神性、本当に見習いたいです。

今までわたしが学んだわずかばかりのことは、わたしのまだ知らないことに比べればほとんど無に等しい、しかもわたしはまだ学びうるという希望を捨てていない、このことを知っていただきたいと思う。というのは、諸学問のなかで少しずつ真理を発見していく人は、金持ちになり始めた人たちが、まえに貧乏だった頃はるかに少ない利を得るのに費やした労力にくらべて、少ない労力で大きな利を得るのと、よく似ているからである。【第六部 p87】

最後に、本書からイチオシの金言を一つ。

健康はまぎれもなくこの世で最上の善であり、ほかのあらゆる善の基礎である。【第六部 p82】