この記事は、Uzabase Advent Calendar 2023の10日目の記事です。
昨日の記事は@itsukiyさんの「YAGNIから受け取ったメッセージ」でした。
まえおき
現在僕が所属するユーザベースでは、エンジニア、デザイナー、プロダクトマネージャーは別の組織に所属していて、チームとしてプロダクトを開発・運用する日々の活動はエンジニアからなるプロダクトチームのメンバーが中心となって行っています。
デザイナーやプロダクトマネージャーは兼務であることも多く、日常の多くの時間を共にしてはいません。
もちろん、その時間にデザイナーやプロダクトマネージャーもそれぞれがプロダクトにまつわる活動をしているわけですが、いわゆる全員同席状態、常に自然とチームとしての意識を持ちやすい状態ではない、ということです。
それでも、僕はデザイナーやプロダクトマネージャーを含めた「チーム」として考え、行動することが成功するプロダクトづくりのためにとても重要だと考えています。
それを実現するために、（現状のデフォルトとしての）エンジニアからなる開発チームとして、どのようにプロダクトマネージャーと付き合っていくのがよいか、ということを書きます。（今回はプロダクトマネージャーにフォーカスします）
これから書くことには実績のあることだけでなく、仮説も含まれますが、僕が実現していきたいチームの姿として書いてみます。
外部のステークホルダーではなく、チームの一員
この記事で言いたいことを一言でまとめると、「プロダクトマネージャーを、外部のステークホルダーではなくチームの一員にしよう」ということです。
しかし、日々の活動の中には、プロダクトマネージャーをステークホルダー的に、下手をすると「発注者」のように扱ってしまいかねない数々の罠があります。
ここからは、プロダクトマネージャーをチームの一員にしたいという前提で、「やってしまいがちだが、避けるべきこと」を「Dont's」、「かわりにこうしよう」を「Do's」というかたちで対比させながら記していきます。（なお、記事中の画像はすべてDALL·Eで生成しました）
意思決定に必要な情報を引き出す
Don'ts: 意思決定を委ねる
プロダクトマネージャーは、その知識や経験から、どのような機能に取り組むか、どのような順序で取り組むか、どのような仕様にするかといったことについて決める能力が高いことが多いです。
僕がいる会社では特にこの傾向があるようです。プロダクトがB2B SaaSで、プロダクトマネージャーは営業や、CSといった職種の経験があるケースが多く、ユーザーと話したことも多ければ、自らユーザーとしての視点も強く持っているからだと思います。
だからといって、エンジニアから「どうしますか？」といった聞き方をし、意思決定を委ねてばかりでは、いつまで経ってもプロダクトマネージャーがいないと何も決められないままです。
意思決定を委ねてしまうことは、もともとある情報の偏りがならされないこと、意思決定をする経験の量自体にも偏りが出ることという2つの偏りにつながり、悪循環が生じるからです。
Do's: 意思決定に必要な情報を引き出す
「どうしますか？」という質問は、たとえば「どうするのがいいと思いますか？」と言い換えることができます。
前者は決定そのものを委ねているのに対して、後者は決定のために必要な情報を引き出そうとする態度に一歩踏み出しています。
そこでプロダクトマネージャーが「○○するのがいいと思います」と言ったら、たとえばこういう風に続けることができます。「××だからですか？」、「その場合、ユーザーはどう嬉しいんでしょうか？」、「△△という場合についてはどうでしょうか？」。
こうすれば、チームはユーザーや、プロダクトを取り巻く環境について学ぶことができます。
さらには、プロダクトマネージャーを孤独にすることなく、プロダクトマネージャーを含むチームの共同責任において意思決定を行うことができます。
「どうしますか？」と「どうするのがいいと思いますか？」は小さな違いですが、重要な違いです。
チームが学び続ければ、やがて「こうしませんか？」と言えることも増えていくでしょう。
補足
これは「合議」や「全員の納得」を最重要視することとは違います。
結果として議論が盛り上がったり、全員が納得できる結論が導かれることも多くなるでしょうが、それ自体が目的ではありません。
チームがお互いに学び合って成長し、知りうる情報を最大限活用して意思決定し、エンジニアとしてコードだけではなく、プロダクトにコミットできるようになっていくことが目的です。
プロダクトマネージャーを情報源とのコネクターにする
Don'ts: プロダクトマネージャーを情報のボトルネックにする
プロダクトマネージャーはたいてい、エンジニアが知らないさまざまなことを知っています。
ユーザーのこと、ビジネスのこと、ステークホルダーのこと。
プロダクトが使われる世界のことも、組織のさまざまな事情も、多くの場合、一番知っているのはプロダクトマネージャーです。
だからといって、チームが情報を得るための源泉を、プロダクトマネージャーだけに限定していては危険です。
チームが情報を得る能力が、プロダクトマネージャーの能力（可処分時間、コミュニケーション力、情報処理力等のすべて）を上限としてしまうからです。
プロダクトマネージャーがボトルネックになっている状態です。それでは量も、多様性も足りません。
また、ユーザーや他部署とのやりとりの間にプロダクトマネージャーを挟んでいては、コミュニケーションの階層が増えることから、効率もスピードも落ち、お互いを知る機会も失ってしまいます。
最後に、プロダクトマネージャーが窓口になることで、受発注的な関係にも陥りやすくなってしまいます。
本当はユーザーとビジネスのためのプロダクトを作るチームのはずなのに、ユーザーとビジネスのことを考えているのはプロダクトマネージャーだけで、チームは言われたものを作るだけ、という状態です。
Do's: プロダクトマネージャーを情報源とのコネクターにする
プロダクトマネージャーには、情報のボトルネックではなく、情報源とのコネクターになってもらいましょう。
プロダクトマネージャーに頼んで、営業やCSの人を紹介してもらったり、一緒にユーザーと会わせてもらったり。
エンジニアと他部署のメンバーが直接つながれば、必要なことは直接やり取りしたり、CSの人とのつながりができれば、ユーザーに会わせてもらったり、といったこともできるようになります。
チーム全体が、プロダクトを取り巻く環境とすばやく、豊かなやり取りができるようになり、早く、多くのことを学べるようにます。
補足
個人的な考えですが、最近、文字通り「すべての」メンバーが「直接」ユーザーを知るべきだと思うようになりました。
以前は「開発に集中したいスペシャリストがいてもいいはずだ」と思っていました。しかし、スペシャリストであっても、ユーザーに直接会う経験は持った方が絶対にいいと感じています。
誰が、どういう環境で、どういう目的のためにプロダクトを使うのかということについて、直接ユーザーに会うことで得られる情報が圧倒的に多いからです。
量的にも、質的にも、人づてに聞くのと比べて、非常に大きな差があります。（このことについての解像度がまだ低く、これ以上うまく言語化できないのですが……）
その人自身が有用な情報を得られるという点でも、チームの人たちとのコミュニケーションが取りやすくなるという点でも、投資対効果が抜群に高いのが「ユーザーに会う」だということです。
もちろん、人によって頻度や濃淡は違っていいと思います。
一緒に仕事に取り組む機会を作る
Don'ts: すべての仕事を分担する
エンジニアのチームとプロダクトマネージャーとが同じ部屋で同じ時間を過ごしていない場合、コミュニケーションを取るまでの腰が重くなったり、非同期的なやり取りが中心になったりしやすいです。
「ここまではプロダクトマネージャーの仕事」「ここからはエンジニアの仕事」のように、境界線を引くような様子も、意識的にも無意識的にも、表れてきます。
すべての仕事を一緒にやる必要はないかもしれませんが、一方で、すべての仕事を分担するのも決して効果的とは言えません。
本当は、お互いの仕事の内容や、やり方から学べることがたくさんあり、結果的にチーム全体の成果ももっと大きくできるはずです。
Do's: 一緒に仕事に取り組む機会を作る
プログラマがペアプログラミングやモブプログラミングをするように、プロダクトマネージャーとも、様々な仕事に「一緒に取り組む」機会を作ることができます。
たとえば、リリース計画やイテレーション計画。あるいは、受け入れテスト。プロダクトマネージャーにモブプログラミング自体に参加してもらうこともできます。
これは、「作った計画を説明して見てもらう」であったり、逆に「受け入れテストの定義をしてもらう」ということとは違います。
計画でも、受け入れテストでも、同じ時間、同じ場所で、一緒に計画を作り、一緒に受け入れテストを書く。プロセスも、成果物への責任も共同所有します。
補足1
計画や受け入れテストの例でいうと、もしかしたら、見積もりはあらかじめ済ませておいたり、受け入れテストの自動化コードを書くことはプログラマやテストエンジニアだけでやってもいいかもしれません。
必ず100%の作業を一緒にやろうという話ではありません。
もちろん、一緒にやるのもよいでしょう。
補足2
こういう取り組みは初めはエンジニアから提案し、プロダクトマネージャーに協力してもらうというかたちになることが多いと思います。
その場合、プロダクトマネージャーは慣れないことをしているわけなので、はじめはうまくできなくても大丈夫であることをしっかりと伝え、またやり方についても少しずつ伝えながら徐々に慣れていってもらうとよいでしょう。
一緒に取り組む時間や内容についても、少しずつ増やしたり、少しずつ複雑なものに取り組むようにしていくのがおすすめです。
また、一緒に取り組み続けることで、やがて本当に効果的な分担が見つかり、再び分担するのがよいということになっていくかもしれません。
補足3
最近は、「プロダクトマネージャーへの進捗報告」や、「プロダクトマネージャーが捕まらなくて困っている」などが、このDon'tsが生じているサインだと考えています。
「進捗報告」が必要になるのは、そもそもうまく分担できていないから。（上下関係になってしまっている）
プロダクトマネージャーが捕まらなくて困るのは、そもそも十分な目的と情報の共有・同期ができていないから。
どちらも、「一緒に取り組む時間を増やす」という方法で緩和・解消していけるのではないかという仮説を持っています。（※まだ実績が少なく、仮説レベルです）
お互いに学び合う
Don'ts: エンジニアだけが学ぶ
エンジニアリングはすべてを具体化していく仕事なので、自然とプロダクトマネージャーから情報を「引き出す」側に回ることが多くなります。
すべてが具体化された「コード」を書くためには、不足している情報を発見し、聞き出し、確定させていく必要があるからです。
たとえば、エラー処理一つとっても、どうあるべきかを決めるには、ユーザーからどのように使われるかを知る必要があります。
作業の優先順位を決めるにも、ユーザーやビジネスから、どちらがより望まれているのかを知る必要があります。
これらの情報をプロダクトマネージャーに求めること自体が間違っているわけではありません。
しかし、聞く側・聞かれる側という関係が固定化してしまうと、他のDon'tsを誘発し、受発注的な関係に陥ってしまうリスクがあります。
また、エンジニアが知っていることの中には、プロダクトマネージャーも知っていればもっと適切でタイムリーな行動や意思決定ができることもあるはずです。
Do's: お互いに学び合う
エンジニアがプロダクトマネージャーから学ぶように、プロダクトマネージャーにもエンジニアから学んでもらいましょう。
プロダクトマネージャーには特に好奇心や他職種のことを学ぶ意欲の強い人が多く、エンジニアが思っている以上に学びたがっている可能性が高いと思います。
計画のこと、テストのこと、リリースのこと。どういう理由、どういう考え方で、何をやっているのか。どこにどういうリスクがあり、また機会があるのか。
そういったことを、折に触れて、聞かれなくても、共有していくことはできます。
プロダクトマネージャーが何かを聞いてくれたら、怖い上司や取引先に伝えるようにではなく、すぐ隣の席の同僚に伝えるように、知っていることを気前よく伝えましょう。
文化や慣行、考え方の違いもあるでしょう。驚かせてしまうこともあるかもしれません。
それでも、いや、だからこそ、それらを伝え、学び合うことが、チームになるためには必要です。
補足
これは、デザイナーなどの他職種との間でも同様だと思います。
相手から学ぶことと、相手に学んでもらうことの両方ができているかを問うことは多くの場面で有効です。
おわりに
この記事では、エンジニアとプロダクトマネージャーが日常的には（一見）チームとして活動していない組織で、それでもチームになっていきたいとき、どうすればチームになっていけるかを書きました。
意思決定に必要な情報を引き出す、プロダクトマネージャーを情報源とのコネクターにする、一緒に仕事に取り組む機会を作る、お互いに学び合う。
これらの行動が、プロダクトマネージャーをチームの一員にし、チーム全体として強くなっていくために有効だと考えています。
そもそもなぜチームになっていきたいのか、ということについては特別に取り上げて触れてはいませんが、それぞれのDon'tsやDo'sの中である程度は表現できたのではないかと思います。
僕自身もまだまだ日々考えたり、試してはうまくいったり、いかなかったりしているところなので、記事へのフィードバックや、「自分（たち）はこうしているよ」といったコメントをお寄せいただけるととても嬉しいです。
