この記事はBASEアドベントカレンダー 21日目の記事です。

まえがき

BASE BANK株式会社でエンジニア兼Engineering Program Managerをやっている松雪(@applepine1125) と永野(@glassmonekey) です。 BASE BANKでは組織の拡大に伴って表出した課題を解決するために、プロダクトのデリバリー、クオリティに責任を持つEngineering Program Manager(以下EPM)という役割を導入しています。今回はまだ馴染みのないであろうEPMについてと導入の背景、具体的な働きざまについてご紹介します。

Engineering Program Manager(EPM) とはなにか

そもそもEPMという役割自体が日本で馴染みのないものだと思います。 Apple やAmazon、Meta(旧FaceBook)社などで正式なポジションとして存在しており、ざっくり各社のjob descriptionから要素を抽出してみると、主に以下のような役割を担っていることがわかります。

開発のリードや開発プロセスの改善
設定したリリーススケジュールへの責任とプロダクトのクオリティの担保
プロジェクト、プロダクトの技術的な阻害要因の排除
ステークホルダーと適切なコミュニケーションを取り、自身での意思決定や意思決定のエスカレーションの実施

Product Manager(以下PdM)や外部のステークホルダーと開発チームの間に入り、適切に開発のサイクルを回していくために必要な役割です。組織によってはこれらの役割をProject Manager(以下PjM)、Engineering Manager(以下EM)、Tech Lead(以下TL)といった役割が担っていたり、もしくは名も無き仕事として誰かが対応しているのではないでしょうか。

PjM、TL、EMとEPMの違い

PjM、TL、EMといった、一見EPMと近い役割がすでに存在する中でEPMという役割が新たに生まれたのはなぜでしょうか、PjM、TL、EMとEPMとでは何が違うのでしょうか。それぞれ重なる部分もありますが、役割としては微妙に異なります。それぞれ見比べてみましょう。

PjMとEPM

PjMはPJの完遂に責任を持つ役割です。 PJの要件定義や進捗管理、メンバー集めや、場合によっては予算を獲得してくるなど、PJ完遂のために様々な業務を行います。 EPMとの一番の違いは、技術的なバックグラウンドがなくてもPjMの役割を担える点です。 PjM自身が技術的なバックグラウンドを持っていたり、メンバー内にそういった判断材料を揃えることができるエンジニアがいると開発に関する意思決定がしやすく比較的円滑にPJが進行します。しかしそういったコミュニケーションや意思決定ができないとPjMはただエンジニアが提示する開発スケジュールを飲み込むしか無く、根本原因にテコ入れできずにスケジュール遅延が発生するいわゆるデスマーチへと突入していってしまいます。こうならないようにPjMの意思決定を補佐し、協力してプロダクトのリリースを行うEPMのような存在が重要になってきます。組織によってはPjMを開発面から補佐する役割はTLが担うというケースも多いかもしれません。

TLとEPM

組織によってTLに期待する役割は様々だと思いますが、どの組織でも割と共通しているのはコード品質や設計、アーキテクトの面でチームや組織に影響を及ぼす存在であることかと思います。 EPMでもそういった側面を求められる場面はありますが、そこを主戦場とするメンバーがすでにいるのであればそのメンバーに役割を委譲しつつ、連携しながらプロダクトのデリバリーへの責務を全うするのがEPMの大きな特徴です。

EMとEPM

EMは組織によってTL以上に多様な役割を持っています。参考に、広木氏が提唱するマネジメントの4象限と強め/弱めのEMの定義と照らし合わせてみると、主にPeople, Team Managementを行う弱めのEMとEPMは補完関係になるのではないでしょうか。採用や評価、日々の1on1なども含め、仕事を通した各メンバーの成長やチーム作りと向きあうEMと、メンバーそれぞれのスキルを最大限に生かしてプロダクトのデリバリーとクオリティを担保するEPMとでは、その役割の中で向き合う要素は似ているものの最終的な責任が異なります。この両方を一人で担うのはスイッチングコストがとても高く難しい仕事となってしまいます。

下図のように、強めのEMがいれば弱めのEM、EPM含め様々なマネージャ業を一手に引き受けてもらうことはできますが、そういったスーパーマンはそうそういないため、弱めのEMとEPMそれぞれで責務を分割してフォーカスするのは有効な打ち手なのではないでしょうか。

なぜEPMが必要なのか

ではそのようなEPMはどのようなケースで必要になるのでしょうか？一つ考えられるケースとしては「目的別組織」のマネジメントの場合ではないでしょうか。

目的別組織とEPM

