エンジニアリングバックグラウンドのプロダクトマネージャーがVPoEを兼任するメリット・デメリット

こんにちは。エムスリーエンジニアリンググループVPoE兼プロダクトマネージャーの山崎です。

本ブログはProduct Manager Advent Calendar 2019の9日目の記事です。

エンジニアリングバックグラウンドのプロダクトマネージャーがVPoEを兼任している組織は、もしかしたら珍しいかと思い、今回のブログでは、自分の経験を例に、そのメリット・デメリットついて書いていきたいと思います。

ちなみにエムスリーエンジニアリンググループでは、エムスリー Advent Calendar 2019を絶賛更新中*1ですので、ご興味のある方は是非こちらもご覧ください。

読み進める上で必要な簡単な自己紹介など

現在はVPoEとして主にエンジニア組織とその成果について責任を持っている管理職的立場ですが、私自身、エンジニアリングやプロダクト開発が大好きで、グループ会社ではCTOも努めています。

詳細はSansanの藤倉さんと一緒に行ったエンジニアキャリアのイベントで発表した通りなのですが、8歳からプログラミングを始め*2、中高生の時にパソコン通信にハマりつつ*3インターネットが登場、その後はインターネットの可能性にのめり込み、学部ではネットワークを専門に学びつつ、アルバイトとしてインターネット系新規事業の立ち上げや、非IT企業2社でCTO的なポジションをやっていました。その後、大学院に進学しインターネット関連の研究をしていたのですが、やはりベンチャーが好きなこともあって、博士2年で中退。ベンチャー企業、フリーランスを経て、2006年、臨床研究を手掛けるメビックスに入社*4。2009年、メビックスのエムスリーグループ入り以降、時に自分でコードを書きつつ、主にエンジニアリングマネジメントとプロダクトマネジメントを担当しています。2012年にグループ会社であるシィ・エム・エス取締役に就任。2015年、エムスリーデジカルを共同創業、2017年にVPoEとなり、2018年からエムスリーの執行役員 VPoEとして、エムスリーグループを横断してプロダクト志向の開発プロセスおよび組織化を推進しています。

好きな言語はRubyとC#、好きな言葉は「やっちゃいましょう」*5と「なんとかします」です。

ちなみに直近のプロダクトマネジメント関連の登壇資料などはこちらです。

エンジニアリングバックグラウンドのPdMがVPoEを兼任するメリット

ということで本題です。いくつかあるのですが今回のブログではエンジニアリングバックグラウンドのプロダクトマネージャーがVPoEを兼任することのメリットを3つ、デメリットを1つあげたいと思います。

フィーチャーチームを避け真のプロダクトチームを目指せる

INSPIREDの著者、マーティー・ケイガンさんも指摘している通り、フィーチャーチーム化は良いプロダクト開発にとって警戒しなければいけない状況です*7。私の経験でも下記のようなフィーチャーチームのよくある事例が実際に観測されています。

チームが黙々とバックログの消化をしている
誰のどんな困りごとをどう解決しようとしているか聞いてもメンバーが答えられない
MVPがミニマムでない、リリースまで3ヶ月以上かかっている
誰もユーザインタビューをしていない／したことがない
期日までにリリースすることがゴール
などなど多数

これらの問題を解決し、真のプロダクトチームを目指すためには、エンジニアリングマネジメントに大きく手を入れる必要があり、一般的にエンジニアリングに対して権限を持たないプロダクトマネージャーでは荷が重いという現実があると思います。その際に、エンジニアリングマネジメントのトップであるVPoEが正しいプロダクトマネジメントの知識を持っていれば、これを避け、正しい文化を作ることができます*8。

新規事業が開始される時に基本に忠実なプロダクトマネジメントを実践できる

エンジニアリング作業が必要な新規事業が開始される場合、一般的にはVPoEにリソースアサインに関して相談がある組織が多いと思います。

ここで新規事業の状況がキャッチできることと、実際にエンジニアをアサインする必要があるか判断できることは、正しいプロダクトマネジメントを実践するにあたって大きなメリットです。つまりこのタイミングで、誰のどんな困りごとをどう解決しようとしているか、製品の発見が完了しているかレビューできます。

製品の発見ができていないようであれば、エンジニアのアサインはせず、もっと仮説検証をするべきとアドバイスするか、もしくはエンジニアリングバックグラウンドのプロダクトマネージャーをアサインして、一緒に製品の発見を支援できます。一方で製品の発見ができているようであれば、モックアップやMVPの作成に強みのあるエンジニアをアサインできます。

人事と組んで採用の観点からもより良いプロダクトチームを追求できる

優れたプロダクトの背後には優れたプロダクトマネージャーが率いる優れたプロダクトチームがあります。 VPoEが関与しなくてもプロダクトチームが自己組織化して、自律的にフィーチャーチーム化を避けたり、製品が発見されていない状況での開発を避けたりできれば理想的です。

そのためには、事業の狙いやプロダクトチームの状況、優先順位を人事と共有した上で、優秀なプロダクト志向のエンジニアやエンジニアリングバックグラウンドのプロダクトマネージャーを一定数採用するのが近道で、VPoEは人事=エンジニア採用担当とパートナーシップを持ってこれを推進できます*9。

また、プロダクトチームにプロダクト志向のエンジニアやエンジニアリングバックグラウンドのプロダクトマネージャーが増えると、チームと経営陣や企画、ビジネスサイドとも連携がスムースになり、信頼されやすいという現象も観察されています。

エンジニアリングバックグラウンドのPdMがVPoEを兼任するデメリット

一方でデメリットを見ていきましょう。

死ぬほど忙しいので右腕となるプロダクトマネージャーが必ず必要となる

真っ先に思い浮かぶのはこれです。INSPIREDにも書いてありますが、プロダクトマネージャーとして成果をあげようと思ったら週60時間は必要です*10。それをVPoEと兼任するのですから、自ら大型のプロダクトを引き受けるのは無理があるというものです。実際に、私がエムスリーデジカル*11を立ち上げた頃はプロダクトマネージャーに集中しており、VPoEは兼任していませんでした。

エンジニアリングバックグラウンドのプロダクトマネージャーがVPoEを兼任し、プロダクトマネージャーとしても成果を出すためには、右腕となるプロダクトマネージャーが必ず必要です。

対策として、現在は私が直接、大型のプロダクトを担当するのではなく、メンターとなって数名のプロダクトマネージャーを支援することで、プロダクトマネジメントに貢献しています。弊社には強いエンジニア代表の西場がプロダクトマネージャーとしてチャレンジしているので、それを支援などしています*12。