仲間たちをエンパワーメントする取り組みはつづくよ #WomenCareerTalk
この記事は Engineering Manager vol.2 Advent Calendar 2019 の 4 日目の記事（代打）です。
はじめまして。メルペイでBackendのEngineering Manager（以下EM）をやっている@keigowです。
Merpay Advent Calendar 2019 の初日で行われた、メルペイ VPoE による2019年の振り返りを受けて、メルペイのEM目線でもエンジニア組織を振り返ってみようと思います。
はじめに
メルペイは2017年11月に設立されて、2018年5月にVPoEの@hidekが入社、7月からEMという職種ができ、2019年2月に初めてのリリースを経験しました。その間の開発組織の変遷と課題、どんな事をしてきたのかを出来るだけ具体的にまとめることで、これまでを振り返り、同じく開発組織をつくろうとしている方々に少しでも参考になるような情報が残せればと思っています。
※ 私はメルペイ立ち上げ当時、グループ会社のソウゾウでPlatformチームのマネージャーとして、Product Manager（以下PM）に近い役割をしており、正式にメルペイにジョインしたのは2018年4月なので、そこからの振り返りになります。
振り返り
VPoEの入社（2018年4月〜）
当時のメルカリグループはプロジェクトごとにクロスファンクショナルなチーム（1つのチームにPMやEngineerがいる）を作り、そのチームのマネージャーがプロジェクトを推進し、評価の責任も負うという組織になっていました。組織が小さいうちは意思決定が早くスピード感が生まれる状態でしたが、メルペイ組織の急拡大に伴い、以下のような問題が起こっていました。
- PMがエンジニアを含めたピープルマネジメントに忙殺され、プロダクトについて考える時間が取れない
- プロジェクト間のアサイン調整の難易度が高い
- エンジニアの専門性の評価、キャリア形成が難しい
- セキュリティ対策や技術的な基盤への投資が疎かになってしまう
この問題を解決するために新しく入社したVPoEのリードの下、PM/EM/TL（Tech Lead）を中心としたマトリックス構成の組織を7月から導入しました。詳しい内容は以下のTECH PLAYさんで行ったイベントの記事にまとまっています。
エンジニアリング組織の設計と実践──「メルペイ」の事例から学ぶ、組織とアーキテクトの関係性とは？｜TECH PLAY Magazine ［テックプレイマガジン］
合わせて当時の大きな課題だったのは、作ろうとしているものの規模が非常に大きく、特にBackendのエンジニアがまったく足りていないということでした。全社OKR（会社全体の目標と達成すべき成果）のKR0として採用目標が設定され、採用イベントやカジュアル面談、スカウトの推進、メルペイが立ち上がったばかりだったので、特にリファラル採用も大きな成果を上げました。
直接の採用施策ではありませんが、無料のGo勉強会Gopher道場を立ち上げたのもこの頃で、そもそも周りにGoのエンジニアがまだ多いわけではないという課題感から、メルペイ エキスパートチームに所属するGoエンジニア@tenntenn主導のGopher道場をはじめました。この試みは不定期ながら今も継続して行われていて、ありがたいことにGopher道場でGoを学びメルペイに入社していただけた方もいます。
メルペイがGopher道場をサポートする理由 #メルペイなう vol.16 #gopherdojo | mercan (メルカン)
PM/EM/TL体制の導入（2018年7月〜）
7月からPM/EM/TL体制が導入されましたが、当然これまでEMという人たちはいなかったので、初期のEMは元々開発を中心に行っていたメンバーがメインでした。プロジェクトのマネージャーしか居なかった状態から、エンジニアの職種ごと（Backend、iOS、Android、Frontend…）にEMを置き、エンジニアは元エンジニアのEMと1on1を行い評価されるという体制になりました。しかし、すぐにEMを増やせるわけでもなく、暫定のEMであったり、PMや他職種のEMとの兼務など、体制としてはギリギリの状態からのスタートでした。
当時新しくiOS/AndroidのEMとなった @jarinosuke / @mhidaka のインタビューがあります。
【組織拡大のウラ側】メルペイがスタートさせたEM新体制とは | mercan (メルカン)
体制が導入されたことで、週次のEM MTGを中心として、各PMやProduct Management Office（PMO室）と協力して、これまで手が着けられていなかった、プロダクト開発や組織の問題にも着手を始めました。
- 仕様のドキュメントを統一してフォーマット化
- EM兼務の解消、1人当りのメンバー数を減らすためのEMの採用・育成
- エンジニア組織の健全性を計測するための組織スコアリング（月1回のアンケート）の導入
- 交流を促すためのIn house tech meetup、開発合宿の企画
- マイクロサービスの運用フローの整備
当時の一番大きな課題は、組織の急拡大に情報共有フローの整備が追いつかず、各チームごとに設定されたマイルストーンの依存関係や、どのマイクロサービスはいつまでにリリースが必要なのか、といった情報がまとまっていないことでした。この問題に対してはPMO室とも協力してなんども可視化する試みが行われましたが、それっぽいガントチャートは作れるものの、完璧に依存関係を把握する難易度が高かったり、日々かなりのスピード感で状況が変化するため、実運用に耐えうるものを作るのは難しい状況でした。
この問題を解決するため、各Tech Leadに所属チームのマイルストーンを洗い出してもらい、1つのドキュメントに時系列順にまとめ、必要と思われる各マイクロサービスの機能（エンドポイント）やクライアントの機能を記入し、その読み合わせを行うDeveloper MTGを週次で開催することにしました。MTGにはEM/TL/PMOが参加し、泥臭く現在の状況を確認・共有することで認識の齟齬が防げるようになりました。このMTGはやや役割を変えて、現在も行われており、VPoEやCTOも参加して現場からエンジニアリングの問題解決を行うための良い機会になっています。
リリースに向けた開発（2018年10月〜）
BackendのEMが2名増えて4名体制となり、Backend EMでも個別に週次のMTGを開始しました。2月のリリースを控え、各プロジェクトの進捗や状況に合わせたアサイン調整を行ったり、本格的な運用開始に備えてoncall体制の整備や、インシデントの対応フローを決めていきました。
この頃にはリリース日としてある程度現実的なマイルストーンとスケジュールが設定できた一方で、様々な状況の変化と不確実性により、不正検知のシステム、QA検証や負荷試験などが後手後手にまわってしまい、年末から年始にかけては特にかなり負荷が高まってしまったという反省があります。
VPoEの振り返りでも触れられているので、細かくは割愛しますが、メルカリグループとして最大半年間の大規模なヘルプ異動の実施が決まったのもこの時期で、メルペイ/メルカリのEMで異動の詳細についてディスカッションを行い体制を検討しました。結果としてはメルペイのGolden Weekキャンペーンの成功にはつながったものの、組織としては課題が残る結果となりました。
メルペイ1stリリース（2019年1月〜）
様々な状況の変化と色々なアクシデントを乗り越えて2月13日にiOS版iD決済のリリースを迎えました。2月に開催したメルペイカンファレンスでの発表内容も含め、本当に最後までギリギリの調整が続いたため、職種を超えて関わったすべての方のAll for Oneな協力がなければ、スケジュール通りのリリースは難しかったと思います。
7月から始めたPM/EM/TL体制の振り返りも行い、役割定義の部分での認識のずれなどが課題となりました。特に難しかったのがWhen（Project Management）の責務を誰が持つべきかという観点で、KPTによる振り返りのProblemでもWhenに関するものが多くを占めました。これは各チームでの振り返り、PM/EMそれぞれでの振り返りを通して、最終的にはRACIチャートという形でそれぞれの責務をまとめました。全体的にはプロジェクト全体のマネジメントはProject Owner、開発フェーズにおいてはTech Leadという整理になりましたが、チームによってProject Managementが得意なメンバーが誰かというところにも依存していて、最適な体制は現在も模索しているところです。何れにしてもProject Managementについてはチームとしての責務として捉え、PM/EM/TLが協力してやっていくことが重要だと考えています。
障害振り返りのプロセスも整備しました。メルペイではお客さまに影響があったり、定めたSLOに違反する障害があった場合、インシデントレポートを作成し、再発防止策がきちんと定義されているかを振り返ることにしています。インシデントレポートは反省文ではなく、資産であるという考え方は初期のメルカリから続く文化で、私の好きな文化の1つです。
大型キャンペーンと組織体制の変更（2019年4月〜）
最初のリリースを終えて、Golden Weekの大型キャンペーンを控えるなか、プロダクトの開発体制変更も合わせて変えました。それまでは開発するシステムやお客さまの体験を軸にチームを分けていましたが、リリースを機にプロダクトとして追うべきKPI、そのために協同する職種の人たちを軸にチームを構成するように変更しました。具体的には、グロースに責任を持ちマーケティングと協力するチーム、加盟店さま向けにプロダクトを提供し、セールスと協力するチームなどです。体制の変更自体は大きなものでしたが、役割が明確になりこれまでよりも連携を進めやすくなったと感じます。
エンジニアの採用も引き続き進み、組織が拡大していく中で、Tech Companyを目指していく上での目線合わせを目的として、Engineering All hands（メルペイのエンジニアが全員参加するMTG）を始めました。CTO、VPoEからのメッセージやOKR、PM/EM/TLの役割の再定義など組織としてのメッセージだけでなく、新入社員の自己紹介、技術共有のプレゼンなど、エンジニア全員で作り上げるという形を大切にしています。個人的には愛されるVPoEの司会がとても気に入っています。
人が増えてきてやれることも増えた結果、以下のような施策もこの時期に進めています。
- 組織スコアリングにeNPSの導入と合わせて項目の改善
- エンジニアのキャリアラダーの検討開始
- Tech Blog Openness Monthの実施
- 第2回開発合宿の実施
個人的に思い入れが強いのは、公開できない人事情報をのぞき、SlackのEM用のチャンネルのオープン化、EM MTGの議事録の公開をしたことです。これはメルカリグループとして大切にしている、Trust and Opennessの文化にもつながります。組織が大きくなってくると各自の認識のズレや思い込みが増幅して、穿った見方をしてしまったり、その結果不信感を強めてしまうということが往々にして起きてしまうので、できるだけ情報をオープンにしていくということを日々心がけています。全社OKRの決定を行う会議についても、メンバーの提案により公開されるようになったということもありました。
技術負債の返済と採用（2019年7月〜）
VPoEの負荷が増えてきたことを受けて、TPgM（Technical Program Manager）という役割を新しく導入しました。TPgMは事業部内のエンジニアリング責任者として、事業計画やロードマップ、人員計画の策定をBusinessやProductのOwnerと協力してつくっていく役割で、より事業部ごとに独立した意思決定を進めやすくするために設置されました。このチャレンジについてはメルペイEMの@osamingoが登壇したイベントでも触れられています。
メルカリ・メルペイCTOとエンジニアが明かす「今だからこそ面白い」課題と挑戦 ＃BoldChallenge | mercan (メルカン)
この期間は改めて採用が強く課題となりました。エンジニア組織が大きくなる以上のスピードで、メルペイとしてやりたいことが増えていく中で、このままだと多くのやりたいことを諦めるしかなくなってしまうという状況で、全社OKRにも再び採用目標を設定し、以下のような施策に取り組みました。
- 全社での採用会食やリファラルの推進
- 地道なスカウトの送信
- ミートアップや採用イベントの継続的な実施
- エージェントさまとの密なコミュニケーション
エンジニアの自主的な協力もあり200人を超える規模のミートアップを開催するなど、大変ではありましたが、再び採用の勢いを取り戻すことができました。凄い特別なものはないですが、地道にやるべきことを淡々とやっていくという形で、HRメンバーも含めてAll for Oneに取り組めた成果だと思います。
プロダクトとしては前期までのリリースラッシュで積み重ねた技術負債の返済を行うために、各チームで負債の洗い出しを行い、これも全社OKRに乗せて進捗をトラッキングするようにしました。
成長とクオリティの追求（2019年10月〜）
直近はこれまで整えきれていなかった仕組みを改めてブラッシュアップしています。その1つがオンボーディングで、これまでまとめ切れていなかったドキュメントや、受け入れフローの仕組み化などHRと協力して整備を進めています。またグローバル化の進展に合わせて、やさしい日本語、やさしい英語を使うようにしたり、チーム内でお互いのコミュニケーションのタイプを学ぶことで、コミュニケーションを円滑にするための工夫をしています。
またOKRに成長のためのクオリティの向上を設定し、中長期的にインシデントを減らしていくために、インシデントの可視化と分析、振り返りと再発防止策の徹底を改めて掲げています。
おわりに
こうして振り返ってみると、課題に対して手を打ててきた部分もありますが、当然のように様々な失敗もあり、なにか1つの課題を解決してはまた新たな課題に立ち向かうということの繰り返しに感じます。勿論これはEMだけで達成してきた話ではなく、様々な方の協力があって今のメルペイがあります。
普段はなかなかこういった話をする機会がありませんが、EMとして組織課題に向かい続けるというやりがいが少しでも伝わって、同じくエンジニア組織に向かい合っている方にとって少しでも参考になる内容があれば幸いです。
iOS EMの@jarinosukeがEngineering Organization Festival（EOF）で登壇した記事もぜひ御覧ください。
メルペイでは一緒に組織を改善していくEMを募集しています！
