プロダクトマネージャーの教育を振り返る〜PMマネージャー1年生の試行錯誤記録〜
この記事は、Money Forward 関西拠点 Advent Calendar 2022の24日目の記事です。
こんにちは！京都の冬寒すぎ問題に悩んでいるプロダクトマネージャーの杉浦です。
今年はnoteを全然書けず、気付けば1年ぶりになってしまいました。
この1年、会計Plusとしてはプロダクトマネージャーのチームが誕生した1年でした。（以下、プロダクトマネージャーはPMと略します）
私から見ると、初めてPMのマネージャーとなった1年でもあります。
組織化や教育、決してうまくいったわけではないのですが、色々と試行錯誤を繰り返した年になりました。
教育に関してはあまり記事がないなぁと思ったこともあり、一年の教育活動全体を浅く広く書いている方が参考になるかなーと書いています。
組織化については、スクラムフェスオオサカで話したので、教育をメインに振り返っていきます。（そっちもちゃんと記事にしたい...！）
私自身、誰かから体系立って習っていないので、手探りで手を打っていった形ですが、こんなんしてる人もいるんだな〜と、ご参考にどうぞ！
試行錯誤の中、参考にした本やブログはできる限り紹介していきます！
なお私以外のメンバーは、開発出身とドメイン領域出身とバックグラウンドが全く違う二名です。
以下、それぞれやったことをご紹介していきます！
計画を立てる
PMスキルマトリックス
まずは、計画を立てるために全体像を明らかにしようと進めました。
そんな中、最高に参考になる記事を見つけ、そのまま真似をしています。
のっけから丸パクリスタートです。
スキルの分け方を見るに、マーティ・ケーガンの区分が下地にありそうだったので、その点もありがたかったですね〜。
記事内のリンクからスプレッドシートもコピーできるようになっていて、とても親切です。ありがたい。
社内では、上記の記事とスキルマトリックスを日本語訳して使っています。
ざっくり内容を伝えますと、プロダクト知識、ピープルスキル、プロセススキルを詳細化し、それぞれロール別でどのレベルまで求められるか可視化しています。
意図的に抽象的な内容なので、所々自社向けに具体化する必要は出てきますが、体系化を一気に進められるのでオススメです。
スキルアセスメント
スキルマトリックスを元に、自己評価とメンターによる評価を行います。
ますが、、アセスメントってなると、自分自身できないことが沢山あるので、正直ぐぬぬってなりました。
ただ正面から向き合うことで、できないことを認めて、プロダクトマネジメントもチームでクリアする意識が身につく気がします。たぶん。
強みと弱み、自己評価と他者評価の認識を合わせ、半期でどこを伸ばすのか、お互いの認識を揃えていきましょう。
大抵の場合、伸ばす部分は半期の目標にも絡みはしますが、人事評価などには使わず、純粋に教育計画のみに使います。
スキルは目的ではないですし、PMとしての成果を見たいからですね。
ただしアクション目標も立てている場合には、直接的に目標に入る場合もありました。（ユーザー解像度を上げるため、週に一度ユーザーと会うなど）
集中して取り組むことが大事なので、一律弱みを伸ばすとかではなく、重点分野を少数決めます。
計画作成
ここまで終わったら、一人一人に専用の計画を立てます。
チームの2人のバックグラウンドが違うため、注力ポイントも違い各々専用計画を立てるような形になりました。（そうです。大変なんです。）
とはいえ後述しますが、戦略コンテキストの共有など被るものもたくさんあります。
入社タイミングから計画スタートだったので、最初の90日を終えた後に小さめエピックを任せられるように、まず目標を立てました。
なのでそこから逆算して、チームビルディングから始まり、戦略的コンテキスト、ドメイン知識、マインドセット、スクラムなどのティーチング系を計画。
実践しないと信頼も貯めていけないので、小さなストーリーから始め、徐々に大きなエピックを任せるような計画です。
まあ、結論そんなうまくはいきませんでした。
プロダクトの状況は変わるし、都合の良いサイズのストーリーがいつもあるわけでもないですし。
役立ったのは、半年後どういう姿になっていたいかの認識を何度も揃えた方だったように思います。
なので実際はプロダクトの基礎知識の共有以降、知識の差があるなと思った時にティーチングを挟んでフォローしたり、実践の機会を沢山持てるように意識して計画を修正しながら進めました。
共有する、教える
プロダクトの戦略的コンテキストの共有
戦略的コンテキストという言葉は『EMPOWERED』から拝借しています。
その重要性は以下の通りですね。
プロダクトチームをエンパワーして意思決定ができるようにするなら、チームにはそうした意思決定に欠かせないコンテキストが必要になる。
この戦略的コンテキストは一般的に会社のプロダクトリーダーが決定するが、プロダクトチーム、特にプロダクトマネジャーが深く理解する必要がある。
意思決定に欠かせないコンテキストであるならば、共有せずに独立して動くことはできないので、まずここから共有しました。
戦略的コンテキストは、企業のミッション・目標・スコアカード、プロダクトビジョンと原則、チームトポロジー、プロダクト戦略などがあります。
それぞれのトピックに深すぎる要素があるので、詳細は本に任せます。
問題は、これらが整っていれば良いんですが、整っているわけないということですね。
できていないことは沢山ありましたが、できていないし、やりたいということも合わせて伝えました。
むしろチームとして、できてないから一緒にやっていこうとプロジェクト化していきました。（良いメンバーで本当に助けられました。ありがとう！）
大きな課題としてデータ活用が弱かったのですが、ノーススターメトリックの整備、ダッシュボード作成などは本当この成果ですね。
ドメイン知識の共有
ドメインの難易度が高いプロダクト特有かも知れませんが、知らないと想像も付かないため、ドメインの学習は重視しています。
ドメイン知識というと、かしこまった印象があるかも知れませんが、
例えば、真剣に友人にプレゼントを送るとしたら、友人の今の状況や困りごと、好きなことを知ろうとすると思います。
ユーザーに価値を届けるという意味では、本質的にはこの例と同じと感じており、ものづくりや商売をするとき、顧客について学ぶことは、至極当たり前なんだと思います。
会計ドメインには、安定安心の簿記の資格があるので、まず資格を取ることから始めました。
業務のシミュレーションなどもやっていきましたが、最終的には、先日もえみさんが記事にした勉強会の形になっています。
あることが当たり前になると価値がわかりにくくなるので、一回ない世界に強制的に引き戻すだけといえばそうなんですが、すごく効果があります。（普通にしんどいのでかわいそうですが…）
基本を知ることができれば、あとは顧客と会う回数を増やし、仮説検証を繰り返すような動きになっていきます。
ユーザーの解像度は、問題設定や解決策の質に直結するので、何度も繰り返します。
PMのマインドセット
プロダクトマネジメントがプロセスを固めて必ずうまくいくというものではない以上、マインドセットが大事になると考えています。
文化と言っても良いかもしれませんが、大事にしていることは共有したいものです。
これだ！と決めて掲示したりしているわけではないのですが、今まで話してきたことをまとめたらこんなことを言ってました。
アウトカム志向であること。
作ることが目的ではないことは何度でも伝えています。
誰のどんな問題を解決するのか。ユーザーの生活はどう変わるのか。
問題設定の質には、とことんこだわります。
仮説を見つけ、言語化し、検証する。ビルドトラップは絶対避けましょう。
協働すること。
一人では作れないこと、知らないことが沢山あると認めることが大切だと思ってます。
デザイナーやエンジニアと一緒に最高のソリューションを見つけて、期待を超えるものを作っていきたいですね。
またリスクマネジメントという意味でも、WhatとHowのリスクを協力して潰す姿勢を大切にしています。
早く形にして、早く試すこと。
頭の中で考えてできることには限界があるので、素早く形にして見せてみる聞いてみる。
同時に、やらずにわかることに時間を掛けないことも大切だと思ってますが、最初は判断が難しいので、素早く試す方が大事かなーと
プロトタイピングやデザインスプリントを試すなど、実践にも表れてます。
全ての人を幸せにしようとしないこと。
あなたのため、だから刺さるのであって、皆が嬉しいは誰も嬉しくないというのを肝に銘じてます。
製品開発で得られるあらゆる教訓の中で最も基本的な１つは、すべての人を同時に喜ばせようとすれば、ほぼ確実に誰も喜ばせられないということだ。
油断すると「誰に」が曖昧で話が進むことは、あるあるなので本当に気をつけたいですね。
当事者でいること。
誰かに言われた、要望をもらった、だからやります。
そうなってしまえば、もはやPMのいる意味がなくなってしまいます。
そのまま聞いてしまう行為は、ファンから楽譜を渡されて演奏しちゃうミュージシャンのようなものです。誰もそんなこと期待していません。
プロダクトのベストな姿を、自分の頭で考え、自分の言葉で説明し、作りきること。
あまり教訓めいたことを言いたくはないのですが、チームで大事にしてることのまとめでした。
繰り返しですが、チームで協力する必要があり、こうすれば成功するというプロセスがないとき、同じ意識を持つことの意味は大きいと考えています。
プロセスの共有
さて、マインドがあっても実現するための武器がなきゃ、やり切るのは難しいですよね。
たくさんのことを覚えるというよりは、ユーザーストーリーマッピングを基軸にデリバリーまでやり切れる、まず一つ、得意技を作ろうという方針でやっています。
以前プロセスについて書いた記事もあるのですが、
さすがに2年前なので変わってる部分もありますが、大枠は変わってなかったです。
このトピックについては、なによりジェフ・パットンの本が良いですね。
あとはとにかく実践あるのみなので、何度も何度もやってもらいます。
議論の仕方
対話重視の今、議論の仕方？と思われるかもしれませんが、PMにとっては大事な技術だと思い、よくチームでも話すので取り上げます。
PMは多くの人とコミュニケーションを取る仕事なので、むちゃくちゃなことを言われる可能性がどうしてもあります。
そんなとき、客観的に議論を眺め、自分の心を守るためにも知っておいた方が良いと思うので伝えています。
かく言う私も強く言うのが苦手なので、そんな性格でもプロダクトマネジメントをやり切るために覚えていったことになります。
議論そのものについて説明すると、長くなってしまうので詳細は下記の本をオススメしておきます。（『レトリックと詭弁』は読み物としても面白いです。）
ざっくりと伝えている内容は、反論の仕方（反論できれば自説にも反論できて主張を強化できる）、詭弁（おかしい論理）の見分け方を教えています。
議論に勝つことが目的でなく、建設的な会話が目的で、弱い根拠を指摘する、指摘してもらう事や、議論によって知らないことを知り、より良い結論を導き出す。
そんな風になって欲しいと思っています。
ストーリーの作り方
まだ世にないものを作る以上、ストーリーテリングによって、見えないものを想像できる形にする力はPMにとって大切だと考えています。
ウンベルト・エーコの「理論化できないことは物語らなければならない」という言葉が私は大好きなのですが、絶対の正解がない未来を扱うというのは、まさにそういうことだと思います。
ここでは、ストーリーにはある程度の型が存在するということを伝えています。
物語論を始め、ハリウッドの脚本の本だったり、ゲームデザイナー、漫画家、小説家、無数に物語の本はあるのですが、物語そのものを売るわけではないので、簡素化したテンプレでもかなり参考になると思います。
個人用のテンプレートとしては、ユーザーを主人公に、対面する課題を敵、課題解決の追い風になる賢者、課題解決の武器になるプロダクト、解決後の報酬をアウトカムとして描くものを作って共有しています。
下記の本は、簡潔にまとまっており、物語の構造を知るのにオススメです。
またPMが描くストーリーは、説得する材料となるものなので、ロジカルに根拠も必要になります。
リアルなストーリーを描くために取材をするという話はよくあると思いますが、この活動はユーザー解像度を上げていくこととよく似ています。
そう思って興味が湧き取材についても調べました。
ジャーナリストの方が書いた古めの本ですが、解像度を上げるためにどうやって取材をしているのか、とても面白いです。（データとの向き合い方が入っていないので、ちょっとPMとしては足りないですが、そもそもそういう本ではありません）
任せる、見守る、支援する
スクラムチームへの参加
会計PlusチームはLeSSを採用しており、複数チーム体制で動いています。
最初はディスカバリーグループとデリバリーグループと距離がある形になってしまったのですが、この機会に理想の形を見直すことをしました。
理想は各チームが自走して課題解決できる状態と考え、そこへのギャップを埋められるように体制を組んでいきました。（野中郁次郎先生のフラクタル構造も参考にしています）
特にPMがプロダクトチームの一員としてどのように活躍するかは、この記事を参考にまとめていきました。
その結果、PMはスクラムチームに入り、デリバリーする上での質問に答えたり、不具合の調査・解決を主導してもらうようにチームへの関わり方を変化させています。（この際、私は特定のチームには入らない形にしました）PMはユーザーのことを伝える役割でもあります。
プロダクトチームがユーザーとの距離を近く保ち課題解決できるように、PMがチームから孤立しない形にしました。
開発経験がない場合も、チームに入って一緒に行動することは、知らないことを知り、開発の基礎知識をつける事にも効果は高かったです。
まるごと任せる
これが本当に下手くそで一番難しかったです。
先回って手助けしたくなったり、つい良い方法があると言いたくなったり、今まで手を動かすことを求められてきたから当たり前なんですが、待つというのが本当に苦手でした。
ですが、そうやって自分が手出ししていくと、先にやっていて信頼を積めた自分の方に太い経験がどんどん来てしまいます。
太い経験については、ぜひ森さんのスライドを。面白いです。（私は少しヘコみました）
これでは、機会も経験も信頼も奪っていると思い、まずエピックの意思決定を任せる、口を出さないところからはじめました。
丸投げにならないよう、徐々にプロダクト全体の大きい方をお願いするようにしていますが、この塩梅がまた難しいですね。
結果として、ちょっと大きすぎるかなと思っても渡さないよりマシと思って渡しています。（本人は大変です。ごめんなさい！）
あとはフォローですが、細か過ぎると試行錯誤の機会を奪ってしまうので、様子見しながら、ポイントでレビューを入れるようにしています。
この粒度では実際粗いので、プロセス大丈夫かなーなることがありますが、試行錯誤の機会を奪わないため、完全にスタックしたと思うまでフォローをいれないようにしています。（本人は大変です。本当にごめんなさい！）
フォローも正解がない話なので、問いを投げて、考えを補助することを意識しています。（これまた苦手）
選んでもらっているようで、選択を強制させていないかなど、コーチとして未熟なもので、心配事は尽きないですね。
とにかく任せて、失敗や成功、組織内の信頼を積み上げる、その機会を奪わないことを意識しています。
終わりに
まさかこんな長文になるとは…
ここまで書いても思い返えば、まだまだビジネスの話、データの話、目標設定の話等々色々あるんですが、特に印象的だったものは書けたつもりです。
教育は長いテーマになるので、これからも挑戦していきたいと思います。
来年、早速新たな試みも始めるので、また記事にしてシェアしていきたいと思います！
引き続きよろしくお願いします！
この記事が気に入ったらサポートをしてみませんか？