日々ヶ岳

行雲流水

プロダクトマネージャー 1 年目の振り返り

福岡の街に光が降り注ぐ

仕事でプロダクトマネージャーにロールチェンジしてから 1 年経つので、この 1 年間を振り返ることにした。それをブログに書き残してみる。媒体は普段使っている自分用のメモ帳(Notion)でもよかったのだけど、公の場に出す文章にすることでちゃんと自らを省みる気になるかなと思い、2 年くらい前に作っただけで放置していたブログを掘り起こした。当時のセンスでつけたドメインが気に入らないので早く変えたい。

あらすじ

エンジニアからプロダクトマネージャーへ

会社では、新機能開発が始まるたびに必要なエンジニアやデザイナーがアサインされて、プロジェクトが立つという流れだった。そこにプロジェクトリーダー的な役割がエンジニアから選ばれる感じ。自分はだいたい何らかのプロジェクトのリーダーとして仕様策定や進捗管理といったマネジメント業務をしつつ、エンジニアとして開発も兼務していた。これは正直回らないことが多くて、自分も iOS エンジニアでありながら、プロジェクトには別の iOS エンジニアをアサインして、開発をほぼ丸投げしていたりした。つまり、肩書きこそないものの当時から実質的にプロジェクトマネージャーとして立ち回っていた。

そして、ついに 2021 年 1 月からプロダクトマネージャーになった。きっかけは同じくプロダクトマネージャーだった同僚からの声かけ。これは素直にありがたい話だった。もともと自分はエンジニアとしてのキャリアを突き詰めていく構想は持っていなかったから。ここで転機が訪れたのは素直にラッキーだった。

チーム固定制

というわけで、自分は会社の 3 人目のプロダクトマネージャーとして合流した。そのタイミングで、これまで機能開発のプロジェクトが立ち上がるごとにチームを編成・解散と繰り返していた組織形態を変更し、プロダクトマネージャー含む各職能ごとに1 人以上ずつをアサインした「機能チーム制」をとり、チーム編成を固定してこれまでとは逆に開発プロジェクトをチームに割り当てていく方式になった。会社では 3 チーム制などと言っている。1 チームあたり 7,8 名で編成されている。

チームが固定になったことで、いくつかメリットが出てきた。

  • プロジェクト未満のタスクでも必ずどこかのチームにアサインすることで、全体としてリソース状況が俯瞰しやすくなった。これまでは細かいタスクは職能チームに直接投げていたりして、見えないところでリソース過多が起きていたり、タスクの動きが追いにくかったりしていた。
  • 機能をリリースしてもチームは解散しないので、継続的な改善がしやすい。

一方で、デメリットもある。ただいずれのデメリットもチームを固定したことに直接起因する問題ではなく、運用の問題。プロジェクトの割り当ての仕方や会議体の工夫でどうにかできるはず。

  • 特定の領域の機能をひとつのチームで担当し続けることによって、チーム単位の属人化が起きやすくなっているような気がする
  • 上記に関連して、担当領域の機能に対するオーナーシップが強くなりすぎるあまり、それがナワバリ意識のようなものに変わり、他チームの開発と干渉しようものなら建設的ではない議論が巻き起こる(しかもだいたいそれが相手チームの見えないところで交わされるので建設的ではないと書いた)

といった感じで、チーム固定制をとって、1 年間同じチームメンバーと仕事をした。

振り返り

よかったこと

  • とにかくいろいろな機能をリリースした。会社の成長曲線の傾きを変えるような巨大なインパクトを伴うリリースこそできていないものの、限られた場面では確実に利便性が向上するような機能を着実に開発し、チームとしてフル稼働した。言い換えるとプロジェクトマネジメントは問題なくやれた。兼任プロジェクトリーダー時代は専門としていなかったステークホルダーとの折衝も今年に入ってからは積極的に行った。
  • 8 月くらいから期間を空けて 4 日間にわたり、会社の指示で外部講師によるマネージャー向けの研修に参加した(経営層含む社員約 20 名が参加)。これが自分の考え方を変える大きな転機となった。具体的には、マネジメントとは人と仕事の両輪を回すことにあるということ。人を伸ばせば、その人から生み出される仕事の成果は大きくなるという考え。プロダクトマネージャーというと「ユーザーに価値あるものを届ける」などといった仕事としての成果にフォーカスしてしまうが、結局のところその成果を生み出しているのは人なので、人のマネジメントも同じくらい重視しなければならない。もともと自分はプロダクトマネージャーなのだから人のマネジメントは自分のい仕事ではないと考えて自分のチームメンバーのケアを必要以上にしないようにしていたのだが、これでどうもうまくいかなくて低迷していた時期が夏前にあったので、自らの課題にタイムリーな研修だった。
  • 人が大事なんだとわかったところで、さっそく自分のチームで 1on1 を独自に実施した。うちの会社は 1on1 を導入していて、人事評価と紐づいている。しかし、3 チーム制のメンバーの 1on1 相手は別(そのメンバーが所属している職能チームの長であることが多い)なので、チームのプロダクトマネージャーである自分が、自分のチームのメンバーのことをよく知らないまま一緒に仕事をしているということが起きていることに気がついた。個々のモチベーションやキャリアプランに沿った適切な業務アサインをできるように、独自に 1on1 を実施した。たぶんこれは会社で自分が初めて。来年も定期的に実施してお互いの頭の中のギャップを埋めながら仕事をしたいと思う。
  • 目の前の問題の解決策や新機能を考える時、解決したい課題や目的を明らかにしたうえで考えるようになった。当たり前のことなんだけど、解決策に固執しているうちに目的を見失って、「それで解決したい課題ってなんだっけ」ということがよくある。でもやっぱりたまに迷子になることがあるので、引き続き意識的に取り組んでいく。

