メルペイEMが語る、開発組織の立ち上げから現在までの軌跡

メルペイのEM・TPMが語る組織の今

主森 理氏：今回は、「レッドオーシャンに突っ込むぞ、つかまれ！」というタイトルをつけたんですが、内容としては組織の話をします。

話す内容としては、4つの章に分かれています。

最初に僕が誰かという話、メルペイの組織の体制が構築されるまでの話、僕はエンジニアリングマネージャーをやらせてもらっているのですが実際どういうことをやっているかという話、最後に Bold Challengeという趣旨の話なのでそれについて喋ろうと思います。

僕は、主森理といいます。

@osamingoというアカウントでTwitterとかGitHubをやっています。僕はメルペイに所属をしていて、先ほども申し上げたんですけれども、エンジニアリングマネージャーと、あとはテクニカルプログラムマネージャーを兼務しています。

簡単にメルカリに入社してからの経歴なんですが、ソウゾウという子会社に入社しまして、「メルカリアッテ」というクラシファイドのサービスの運営をやっていました。そのあと「メルカリ カウル」というサービスの立ち上げ・リリース・運用までやって、去年の2月、メルペイに異動し、今年の2月に「メルペイ」をリリースしました。

開発体制が構築されるまで

2つめの「いまの開発体制が構築されるまで」という話なんですけど、「そもそも最初のエンジニアはどうやって集まったんですか？」という話を最初にしようと思います。

2017年11月に株式会社メルペイが設立されました。そのあと、1ヶ月経たず12月頭の全社ミーティングで、メルペイのの社長である青柳と先ほど登壇していた曾川による、メルペイで何を具体的にやっていきたいかというプレゼンが開催されました。

そのプレゼンのあと、社内公募が行われました。実際に異動したいと希望している人に対して、本気度や自分がどういったことをやりたいのかを記述する形式でした。応募したら異動できるのではなく、上の内容をもとに選抜させると。

僕の場合は、これを書いて送って、12月の下旬にある会社の忘年会で当時のソウゾウの社長から「どれぐらい本気なんだ？」と軽く詰めらました（笑）。そこでヒアリングをされて、酔っ払ったままなんですけど、「僕はこういうことをやりたいと思ってます」というプレゼンをしていました。

年明けに異動者が発表され、約1ヶ月間ぐらいで引き継ぎを行い、異動となりました。だいたい会社が設立されてから2ヶ月ぐらいで、一気に50人ぐらいが異動するという地殻変動が起きました。

メルペイの初期はソウゾウからの異動者とメルカリからの異動者がいたんですが、やはり母集団が違うので、メルカリのスタイルを継承することにしました。

それぞれのグループにプロダクトオーナーがいて、プロダクトマネージャーがいて。グループによって特性が違うんですが、実際にメルカリのアプリの画面にはデザイナーさんがいたりとか、もちろんクライアントのエンジニア、あとはフロントエンド、バックエンド。ただ、プラットフォームなど基盤的な役割のチームになると完全に後ろのマイクロサービスを作るほうになるので、デザイナーさんが居ないといった違いはありました。

VPoEが来て変わったこと

最初に着手していたことなんですが、決済プラットフォームや認証プラットフォームは、先ほど中島が話したとおり、マイクロサービスの流れもあってメルペイ設立前から着手されていたので、その流れは継続してやっています。

それとは別にメルペイの初期要件としてオンライン決済の設計があったんですが、僕はここを担当していました。あとは各銀行さんとの接続の準備だったり、当時はブロックチェーン周りをやっていました。

そして「うぉー！」と作っていくんですが、どんどんいろいろな問題が発生して、いろんなイシューがボトルネックになっていって「ぜんぜん速度出ねぇじゃん」みたいな話が出てきました。

そのなかでターニングポイントがありました。2018年の5月、今のメルペイのVPoEをやっている木村が入社しました。

木村は入社して何をやったかというと、先ほど登壇したCTOの曾川をビジネスとテクノロジーに集中させました。それまではエンジニアリングのマネジメントなど、いろいろな責務を担っていたんですが、ビジネスとテクノロジーに集中してもらいました。

