lasciva blog

開発して得た知見やwebビジネスのストック

Product Manager Conference 2017【後篇】

2017.pmconf.jp

だいぶ過去ですが、メモが見つかったので公開しておきます。

アジェンダ

  1. 今いるメンバーで「大金星」を挙げるチームの法則
  2. Product strategyによって組織は大きく成長できる
  3. 多様性を成功に導くプロダクトマネジメント 5選
  4. ユーザーの“心の声”を探るUXリサーチ
  5. PM が UXするために必要なのはおそらく IA
  6. プロダクトマネージャーの採用と育成
  7. 日本のプロダクトマネージャーは今何をすべきか

1. 今いるメンバーで「大金星」を挙げるチームの法則

登壇者:仲山 進也 氏(仲山考材(株)代表取締役楽天(株)楽天大学学長)

グループとチーム
  • グループをチーム化する(グループが成長してチームになる)
  • チームづくりはジグソーパズルに似ている
    • ピースを色とかでグルーピングして、組み合わせていく
    • 人を職種とかでグルーピングして、組み合わせていく
  • チームの成長法則
    • 70点→赤点→120点
    • f:id:hacking15dog:20171115152939j:plain
    • 4つのステージ
      • フォーミング(形成期)
        • f:id:hacking15dog:20171115153146j:plain
      • ストーミング(混乱期)
      • ノーミング(規範期)
      • トランスフォーミング(変態期)
  • 人数が少ない方が簡単にうまくいく(多いと難しくなる)
  • フォーミングの鍵:「心理的安全性」
  • 失敗の秘訣
    • 役割分担をしてから意見を言い合う(ストーミング風なことをする)
    • アクティビティをやった趣旨は「ぷちストーミング超え体験」が味わえるから
    • 共通言語を持てると、チームビルディングは加速します
    • 無茶振りされてやりきった経験とか、クレーマーが最良の顧客になるのもストーミングを超える経験を経るから

2. Product strategyによって組織は大きく成長できる

登壇者:詫間 亮平 氏(楽天株式会社 レジャーサービス開発課 ゴルフプロダクトマネジメントグループ マネージャー)

  • 担当事業
    • 楽天GORA
    • サービスできて13年で、国内60%シェア
  • 組織構成
    • buisiness
      • Sales
      • UI/UX
      • Marketing
    • developmet
      • PM
      • Engineer
      • QA
Product strategyによって組織は大きく成長できる
  • 改善前の問題点
    • 頻繁な優先順位変更
      • 競合リリースの機能差分
      • ユーザからの問い合わせ
    • 皆が目前の作業没頭
      • 多方面に案件が膨れ上がる
      • 数打てば当たるみたいな考え
    • リリースしても利用されない
    • 開発してもリリースされない
    • メンバーからの不満
      • 方向性、提案しない、やらされている感
  • 改善後
    • Product
      • 勇気を出して一歩引いて、広い視野で先を見る
      • ビジョンを浸透させる -課題の特定
        • 分析
          • 何故No1になれたのかの分析
          • 1990年から縮小傾向の業界
          • その縮小の本質的な原因を特定する
          • ゴルファーをつなげるコミュニティに
        • 方向性
          • 国内:新規獲得からヘビーユーザを囲い込むように変更
          • 海外:ブルーオーシャンで、アウトバウンド・インバウンドに力入れる - 組織体制
      • PMとエンジニアを別グループにした
      • 以前の問題点
        • PMが工数とかを考慮してしまった
        • 本来やるべきことを実行できない
        • エンジニアの成長機会を奪う
      • 改善後
        • PMはプロダクトを全身させるコトだけを考える
        • エンジニアが、システムを巻き取る
        • PMがエンジニアに業界背景や問題、解決策を与える
        • エンジニアがつくりたくなる熱狂的なものに
        • プロフェッショナルな関係になる
      • KPIを常に表示して、エンジニアが提案するようになった
      • 戦略ありきで進める
  • その他
    • 仕事の半分は考える時間に
    • whyを突き詰め問題の本質に
    • StrategyでInovationを起こせない
    • やらないことを決めるところが腕の見せどころ
    • 理想を描いて、皆が熱狂するstrategyを描く
    • 何度も繰り返し提案する熱意情熱
    • 浸透するには数年かかる
    • 最初は浮く存在になってしまう、批判は覚悟する
    • 結果が出れば批判は消える

3. 多様性を成功に導くプロダクトマネジメント 5選

働き方の多様性 | 大阪リモートチームとのプロダクトマネジメント

登壇者: 尾部 絵里子 氏(Sansan株式会社)

  • 未来のことを考えることが最重要
  • PMはワイヤーフレームを書かない
  • そうするのは自走できるような環境にすることが重要
    • リモートとのコミュニケーションコストを下げる目的でも

f:id:hacking15dog:20171115154310j:plain

4. ユーザーの“心の声”を探るUXリサーチ

登壇者:奥泉 直子 氏(フリーランス・ユーザーリサーチャー)

アジェンダ
  • UXリサーチとは
  • UXサーチ方法
  • ヒトの認知特性
