CLOSE

赤裸々に語る 変化と挑戦(全3記事)

メルカリ・メルペイCTOが語る、エンジニアリングマネージャーに求めるもの Part.3

2019年9月24日、株式会社メルカリにて、エンジニア向けイベント「Mercari Bold Challenge ~CTOとエンジニアが赤裸々に語る 変化と挑戦~」が開催されました。社員数は1,800人を超え、40ヵ国以上の国から多様な人材が集まり急成長を続けるメルカリ。一方で、急成長に伴って新たな課題も生まれています。そこで今回は「Bold Challenge(大胆な挑戦)」というテーマで、メルカリのエンジニア組織の変化と挑戦について、そのリアルを語ります。「メルカリ・メルペイ CTO公開対談『赤裸々に語る 変化と挑戦』」に登場したのは、株式会社メルカリ CTO・名村卓氏、株式会社メルペイ CTO・曾川景介氏、株式会社レクター広木大地氏。

1on1の面談では何を重視しているか

広木大地(以下、広木):それでは、会場の質問です。評価の話は今していただいたんですが、「1on1って何を話しますか」という質問が来ていますが、EMのほうで1on1の話ってしていましたっけ。

曾川景介氏(以下、曾川):EMの人がたまにエンジニアとしたりしますが、私はそれなりにしています。ときに私がやりたいことや好きなことを話しているときもありますね、事実として(笑)。

(会場笑)

でも、結局その人が解決できない問題があるときに、それを一緒に解決するための時間だと思うので。そういうイシューなど、もちろんそれは会社のイシューでもいいし、個人として「こういうことに悩んでますよ」というのがあるんだったらそれを目標にします。とはいえ毎回毎回、そんなにきれいに悩みがあるわけでもないので「こういうもの作りたいよね」といった話をしているときもあります(笑)。

広木:なるほど。名村さんは、1on1とかけっこうするんですか。

名村卓氏(以下、名村):エンジニアマネージャーほどはしていないと思いますが、ダイレクトレポートの人とはやっています。どちらかというと組織の話が多くて、基本的に上司の役割はブロッカーを取り除くことだと思っているので「ブロッカーって何かありますか」というのが多いとは思いますね。ただ僕のダイレクトだと、勝手にブロッカーを取り除いてくれる人たちなので。

広木:(笑)。

名村:最近は、世間話や「次にメルカリをどういう組織にしていこうか」といった話が多いと思います。

広木:なるほど。もう1個、いただいた質問をやっておきますか。「エンジニアリングマネージャーの役割は、マネージャーとは具体的に何か」。エンジニアリングと付いているからには多少はスコープ違うところがあるんだと思いますが、具体的に何か違いはありますか?

名村:僕の理解だと、エンジニアの組織をマネージしているものだと思います。エンジニアのメンバーを、マネージャーとしてピープルマネージしているという人です。メルカリの場合、エンジニアリングマネージャーはほぼ全員、元エンジニアだと思います。エンジニアのことを理解できないといけない。

広木:マネジメントスキルを、エンジニアの人がエンジニアリングマネージャーになったときに、学ばなければならないじゃないですか。下手したら英語より大変だと思うんですけど、何かそういう支援はしているんですか? ……していきたいと思っていますか?

名村:していきたい。

広木:いきたい(笑)。

(会場笑)

EMがPMと話すことで解決しなければいけないこともある

曾川:最初の最初は研修などをやっていたんですよね。でも、それよりは、eNPSを取っていたことをきちんとマネージャーが振り返ったり、自分のチームで「こういうことが起こっているよね」と考えたりしています。

ただそれって、おそらく誰かが説明していたと思うんですが、メルペイは横軸EMで縦軸PMなので、EMだけで解決できないこともたくさんあると思うんですよね。だからそういうときは、EMがPMと話すことによって解決しなきゃいけないこともあります。

エンジニアリングマネージャーの役割は要するに、組織の結節点として落ちてしまうボールや、「誰に聞いたらこれ解決するんだろう」をちゃんと解決することも含めてやらないとダメなので。ロールとしては確かにおっしゃるとおり、マネジメントスキルというのはあります。

