メルペイiOSエンジニアが「EMとしての1年半」で気づいた、チームに必要な3つの要素 #eof2019

2019年10月31日、「エンジニアリング組織をもっとオープンに」をビジョンに、エンジニアリングマネージャー（EM）やエンジニアを対象としたイベント「Engineering Organization Festival 2019（EOF2019）」が開催されました。

メルカリはイベントスポンサーを務めたほか、メルカリ・メルペイメンバーも登壇。特に後藤秀宣（メルカリBackend、EM）と石川直樹（メルペイiOS、EM）は、「メルカリ・メルペイのエンジニアリング組織の変化〜Engineering Managerの視点から〜」と題して、今まさに開発現場でのマネジメントでぶつかっている壁と、その乗り越え方、理想の体制を語りました。

前回に続き、今回はメルペイiOSチームのEM石川による登壇レポートを公開します。2018年2月にメルペイへ異動し、現在はメルペイiOSチームのEMを担当している石川。そんな彼がまず話し始めたのは、メルペイにおける開発体制、そしてEMの役割と権限でしたーー。

横軸と縦軸を用いた、メルペイのプロダクト開発体制

石川：僕からはまず、メルペイのプロダクト開発体制の全容についてご紹介します。メルペイでは今、プロダクトマネージャー（PM）とテックリード（TL）、EM体制で開発を進めています。そこへ、iOSやAndroid、Backendなどエンジニアの職種ごとにチームを縦軸にし、さらに各プロジェクトを横軸にしたような体制となっています。僕はiOSチームを担当しつつ、各プロジェクトのTLやソフトウェアエンジニアをアサインしています。

石川直樹（メルペイiOSチーム、エンジニアリングマネージャー）

ーメルペイのプロダクト体制に続いて、石川が紹介したのは、メルペイにおけるEMの役割についてでした。

石川：メルペイEMでは、以下のような役割があります。簡単に言うと、開発チームのスループット（時間当たりの処理能力）向上に責任を持って挑む役割です。また、メンバーのマネジメント、そして採用のためのPR活動も行っています。そして、もう1つ大事な役割が、各プロジェクトへのメンバーのアサイン。当然ですが、これはEM自身が事業を理解したうえで行うことが前提です。

ーメルペイでは、EMのタスクを大きく5つに分解しています。それが、PR、採用、育成、評価、リテンション。

石川：PRは、社外での登壇のほか、テックブログの執筆、OSSの促進などです。採用は、技術課題の整備などに貢献しています。育成では、入社したメンバーのオンボーディング、またはそれに必要なメンバーのアサイン。そして、評価ですね。これは四半期ごとにメンバーの評価とフィードバック、半年ごとの給与査定などしています。リテンションでは、メンバーに楽しく長く働いてもらうために、開発合宿や国内外のカンファレンスへ積極的に参加できる仕組みづくりも推進しているのです。

約1年半のメルペイEMで一貫した「ドメイン知識の属人化を避ける」

ーでは、約1年半に渡ってメルペイEMを担当した手応えはどうだったのでしょうか？EMとしての自分自身の変化を振り返るため、石川がスライドに映し出したのは「ヒト」「事業」「自身の役割」の3つの要素でした。

石川：1年半くらいEMをやってみて、思い出せないくらいいろいろありました。そのなかで、「ヒト」「事業」「自身の役割」の大きく3つの軸で僕自身の変化と振り返りをお話しします。

まず「ヒト」ですね。メルペイiOSチームはスタート時に比べて人数が4倍になりました。第一言語はまだ日本語ですが、徐々に多言語化が進んでいます。振り返りとしては、他チームの協力もあり、特に海外から来たエンジニアの採用率が上がりました。そのため、チームのMTGでは、週ごとに日本語・英語を切り替えながら進めています。

2つ目は「事業」。これは振り返りきれないところもありつつ…。メルペイは、1年ほどかけて開発し、サービスをリリースしています。その間に、仕様変更やプロジェクトの優先順位変更もあり、すごく大変でした。リリースは今年2月ですが、並行してリリース以降に実装する機能開発もしていたので、複雑性と不確実性が二重三重で増えていたように思います。リリースして数ヶ月後、さまざまな開発が落ち着きつつある今、プロダクト組織全体で技術負債の優先度を上げて取り組んでいるところです。