UXリサーチとは
  • UXとは
    • ISOでは製品やサービスを使用したとき、また使用を予測したときに生じる個人の知覚や反応
    • 環境文脈
    • 時間軸
    • 人の内面
UXリサーチとは
  • Research Toolbox
  • UCD
    • インタビュー(人の内面)
    • 日記調査(時間軸)
    • エスノグラフィ行動観察(環境、文脈)
  • これらの調査を組み合わせる(仮説と検証をはっきりさせるため)
ヒトの認知特性
  1. 認知の相互作用
  2. 先入観
  3. 機能的固着
  4. 知識の呪い
  5. 記憶
  6. 認知的不協和
  7. 選択的不協和
  8. 確証バイアス
まとめ
  • UXのリサーチする
  • まず、ユーザインタビュー
  • 人の認知特性を知る

5. PM が UXするために必要なのはおそらく IA

登壇者:小久保 浩大郎 氏(株式会社CAMPFIRE)

アジェンダ
UX is 何?
  • Userとプロダクトを取り巻く全部のことを指す
  • UXは環境やコンテキストに依存する
    • ユーザと対象の二者間のものではない
    • それらを取り巻く閑居やコンテキスト
  • UXは発明されたのではなく、発見された概念である
ユーザビリティとUX
マーケティングとUX
  • 対象ユーザのペルソナをどう考えるか
  • ユーザの分類
    • innovator
    • early adopter
    • early majority
    • late majority
    • Laggard
  • 学習曲線のデザインが変わる
    • サービスの提供価値などの理解度
    • よく使う機能を意識せずに使える
    • 高度な機能を見つけて使いこなす
UIとUX
  • PMが考えないといけないモデルたち
    • ビジネスモデル
    • システムモデル(事実)
    • メンタルモデル(認知)
    • (ここではプロダクト= システムモデル + メンタルモデル)
  • 事実と認知をどうするか
  • システムモデルとメンタルモデル
    • 単純に一致させればいいものでない
    • 効率的で合理的なシステムの動作モデルと、ユーザがわかりやすく使いやすいモデルは違うことが多い
    • どちらが先に決定する訳ではなく、相互に影響しながらできあげることも多い
    • 恐らく昔はシステムモデル先行だったが、ユーザビリティや人間中心設計といった概念の普及により改善された
    • UXという概念の普及もこの流れの一貫といえる
  • メンタルモデルは2つに分類
    • デザイナーモデル(こう思わせたい)
    • ユーザモデル(こう思った)
    • このブリッジになるのふぁUI
  • デザイナーモデルとユーザスモデル
    • 可能な限り一致させたい
    • それをどう上手くやるのかというのがUIデザイナー
    • UIを通して
  • ターゲットペルソナは複数いる
    • プロダクトサイクルによって最適が変わる
名前重要
  • 人はそもそも物事をどのように理解するか

    • 理解 = わかる = 分かつ
    • 名前を与えられて始めて区別できる
    • 別々の名前をつけることで2つの存在
    • 分かつことによって、その抽象的性質を帰納的に推論できるようになる
    • この抽象モデルが「理解」
  • 基本的なところは統一した方が良い

    • システムの根幹的な概念や動作モデルに関する名称
    • 主要なオブジェクトたち(名詞)
    • それらが取りうる振る舞い(動詞)
    • 利用シーンにおけるユーザの区別(名詞)
    • ユーザが取りうるアクション(動詞)
  • 統一する利点

    • 開発チーム内のコミュニケーションの効率化
    • バックエンド、フロントエンド、デザイン、コピーにおける名称の一貫性
    • システムモデルとメンタルモデルの差異が意図的か否かわかる
    • 開発ドキュメントが書きやすく、読みやすく
    • マニュアル、FAQ、マーケティングにも一貫性
    • 新しい概念に対する命名の必要性の土台

6. プロダクトマネージャーの採用と育成

  • 登壇者
    • Bryan Cheng 氏
      • Google, Inc.
      • GoogleMapのLocalGuides
    • Capella Yee 氏
GoogleMapのPM
  • 3種の境界付近
    • UXデザイン
    • エンジニアリング
    • ビジネス
  • 関係構築も仕事の一つ
  • リーダーであることが求められる
日本でのGoogleのPM
  • マウンテンビューと日本で仕事そのものの大きな違いはない
  • 違うオフィスに行くことが重要
  • 早朝にMTGなりがち
  • 鉄道システムとか最先端
APM
  • Associate Product Manager
    • PMの赤ちゃん
    • 2年間で2プロジェクト担当する
  • PMが足りない中で、情報専攻学生を育てるでMerrisaMayerがAPMを設立
  • 何故特別か?
    • いろんな文化を体験することができる
  • APM同期が財産になる
    • いろんなプロダクトのPM担当と繋がりを持てる
APMトリップ
  • 4カ国回って国の違いを
  • 文化の違いを学ぶ
どうやってAPMになるか
  • 面接
    • 技術の質問
    • 適性、やる気、クリエイティブ重視
  • 経験必要なし
  • APMを卒業してPMになる

7. 日本のプロダクトマネージャーは今何をすべきか