エンジニアリングマネージャーは「エンジニアじゃないと解決できない」「エンジニアじゃないと理解できない」部分があるので、そこはエンジニアリングマネージャーが積極的に拾うんですが、それ以外のところは先ほど言われたとおり、普通にマネージャーとしての役割を求められます。

最初やっていた研修や、最近は研修よりは、OJTじゃないですが「きちんとeNPSを見ながら振り返りをしましょうね」と言われていることです。

広木:チームや組織のオブザーバビリティじゃないですが、「サービスで言ったらオブザーバビリティ」といったことだと思っています。そういうものの基準は、ある程度考えていこうとしているのか。もうすでにそういうサーベイを、より強化していくのか。

曾川:まさに「さっきのをなんで取ってんだろう」というのは、「あれをゼロにしなきゃいけないから」。だから僕らは取り始めていて。それを出したのも、今は正直僕らの採点をされるというか、通知表をもらったらアレなんですよね。

だから、それをきちんとトップが責任を持って解決していかなければならないし、マネージャーも、一人ひとりのエンジニアリングマネージャーも責任持たなきゃいけないし、エンジニアリングマネージャーだけではきっと解決できなくて。おそらくプロダクトラインから起こっている問題もいくらでもあるので、両方やらなければいけない。

ただ、それを解決しても事業成功しなかったら何の意味もないので、結局そのバランスというか組織のスコアリングをにらみながら、きちんと事業のマイルストーンを達成していくのがマネージャーに求められているものです。大変ですよね。

だから、マネージャーやテックリードはけっこう大変です。逆にそのマネージャーとテックリードのスコアが低かったりすると、そのチームが低くなっていくんですよ。だから「そこの人たちのスコアを上げられるか」というのが結局、経営陣やマネージャーに求められていること。MOM(Manager of Manager)とかディレクターと言われている人たちに求められていることだと思います。

広木:じゃあ「この通知表を良くしていくから、大変な思いをしたい人は来てくれ」といった、そんな感じなんですかね。

曾川:そうですね、それが一緒にやりたいとか(笑)。あと別に「悪いから即ダメ」というよりは、原因がきっとあるわけじゃないですか。エンジニアリングは「課題解決すること」だと僕は思っているので、結局それを一緒にやるんだと思います。きちんと向き合って、人であろうとプロダクト・システムであろうと、どっかに問題があるからそういう結果が出るわけなので、その数値と科学しながらやっていけばいいと思います。

広木:ではそろそろ時間も来たので、最後にそれぞれ一言ずつ。せっかくこういう会で「赤裸々に語った」「決意表明した」ので、何かコミットメントを1つ喋ってください(笑)。

「1on1などの最後はコミットメントを口にしてもらったほうがいい」というのもあると思いますし、せっかくこういう公開の場なので(笑)。1~2つコミットメントしてフィニッシュもいいのかなと思います。……あと10分も考える時間があるそうで(笑)。

名村:まだ質問いっぱいあるんじゃない?

広木:設問、まだいっぱいある?

曾川:もうちょっと答えてもいいですよ。

マイクロサービスの切り出し方・作り方は?

広木:じゃあもう少し答えてみましょうか。「マイクロサービスについて、サービスの切り出し方・作り方が難しそうな印象ですが、コツやノウハウはあるんでしょうか」。

(会場笑)

名村:ないですね(笑)。

曾川:これは難しいね、みんな爆笑していますね(笑)。「ない」って言っている。

名村:もう思うように切ってくれたらいいんじゃないですかね……。

(会場笑)

曾川:でも、CTOには結果責任はあるので(笑)。だから、うまくいかなかったことをちゃんと振り返ったりします。あと、メルペイもいろいろやっていくと、うまくいっているマイクロサービスとそうじゃないマイクロサービスに分かれてくるわけです。それを見ながら、うまくいっているところにはやっぱり良いテックリードやプロダクトマネージャーがいたりするんですよね。