組織形態としてよく比較されるのが"機能別組織(職能別組織)"と"目的別組織(職能横断型組織)"です。機能別組織の場合、PJ毎に各チームからメンバーが集まり、PJが終わると解散、各々別のPJへ・・・というのがよく見る流れではないでしょうか。こういった組織運営を行っている場合、わざわざEPMなどを配置せずとも、PjMやEM、TLがEPMの役割も担うことでとりあえず目の前のPJを完遂させる事はできると思います。

しかし目的別組織になると、自分が所属するチームが受け持つ機能、プロダクト、領域と継続的に向き合えるようになります。すると開発プロセスやステークホルダーとの関わり方の改善も半永久で継続的に行う必要があったり、チームの経験を形式知として蓄積しやすくなるため、それらの活動を主な責務とするEPMを配置することは合理的ではないでしょうか。

特に特定の領域と継続的に向き合い価値提供していくためには、その領域の深いドメイン知識も必要になってきます。仮に開発プロセスやコミュニケーション力が高かったとしても、深いドメイン知識がないと適切なエスカレーションや開発スコープの変更判断などができないためです。

BASE BANKがEPMを据えた背景

ここからは具体例の一つとしてBASE BANKがEPMを据えた理由とBASE BANKでのEPMの働きざまについてもう少し深掘ってみます。

BASE BANKはショップオーナーが売上を立てたあとの活動に関わる機能やプロダクトを受け持っているチームです。またBASE BANK社を設立した2018年はまだBASE社は目的別組織ではなかったため、BASE BANKはある意味BASE内での実験的な目的別組織(チーム)としてチームを成長させてきました。そういった事も踏まえ、メンバーが増え受け持つプロダクトも増える中で、上記のようなEPMとしての責務を持つ役割が必要となったのは必然とも言えました。

BASE BANK黎明期

BASE BANKの立ち上げ期はざっくりエンジニアとPMが存在しており、明確に役割を細分化しなくても開発を回していける規模でした。

メンバーが増え、よりチームらしく

エンジニアメンバーがjoinし、人数が少しづつ増え、受け持つ機能やプロダクトも増えててくると、ある程度意識して開発プロセスや採用、評価を回していく必要が出てきました。そこでTeam Managementを行うEM、TLといった役割が生まれ、PMと協力してTeam Management、People Managementを行うようになりました。このときはまだ、各機能の開発の運営はTLやPMが並行して受け持つ形になっていました。

ピザ2枚を分け合う以上の規模に

更にメンバーの採用が進み、関わるプロダクトもYELL BANK、BASEカード、振込申請などさらに増え、各プロダクトのグロースにも本格的に着手しなければならなくなりました。すると、それまで並行して複数プロダクトの開発プロセスを主導していたEMやPdMが本来の責務である組織全体の事業推進やTeam、People Managementに注力せざるを得なくなり、各プロダクトの開発プロセスの主導やPdM、各ステークホルダーとの橋渡し役として開発を主導するEPMという役割が生まれました。

ちなみに、BASE BANKのエンジニアは各々の強みを活かしつつ開発の全てのライフサイクルに関わるフルサイクルエンジニアとしての能動的な働きを求められます。

そのため、EPMは主導といってもマイクロマネジメントをするわけではなく、開発チームとしての目的やビジョンを掲げつつ各メンバーと協力して日々の運営や改善をしたり、メンバーがより能動的に動けるようなお膳立てをします。

それぞれのプロダクトごとのEPMとしての役割

では、EPMのプロダクトごとの具体例を紹介します。現時点では、主にBASE BANKとしてはBASEカードとYELL BANKがメインのプロダクトです。

決済のドメイン知識を持つ松雪(@applepine1125)がBASEカード、元々YELL BANKの開発をしていた永野(@glassmonekey)がそれぞれEPMとして開発を主導しており、それぞれのEPMの役割について紹介します。

BASEカードにおけるEPM

BASEカードのEPMとして、現在以下のような仕事を行っています。 - スプリントの運営 - QAの仕込み - 社内外のステークホルダーとのコミュニケーション - 関係各所へ決済の知識やBASEカードの仕様をインプット - 意思決定のための技術面または仕様面(特にカード決済の知識)の判断材料の提供、場合によっては自身で意思決定

https://cp.thebase.in/basecardcp.thebase.in

BASEカードはショップの出金に直接関わる機能のため、内部統制などを責務とするCorporate Solutions Engineer(CSE)やリスクマネジメントチームとの関わりが多く、日頃から密にコミュニケーションを取っています。また、機能実現のために外部企業が提供しているAPIを利用しており、仕様面の調整や、精算上の証跡を用意するためにBASEの経理との連携も密に行う必要があります。 BASEカードの場合、リアルカードの発行など直近の大まかな開発マイルストーンが割と明確であることから、実装したい各機能のスケジュール上での優先度をPdMと議論、調整し、開発をすすめる上で発生する技術的な阻害要因を排除することがEPMとして重要になります。