プロダクト戦略をドライブさせるPMスキル定義
CADDi Drawerというデータ活用プロダクトでは、プロダクト戦略をドライブするためのプロダクトマネジャー(PM)スキルを定義しています。この記事はそのスキル定義の策定プロセスとスキル向上の運用について紹介します。
はじめまして、CADDi Drawerでプロダクトマネジャーをしている安部です。
なんのためのスキル定義？
元々弊社キャディには、ビジネス職群において共通の物差しとなる人材評価フレームワークがあります。現在、PMもビジネス職群にいるので、類に漏れずその枠組みで評価され、成長・育成PDCAを回してきました。
その一方で、プロダクトマネジャーに特化したスキル定義も多く存在しています。プロダクトマネジメントトライアングルはそれに近い整理としてもっとも有名です。
そんな中で、改めて整理の必要があったのか。
我々はプロダクトの0→1フェーズを越え（たか越えていないか定かではないですが）、拡大フェーズに入ったあたりでプロダクト全体のビジョンや戦略が策定されました。「我々は何者になっていくのか、何を実現するのか」「そのためにどう登っていくのか、何をしないのか」が改めて定められました。
スキル定義の契機はそこに有ります。それらをPMとしてドライブしていくために、必要なケイパビリティはなにか。「キャディの汎用的な人材評価フレーム」や「一般的なPMスキル定義」よりも具体的に今なら捉えられるのではないか、と考えたのです。顕在・潜在ふくめて不足スキルを明確化することで、組織的な調達に繋げていきたいという狙いがあります。
スキル定義のレシピ
ご想像の通り、A.縦(カテゴリ)x横(レベル感)のフレーム定義と B.そのマトリックスに入る要件の具体化がざっくりプロセスです。その精緻化のために、大きく3つのアプローチをとりました。実際にはA.をやってB.に進む、という線型な動きではなく下記を通じてA.とB.を行き来しながら精度を高めていきました。
世の中のスキル定義フレームを参考にする
先行プロダクトの職務要件を洗い出す
隣接組織からの期待値を集める
1.世の中のスキル定義フレームを参考にする
世のフレームも大いに参考にしました。列挙するとキリがないのですが、ここではいくつか特に参考になったものをご紹介します。
↑ CircleCIのエンジニア定義：ヨコ軸のレベル定義はほぼこれを……
↑ ITスキル標準（ITSS)：スキルの概念、粒度感を参考に
↑ データサイエンティスト協会スキルチェックリストver.5：特に「ビジネス力」や「AI利活用スキル」の記載ぷりを参考に
↑ 及川さんのPMスキルフレーム：弊社版のスキルマップを大方作成した後に対象関係を整理し、抜け漏れなどがないか確認させてもらいました
2.先行プロダクトの職務要件を洗い出す
プロダクト特長や向かっていく方向性を捉えた時に、他領域および海外を中心に、ベンチマークになるプロダクトをいくつか列挙できました。
それら企業が、PMのJob descriptionにどういった要件を記載しているかを網羅的に抽出しました。StaffとSeniorってどっちが上なん？Senior staff PMとPrincipalって……といったところからのスタートでした。
3.隣接組織からの期待値を集める&有識者にレベル定義相談
エンジニアはもちろん、BizDevやCustomerSuccessなどの部門長クラスにもPMに期待していることをヒアリングしてレベル定義に盛り込んでいきました。なかには「こういった期待があったんだ」という発見もあり、このインタビューは定期的に設けていきたいと思いました。
暗黙的だった期待値が言語化されてあるべき姿の議論が加速
こうやって輪郭が具体化してきたいくつかのカテゴリでは、現状のPMチーム内に十分なスキルホルダーがいないものもありました。それではどうしても筋の良い詳細化ができない。
そこで、社内有識者を特定しレベル定義の詳細化に協力してもらいました。特にテクニカルなテーマは、社内のTechLead陣に広く依頼しました。
できあがったスキル定義の外観
結果的にどのようなアウトプットになったのか、その骨子だけここでお伝えします。
タテ：（課題解決+専門性）x(共通+個別)
どんなイシューに対峙してもPMとして共通して求めたい課題解決と専門性、あとはメインで並走する開発チームによって個別に求められる専門性としてスキルをカテゴライズしています。
その粒度ですが、なるべくノウハウやナレッジなど要素スキルそのもので捉えるのではなく、それらを適切に統合してアウトカムを生み出せる状態を定義として意識しています。その辺りは情報処理推進機構/ITスキル標準の考えを参考にしています。
具体的には「何かを知っている」といった記述に閉じないようにしています（なるべく）。その一方で「プロダクトロードマップ」といったような具体的なアウトプットでスキル構成するのも避けています（なるべく）。
ヨコ：影響範囲の広さ
共通スキルにおいては、1つの開発チームと共に典型的なプロダクトマネジメントを実施できる状態をLv.2としてイメージし、自身がオーナーシップを持てる広さでレベル分けしています。
個別スキルは、ソフトウェア技術に関するスキルが多いのですが、レベル感は共通スキルと平仄をとりつつ、もう少し具体的な表現をしています。エンジニア陣からの期待を参考にして設定しました。
運用における3つのコンセプト
磨き込み余地はあるものの、運用を開始しています。まずは各自スキル評価を行って現在地を明らかにして、組織としての課題設定を行いました。
課題設定にあたってのコンセプトは下記の通りです。
共通に求めたいスキルに関しては、その平均点を上げる。できれば最低点を確実に短期で底上げできる仕組みを用意する
個別に求めていくスキルに関しては、それぞれのカテゴリにおいてハイスコアメンバーがいる状態を目指していく。誰かが高い専門性を有している状態を組織として作っていく。どうしても経験によってしか習熟していかないが経験が希少なカテゴリにおいては、採用を視野に入れる
該当テーマにおいては、現時点のハイスコアホルダーをオーナーとして独自カリキュラムを作成。組織的に、そして「計画的に」スキル伸長にコミットします
直近テーマでは、複数チームごとに探求テーマをわたしてリサーチ&ドキュメンテーションするプログラムが組まれました。先日、各チームよりそれをベースに講義がありました。後日、テストを通じてスキル評価をします。いずれも前提理解に基づき、自分たちのプロダクトを捉え直すことが求められる実践的な出題になるとかならないとか。
これから
以上がスキルマップの策定プロセスとそれを通じた運用イメージです。
スキルカテゴリの中には、上記画像にもあるように「⚫︎⚫︎理解」系がいくつかあります。これらは継続的なキャッチアップや考察が求められます。今日現在のスナップショット理解で終わらず、組織としての継続的な仕組みや習慣に昇華させて、プロダクトマネジメントに活かされている状態を作っていきます。
またスキルマップ全体も、事業イシューが変わればチューニングされていくべきだと捉えています。常に中期的な視点に立ち、ケイパビリティデザインを心がけていきたいです。
ぜひ一緒に話しましょう！
今回は、具体的な部分は伏せた形で述べさせていただいていますが、クローズドでお話する機会であればもう少し具体的な話もさせていただけると思っています。私もこの取り組みをもっと強化していきたいと考えていますので、色々なプラクティスも教えていただけると嬉しいです！
Twitterで@abeshowまでお気軽にDM頂けたらと思います！ また一緒に働きたいと思ってくれた方がいたらもっと嬉しいです。こちらからのカジュ面もお待ちしています。
この記事が気に入ったらサポートをしてみませんか？