はんなりと、ゆるやかに

アジャイル、スクラムが好きなITエンジニアが日々から学んだことをアウトプット

育成をマネジメントする仕組みが学べる / 経験を深く、広く、早く。プロダクトマネージャーの成長を加速する3つの仕組み(pmconf2022)

今年も開催されましたプロダクトマネージャーカンファレンス 2022。楽しみなイベントです。複数回に分けて内容をまとめていきたいと思います。

2022.pmconf.jp

本ブログで紹介するセッションは経験を深く、広く、早く。プロダクトマネージャーの成長を加速する3つの仕組み です。PMに限らず社内の育成について応用の効く内容でした。

概要

  • イケてるPM:どんなプロダクトでも難易度でもゴールを定め、解決策をデザインし、最速でプロダクトを成功させる
  • スキルアップには経験をマネジメントすることが重要
  • 経験を深める、広げる、早める施策に分解
  • 深さを測るモノサシとして難易度テーブルを定義した。「見立て(Why/What)」「仕立て(How)」に分解しさらに3つずつ、合計6つのカテゴリで測れるようにした
  • 経験を広げることで観点を広げる。
  • 本人の次のステップとして、別プロダクトに機会があれば異動を検討する
  • すべての経験をするのは時間的には無理があるので、経験を共有し追体験する
  • 過去の案件を見れたり、ナレッジシェアするイベントがあったり、オンライン講座があったり、チャット形式のコミュニティーがある
  • ナレッジシェアは盛り上がらない問題が良くあるが、目標を置いて運営することと、良質なコンテンツ作りを工夫している

深さを測るモノサシとスキルマップ

どの領域にも使えるモノサシとして「影響範囲」「課題抽出度」「実現難易度」「ユースケース複雑度」「仕様難易度」「コミュニケーション難易度」が定義されていました(それぞれにLv1~3があります)。これを難易度テーブルと名付けられていました。この難易度テーブルは1年かけて作られていました。原案を作って、複数のマネージャーから意見を聞き、運用しながらも意見を聞いておられました。
ソフトエンジニア業界でもよく耳にするスキルマップと似ていると思いました。個人的に良いと思ったポイントは2つです。抽象度とLvの分かりやすさ。
抽象度はカテゴリの分類が多すぎない点が良いと思いました。細分化しすぎていると全体の見通しが悪かったり、ドメインに特化しすぎて他で使えないスキルになったりします。抽象化しすぎも良くないのでバランスは大事ですが、私は細かくしがちなところがあるので、抽象度を意識したいと思いました。
Lvの分かりやすさ。発表から一例を抜粋しますと影響範囲だと「Lv1自グループ」「Lv2自事業部」「Lv3全社」と定義されており、簡単に判断がついて良いと思いました。

この分かりやすい難易度テーブルが出来上がったのは作るプロセスが良かったのだと思います。一部で作り切らず対話をしたり、運用しながら改善したことで、ちょうど良い抽象度と分かりやすいLvになったんだと思いました。

経験を得るためにプロダクトを変える

今の延長線上に深いレベルの経験を積む機会がない場合、別のプロダクトを検討するという話は驚きでした。しかし、育成面では良い考え方だと思いました。スキルを伸ばすには経験を積むことには同意です。書籍を読んだりイベントに参加して知識を得ることは大切だと思いますが、経験ほど育成効果があるものはないと思います。本人の意思とマッチしていれば経験を積むために環境を変えるのは良い選択だと思いました。

ナレッジマネジメントの仕組み

ナレッジマネジメントの仕組みが全社的にあるのが素晴らしいと思いましたし、その仕組みが活性化されるため目標が設定されてたり、フィードバックからの改善が進んでいる点が良いと思いました。

まとめ

PMに限らず育成の観点で汎用的に活用できる内容だったと思います。私自身もスキルマップの見直しや、社内勉強会の改善を進めようと思いました。