プロダクトマネージャーカンファレンス2019で経た学びと思考の整理 #pmconfjp

表題のイベントに行ってきました。

プロダクトマネージャーカンファレンス 2019

「プロダクトマネージャー」とは、サービス型プロダクトの責任を一手に引き受けるロールです。サービスの持続的な成長・顧客への価値提供・売上向上…などを考え続ける、昨今のSaaS型ビジネスの台頭により注目され始めてきたロールかな、と思います。私がこのイベントを知ったのはfukabori.fmの及川さんゲスト会です。ちょうど自身がサービス開発を行っているため、何かヒントが得られればと思い参加しました。

私はとあるSIerでサービス開発の部署に所属する一社員。SI主体のビジネスからサービス開発に舵を切る事になり専門の部署が立ち上がるも、手探り状態で四苦八苦。そんな状態なので、全てのセッションで学びがありました。

ここではその学びを

  1. ロール
  2. スキル・テクニック
  3. マインド
  4. 組織

の4つに分けてまとめていきます。

ロール

「プロダクトマネージャーって何する人?」という問いが、カンファレンス全体のテーマでした。それに対する登壇者のアンサーはさまざまでしたが、会社の規模・プロダクトのフェーズによってPdMに求められる役割は変わるが結論かと思います。これはプレイド 棚橋さんのスライドがよくまとまっており、自社/プロダクトの状態にマッチしたPdMのロールを考えるのが、pmconf参加者の宿題だと思いました。

ヒントとなるのは「企業が求めるプロダクトマネージャーとその人材戦略」でパネラーの皆さんが話されていたこと。

  • 転職者をそのまま採用してもうまくいかない
  • オンボーディングが何より重要

という話があった通り、後述するプロダクト開発のスキル・テクニックを持った前提で、社内文化の理解・社内ステークホルダーとの調整できる能力が重要なのかな、と思いました。確かに、自社内の人材にPdMとしてのスキル・テクニックを身につけさせる方が、社内リソースの理解、競合他社と自社の差別化ポイントの理解、社内の顔の広さなどでPdMの仕事はやりやすいと思います。

もう1つはLINE 三木さんのセッション。

プロダクトのフェーズでPdMは人格を変えないといけない、という話に深く納得。私自身、営業にロードマップをコミットしつつ、技術メンバーに品質アップを求め、二枚舌を使い分けています。うまくバランスとりつつフェーズ毎で重視するポイントを変えるのがPdMのロールだと思いました。

