ProductManagerConference2019に参加してきました

はじめまして。SIS事業本部の松本です。

Product Manager Cnoference 2019に参加してきました。その所感をレポートしたいと思います。

背景

新規事業を始めるにあたって、PMの果たすべき役割やチームビルディングについて 理解し、来年からの行動に活かすために参加しました。

今年の副題は「すべての企業にプロダクトマネジメントを」でした。 去年の「愛されるプロダクトをつくろう」からの流れを感じます。

「こんなプロダクトをつくりたい」から「では、そのための最適な体制や運営、責任者の役割は？」 このような問いに直面し試行錯誤してきた組織が増えてきたと思います。 その実体験を聞くことができたのが貴重でした。

特に印象に残った講演の要約と所感を記します。

LINEにおけるお金とユーザーのジレンマ

LINE株式会社 執行役員

二木 祥平さん

speakerdeck.com

要約

• PMの役割

  • PMには多様な人格＆スキルが要求される
    • ex.) ビジョナリスト、プロジェクトマネージャー、テクノロジスト...etc. -さらにプロダクトのフェーズによって求められる人格＆スキルの配分が変わる
    • ex.) 企画フェーズではビジョナリスト:プロジェクトマネージャー:ビジネスアナリスト:スペックライター=4:2:2:2
    • ex.) 開発フェーズではビジョナリスト:プロジェクトマネージャー:スペックライター:UXデザイナー:テクノロジスト=1:5:2:1:1
  • スーパーマンになれ、という意味ではない。役割は「何を作るのかを決め、それを市場に届ける」こと
  • 自分のスキルを把握し、協力を得て足りないところを補完できれば良い。

• PMの抱えるジレンマ

  • PMは多くのステークホルダーと話す。必然的にジレンマを抱えやすい。
    • ex.) デザイナーは画面Aが良いというが、開発は画面Bが作りやすいという
  • ここでPMが機能しないと妥協したプロダクトが出来上がる。
    • ex.) 短絡的選択＝A or B , 合議的結論= A+B
  • 複合的情報を持つのはPM。だからこそ決定責任がある。
  • 「何らかのジレンマが存在する場合、それは我々の認識のどこかが間違っている可能性を示唆している」By ニュートン
    • AとBは二律背反なのか？根底のビジョンは同じではないのか？
  • "PMの仕事はジレンマの連続でありつつ、解決できないジレンマはない" そして、"ジレンマの解消自体がクリエイティブな仕事であり、プロダクトに競争優位性をもたらす"

所感

役割の話は、PMに定型はなくて自己変革とチームビルディングで対応すべき、と理解しました。 ジレンマの話は、PMに限らず複数の利害関係者と関わる役割全般に適用できる内容。 ジレンマ（に見える）状態に直面した時、必要なレイヤーまで抽象化して共通認識を作れるか。 AとBの選択肢があるときにCを探れているか、という自戒を持っておきたいです。 最後の言葉は勇気をくれるとともに責任を感じさせてくれる言葉だと感じました。

“失敗事例で学ぶ” 失敗しないプロダクトマネジメント - PMの必須スキルと、自走する組織のつくりかた -

エン・ジャパン株式会社デジタルプロダクト開発本部 部長 / プロダクトマネージャー

岡田 康豊さん

speakerdeck.com ご本人のnoteに核の部分の詳細が書かれていた。 note.mu

要約

• 数年前まで、社内ではキャリアに対する不安からPMの離職率が高かった。
• そこでPMに求められるスキルセットを言語化し、現在位置を確認する取り組みを始めた。
• 結果生まれたのが、プロダクトマネージャー・スキルチャート・ヘクス
• 6つの項目でPMのスキルセットを整理した。
  • 1.Project Management
  • 2.Dev.
  • 3.Design
  • 4.Growth
  • 5.Business
  • 6.Domain Knowledge
• 各項目は5段階で評価し、評価基準も言語化されている。
  • ex.) Project Management
    • Lv.1 ヒアリングを行い、プロジェクトの要件定義をすることができる
    • Lv.2 要件定義を分解した上で、タスク整理とスケジュール作成ができる
    • Lv.3 スケジュールの遅延なく、リリースまでをプロジェクトマネジメントできる
    • Lv.4 ウォーターフォール型、アジャイル型を問わず、プロジェクトマネジメントができる
    • Lv.5 コスト・リスク・リソース・品質の観点から最適なプロジェクトの計画と実行ができる
• 各levelを達成するための基礎スキルも言語化した（スライド、note参照）。
• スキルの向上に努める社員が増え、離職者が減少した。

所感

スキルセットを言語化したら組織が良くなった、という単純な話ではなく、同時にスキル習得を支援する取り組みも行っていたようです。 PMの役割の全体像と自分が今どのレベルにいるのか分からず組織に不安が広がっていた中で、人に寄り添ったアプローチをとったのが良かった、と理解しました。 ここまで徹底的に明文化に拘ってやりきるのはすごいと感じました。

プロダクトアウトな新規事業立ち上げのリアル（とその後の質問セッション）

株式会社プレイド プロダクトマネージャー

棚橋 寛文さん

要約

• 冒頭
  • PMの役割、プロダクトマネジメントのフレームワークは多様
    • 事業ドメインによって求められる資質は異なる
    • 具体的行動につなげにくい
    • 具体例をたくさん知っておくことが大事
• プレイド
  • Mission：データで人の価値を最大化する
  • KeyContexts：インターネットの構造的欠陥
    • 強いワードだけど”匿名性によるデメリット”のようなニュアンス
