プロダクトとエンジニアリングとのマトリクス型組織で役割と責任を明確化し、連携を強化する
――組織が大きくなると、プロダクト側とエンジニアリング側とのスムーズな連携が難しくなると言われています。どのように再編成を行われたのでしょうか。
木村：どんな業界でも組織が大きくなると、企画と制作に分けることが多いと思うのですが、プロダクトとエンジニアリングでチーム分けをしただけでは、もともと異なる視点や価値観をもつだけに、対立や分断が生じてしまいがちです。
そこで縦軸にプロダクト、横軸にエンジニアというマトリクス型とし、横軸はバックエンドやiOSといった技術別でマネージャーが束ね、その統括をエンジニアリングマネージャーが行うようにしました。さらに、それまでプロダクトマネージャーが担っていたメンバーのアサインを、エンジニアリングマネージャー主導で行うようになりました。このマトリクス型組織の考え方はGoogleなどでも採用されており、母体であるメルカリでも同時に導入しています。
再編成から約７か月後の2019年2月に「メルペイ」を無事にリリースし、その後は継続的に新機能の追加や改善などもスムーズに進んでいるので、急激に人数が増えてスケールしながらも、連携が密になって仕事を進めやすくなったという実感があります。定量的にも、月次でトラッキングしている社員の「働きやすさ」のスコアが上がっていることから、間違いないと思います。
また、プロジェクトへのメンバーのアサインも、的確にできるようになったと思います。というのも、プロダクトマネージャーは、どうしてもプロダクトの成長や品質に思いが先行するので、スタッフを抱え込んだり、アサインが偏ったりすることがあるのです。そこで、エンジニアリングマネージャーとしては、エンジニアの適性や成長、キャリアといった点を意識するようにしています。実現できるスキルがあるかどうかはもちろんですが、エンジニア個人のチャレンジも組織の成長には重要ですからね。プロダクトとエンジニアの両面からバランスを取ることが大切だと思っています。
――機能追加や改善については、どのように決定されるのでしょうか。優先順位の考え方についても、プロダクト側とエンジニア側で違いが生じそうです。
木村：それは……、かなりありますね（笑）。例えば、エンジニア側から見れば、最初の見積もりはスコープを価値ある最小限にとどめ、段階的に行っていくのが一般的です。しかし、プロダクト側が最初のスコープを切ると、要件が肥大化する傾向にあります。もちろん決済アプリとして機能の網羅性が不可欠であったり、関係するステークホルダーが多くてビジネスロジックが複雑だったり、事業的にやむを得ないこともあります。
しかし、要件が肥大化すれば複雑な依存関係も相まって不確実性が高まり、見積もりを大幅に超過して意味をなさないものになってしまう可能性があります。さらに要件が多いとプロジェクトチームが細分化し、各チームの連携も難しくなって混乱しがちなのです。
まさに2018年5月頃はそうした状態にあったので、対症療法的ではありましたが、私が中心になってそれを解きほぐし、フェーズとスコープの整理を行いました。なかなかタフな仕事だったのですが、改めて全体を見渡すエンジニアリングマネージャーの役割の重要性を実感しました。もちろんプロダクトマネージャーも全体を見ていますが、どうしても「お客さまにいいものを届けたい」という気持ちの方が勝って、機能を盛ってしまいがちなんですよね。事業インパクトの面からは正しいことではあるのですが、エンジニアリングの実現性という観点からは、やり方を工夫する必要があるわけです。
――プロダクトマネージャーとの連携や責任分担なども含め、エンジニアリングマネージャーの役割や存在意義が大変よくわかりました。後編ではさらに具体的にどのようにエンジニアリングをリードし、運営や改善、機能の追加などの業務に取り組まれているのか、具体的な例もご紹介いただきながら、手法や工夫などについて伺います。
