こんにちは。PMチームのしだです。
会社のカンファレンス参加精度を利用して、2019年11月12、13日に行われたプロダクトマネージャーカンファレンス2019に参加してきました。
参加した9つのセッションの中から、
「PMが学ぶべき、最低限のデータ活用スキルとは」
についてレポートします。
レポート
セッション概要
『PMが学ぶべき、最低限のデータ活用スキルとは』
株式会社Hakali代表取締役
小川 晋一郎
データは分析するだけでは意味がなく、ユーザーのために活用されてはじめて価値が生まれます。ですのでユーザーのことを日々真剣に考え、新たな価値提供を生みたいと常に思っているPMの人たちこそデータ活用スキルを身につけるべきです。しかし、かといって統計学を一から学んで、、、とか、機械学習の講座を受けて、、、では遠すぎます。必要最低限のデータ活用スキルを身につけて、ユーザーへの価値提供力を高めましょう。
https://2019.pmconf.jp/sessions/2019/11/13/S2-003/
はじめに
よくある事例
- 数字を今すぐ見たいPM VS 忙しいエンジニア
- 説明をしたいPM（ユーザーに嫌がられるのでユーザーへのメール数を減らしたい） VS 話の通じない上司（減らして売上あがるの？）
- 自分でデータを扱えればこんな事例に対応できる
実際に対応した事例
- Before:機能ベースのKPI設定で現場が疲弊
- After:意味ベースのKPIを設定したことで、中長期的な目線での戦略が打てるように
＝受注の背景には何があるのかを見つけて意味ある指標を設定する
ふまえて今回のテーマは
- 意思決定のためのデータ活用手順
- 具体的なスキルとその身につけ方
意思決定のためのデータ活用手順
- データ活用に最も大切なテーマ
- データというコミュニケーション言語をつかって、解くべき「課題」をチームで合意する
- 事業インパクト
- 解決コスト
- 戦略の方向性
- 部門ごとの視点
- 組織のcapability
- データというコミュニケーション言語をつかって、解くべき「課題」をチームで合意する
指標が相手や営業に刺さらない場合はだいたい「課題の設定」がずれている
そのためにPMとしては
解くべき「課題」を決めるための合意形成プロセスに責任をもち、
議論が進むための素材を準備する
- おすすめのデータ活用モデル
- OODAループ
- Observe 見る
- Orient わかる
- Decide きめる
- Act うごく
- PDCAだとPlanが先にくるが、Planを立てるということは難しいこと
- なので、まずは観察することから始める
- 先の読めない、リーンな開発には特に合う
- OODAループ
Observe（見る）
- 現場感覚（インタビュー） と 生データ
- ユーザー（顧客）と接点ある人達から課題感を聞いて整理
- 現場のモヤモヤはだいたい正しい
- モヤモヤ会議で課題を集めてみる
代案のない提案をするなとか代案出さずに不満だけ言うななどと言われがちだが、モヤモヤにある課題が何なのかの見極めも、その解決も難易度はとても高い
代案が出せない場合ずっとももやもやを抱えている状態が続くことになる
なのでまずは現場のモヤモヤを吸い上げて整理するのが大事
モヤモヤ集めで課題認識が擦り合うだけで、現場の協力が得られるようになり、その後の議論がスムーズになるケースもある
- 生データを見てみる
- 分析手法をつかってかっこよく鮮やかな正解を出す…とかいうよりも、とにかく生データを見ること
- エクセルでの数値管理はつまりサマリなので、生データからあたってみるだけでもかなり違う
Orient（分かる）
- モデル化
- 現実の見方や捉え方を言語化、可視化してKPIツリーに紐付けること
KPIツリーに出てきにくいが「スピード」が重要な指標となることは多い（例えばマッチング後の面接設定メールなど）
スピードを加味したモデル作りをする
- 総数問題のモデル化
- 一般的に「総数」が増えると「次のファネルへの移行期待値」が上がるが、閾値がある
- 増やせば増える、には限界がある
- 適切なところを指標に設定する必要がある
- 一般的に「総数」が増えると「次のファネルへの移行期待値」が上がるが、閾値がある
- 総数問題に関連して…
冒頭ちらっと出したユーザーへのメール爆打ち問題のモデル化
- それが起きやすいのは、送れば送るほどKPIツリーの数字が増えるモデルにしているから
- そういう状態にしないために、KPIの中にネガティブ要素を含める必要がある
- 例えば、数打ちすぎると退会率があがる、開封率が下がるなどが考えられるので、退会率や開封率も組み合わせるなど
- トータルの売上を意識している人と同じ言語でデータで語る必要がある
細分化の罠
- 細かいパターン分類に走っても、打ち手を細かく打つコストが高いことが多い
- KPIツリーのマクロデータのみで思考すると起こりがち
Decide（きめる）
- マクロで見たときの施策インパクトは常に確認する
- PMが「やりたい」ことが、案外マクロでみたらインパクトが小さいことは少なくない
- 率改善が売上にどうインパクトするのかという視点を常に持つ
比較
- 比較がないと良い悪いの判断ができないが、比較するものによって見える結論は変わることを自覚する必要がある
WEBサービスの外のモデルが大切なこともあって見落としやすい
- WEBサービスのことばかり見ていて、一連の作業の流れなど大きなところをみることを忘れると見落としが発生しがち
- ユーザーの行動全体をみる
その他気をつけること
- 普段会議にいないキーマンの観点を考慮できていないと意思決定できないこともあるので注意
- 常に視座を高く持っておくことが大切
まとめ
- チームでデータを扱いながらOODAループを回すことで、事業クリティカルな課題を1つずつクリアしていく
- OODAループ
- Observe 見る
- Orient わかる
- Decide きめる
- Act うごく
- OODAループ
具体的なスキルとその身につけ方
たくさん覚えるのではなく、必要最低限で生き延びること
＝サバイバル
データ活用のために押さえること
WebサービスのPMであればまずはSQLを覚えるべし
- 実践がないと頑張れないので、準備より本番
- データ定例を作って関係者を週次であつめる
- もやもやを話してもらって宿題化する
- 宿題を解くことで力をつけていく
試行錯誤しやすい環境を構築することも必要
概念的に理解すべきポイント
- データをDatabaseとして「テーブル」の概念で扱えるかどうかは大きな分岐点
- 人間が読むことではなく、システムが読める形で扱う
おすすめのSQL修業ステップ
- ちゃんとした人（エンジニア、データサイエンティスト）が書いたクエリを読み込み、一部だけいじって出してみる
- 自分で簡単な文法で書いて抽出したものを、BIツール等外で加工して利用
- WINDOW関数やサブクエリ等、ある程度複雑なものもSQLで表現
- DBのテーブルにどんなデータが入っているのかを読みとけるようになると自走力は上がる
分析手法として 何をしっておくと良いのか
分析はrawdataの意味を取りやすくしたもの
rawdata
- 量が多い
- 全体の意味が読み取りづらい
- 予算のモデルにしづらい
統計処理
- 全体の意味を読みやすく集計しているにすぎない
- データ全体を一言で表現；代表値（平均値、中央値）
- まとまったパターンに集約：クラスタリング
- 可視化：各種グラフ
分析手法：分布
- 平均値より中央値
- でも意味を考えるならまずは「分布」を眺めたほうがいい
クラスタリング
- タイプごとの中央値みたいなイメージ
- 共有するときには、データの裏付けを元に「意味」ベースでラベリングすると議論しやすい
まとめ
とにかくやり続けられる環境を作ることが大事
やり続ければいつかスキルは上がる
データ抽出スキルがあることで世界は広がる
Web業界であればまずはSQLを学ぶこと
生情報（インタビュー、rawdata）を元に事象をモデル化して、チームでOODAループを回す
カンファレンス全体通しての感想
- 会社の状況や文化、事業の内容、一緒に仕事をする人やチームの体制によってPMがやらなければならないことにはかなり差がある
- 共通しているのは『担当プロダクトの価値を上げること』がミッションで、そのためにできることは何でもするという点（解像度低め）
- 一般的に定義されているPMの役割について知っておくのは、考える糸口として必要
- ただ、それにむりやり当てはめるとうまく行かない場合が多そう
- たくさんの事例を知っておくのは臨機応変な対応をする上で重要
初参加でしたが、普段知ることができないたくさんの企業の様々な事例とその対応を知ることができ、大変有意義な勉強をさせて頂きました。