• プロダクトアウトとマーケットイン
  • プロダクトアウト：企業ミッションに基づき思想を市場に押し付ける
  • マーケットイン：顧客ニーズに基づき課題を解決するプロダクトを提供する
  • どちらが正しいではなく両方使って提供価値を最大化する
  • プレイドはプロダクトアウト的側面が強い
    • CEOのポエム（インターネットの構造的欠陥云々）がきっかけ
• プロダクトアウトであり続けるには
  • ミッションや思想レベルで目線を合わせる
  • 壊すことを恐れない
  • 失敗から学習する
• プロダクトアウトだとビジネスと乖離しないか
  • プロダクトをビジネスとして価値化する
  • 顧客の本質的課題を捉えてプロダクトをアップデートする
  • PMが頑張る
• BtoCとBtoBの違い
  • BtoC：プロダクトとコンテンツ
  • BtoB：プロダクトとコンテンツとビジネスオペレーション
    • フェーズに合わせて集中するポイントを決定する必要がある
    • 新規事業ではスピードに直結する
• SaaSプロダクト
  • ProductとCustomerSuccessの関係
    • ユースケースから価値・課題を吸い上げプロダクトに反映
    • ユースケースを解像度高く理解し、提案できるか
• アイデアのアプローチ
  • 世の中の流れの先にあるもの
  • アセットや強みが生きるもの
  • クライアントの課題やペインを解決するもの
• PMに重要なこと
  • 当事者意識・主体性
  • 事業成長へのコミットメント
  • レバレッジが効くことをやり続けること
  • 概して、経営者視点
    • 経営者のように振舞うということではなく、高い視座を持つこと

所感

PMFの達成にはプロダクトアウトとマーケットインの両方が必要ということは当たり前になりつつあるように感じます。 個人的にはマーケットイン的取り組みは再現性が高い一方、差別化要素を産むにはプロダクトアウト的視点が必要、という認識です。 PMのタスクの切り方として、”レバレッジが効くか”という言語化は斬新で的確だと思います。チームビルディングとかCSの仕組みづくりは最近注目されている好例。

発明、ドッグフーディング、プロダクトマネジメント

Nota Inc. CTO

増井 俊之さん

要約

• Nota Inc. ではGyazo, Scrapbox等のプロダクトを展開している
• プロダクトを産むメソッド
  • プロダクトイン（自己中心設計）
    • 自分で使いたいもの
    • 簡単で有益なもの
    • 誰もが使えるもの
      • できるだけ認証はなし
• 発想法
  • 情報収集→バックグラウンドで考える→ふとしたときに思いつく
  • そもそも発想
  • わざと制約を作る
  • 音楽は聴かない
• ドッグフーディング
  • 自分で作って自分で使う
  • まじめに作らないと困る状況を作る

所感

マーケティングはプロダクトアウトとマーケットインという対比で語られることが多いですが、前者は顧客の発見が、後者は真の課題と解決策の特定が困難というトレードオフがあると思います。 それに対する解として、”プロダクトイン”（自分の思想で自分の課題を解決する）を提唱している、と解釈しました。 衝撃だったのは、”バックグラウンド発想法”が自分が高校生の時から実践しているものと全く同じだったこと。 これが正攻法なのだろうと自信になりました。

今からはじめるデザインスプリント

株式会社シークレットラボ代表取締役 / エクスペリエンスデザイナー

佐藤 伸哉さん

要約

• デザインスプリントとは
  • 限られた時間内で
  • 状況を理解し
  • アイデアを創出し
  • 実装する
• 5日間でやるなら
  • 月曜：全体と詳細の理解
    • チームで情報をシェアして理解
    • 専門家に聞く
    • 一人一人が質問する
    • 必ず全員が各々メモを取る
    • 簡単なダイアグラム(5~15ステップ)を作成する
    • 顧客タイプやペインポイントを理解する
    • 解決すべき課題を決めてスプリントの対象とする
  • 火曜：アイデア整理
    • ブレスト・ディスカッションは機能しないのでやらない
    • 個人で考える
    • 個人でアイデアをスケッチする
    • アイデアを徐々に具体化・詳細化する
    • 図を使って抽象化する
    • 上記を繰り返す
  • 水曜：プレゼン
    • グループ審議しない
    • サイレント投票（禅投票）で採決する
    • 個人の主観で決める
    • 最多投票アイデアを採用
      • ポジションによって表に重み付けするのはあり
    • 採用されたアイデアをストーリーボード（画面遷移等、詳細なユーザー体験）に展開
  • 木曜：プロトタイプ
    • ユーザーに使ってほしい部分を細かく作る
    • 実際は時間の関係で水曜までのことが多い
  • 金曜：テスト
    • ユーザーインタビューは5人やれば十分
      • 5人で問題の85%は出てくる
    • ユーザーに1vs1でインタビュー
    • 全員別室でビデオ視聴
    • ここでも各々必ずメモを取る
    • 各自が主観で課題を出す
    • 同じ課題に対してリテレーションしない
      • 崖っぷち感が大事
• 参考：GoogleのDesignSprintKit
  • designsprintkit.withgoogle.com
  • たまに改訂されている

所感

デザインスプリントというと縁遠く感じるかもしれません（私もやったことない）が、前半は要するに”アイデア出し”と捉えると参考にできそう。 個人ワークとグループワークの使い分けが特徴的。 情報を共有したら”何を課題と捉え、どう解決するか”は個人で考える、集まったアイデアで何がいいかは投票で決める、テストの時の課題発見も個人で考える、と個々の裁量が大きい。 優秀で多様かつ互いをリスペクトしている集団で成果を最大化するため、と考えると納得できる。