2024.12.19
システムの穴を運用でカバーしようとしてミス多発… バグが大量発生、決算が合わない状態から業務効率化を実現するまで
リンクをコピー
記事をブックマーク
広木大地(以下、広木):それでは、会場の質問です。評価の話は今していただいたんですが、「1on1って何を話しますか」という質問が来ていますが、EMのほうで1on1の話ってしていましたっけ。
曾川景介氏(以下、曾川):EMの人がたまにエンジニアとしたりしますが、私はそれなりにしています。ときに私がやりたいことや好きなことを話しているときもありますね、事実として(笑)。
(会場笑)
でも、結局その人が解決できない問題があるときに、それを一緒に解決するための時間だと思うので。そういうイシューなど、もちろんそれは会社のイシューでもいいし、個人として「こういうことに悩んでますよ」というのがあるんだったらそれを目標にします。とはいえ毎回毎回、そんなにきれいに悩みがあるわけでもないので「こういうもの作りたいよね」といった話をしているときもあります(笑)。
広木:なるほど。名村さんは、1on1とかけっこうするんですか。
名村卓氏(以下、名村):エンジニアマネージャーほどはしていないと思いますが、ダイレクトレポートの人とはやっています。どちらかというと組織の話が多くて、基本的に上司の役割はブロッカーを取り除くことだと思っているので「ブロッカーって何かありますか」というのが多いとは思いますね。ただ僕のダイレクトだと、勝手にブロッカーを取り除いてくれる人たちなので。
広木:(笑)。
名村:最近は、世間話や「次にメルカリをどういう組織にしていこうか」といった話が多いと思います。
広木:なるほど。もう1個、いただいた質問をやっておきますか。「エンジニアリングマネージャーの役割は、マネージャーとは具体的に何か」。エンジニアリングと付いているからには多少はスコープ違うところがあるんだと思いますが、具体的に何か違いはありますか?
名村:僕の理解だと、エンジニアの組織をマネージしているものだと思います。エンジニアのメンバーを、マネージャーとしてピープルマネージしているという人です。メルカリの場合、エンジニアリングマネージャーはほぼ全員、元エンジニアだと思います。エンジニアのことを理解できないといけない。
広木:マネジメントスキルを、エンジニアの人がエンジニアリングマネージャーになったときに、学ばなければならないじゃないですか。下手したら英語より大変だと思うんですけど、何かそういう支援はしているんですか? ……していきたいと思っていますか?
名村:していきたい。
広木:いきたい(笑)。
(会場笑)
曾川:最初の最初は研修などをやっていたんですよね。でも、それよりは、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です。もう正直に言います。
広木:(笑)。……銀行とかは?
曾川:銀行ですか。お客さまのお金をお預かりして、もしお金がなければ貸すことができる。旧来銀行業という免許でそれをやっていましたが、それをここで話していいんですかね?
広木:じゃあ、続きは懇親会で(笑)。そういった感じで、今日はいろいろ赤裸々にオープンにしていただきました。もしかしたら、みなさんにも持ち帰れるものが増えたのかなと思います。それでは長い時間でしたが、ありがとうございました。
(会場拍手)
関連タグ:
2024.12.20
日本の約10倍がん患者が殺到し、病院はキャパオーバー ジャパンハートが描く医療の未来と、カンボジアに新病院を作る理由
2024.12.19
12万通りの「資格の組み合わせ」の中で厳選された60の項目 532の資格を持つ林雄次氏の新刊『資格のかけ算』の見所
2024.12.16
32歳で成績最下位から1年でトップ営業になれた理由 売るテクニックよりも大事な「あり方」
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
PR | 2024.12.20
モンスター化したExcelが、ある日突然崩壊 昭和のガス工事会社を生まれ変わらせた、起死回生のノーコード活用術
2024.12.12
会議で発言しやすくなる「心理的安全性」を高めるには ファシリテーションがうまい人の3つの条件
2024.12.18
「社長以外みんな儲かる給与設計」にした理由 経営者たちが語る、優秀な人材集め・会社を発展させるためのヒント
2024.12.17
面接で「後輩を指導できなさそう」と思われる人の伝え方 歳を重ねるほど重視される経験の「ノウハウ化」
2024.12.13
ファシリテーターは「しゃべらないほうがいい」理由 入山章栄氏が語る、心理的安全性の高い場を作るポイント
2024.12.10
メールのラリー回数でわかる「評価されない人」の特徴 職場での評価を下げる行動5選
Climbers Startup JAPAN EXPO 2024 - 秋 -
2024.11.20 - 2024.11.21
『主体的なキャリア形成』を考える~資格のかけ算について〜
2024.12.07 - 2024.12.07
Startup CTO of the year 2024
2024.11.19 - 2024.11.19
社員の力を引き出す経営戦略〜ひとり一人が自ら成長する組織づくり〜
2024.11.20 - 2024.11.20
「確率思考」で未来を見通す 事業を成功に導く意思決定 ~エビデンス・ベースド・マーケティング思考の調査分析で事業に有効な予測手法とは~
2024.11.05 - 2024.11.05