次にプロダクトオーナーからエンジニアリングのマネジメントを完全に剥がして、プロダクトの設計や仕様を記述する時間を捻出しました。

これに伴い、エンジニアのマネジメントを剥がしたのでエンジニアのレポートラインを作って組織構造を再設計しました。それに伴い、PM-TL-EM体制を構築しました。

この体制については、もともとGoogle社が発案しているやり方で、僕らのオリジナルというわけではありません。ただ、それをそのまま組織に適用するとうまくいかないことが大半なので、これをどうやって僕らなりにやるかです。

これは体制のイメージ図です。先ほどのグループは縦にプロダクト軸で並んでいて、それぞれにテックリード（TL）が1人います。エンジニアのマネジメントは切り出したので、職能軸でグループがマトリクス状に組まれているものになります。

PM・TL・EMの役割を定義

また、プロダクトマネージャー (PM) の役割と何を担っていくのか、ちゃんと定義する必要がありました。メルペイ社の場合では、プロダクトの方針を定めて、成功に責任を負うというところがものすごく強いです。あとはプロジェクト全体の進行に責任を負ったりUXの部分ですね。設計したり、その品質は何を要求されているのかを仕様に落としたりしています。

思考軸の部分なんですけど、PMの場合、Whyがすごく重要です。「なぜそれを作る必要があるのか？」。

運用だと「数字を上げたい」という悩みがあります。「なんで上がらないのか？」みたいなところの仮説をちゃんと作って、何がファクトなのかをしっかり見積もる。そのファクトを基に、What（Whyを解決するために何をつくるのか）がものすごく重要です。

Whenのところは「いつ出すか。どのタイミングで出すか。いつまでに出さないけないのか」という話になります。

テックリードは、エンジニアから選抜される役割です。PMの良き相談相手になりプロダクトを成功に導く。見積もりなど、プロジェクトの技術的進行に責任を負う。あとは、設計や実装ををやったり、技術の意思決定をやったりします。

思考軸は、やはり「何を作るのか」。先ほどの「何をつくるのか」とエンジニアの「何を作るのか」は微妙に違うと思います。例えば「どういうマイクロサービスに切り分けるのか」「どのマイクロサービスを作るか」「どういうふうな機能を？」みたいなところですね。

Howの部分は「どうやってつくるのか」という部分です。最終的にそれをいつまでに完成させてリリースするのかがWhenの責務になります。

最後に、エンジニアリングマネージャーです。エンジニアリングマネージャーはプロダクト軸のグループに所属をして居らず、完全に組織に対してコミットする役割になっています。

役割の1つは、やはり強いエンジニアチームを作り育てるというところです。あとは、イノベーションを起こすための環境構築や、クリエイティブな発想を生む文化の醸成。組織に対してコミットメントしていきましょうという話です。

思考軸もあまりかぶっていません。最初はWho（誰が働くのか）、Where（誰がどこのチームに所属して働くのか）、　そして How (その人がパフォーマンスを上げていくようにどういうふうにすればいいのか)、というところが思考軸になります。

運用において発生した不満・問題

これは最初からうまくいくわけもなくて、体制運用にあたり不満や問題がすごく発生しました。

1つめは、よくある問題として期日は決まっているのに仕様が決まらない問題があると思います。それに対しては4つマイルストーンを設定して、ウォーターフォール的な思考に意識を全部振らせました。必ず前工程を踏まないと次の工程には進めないようにしました。

僕らが定義しているのは、Requirements AcceptanceとSpec Freeze、Code Complete、Release Candidateの4つにしています。

2つめは、マイクロサービス間の連携調整に忙殺される問題です。

メルペイはマイクロサービスで立ち上げたんですけど、いっぱいのサービスが一気に立ち上がりすぎて、「あのマイクロサービスの機能がないとできない」みたいな依存関係がすごく多発していました。

それを解決するために、組織として「Developer MTG」という全体進捗を中心においた会議体を設置したり、依存度の大きさによる開発のポリシーを僕らが作って設定したりしました。

このポリシーは、クオリティとアジリティの両立や、「こういうものを作って欲しい」という要件元と、要件先の責任範囲の整理がされているものです。