ー組織負債に関しては、疲弊したメンバーのケアなども組織一丸となって取り組んでいたと話す石川。同時に、メルカリ・メルペイの組織間のコミュニケーションコスト増大への対応もしていたと言います。

石川：メルペイのリリースは、とても大きなものでした。ABテストなどでは制御しきれない規模のリリースだったため、なるべくiOSチームだけでなく、Androidチームとも連携しながら慎重にプロジェクトマネジメントしていました。結果的には、リリースに向けたスケジュールの策定やバグ対応の優先度を決める場に関与できたのはよかったと感じています。改めて、組織状態の可視化やモニタリングの重要性を再認識できました。これによってeNPS（Employee Net Promoter Score）を定期的に計測し、チームに問題があれば個別にシューティングする体制ができたんじゃないかとも思っています。

最後は「自身の役割」について。僕がEMになった当初のメルペイiOSチームはまだ少人数だったので、僕も一緒にコードを書いていました。ただ、リリースが近づくにつれてコードを書かないようにしていきました。これは、EMである僕がメンバーとしてコードを書き続けることで、コミュニケーションやドメイン知識が固定されてしまい、チームとしてスケールしないという問題意識を持ち始めたからです。

石川：この気付きのおかげで、メルペイiOSチームのスループット最大化に向けて、ボトルネックとなりつつあった自分の問題を発見し、シューティングに専念できました。具体的に何をしたかと言うと、プロジェクトごとにiOSチームのTLをアサイン。彼ら・彼女らがなるべくドメイン知識を得つつ、コミュニケーションの窓口になってもらっていました。

目指したのは「自律して行動でき、スケール可能なチーム」

ーそして、石川は育休を取得し、一時的に開発現場を離れます。その間も、メンバーたちが各プロジェクトを横断しながら自律的に開発を進めている姿を見て、石川が具体化したのは「EMになった当初から考えていた理想のチーム像」でした。

石川：僕はEMになったころから、自律した行動ができ、さらにスケール可能なチームを目指したいと考えていました。そのために、EMやメンバーがボトルネックにならず、誰もが意思決定できるようにしたかった。さらに、能力関係なくチーム自体が並行して分散し、スケールアウトできるチームになれるといいなと思っています。

ーでは、石川が目指す「自律して行動でき、スケール可能なチーム」になるため、メンバー間で何を共有しておくべきなのでしょうか？

石川：まず3つ考えました。1つ目は、メルカリグループのバリューである「All for One」。最近話題になっていたラグビーワールドカップで言うと「ONE TEAM」ですね。2つ目は「HRT（Humility：謙虚、Respect：尊敬、Trust：信頼）」。これは開発チームをつくるためのノウハウが書かれた書籍『Team Geek』（オライリージャパン）からそのまま持ってきています。3つ目は「MO（Margin：余白・余裕、Opportunity：機会）」。これは、僕が考えた言葉です。土台としてHRTやMOがあり、そのうえにAll for Oneがあるイメージですね。

石川：最初に「All for One」について。そもそもメルペイに限らず、いろいろな企業で日々予期せぬ問題や環境変化が起こっています。メルカリグループでも、ずっと混沌とした状況が続いています。個々の見るべき方向性が違うと、チームだけでなく会社としてのゴールもズレていきます。そこで、EMとしてできることは何か？ずばり「環境づくり」です。

環境づくりは「チームとしての行動」「個々のマネジメント」の大きく2つに分けられると思っています。「チーム」に関しては、バリューなど重要視すべきことをくり返し伝える。そして、EMとして決定を下した背景をしっかり共有することが大事。責任のオーバーラップや役割の違いはあまり気にせず、チーム一丸となってボールを拾いにいきたいと思っています。

