この記事は、Merpay Tech Openness Month 2021 の4日目の記事です。
こんにちは。メルペイのVP of Engineering兼VP of Productを担当している野澤（@nozaq）です。
Merpay Tech Openness Month 2020ではメルペイに二人目のVP of Engineering（以下VPoE）として参加し、Product Engineeringという部門をスタートした記事を書きました。
あれから一年たって、今年の4月からVP of Product（以下、VPoP）としてプロダクトマネジメント組織も合わせて担当しはじめました。本記事ではエンジニアリング組織とプロダクト組織を兼務してみて良かったこと・大変だったことをまとめてみたいと思います。
担当している範囲
エンジニアリング組織とプロダクト組織を両方担当しているといっても、プロダクト開発の全てを一人で担当しているわけではありません。エンジニアリング領域はCTO（Chief Technology Offifcer）のsowawaさん・VPoEのhidekさん・私の3名で手分けしています。技術的な方針はCTOがリーダーシップを取りつつ、Platform Engineeringという共通・基盤部分をもう一名のVPoEが、Product Engineeringというサービス開発を推進するチームを私が担当していました。
また、プロダクト領域はCPO（Chief Product Officer）のtakeoさんとVPoP（私）の2名で担当しています。組織図上はCPO配下にはデザインチーム・機械学習チーム、VPoP配下にはプロダクトマネジメントチームがいる状態で、個々のプロダクト施策判断はCPOが積極的に関与しつつ、VPoPはそれら全体の進行をスムーズにするべく組織管理や全体進行に比重を置いて活動しています。
メルペイでは下図に示すようにプロダクトマネージャーとエンジニアがプロジェクトチームを組成するマトリックス型の運営をしています。
図1. メルペイのマトリックス型プロジェクト体系
今回、プロダクト開発をしていく上で常に緊密に連携していくことになるProduct部門とProduct Engineering部門を一人が担当することで進行をよりスムーズにし、よりスピード感を上げていくチャレンジとして私が両部門を兼務することとなりました。
領域横断することのメリット
ほとんどのプロジェクトはプロダクトマネージャー・デザイナー・エンジニアといった参加メンバーによって推進されていきますが、時々マネジメントによる判断・サポートが必要になるケースがあります。そういった際に、エンジニアリング側・プロダクト側どちらでエスカレーションしても結局同じ担当VPがいることでプロダクト開発全般に対しての意思決定フローがシンプルになったことがメリットだったと思います。
例) 例外的なリリース承認対応
メルペイでは通常、各機能領域で日々独立して機能リリースを行っていますが、1~2ヶ月ほど例外的に全てのリリースを集中的にコントロールする必要がある期間がありました。その間に100を超えるリリース候補を、プロダクト・ビジネス的なインパクトとシステム変更内容の依存性などを基に並び替えたりする必要があったのですが、こういったプロダクト領域・エンジニア領域それぞれの事情を総合して勘案する必要があるケースにおいて意思決定者が絞られるのは明確なメリットでした。
組織的な面においても、プロダクト・エンジニアリングで連動するチーム構成や責務の調整が行い易くなりました。プロダクト組織は機能ドメインごと、エンジニアリング組織は技術ドメインごと（iOS・Android・Webなどの技術単位やマイクロサービス単位）にチームが分かれているのですが、大まかにどのプロダクトチームとエンジニアリングチームが一緒に業務をするかという対応関係があります。ビジネス戦略のフォーカスや、組織の状態に応じてこれらのチームの分け方や担当範囲を変更するニーズはそれなりに発生するのですが、その際にそれぞれの視点でのPros/Consを一元的に把握できる為、検討がやりやすくなりました。
領域横断することの難しさ
一方メリットの裏返しでもありますが、様々な議論や意思決定に関わりやすくなったことで、逆に各所で自分が推進のボトルネックになるリスクが増大しました。これに関して銀の弾丸となる解決策はないですが、部門を跨いだ調整において必要となるような背景情報だけを明確に伝えつつ、出来る限りメンバーに委譲していく必要があります。
また、事業やプロダクト開発を推進していくという観点に加えて組織・個人としての成長に責任があります。私自身はエンジニアとして過ごしてきた時間が長いので、プロダクトマネジメント業務について一定の理解はありつつ、プロダクトマネージャーのキャリアについての専門的な知見が十分なスタートではありませんでした。エンジニアリング組織についてはCTO・VPoEの3名、プロダクト組織についてはCPO・VPoPの2名がそれぞれ人事・組織の議論に参加することで専門性・客観性を担保することを目指しています。また、自分自身としてもエンジニア・プロダクトマネージャーそれぞれのキャリア・パスについて社内事情に留まらないベストプラクティスをしっかり理解していくためにまだまだ勉強中です。おまけですが、参考までにここ一年で読んだ本からそれぞれの領域でとても参考になった本を一冊ずつご紹介します。
An Elegant Puzzle: Systems of Engineering Management
Will Larson(著)
詳細リンク
プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける
Melissa Perri(著)
詳細リンク
おわりに
今回は私自身がエンジニアリング組織とプロダクト組織を兼務した経験について書いてみましたが、メルペイでは他のVPも複数の分野を横断しています（例えば、CTOのsowawaさんはセキュリティ領域、VPoEのhidekさんは人事領域、CPOのtakeoさんはマーケティング&グロース領域も担当する等）。
マネジメントチームが自身のバックグラウンドを活かしながら少しずつ横の領域まで担当しあっていることが部門間の連携をスムーズにしたり、領域をまたいだ意思決定の速度を上げることで事業運営のスピード感を支えています。
一緒にプロダクトを作っていく仲間を募集しています
メルペイではエンジニア・エンジニアリングマネージャー・プロダクトマネージャーと様々なポジションで一緒に働く仲間を募集しています（募集ポジションの詳細はこちら）。まだまだ新しいサービスを立ち上げていく攻めのフェーズでもあり、自分の職種にこだわらず領域を超えて活躍していくような働き方を求めてる方をお待ちしています。
明日の記事は @orfeonさんの「お手軽な全文検索API構築」になります。引き続きお楽しみください。