また、工数がバッティングしてエンジニアの時間が取れない場合のエスカレーションフローの整備。「なんかよくわからないけど、どうすればいいのかわからない」みたいな問題を解決するために、こういうことをしています。

3つめは、プロジェクトマネジメントのボールが落ちがち問題。

メルペイでの PM はプロダクトマネージャーなので、プロジェクトマネージャーではないんですね。PM-TL体制だとプロジェクトマネージの責任をPMとTLが持ち合っている部分があるので、責任者が明確じゃない場合がありました。そのためにプロジェクトオーナー、社内だと「PJO (Project Owner)」と呼んでいるんですが、役割を明確化しました。

フェーズによってリードする人が変わることがあります。先ほど4つのマイルストーンがあったと思いますが、Spec FreezeまではだいたいPMの人がやったりします。Code Complete以降はエンジニア、テックリードが負ったりすることがあります。

こういう体制を敷いたらすぐできるかというとそうではなく、いろいろ解決して今があるというのと、今も解決中ですよという話です。

メルペイのEMの仕事

3つめの章ですが、「正直、EMってなにやってるの？」。僕自身、EMをやっているのですが、まずメルペイでEMになった人の経路はこれだけあります。

もともとプロダクトオーナーをやっていたり、EMとして採用されていたり、もともとメルカリのEMをやっていた人がメルペイに来たりとか。僕はテックリードを先にやってからEMになりましたが、色んな人がいます。

実際にふだんはどういうことをやっているかというと、まずは自分のチームですね。僕は「Merpay Backend 3」というグループのマネジメントをしているんですが、1on1をしたり、OKR（目標設定）したり、評価や雑談・相談したり。

あとは、エンジニアリング組織全体のこともやっています。活性化施策として例えば開発合宿しましょうとか、そういう話ですね。あとはインターンや新卒採用の担当窓口をやったり、今日のようなイベントの登壇もしています。

僕はバックエンドエンジニアのエンジニアリングマネージャーなので、バックエンドエンジニアに特化したこともやっています。チーム構成やエンジニアの適材適所をどうするか。先ほどのWho・Whenの部分ですね。あとはチームを横断した人員計画や未来の計画。あとは採用に用いる技術課題の開発支援や運用を主にやっています。

EMになるとプログラミングができなくなるのか？

EMをやっていてよく聞かれるのが、「プログラミングできなくなるんですよね？」とか「なんでマネジメントをしようと思ったんですか？」とか、あとは「プロダクトから離れて組織貢献って、そもそも楽しいんですか？」など、ネガティブな疑問多かったりします。

1つずつ答えていこうと思うのですが、そもそもプログラミングができる・できない問題はEMのスタンスによるのでケースバイケースになる、という曖昧な答えになります。テックリードを兼務している場合は、EMをやっていてもコードを書いている場合が多いです。今もメルペイのEMでコードを書きながらやっている人も普通にいます。

ただ、自分の場合は書いていません。理由としては、マネジメントしているメンバー数がそもそも多いので、1on1などに時間を取られます。あとはテクニカルプログラムマネージャーを兼務しているためミーティング数が多く、まとまった時間が取りにくくなっています。この業務内容はあとで説明します。

自分自身が業務のブロッカーになる可能性が高くて、プロダクトのスピードが落ちていくので、それは嫌だと思い、プログラミングはやっていません。

ただ、コードを書く勘を保ち続けるために、『Software Design』に寄稿したり、表現する方法がちょっと変わりました。あとはプライベートでコードを書く時間が増したんですが、毎日書いているわけじゃないので、コーディングスピードが3分の1ぐらいに落ちるという結構凹む事態も感じつつやっています。

マネジメントに興味を持ったきっかけと、EMの醍醐味

2つ目、そもそもマネジメントをやろうと思ったきっかけです。もともと僕はマネジメントには興味がありました。人に興味があって、若手のエンジニア育成を前職や、現職でもやっているのですが、けっこう得意分野だなと思ってやっています。ただ、やっぱりコードを書くのは好きだしプロダクトを作るのも好きなので、なかなか「うーん……」というよくある問題です。