反省点・課題

  • 自分は完璧主義っ気があるのだが、それが悪い方向に働いているのではないかと思う場面があった。例えば、議論のたたき台を作ろうと思ったらほぼ完成形を作ってしまい、チームからすると細かい点のフィードバックしか差し込む余地がない状態になっていたりする(説)。自分が事前に煮詰めてチームに持ってきた話がすんなり決まったときは、案外これに陥っていて、チームの活気を殺してしまっているのかもしれない。これだと自分がもし病気で寝込んだらチームが方向性を見失ってしまう。プロダクトマネージャーとして自分は「なぜ作るのか」や「叶えたいことは何か」といった WHY の領域にできるだけ多くコミットして、WHY を深いレベルで共通認識にすることが求められるはず。HOW の部分はチームの文殊の知恵で組み立てるほうがいいだろう。
  • 意識的にも、無意識的にも、チームにとって "良い人" であり続けようとしていた。その結果、チームメンバーに面倒な思いをさせないようにと雑務は自分が巻き取ってしまったり(その結果忙しくなって本質的な仕事に時間が使えなくなる)、チーム内で出てきたアイデアをなんでも取り入れて開発スコープを肥大化させたりした。
  • 1 週間の自分の仕事の出来に納得がいかなくて、休日も仕事のことを考えっぱなしだったことが多かった。頭の切り替えがうまくできてなくて、翌週もそのまま中途半端な成果で終わるという悪循環。優秀な人ほど休日や夜の時間をしっかり自分のために使えている印象。
  • プロジェクトマネージャー的なマインドが抜け切っていない。スケジュール通りに機能リリースするのが一般的にはプロジェクトマネージャーのミッションなのだけど、プロダクトマネージャーはその先の成果を追い求めなければならない。アウトプットではなくアウトカムにコミットすべしってやつ。

主に読んだ本

プロダクトマネージャーは経験値が物を言う職種ではあるのだけど、それでも知識の引き出しがないと、行動が起こせない場面が実際にある。とりあえず本が言ってたことをやってみて、うまくいったら自分のものにできるし、うまくいかなかったら反省を踏まえて改善して次のアクションに繋げればいい。簡単に言うけど、実際の現場では過去の学びを忘れていて同じ轍を自分で踏むことがある。まずはこれ自体を反省しないといけない。

まずは世の中的にプロダクトマネージャーってどういう役割の人なんだろうということを理解するために、とりあえずプロダクトマネージャーのバイブル的な本として筆頭に挙げられるようなものを何冊か読み漁った。

もともと読書が好きじゃなくて、本を読んでいる時間は基本的に面白くないんだけど、今年の前半はコンスタントに月 1 冊くらい頑張って読んだ。

  • リーン・スタートアップ
  • INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント
  • プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける
  • 外資系コンサルが教えるプロジェクトマネジメント
  • プロダクトマネジメントのすべて(読み通さず辞書的に使っている)
  • プロダクト・レッド・グロース「セールスがプロダクトを売る時代」から「プロダクトでプロダクトを売る時代」へ(読み途中)

来年の抱負

  • 自分の得意領域・伸ばしたい領域を明確にしたい。究極的にはプロダクトマネージャーって全部できないといけないのだけど、関わる領域が広いからこそ、軸がどこかにないとただの何でも屋になる。今やっていることが自分がやるべきことなのかどうか分からないままやり続けるという状況に陥ってしまう。伸ばしたい領域がはっきりしていれば、その領域の仕事を積極的に取りに行ったり、自ら生み出したりといったプラスアルファの行動ができるようになるはず。
  • 得た知見を概念化して再利用可能にする。セルフ車輪の再発明をしない。特に、「こういうときどういう流れでロジックを整理したらいいんだっけ。前もあったな」「こういうときどういう判断基準で意思決定すればいいんだっけ。前もあったな」ということがあっても、過去の似た場面で場当たり的に対応したせいで知見として身についていないのが現状。
  • プロダクトのビジョンを確立して、自分たちのプロダクトはどこを目指しているのかを明らかにする。これがあれば、プロダクトのどこを伸ばしていくべきなのか、どのユーザー課題が重要なのかといった判断基準が持てるようになるはず。開発チーム全員の目線も揃いやすくなり、マネージャーが細かいところに入らなくてもチームが自走するようになるのではないかな。
  • もっと情熱的になる。唐突に根性論だが、プロダクトマネージャーたるもの、人一倍プロダクトを良くすることに想いを燃やしていないとダメなんじゃないか。マネージャーになってからの自分はなんかすべてがいい感じに回るようにフニャフニャしている感じがする。

駆け出し期に立っている自分にとって、体系的な知識のインプットは大事だが、とくにプロダクトマネジメントのような抽象的な領域の職種は、会社の数だけ知見があるようなものなので、気をつけないと情報過多に陥る。インプットはほどほどにして、さっさと実践して、学びを概念化して再利用可能な知見に落とし込むほうが自分にとってプラスになるだろう。

あとは本やインターネットで得た知識をちゃんと自分の組織やプロダクトのコンテキストに合わせてアレンジして使わないと、現場感覚とズレてなんか変な感じになると思う。この点をしっかり意識しながら仕事する。ちゃんとジブンを持った骨太なマネージャーでありたい。

まだまだ書ける話はあるけど、いったんここで一区切り。 このブログが続いていくようなら、定期的に頭の整理を兼ねて小出しにしていきたいと思う。