2024.10.21
お互い疑心暗鬼になりがちな、経営企画と事業部の壁 組織に「分断」が生まれる要因と打開策
リンクをコピー
記事をブックマーク
広木大地(以下、広木):それでは、会場の質問です。評価の話は今していただいたんですが、「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.11.13
週3日働いて年収2,000万稼ぐ元印刷屋のおじさん 好きなことだけして楽に稼ぐ3つのパターン
2024.11.21
40代〜50代の管理職が「部下を承認する」のに苦戦するわけ 職場での「傷つき」をこじらせた世代に必要なこと
2024.11.20
成果が目立つ「攻めのタイプ」ばかり採用しがちな職場 「優秀な人材」を求める人がスルーしているもの
2024.11.20
「元エースの管理職」が若手営業を育てる時に陥りがちな罠 順調なチーム・苦戦するチームの違いから見る、育成のポイント
2024.11.11
自分の「本質的な才能」が見つかる一番簡単な質問 他者から「すごい」と思われても意外と気づかないのが才能
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
2024.11.18
20名の会社でGoogleの採用を真似するのはもったいない 人手不足の時代における「脱能力主義」のヒント
2024.11.19
がんばっているのに伸び悩む営業・成果を出す営業の違い 『無敗営業』著者が教える、つい陥りがちな「思い込み」の罠
2024.11.13
“退職者が出た時の会社の対応”を従業員は見ている 離職防止策の前に見つめ直したい、部下との向き合い方
2024.11.15
好きなことで起業、赤字を膨らませても引くに引けない理由 倒産リスクが一気に高まる、起業でありがちな失敗
2024.11.13
週3日働いて年収2,000万稼ぐ元印刷屋のおじさん 好きなことだけして楽に稼ぐ3つのパターン
2024.11.21
40代〜50代の管理職が「部下を承認する」のに苦戦するわけ 職場での「傷つき」をこじらせた世代に必要なこと
2024.11.20
成果が目立つ「攻めのタイプ」ばかり採用しがちな職場 「優秀な人材」を求める人がスルーしているもの
2024.11.20
「元エースの管理職」が若手営業を育てる時に陥りがちな罠 順調なチーム・苦戦するチームの違いから見る、育成のポイント
2024.11.11
自分の「本質的な才能」が見つかる一番簡単な質問 他者から「すごい」と思われても意外と気づかないのが才能
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
2024.11.18
20名の会社でGoogleの採用を真似するのはもったいない 人手不足の時代における「脱能力主義」のヒント
2024.11.19
がんばっているのに伸び悩む営業・成果を出す営業の違い 『無敗営業』著者が教える、つい陥りがちな「思い込み」の罠
2024.11.13
“退職者が出た時の会社の対応”を従業員は見ている 離職防止策の前に見つめ直したい、部下との向き合い方
2024.11.15
好きなことで起業、赤字を膨らませても引くに引けない理由 倒産リスクが一気に高まる、起業でありがちな失敗