属人的になってしまっていますが、その人がやっていることなどを横のチームがきちんとできたりそのノウハウが展開されないと、良いようにはならないので。ただ切り方の問題って、そもそも切ったときに始まっているんです。チームどうのじゃなくて、そもそも責務をちゃんと切り分けられなかったところに敗因があって。もう始めたときに負けている話ですよね。

広木:プロセスとして、例えばイベントストーミングのような何らかの要求定義手法を1個かませよう、といったことはトライしていますか。

曾川:最初、僕らがメルペイを作っていた頃はちゃんとやれていなかったので、そういうゴミ溜めみたいなマイクロサービスもあります。

(会場笑)

広木:「ゴミ溜めみたいなマイクロサービスもある」(笑)。

曾川:それはそれでしょうがない(笑)。だけど、今はきちんとデザインブックを作って、そのマイクロサービスの責務をきちんとやっています。そのマイクロサービスが必要になるほかのマイクロサービスなどを、広木さんがおっしゃるように、イベントやドメインを定義しているのでもう少しマシになってきています。

それはやってみて、やっぱりそういう問題が起こったからプロセスを改善する、といったことが行われているなと私は感じています。

広木:名村さんはこのあたりはどうですか。

名村:マイクロサービスの経験が豊富だとなんとなく勘どころがありますが、ないとおそらくわからないのでやってみるしかないかなという気はしますけどね。

広木:マイクロサービスにも何段階か抽象レイヤーというか、レイヤリングアーキテクチャのようなことをしているんですか?

名村:おそらく根本的にはコントローラーとして、ドメイン的なデータを扱うレイヤーと、ビジネスロジックやコントローラー的なロジックを扱うレイヤーは、自然と発生すると思いますね。

広木:そういうのはポリシングしているわけじゃなくて、自然とそんな感じかなという。

名村:そうですね。とくに「絶対そうしろ」とはなりませんが結局、データの扱いは自然とそういうふうにせざるを得ない。

メルカリではデザインブックが公開されている

広木:(スライドを指して)良い質問が来ましたよ。「デザインブックって、サンプルでもいいからどこかで見れますか?」って(笑)。

曾川:なんかテンプレートでも公開したらいいんじゃないですか。

名村:deeeetとかに聞いたら出てくると思います。

deeeet氏:あっ、見せます!

(会場笑)

広木:deeeetさんが「見せる」そうです、ありがたい(笑)。

名村:一応、社内では全員に全部デザインブックが公開されています。誰でもコメントしたり、見たりできます。デザインブックのSlackチャンネルがあって、そこにプロポーザルが上がってきて、誰でもそこにコメントしていいようになっています。

広木:サービス縦断した述語やフレーズ、キーワード、ユビキタス言語、そういうのがあると思いますが、そういったサービス全体で共有できる言葉集はどこかで管理しているんですか。

名村:あ、用語集みたいなものですか。ない気がしますね……。

広木:「ユーザー」「ID」みたいなのがあったら、ね。

名村:はいはい。

広木:メルカリにおいて「ユーザー」とはこれです、みたいな。

名村:ないですね。「プロトコルバッファの定義見て」という感じかもしれないです。

広木:こういうスキーマドリブンのようなものをやっている方ってけっこう多いんですかね、最近。

名村:でもgRPC使うと自然とそれをせざるを得なくなってしまいますね。

曾川:それをやってなかったら、みんなバラバラに管理していたら、おそらく今頃メルペイはリリースできていないと思うんですよね。だからある程度一元的に管理していたというのは、メルカリがしたときによかったことなんだと思うんです。「それで縛っているから、一応くっつけたときに動く」みたいな。縛ってなかったら、くっつけたときに動かないと思うんですね。

広木:コンシューマー駆動契約というか、サービスの外形のテスティングってあるじゃないですか。ああいうのって何かスキーマに対してしていますか?

名村:ある……やってない?

