複数事業部を抱えるPharmaXエンジニアチームにおける横軸を通した会議体「プロダクト横断エンジニアリング委員会」について
こんにちは。
PharmaXエンジニアリング責任者の上野（@ueeeeniki）です！
昨日は、『PharmaXエンジニアチームの組織構造について〜「事業部プロダクトチーム」と「エンジニアチーム」の関係性』で組織構造についてお話をしました
今回は、PharmaXのエンジニアチームで行っている複数の事業部のエンジニアリングリーダーが集まって行う「プロダクト横断エンジニアリング委員会」という会議体について書きたいと思います。
PharmaXでは、2事業部3プロダクト体制になっており、「プロダクト横断エンジニアリング委員会」では、プロダクトをまたがって共通の技術課題やエンジニアチームのリソース配分などについて議論しています。
複数プロダクトにまたがるエンジニアチームのマネジメントについて考えているCTOの方やエンジニアの方の参考になれば幸いです。
PharmaXの組織構造について
それでは早速PharmaXの組織構造について順を追って簡単に説明していきます。
昨日の『PharmaXエンジニアチームの組織構造について〜「事業部プロダクトチーム」と「エンジニアチーム」の関係性』とほぼ同じ内容になるので、昨日の記事を読んでいただいた方はさらっと読み流していただいて大丈夫です。
まず、右下にあるのがエンジニアチームであり、そのエンジニアチームから各事業部・プロダクトのプロダクトチーム（＝Pdチーム）にエンジニアがアサインされます。
同じプロダクトチームには、プロダクトマネージャー（＝PdM）の他にオペレーションリーダー（＝OpsL）、マーケティングリーダー（＝MKTL）、カスタマーサクセスリーダー（＝CSL）、デザインリーダー（＝DSGL）などが含まれます。
これらのメンバーが集って、スクラムを形成し、プロダクトチームは運営されます。
各プロダクトのエンジニアの中で、要件の優先順位をPdMとすり合わせたり役割を担ったり、エンジニアチームの役割分担の最終オーナーを持つ人をエンジニアリングリーダー（＝EL）と呼びます。
エンジニアリングリーダーだけでは、技術的にすべてを見切ることはできないので、テクニカルリード（＝TnL）と分担して技術的意思決定を行います。
いまお見せした簡略図①はかなりの簡略図であり、より厳密に言えば、下図のようにプロダクトチームの横にオペレーションチーム（Opsチーム）やマーケティングチーム（MKTチーム）があります。
これは考えてみれば当たり前で、プロダクトチームだけでは、各事業・プロダクトを運営することはできません。
例えば、マーケティングリーダーはマーケティングチームにも所属しつつ、プロダクトチームにも参加しています。
このマーケティングリーダーを通じて、マーケティングチームの情報をプロダクトチームに吸い上げ、逆に、マーケティングリーダーからプロダクトの情報がマーケティングチームに展開されます。
他のリーダー陣も役回りは同様です。
そして、いよいよプロダクト横断エンジニアリング委員会を組織構造の中に明示したのが下の簡略図③です。
図が見えづらくなってしまうので、オペレーションチームやマーケティングチームの円は再度見えなくしました。
OpsチームやMKTチームを消した。
プロダクト横断エンジニアリング委員会は、各プロダクトチームのエンジニアリーダーが集まり共通の技術課題やエンジニアのリソース配分などについて議論し合う会議体です。
プロダクト横断エンジニアリング委員会のアジェンダ
プロダクト横断エンジニアリング委員会のアジェンダについて見ていきましょう。
アジェンダは下記の通りです。
・各プロダクトチームから出た進捗の懸念ポイント：人材のリソース配分についての論点
・各プロダクトの重要技術的論点
・（上記2アジェンダを受けての）採用計画・方針の変更
プロダクトを横断してわざわざ集まっている理由は、エンジニアチームとして各プロダクトの状況の理解や重要な技術的課題を解決したうえで、採用計画・方針を変更することにあります。
1つ目のアジェンダで、各プロダクトチームの進捗はどうか、特に人が足りていないプロダクトチームはどこなのか？を明らかにします。
2つ目のアジェンダでは、各プロダクトチーム内だけでは解決できないような重要技術的論点を持ち合って相談します。
特に、他のプロダクトチームからの意見も聞きたいような難しい課題について議論するようなイメージです。
また、各プロダクトチームで取り組んで良かったor悪かった技術的プラクティスについても共有することで、隣のチームが車輪の再発明をすることをさけることができます。
最後の3つ目のアジェンダでは、それまでの議論を踏まえて採用計画を必要に応じてアップデートを行います。
最後に
今回は、PharmaXでプロダクトチームを横断して行っている「プロダクト横断エンジニアリング委員会」について解説しました。
意思決定の速度を上げるために各プロダクトチームが独立して動くことも重要ですが、あまりにも独立しすぎてしまっているとすぐ隣のチームで同じ過ちを繰り返してしまうこともあります。
また、特に採用計画については全プロダクトチームを横断して判断しなければいけません。
このような課題を解決するために「プロダクト横断エンジニアリング委員会」は存在しています。
私たちの取り組みが、少しでもCTOの方やエンジニアチームをマネジメントする立場の方の参考になれば幸いです。
いつでもご連絡ください
もしより詳しく聞きたい、もっと議論したいという方がいれば、YOUTRUSTまたはTwitter DMからお気軽にご連絡ください！
この記事が気に入ったらサポートをしてみませんか？