Webサービスのプロダクトマネージャーはどの程度の開発知識を持っておくべきかという問いに対しての2019年時点の結論

プロダクトマネジメントトライアングルの考え方によると、プロダクトマネージャーは「顧客」「ビジネス」「開発者」という三領域の機能をプロダクトチームに提供（機能がなければ自分で役割を演じたり、補う方法を見つける）していくことが求められている。

つまりは、「開発者」としての機能を自分自身に持たなかったとしても、その役割を補完できる誰かがいるのであれば、それらは問題がないという考え方だ。他方、現実的なプロダクトチームにおいては、プロダクトマネージャーとエンジニアがプロダクトについての会話をすることも多く、一定程度の開発知識を持っておくことが望ましいと思われるケースも多くみられる。

このエントリでは、bosyuのプロダクトマネージャーが考える、プロダクトマネージャーが持っておくべき開発知識についての見解を記す。

なお、この記事はbosyu Advent Calendar 2019 の16日目の記事として書かれている。（本当はFlutterについて書こうと思ったものの、テクニカルな内容が何も浮かばなかったので逃げた結果の記事がこれ）

身も蓋もない言い方をすればチーム次第でしかない

はじめに結論を書くが、この問いの解は「チーム次第」ということでしかない。いわゆるビジネス領域に強いエンジニアが多いチームであれば、プロダクトマネージャーの意図をエンジニア側が汲み取ってくれることも多く、プロダクトマネージャーに開発知識がなくとも成り立つケースが多い。

他方、ビジネス領域の興味関心が薄いエンジニアが多いチームの場合、プロダクトマネージャー側がエンジニアに歩み寄る必要が多く、一定程度の開発知識が必要となる。

また、そもそもエンジニアの人数が少ない場合などは、プロダクトマネージャーも一定程度の開発を行う必要があり、この場合はそもそもとして開発力がないと話にすらならない。

つまりはチーム次第。とはいえ、このように書いてしまうと議論が前に進んでいかないため、いくつかの前提をもとにした場合に、それぞれどの程度のエンジニアリング力が必要かという観点で議論を進めることとする。

一人チームの場合

プロダクトマネージャー＝エンジニア＝ビジネスサイドになるため、自身のエンジニアリング力が全て。割愛する。

三人チームの場合

多くの場合、エンジニア2名 + ビジネスサイド1名もしくは、エンジニア2名 + デザイナー1名のチームとなる。この場合、プロダクトマネージャーの役割をこの三人で分割して行うこととなる。そのため、エンジニアと同様のエンジニアリング力がない場合はチームとして成立しない。

7人チームの場合

これくらいの人数になると、プロダクトマネージャーという専任の役割がいても良い規模感になる。多くの場合下記のようなチームとなる。

・PdM/PjM1人、エンジニア4人、デザイナー1人、ビジネスサイド1人
・PdM/PjM1人、エンジニア3人、デザイナー2人、ビジネスサイド1人

チームの人数に余裕がないため、PdMがPjMの役割を兼任するケースが多いと考えている。そのため、エンジニアやデザイナーとの直接のやりとりが多数発生するため、一定程度のエンジニアリング知識やデザインに関する知識がないとチームをうまく進めることが出来ない。

ここでいう一定程度とは、下記のようなレベル感をさすと考えている。

・プロダクト開発に関する主要な手法についてを他者に指導できる
・データベースのテーブル構造を理解することができ、SQLを利用して主要なデータの抽出を一人で行うことができる
・利用しているプログラミング言語の特徴を理解しており、なぜその言語で作る必要があるのかを理解している
・利用しているフレームワークの特徴を理解しており、なぜ他のフレームワークではなくそのフレームワークをエンジニアが選択したかについての自分なりの説明ができる
・プロダクトに問題が発生した時に、少なくともサーバーサイドの問題なのか、フロントエンドの問題なのか、インフラに関連する問題なのかといった大枠の切り分けができる
・開発に関するチケット等を作成した時に、そのチケットの対応にかかる時間の概算を見積もることができる

10人チームの場合

多くの場合に、専任のプロダクトマネージャー（もしくは、プロジェクトマネージャー）が配置される人数。場合によってはその下にプロジェクトマネージャーが配置される。

プロジェクトマネージャー（スクラムで開発する場合はスクラムマスターの役割を担う人）が配置されている場合、プロダクトマネージャーが持つべきエンジニアリングの知識は大幅に減少する。

他方、上記の役割を担う人が存在しない場合、7人チームの場合と同様の知識を保持しておく必要がある。

20人以上のチームの場合

プロダクトマネージャーが配置され、かつ、その下にサブチームごとのプロダクトマネージャー（もしくは、プロジェクトマネージャー）が配置されることになる。

この規模になるとチームが階層化されることが通常であるため、自身よりエンジニアリング力のあるプロジェクトマネージャー等を配置することができれば、これといったエンジニアリング知識は不要となる。

また、この規模になると自身のエンジニアリング力自体がチームにとって足枷となるケースが発生する。つまりは、プロダクトの方向性の限界を自身の開発力の限界に置いてしまうという問題が多発してしまうのである。作れないかもしれないものを提案、推進していく力が重要になってくるため、エンジニアリング力があったとしてもそれを忘れた上でプロダクトの方向性を定めていく胆力が必要となる。

100人以上のチームの場合

100人以上のチームのプロダクトマネージャーの役割を担ったことがないので空想で話す。ここまでくるとエンジニアリング力など皆無でもチームを前に進めることができるはずだ。

おわりに

テクニカルな記事がかけない程度のエンジニアリング力しかない自称プロダクトマネージャーが戯言を書いてきたが、一番伝えたかったのは「チーム構成によってプロダクトマネージャーの役割は変化する」ということである。そのプロダクトが勝つことが一番大切であって、自身の役割など気にも留めない人が、個人的にはプロダクトマネージャー向きの人材だと思っている。その観点からすると、開発知識にしろ、ビジネス知識にしろ、ドメイン知識にしろ、全て多く、強いに越したことはない。それゆえに、学びを忘れた瞬間に、職業としての死しかない。

P.S. 職業としての死を迎えつつあるアカウントがこれ。

タイトル未設定