ログラスの浅越(@asa_kossy)です。
本記事は 株式会社ログラス Productチーム Advent Calendar 2022 の21日目になります。昨日は@r-kagayaのFour Keysだけじゃない開発者生産性フレームワークでした。

筆者はBtoB SaaSの1→10フェーズのプロダクトマネージャーです。前職も含めて5年くらいこのポジションの仕事をさせていただいてます。
ここ1〜2年、多くの書籍が出たり、いろいろなコミュニティやイベントで情報発信が行われたり、プロダクトマネジメントに関するノウハウの流通量が国内でずいぶん増えました。おかげで仕事がやりやすくなり大変ありがたいです。
その中で、感覚値ではあるのですが「プロダクトマネジメントの考え方は誰かが単独で実行するものではなく、様々な職種がコラボレーションして不確実性に対処することで成果に繋げるのが一番良いよね」という考え方が近年はっきり根付いてきた印象があります。
今日は関連して、自社事例を交えた小話を少々。

協働がより良い成果を生む

プロダクトマネジメントの仕事とよく言われる内容でも、弊社の場合はプロダクトマネージャー以外のメンバーが一定役割を担ってくれていたり、オーナーシップを持ってくれていることが多いです。
スタートアップなので常に人手不足な状態ではありますが、その中でも協働できるポイントを作ることを意識して、わざと一定仕事を手離れさせてしまうほうがよいな…と最近思うようになり、こうなっています。
意識してプロダクトマネジメントの業務に入り込んでもらうことで、より再現性をもって成果が出せるチームを作るのが狙いです。

手離れさせているものでいうと、例えばプロダクト戦略やロードマップの具体化と、その背景情報の整理には多くのメンバーに入り込んでもらっています。

もともと「何を・いつまでに・どうやって実現するか」「なぜそうするのが良いと考えられるのか」の定義、紐づくファクトの整理、不確実な部分の絞り込みと探索のための戦術検討…あたりはPMのお仕事の重要な部分だと思いますし、お伺いするとそこにプライドを持つ方も多い気がします。自分もそうでした。
ただ、この作業は関係するエンジニア・デザイナーやビジネスチームのメンバーにある程度オーナーシップを持ってもらうからこそ、うまくワークする側面があります。プロダクト戦略やロードマップ等の各種アウトプットは、関係者間で流通して血が通ったものにならなければ、実現性のある計画にはならないからですね。
議論を速くするために要所要所でポジションを取ったり、叩き台をつくったりするのは大前提ではあるものの、複雑性のあるBtoBプロダクトの場合、プロダクトの提供価値の言語化やターゲットの選定はより顧客に近いビジネス組織のメンバーの、デリバリー上の不確実性の対処は技術とスクラム開発に長けているエンジニアリングのメンバーの一家言をどう活かすかが重要なのは自明です。
それなら、柔らかい段階から協働して方針を詰める=「みんなでプロダクトマネジメント」に取り組むことによって、内容を具体化するプロセスと目線を揃えていくプロセスを同時に回すほうが、最終的には手早くて合理的な場面が多いと感じます。

他には、プロダクトのメトリクスの洗い出しやKPIツリーの検討。
「どういったKPIが存在するのか」「それぞれのKPIはどのように相互作用しそうなのか」「その中で何がノーススターにより近く、その理由は何なのか」も、プロダクト戦略と同様に、関係者の理解がなければ数字の羅列にしかなりません。
また、アーリーフェーズのスタートアップの場合、KPIを見られるようにきちんと体制を整備していくこと自体が結構な重労働です。
「この数字が悪いです」「この数字を見られるようにしたいんですよね」というコミュニケーションだとスピードが遅いですし、面白くなくて長続きしません。「プロダクトの提供価値がこうだとすると、直近はこのあたり、将来的にはこの辺のデータが見られて改善策が立てられると嬉しいですね」というやり取りをして、データが生きて歩き出すようにしたい。そのためにはデータの意味・データを取る意味が腹落ちしていないといけないわけで、そのためにはKPIツリーの検討から一緒に始めるのが素朴で速いはずです。

「プロダクトマネージャーは何でも屋」「何でもできる人」と言われることもたまにありますが、主従が逆転して何でもやろうとすることは次善の策だと感じます。実際、何でもできたりはしない・できることしかできないですし。
プロダクトマネージャーが自分で腕をぶん回す機会はこれからもどんどん減るし、減らしていく事が成功の確度を上げることだよねと思ったりします。
昨今サーバントリーダーという言葉が完全に定着したと思いますが、キラキラしたタレントとしてプロダクトづくりを担うのではなく、地味PMとして力強く走れる組織に貢献するほうが、普遍的に求められるスキルになるのではないでしょうか。

文化がより良い協働を生む

上の節で書いたことはもちろんキレイゴトが混じっています。が、キレイゴトをうまくワークさせて実現に近づけるための手段も色々あるな、と感じています。

一番分かりやすいのは組織の文化。
スタートアップあるあるではありますが、弊社もバリューを掲げています。

ログラスの3つのバリュー

「未来へ前進するために必要な提言」を尊んでいて、日常的にそれが讃えられるようになっているからこそ、本来は他に任務がある各職種のメンバーもスムーズに越境してプロダクトマネジメントに関わってくれているわけですね。
「逆境の中でも楽観に逃げない」と言っているからこそ、難しいお題もありのままに受け止めて協働して対応ができます。
「あのときからやっておいてよかったという決断を日々行う」と言っているからこそ、将来的にプロダクトはこう進化するから、それを踏まえたデザインや設計がありえるのか、という話ができるわけです(今決めなくて良い事を切り分けてアジャイルに振る舞う必要はあります)。

うまく協働ができるかどうかは、まずは個々のメンバーのパーソナリティに依存する部分が大きいです。組織のトポロジーなど他の要素もたくさんありますが、まずは前提条件として。
価値基準に共感してメンバーが集まるからこそ、キレイゴトである協働がうまく機能するのだと思っています。
だからこそ、共鳴できる人を探して採用活動として多くの人とお話させていただいたり、掲げた文化を実践する取組も大事にしたいですね。

協働と成果がより良い文化の土壌になる

組織文化が謳われていてもそれがきちんとワークしているか、実際に日頃から体現されているか…もまた別の話で、特に組織が一定の規模になる頃には文化自体がキレイゴトになっている可能性はあります。

ただ、「文化が協働の促進や成果に役立っている事を実感するからこそ、より文化が大事にされて磨かれていく」という側面があります。
個人が成果を出して、それが自己効力感として自分を高めていくことに繋がるのと同じように、組織文化にも自己効力感があるのかもしれません。

組織を活かして協働し、それを成果に繋げる振る舞いが、回り回ってより組織を良くして、もっと成果を出やすくしてくれる。
「みんなでプロダクトマネジメントに取り組む」ことの目的を、定性的でちょっとポエミーに表現するとそんな感じになりそうです。

日々の協働と成果が文化を育てるなら、自分たちの仕事はアウトカムの向上と組織の進化を両輪で回せているわけで。成果の追求と組織づくりが密接につながってサイクルになっている、というのは面白みを感じます。

おしまい

以上です。
明日はRustに関する著書もある@tabito1975が、AWS SDK for Rust & CDK for Terraform on AWS (CDKTF)について書きます！引き続きログラス Productチーム Advent Calendar 2022をお楽しみください。

また、ログラスではプロダクトマネージャーそのものも、プロダクトにもっと関わりたい他職種も絶賛採用募集中です。
詳細は以下の採用ページからどうぞ。
https://job.loglass.jp/