ただ、メルペイに異動してきて、「このメルペイというプロダクトを成功させることに対して、今までと同じような行動をしていていいのか？」という漠然とした不安のなかやっていたというのが、心理的な背景としてあります。

2018年の5月から「 Engineering Manager Philosophy Talk」という社内勉強会が開催されて、全部で4回やりました。このあとパネルディスカッションで登壇していただく広木さんの回もあったりとかします。

これにものすごく感銘を受け、これを聞いてプロダクトのためにやれることってまだまだあるな、ってすごく感じたんですね。

実際にオファーしてもらえる機会があって「やります」ということでやってみて。実際はマネジメントという新しい領域にジョブチェンジしたような感じで、チャレンジの楽しさがあります。

あとは、1人だけでは出せない成果をチームで達成するというところに、すごく影響を与えることができる。あとは、経営層と近くなって扱える情報量が多くなったりします。

チームで達成するということもそうですが、良い意味でも悪い意味でも影響範囲が広がるというところで、かなりアグレッシブでスリリングな環境ですね。

結果からの振り返りになりますが、いわゆる3つのバリューのうちの1つの「All for One」という精神が行動として表れたのかなとすごく感じています。

テクニカルプログラムマネージャー（TPM）が誕生した理由

最後に「現在のChallengeについて」。

先ほども話しましたが、テクニカルプログラムマネージャー、社内だとTpGMと呼んでいるんですが、一般的にはTPMと呼ぶらしいのでここではTPMとして呼称します。TPMは、健全な事業推進が行えるように技術面からリードするのがミッションです。

メルペイでは職位ではなくて役割、「マネージャーも役割、TPMも役割」という立ち位置でやっています。

主にやっているのは、僕らはDivisionというふうに呼んでいるんですが、いわゆる事業部単位での事業計画の策定。あとは、プロダクトのロードマップの策定、プロジェクトの進捗管理。あとは人員計画の策定を役割として持っています。

そもそもなぜTPMという聞き慣れない役割が生まれたのか。いろいろな問題が生じている中で、事業部ごとにビジネスとプロダクトのオーナーがすごく明確化されていますが、その一方でエンジニアリングのオーナーが明確化されていないところがありました。これでは、すべての人員計画やロードマップがVPoEに集中してぜんぜんスケールしないよね、という問題がありました。

また別の問題としては、エンジニアリングのフィジビリティが欠落したまま事業計画を設定されると、実現性の低い計画になってしまう恐れがありました。結果的に、開発の期日設定がロジカルに行われていないという問題がありました。それを解決するためにこういう役割を作りましょうという話がありました。

この役割自体は2019年7月に設定されたばかりで、TPMの役割自体はあんまり定まっていないので、もうやれることは全部やる。すべての職能に対するリスペクトと壁を作らないコミュニケーションで、Give & Giveの精神でやっていく。

僕が今いる事業部には、営業組織やビジネスデベロップメント、あとはPRだったり、GR（Government Relations）、いわゆる省庁とやる人たちがいたり、職能が多岐にわたる事業部です。なので、ここはすごく考えながらやっています。

このような役割を設定し会社として認識してもらえるとすごく動きやすくなるので、キーマンからどんどん率先して巻き込んでいくということを意識しています。

あと、いろんな問題があってこの役割が生まれているので、「本当にこの役割は今後も必要なのか？」とか「今、必要なのか？」とか「この事業部では必要なのか？」というのも常にネガティブチェックしながらやっています。

何より初めての取り組みなので、一番大切なのはまずは事例を作って、それをどうやって再現して、繰り返し成功に対して寄与していくのかも考えながらやっています。

実際にTPMができてから2ヶ月半なので、まだまだやれることが盛りだくさんであるということを肌感ですごく感じています。

最初に「レッドオーシャンだ」という話をしましたが、これを泳ぎ切る、泳いでいくために、いろいろな組織をつくるために、EMであったりTPMという役割を作ってもらっていろいろやったりというところを、試行錯誤している最中です。興味ある人は、いろいろ話せればと思います。

僕の発表は以上になります。ありがとうございました。

（会場拍手）