逆説的ですが、個々のマネジメントも大事だと考えています。会社やEMがメンバーに対して期待していることを個々にしっかり伝えて、両者で合意する。そのためのツールとして現状用いているのが、OKRです。それを日々の1on1で振り返り、期末での評価にサプライズがないよう、方向修正しながらマネジメントしています。期待値という文脈では、入社時や採用面接時でも会社やチームの現状をなるべくフラットに伝え、相手に判断を委ねるようにしています。

そして2つ目の「HRT」。チームは、人と人のコミュニケーションで成立しています。そこに、謙虚や尊敬、信頼みたいなものがないと、コミュニケーションコストが一気に極大化してしまうのです。それを避けるためにできることが「採用時のフィルタリング」。例えば採用時など、いくら優秀なエンジニアでも、カルチャーフィットや振る舞い、事業値への共感において「？」となったら、なるべく採用しないようにしています。

石川：また、入社後はEMとしてメンバーに推奨したい・尊重したい行動はできる限りパブリックな場でフィードバックします。同時に、推奨したくない行動をとったメンバーへのフィードバックも重要。その場合は1on1、緊急性が高いときはMTGを開いてでもフィードバックし、一緒に修正できるように話し合います。そうすることで、チームの好影響な行動はオープンな場でメンバーに知ってもらうことができ、悪影響な行動は閉じた場で目立たずに修正してもらえると思っています。

余白と余裕、機会がチームのパフォーマンスを上げる

ー最後に「MO」。これは石川が考えたものですが、この言葉が誕生した経緯とは？

石川：僕はEMとして仕事をするなかで、余白や余裕、機会みたいなものがチームにとって重要なんじゃないかと思うようになりました。自律的に創造性を発揮し、想像以上のパフォーマンスを出すための土台につながると考えています。

石川：まず「余白」です。特にMobileやFrontendでは、過度な抽象化や共通化は、オンボーディングコストを増大させる可能性があります。もう少し具体的にお話しすると、例えばMobileではOSのメジャーアップデートが1年ごとにあり、さらにUIロジックも多く、プラットフォームによる更新頻度も高いです。そのため、複雑化させすぎないことが重要だと考えています。メルペイiOSチームでもOSSをなるべく使わず、アーキテクチャに関してもできる限りシンプルにしています。

ー2つ目の「プロジェクトアサインの流動化」。これは先ほど石川が話していた「ドメイン知識を属人化させたくない」という考え方から誕生したものでした。

石川：ドメイン知識の属人化は、どうしても避けたい。そのため、メルペイiOSチームでは原則2人ペアでプロジェクトをアサインしています。そうすると、メンバーのプロジェクト間での流動性が高まります。特定のドメインを長期間続けていると、人によっては、どうしても「飽き」が発生してしまいますが、2人ペアにしたことで、いわゆるbus factorに対する予防もできました。

前提として、僕らが会社に在籍し、給与をもらいながらコードを書くのはすべて事業のためです。趣味や暇つぶしではない。一方で、事業が少しずつ軌道に乗ると新しいメンバーを採用できたり、時間的にも余裕になれたりするタイミングがやってきます。そのようなときに、EMやメンバーが溜めていた「緊急度は低いけれどすごく重要なタスクや問題」を優先的に扱える仕組みづくりを積極的に行うことが、EMの役割だと思っています。

正しいかどうかわからない、だから試していく

ー最後に、再び自分自身が目指している理想のチーム像を書いたスライドを映し出し、発表を締めくくる石川。

石川：これは僕の個人的見解で、会社の見解というわけではありません。正しいかどうかもわからないので、今はひたすら試していくしかないと思っています。もしみなさんのなかで目指しているチーム像があれば、ぜひ雑談しましょう。ありがとうございました。

石川直樹（Naoki Ishikawa）

ヤフー株式会社、株式会社イグニスを経て、2016年5月にiOSソフトウェアエンジニアとしてメルカリに入社。メルカリJP/USアプリの開発に携わった後、2018年1月にメルペイへ。現在はiOSチームのEMを務める。趣味はスティーブン・キングの小説をメルカリで購入し、積読すること。

石川による当日の登壇資料はこちら