曾川:最近、End to Endテストはやり始めていて。それはたぶんやったほうがいいんですよね、デプロイとかが起こったり、QAで全部見るのは大変すぎるので。自動化してやっていくことはアプローチとしてある程度やっています。

マイクロサービスがこれだけ増えていて、とくにメルペイはほとんどマイクロサービスなのでそれがないと、自分たちの状態を正しく知ることができないから必要だと思います。やったほうがいい。もし今悩んでる人がいたら、やったほうがいいと思います。

広木:じゃあ「やったことあるぜ」なんて人がいると。

曾川:グッドですね。今一緒にその人と作っています。

広木:(笑)。なるほど、なるほど。

コードコミットしてプロダクトリリースできる環境をつくる

広木:あと4分ありますよ。何か話したいテーマありますか。

名村:貸し倒れリスクね……。

曾川:貸し倒れリスク、これ本当に大事なんですよね(笑)。一応今、直近で発表したカンファレンスでは99パーセント回収しているので、けっこう良い数字が出ています。それはちゃんとモデルが当たっているから。機械学習などを使ってモデルがうまくいっているので、わりと回収率が高いんです。

広木:そういう保険会社のアクチュアリーなどをやっている人で、エンジニアやりたい人ってほしいですか?

曾川:いや、そういう人が今チームにいて。

広木:あっ、なるほど。

曾川:プロダクトコードというか、モデルを作るといった仕事ですよね。メルペイにはそういう仕事もありますね。

広木:じゃあ、そろそろコミットメントいただけますか、名村さん(笑)。

名村:コミットメント(笑)。

広木:決意表明というか。

名村:今、エンジニアが自分で一生懸命考えてプロダクト開発にコミットメントするといった、実際にコードコミットしてプロダクトのリリースできる環境ができていないので、それが急務かなと思っています。すごく社内向けなアレなんですが、1年以内にそれをできるようにしたい感じですね。

広木:なるほど。いいじゃないですか。「1年以内に」って期限をつけて、スマートゴールにしていただいたところで(笑)。

名村:そうですね(笑)。

広木:曾川さんはどうですか?

曾川:僕は、今日は組織の話をしていて、広木さんも名村さんもけっこう組織目線でいっていますが、僕は背中を守ってくれるおじさんがいるので。誰か今日話していたと思います。VPofEが組織のことをしっかり見てくれます。

事業としてメルペイは、ぜんぜんメルカリに比べれば盤石な事業状態というか、フェーズでもないんです。しっかり事業の立ち上げを継続して行っていくことや、あとちょうど10月になってみなさんにとっても重要な増税というタイミングなので、来クオーターにかけてしっかりとキャッシュレスを広げていくところにコミットしていきたいなと思っています。

僕はそういうOKRです。もう正直に言います。

広木:(笑)。……銀行とかは?

曾川:銀行ですか。お客さまのお金をお預かりして、もしお金がなければ貸すことができる。旧来銀行業という免許でそれをやっていましたが、それをここで話していいんですかね?

広木:じゃあ、続きは懇親会で(笑)。そういった感じで、今日はいろいろ赤裸々にオープンにしていただきました。もしかしたら、みなさんにも持ち帰れるものが増えたのかなと思います。それでは長い時間でしたが、ありがとうございました。

(会場拍手)

続きを読むには会員登録
(無料)が必要です。

会員登録していただくと、すべての記事が制限なく閲覧でき、
著者フォローや記事の保存機能など、便利な機能がご利用いただけます。

無料会員登録

会員の方はこちら

関連タグ:

この記事のスピーカー

同じログの記事

コミュニティ情報

Brand Topics

Brand Topics

  • 孫正義氏が「知のゴールドラッシュ」到来と予測する背景 “24時間自分専用AIエージェント”も2〜3年以内に登場する?

人気の記事

人気の記事

新着イベント

ログミーBusinessに
記事掲載しませんか?

イベント・インタビュー・対談 etc.

“編集しない編集”で、
スピーカーの「意図をそのまま」お届け!