あと、PdMはなんでもやって当然、ということ。私自身、いろんな所から呼び出し食らって「この職業何なの!?!?」と思っていたところに全部やる職業だよ～と言われたので、覚悟を決めて呼ばれる前に自分で動くことにします(白目

スキル・テクニック

PdMに必ず必要な顧客ニーズ理解スキル。これは小城さんのセッションが素晴らしかったです。

顧客ニーズ理解の原理原則はジョブ理論やデザイン思考だと思いますが、これを実際の現場でどう実践すればええねん?というアンサーに応える、体系化されたプロダクト開発の手法と実践がまとめられていました。

類似の話で、freeeの岡田さんによるストーリーテリングの重要性も面白かったです。

出席できませんでしたが、en-japanの岡田さんのセッションも面白そうでした。

#pmconfjp Day 1 登壇資料シェア＆フォローアップ｜岡田康豊(OkaP) | HR Tech プロダクトマネージャー｜note

「ひとまず出来る人をアサインして何とかしてもらう」するだけのPdMは終わり、ウォーターフォールでいうPjM、PL、Memberのようなステージを定義し、PdMを目指してもらうようなキャリアパス定義するのは、大きい組織を動かすには大事だな思いました。先進企業によってPdMに必要なスキルが定義されつつあるのが、ありがたい事です。

少し変わったところだと、会議のテクニックの話を頂いたCOPILOTの定金さん。

初日のTransferWiseさんのセッションで「自律的なチームは、会議などせずとも、プロダクトの計画、ロードマップを策定できる」と言われてましたが、現実的にはそんなチームばかりではない。チームをそこまで引き上げるための手段として会議というツールは有効なのかな、と思いました。

また、PdMにはデータ分析スキルは必須！というセッションに響いている方が多かったです。関連セッションはこちら。

弊社の主な販路が既存顧客と紹介顧客、販売単位も会社なので、集められるデータが少なく私はピンと来ませんでしたが、マーケティング部門はAdobe社のMarketoを利用していろいろやり始めたようなので、必要なスキルとして意識はしようと思いました。

マインド

  • 上層部はチームをチームを信頼し、権限と責任を移譲する。チームは結果でそれに応える。
  • メンバーを信頼し、自律的に動いてもらう
  • 機能を実装するのではなく、顧客に価値を提供するとプロダクトに関わる全員が理解する

最初のキーノートをはじめ、いろいろな場所で同じようなことが語られていました。小手先のテクニックより一番大事な話だと思いますが、文章で伝えるのは難しいのでこのブログでは軽めに紹介して終わり。こういうのを肌で体感出来るのはカンファレンスに参加した人の特権ですね。そして参加しなかったメンバーにどう伝播させるかが難しい。

このために利用されるのにOKRという概念があり、セッションでもたびたび登場していました。こちらはプロノイア・グループ株式会社のピョートルさんの発表より。

こういった記事もあります。

Googleの「最高の上司」がチームの生産性を高めるためにしていること

ただ、旧来型の組織にOKRをいきなり導入するのはハードルが高いので、OKRに飛びつくのではなく、自身/メンバーのマインドセットを育てたり、チームの心理的安全性を高める、といった改善から進めるのがよいかと思います。

組織

サービス開発という概念の薄いSIerで、どうやってサービス開発をやっていくのか?共感したのがKDDI 山田さんのセッション。

権限もリソースも与えられないのにサービス開発しろとか無理だよね、けどPdMの努力で徐々に会社を変えていける…という内容でした。こちら、自分が今会社でやろうとしている事と非常に似ている & 上司がやってくれている事と似ていて勇気づけられました。

弊社の事情

サービス開発をすると勢いづいてはいるが、サブスクリプション型ビジネスに対応した組織体系・評価体系にはなっていない。サービス開発はリリースしてからが本番とも言えるが、SIの考えが強く、リリース後のフェーズを"保守・運用"と位置づけられています

この考えを変えるため、

  • 受託SIとは全く違うロールが必要である
  • そのロールやタスクは○○である

という可視化をし、認知するところから始めてます。今作ってるのはこんな感じの図。

幸い、上層部の協力者とのつながりはあるので、ある程度まとまったら話に行こうと思っています。

また予算策定・人員配置についても、予算と必要なメンバーを計画する権限はあります。人事権はありませんが、上司がメンバーを引っ張ってこれなかったら予算は達成できなくても仕方ない、となっているので、よいかな…と思います。もちろん、アサインついたら実行責任もついてきますが、PdMのあるべき形っぽくていいかな、と思います。

予算もメンバーに可視化され、プロダクト別の採算になっているので、KDDIさんの目指している形と近いのかなと思いました(上司ありがとう)。とにかく、自分の方向性が間違っていない事を確認できたので、非常に良いセッションでした。

宣伝：弊社のプロダクト

これだけだと弊社の欠点だけあげつらった形になるので、プロダクトも少しだけ紹介しておきます。

この2つに私は関わってないので、これらのプロダクトチームは上にあげた課題を解決した上でプロダクト開発しているのかもしれません。

まとめ

登壇している方はサービス開発先駆者の皆様ばかりで、非常に学びになりました。一方、初日のネットワーキングで会話した方々は、私と同じでサービス開発初心者だったり、会社にサービス開発を理解してもらうよう奮闘していたりと、仲間がたくさんいる事が分かり勇気づけられました。

非常に素晴らしいイベントでした。また来年も参加したいです。

関連リンク

Posted by tera