hidekのエンジニアと長話 第3-3回【全文書き起こし】
stand.fmで配信中の「hidekのエンジニアと長話」3人目のゲストは庄司嘉織さんです。
---
「hidekのエンジニアと長話」は、メルペイVPoEのhidekさんこと木村秀夫さんをメインパーソナリティにお招きし、毎回登場する様々なゲストエンジニアとともに作っていくスペシャルトーク番組です。
第3-3回の今回は、第3-1回、第3-2回に引き続き、ドワンゴやCookpadを経て、現在はLaunchableにて新たな挑戦をされている庄司嘉織さんをお招きして、マイクロサービスと組織やコンウェイの法則、組織分割などについて語りました。
※本記事は、2020年12月25日にstand.fmで配信を開始した番組を書き起こしたものです。
——-
Profile
＜ゲスト＞
庄司嘉織 氏
Launchable Japan プリンシパルソフトウェアエンジニア
＜「hidekのエンジニアと長話」メインパーソナリティ＞
hidek（木村秀夫）氏
株式会社メルペイ VPoE（Vice President of Engineering）
——-
マイクロサービスと組織のあり方
hidekさん（以下、敬称略）：これから本題に入っていくんですけど、今日、この話を嘉織とする時に、嘉織に「何話したい？」って言ったら、アーキテクチャと組織というか、特に「マイクロサービスと組織とのあり方」ということを話したい、と。指をポキポキ鳴らしていますけど（笑）。
庄司さん（以下、敬称略）：ごめんね、聞こえちゃってた。ごめんね（笑）。
hidek：いやいや。その話って、やっぱりCookpadの頃の話になるのかな？
庄司：そうね。っていうかね、もともと俺が大好きなのよ。ここが大好きで。分散システムとかのことを考えるのが好きで好きでしょうがなくて。そう、だからね、ここを語りたくてしょうがない。言い方が悪いんだけどさ、あ、ポッドキャスト出るのはじめてなのよ。
hidek：はいはいはい。
庄司：この話題の転換の仕方、藤本さんっぽくて嫌だな。
hidek：同じにおいを感じました（笑）。
庄司：（笑）。ポッドキャスト出るのはじめてなの、これ。でさ、それこそさ、みやーんのRebuildとか聞いててさ、「いつか出たらこの話しよう」みたいなのを妄想したりするわけじゃん（笑）。
hidek：かわいいな（笑）。
庄司：え、しない？ みんなしないの？
hidek：え、考えたことないな（笑）。
庄司：マジで？ 「俺、みやーんから声かかったら何話そうかな」みたいなこと考えるじゃん。その中のひとつが、このマイクロサービスの話。
hidek：へー。
庄司：めちゃめちゃこれは話したくてしょうがなかったんだけど、話してもいい？
hidek：全然構わないんだけど、前提としては、Cookpadの……。マイクロサービスは規模としてはどのくらいなんだろう。
庄司：そうね。まあ、「最低でもCookpad」みたいな話、に今からしようかなっていう。
hidek：マイクロサービスの数で言うと100とか？
庄司：とか、っていう話なんだけど。もっと全体的な話から。じゃあ、今から「早口オタク」をしてもいいですかね？（笑）
hidek：いいよ（笑）。
庄司：好きなものを話すので。hidekには釈迦に説法かもしれないけど、歴史的なのとか背景を話させてください。マイクロサービスの話をする時に、みんな、「大きくなったシステムを分割する話」として話すことが多いんだよね。でも、それって、マイクロサービス以前からもあった話で。そもそも分散システムとかっていうのは、全体として大きくなり過ぎたソフトウェアを細かくしていきましょう、分割していきましょう、っていうのは昔からあった話。
hidek：うん。
庄司：で、どんなシステムでもそうなんだけど、システム分割をしていくと、全体としては複雑になるんだよね、当たり前だけど。なぜかと言うと、今まで一個のアプリケーションだったら、メソッド呼び出しで済んでいたものが、通信をかませなければいけなくなる。
hidek：そう。障害ポイントが増えるもんね。
庄司：障害ポイントが増えるし、その通信が成功するかわからない、とかいろいろ考えなきゃいけないことも増えてくる、というのが分散システムの基本的な話。それは、マイクロサービスか関係なく。で、もちろん、「じゃあそんなことする必要ないじゃん」って言うけれども、分散システムをする利点もあって、その分散したアプリケーション単体ではシンプルになるんだよね、すごい。
hidek：はい。
庄司：だからわかりやすくなるし、それぞれ、分散システムが個々に立ち上がるので、スケールしやすいんだよね。こっちは100台にしておいて、こっちは5台で済む、みたいな、とかがスケールしやすいというのはある。で、アプリケーション単体ではシンプルになるのと、もうひとつシンプルになるものとして、インターフェースが集約するんだよね。メソッド呼び出しだと、本当にどっからどこを呼ばれているかが全然わからないんだけど、インターフェースが、それこそ通信になった時点で、「ここでやりとりしている」というのがわかるのでシンプルになるんだよ。インターフェースがすごい分割されてわかりやすくなる。これ、考え方としては「GOTOと構造化プログラミング」にも通じると思っていて。昔、アセンブラの時とか、GOTOみたいなのばっかりでプログラム書いていた時って、どっからでも呼び出せて、本当にぐっちゃぐちゃだったんだけど、GOTOを禁止して構造化プログラミング、構造化プログラミングにしていったら、ちょっと制約はできたけど見通しがよくなったよね、っていうのと同じで、システムを分割してインターフェースをかますことによって、構造化できるよね、みたいな利点もある、っていう分散システム。
hidek：基本的には、プログラミングのリファクタリングと考え方は一緒だよね。
庄司：そうそう。それこそ、SOAPとかRPCとかが昔からあったのは、そういうのを扱うためにあったわけじゃん。
hidek：はい。
庄司：SOAPとかRPCが重すぎるから、って言ってRESTとかが流行って、JSON over HTTPとかっていう歴史があって、また最近gRPCになって、みたいな歴史があったりとかっていうのも、要は、ある意味、昔から分散システムみたいな考え方はあったよね。で、複雑になったシステムをうまく分割する、っていうのは大変なんだよね。
hidek：うん。
庄司：どう分割していくのがいいのかわからないし、どうやったらうまく分割できるかっていうのは、みんな試行錯誤して大変だった。
hidek：はい。
マイクロサービスとコンウェイの法則
庄司：で、炎上したくないから先に言っておくんだけど、俺の個人的な見解です。はい。
hidek：はい（笑）。
庄司：個人的な見解なんだけど、どうやってシステムを分割していくのか、っていうのが大変でわからない、って言った時に、一個、マーチン・ファウラーが提案したのがマイクロサービスだと思ってて。
hidek：はい。
庄司：で、マーチン・ファウラーが言ったのは、「システムを分割する時に、どうやって分割するかを考える時に、『コンウェイの法則』というのが実はあります」。
hidek：はい。
庄司：要は、システムっていうのは組織構造に似てしまいますよ、というのがあるから、そもそもシステムを分割するのは大変なんですよ、って。じゃあどうしたらいいかって言うと、システムを分割するように組織も分割した方がいいよね、組織ごと変えた方がいいよね。で、そうなると、組織ごと変えて独立した組織がどんどんできるようになるよね。で、これをマイクロサービスと言いましょう、っていう話だと思ってる。個人的な見解です。
hidek：でも、それは僕、見解は一緒で、分散システムって昔からあるって話だったけど、それこそSOAみたいな。あれもまさに、大きなアーキテクチャをいかに分割するか、っていう、アプリケーションモデルみたいなのを切り出していって、っていうのは、すごく、2000年初期から、下手したら1990年代からあった話で、それ自体はそんなに新しくないんだけど。マイクロサービスって実はアーキテクチャの話っていうよりは組織論なんだよね、たぶん。
庄司：そうそう。
hidek：そこはすごいアグリー。
庄司：システム分割の難しさを語るのと、マイクロサービスを語るのってちょっと違うな、と思ってて。最近、「マイクロサービスについて語ります」っていう話だと、「システム分割すると通信が大変で」みたいな話になるんだけど、「いや、そうじゃねえんだよな」っていう。
hidek：はい。
庄司：俺が話したいマイクロサービスの話はそうじゃなくて、システム分割が難しいのをどう解決しようか、っていうひとつの提案がマイクロサービスで。そこで出てきたのがコンウェイの法則。で、逆にコンウェイの法則を知っているんだったら、要は、「組織構造にソフトウェアが似ちゃう」って言ってるんだから、逆に言うと、「組織を変えないのにソフトウェアを変更できる」ってなぜ考えるのかわからないじゃん。
hidek：はい。
庄司：ってなると、組織を変えなきゃいけないよね、変更していかなきゃいけないよね、っていうところの話をしたいのに、その話全然出てこないんだよね、世の中に。
hidek：あー、なるほどね。でも、僕は完全にこれは組織論の話だと思ってて。
庄司：そうそう。
hidek：でも一方で、僕が話していいのかわかんないけど、逆にその「マイクロサービスに合わせた組織」っていうのをやっていくと、当然、組織も分散していって。たしかにその中のフットワークの軽さだとか、PDCAサイクルを回しやすいだとか、コミュニケーションも少なくなるし、というのはまさにそうなんだけど、一方で、組織がバラバラになっていくとマネジメントの難しさとか、あともう一個ずっと言っているのが、運用がすごく難しくなるなっていう。
庄司：うんうん。
hidek：もっと言うと、マイクロサービスにどんどん属人化していってしまう。そこの難しさっていうのは一方あって。そこをみんなどうしてるのかな、っていうのはすごい昔から思ってるんだよね。
庄司：はいはい。そうね。これね、マイクロサービスがすごい流行ったのって、完全オタク話なんだけど、もう一個あるものとして、コンテナ技術がすごい成熟した、っていうのがでかいと思ってて。コンテナ技術・Dockerが成熟して、要は、アプリケーションのポータビリティがめちゃめちゃ上がったんだよね。それこそ昔って、アプリケーションサーバ、「アプリケーション新しいの作りました」って言ったら、それ用のサーバを用意して、ってやらなきゃいけなかったんだけど、今ぶっちゃけ、Kubernetesとか立てておいて、「Podsで管理しておくんで、Docker Imageだけ作ってください」でいろんなサービスを立てられるようになってるわけじゃん。だから、これも、マイクロサービスとかシステム分割とか、分散システムを作るのの後押ししているのかな、という気はする。
hidek：うん。
組織分割に失敗した話
庄司：で、言ったように、システムとしてはまあまあ作りやすくはなっている気はするのよ。それこそ、システム間通信もさ、サービスメッシュとかenvoyみたいなのが出てきてさ、いろいろ便利にはなっているのでいいんだけれど、hidekが言ったように組織の話が結構難しいな、と思ってて。これは、俺は、どこまで話していいのかわかんないんだけど、失敗してるのね、一回、組織分割を。
hidek：あー、なるほど。
庄司：そう。で、具体例があった方がわかりやすいと思うので、具体例込みで話しちゃうんだけど。これね、話しちゃいけないことまで話してたらごめんなさい、って先に、今、これ、インターネット越しにミラクイに謝っています。
hidek：（笑）
庄司：前職の時に何をやりたかったかって言うと、どんどん組織を分ける。で、マイクロサービス化をする、っていうのがやりたくて。何をやりたいかって言うと、まず、ユーザーを分けたかったのよ。たぶんメルペイとかもそうだと思うんだけど、メルカリのユーザーアカウント使って、とかやったりとかさ、どんどんマイクロサービス化していくと、ユーザーって切り分けてて、いろんなところと通信させるべきだ。だから、まずユーザーを分けたいな、と思ってて、一旦、分けたのよ。で、それは、グループとして分けたの。
hidek：ふーん。
庄司：グループっていう単位がどんなものかって言うと、なんか、部長ではない課長くらいのレベルで分けたのね、組織として。で、それを、もともと俺が見ていた技術部っていう部にあったのを、この部じゃなくて違うところにあった方がいいだろうな、って話をして、当時、会員事業部、Cookpadの会員を持っているところに、まあ、ユーザーって結構会員と密接だから、そこのグループで持っていきましょう、みたいな感じで持っていってもらったのよ。で、やったんだけど、正直うまくいかなかったのよ。これ、すごく申し訳なくて、完全に俺が悪いんだよ。その時に頑張ってくれていた人とかもいるから、「うまくいかなかった」って言っちゃうのはすごいよくないことだとは思うんだけど。でも、反省としては、やっぱりうまくいかなくて。思っていたようにはうまく分割できなくて。で、何かって言うと、その時に感じたのが、予算を持っている単位より下にグループとして、課としてあっちゃうと、どうしても全体の予算のところに影響されちゃうんだよね。
hidek：なるほど。うん。
庄司：課だとすると、要は、部の予算とか部の目標とかにどうしても影響が出てきてしまう。
hidek：はい。
庄司：っていうのがわかって、これはよくないな、と思って。で、もう一回チャレンジをさせてもらって、もう一回それを技術部に戻して、俺のところに戻して、もう一回、俺のところのグループとしてやりながら、もうその時から、そのグループリーダーに、「お前は来年、部長にするから、組織として完全に分割するから」っていう話をして、次の年に部として立ち上げたの。で、これは何かって言うと、予算から何から、全部独立して考えられる単位で切り分けた。
hidek：はい。
庄司：ってやったら、ある程度うまくいったのよ。だから、マイクロサービスとして組織を切り分けていくタイミング、切り分ける単位としては、予算とか人事権まで持った単位で切り分けないとダメなんだな、っていうのが最近の学びだったりとかするのね。
hidek：うんうん。まあ、そうだよね。予算っていう考え方もあるし、当然リソースって有限なので、たぶん、プロジェクトの優先順位。例えば、それが会員を扱うところで、認証・認可の仕組み込みでマイクロサービスをつけた時に、認証・認可を社内でより使いやすくしよう、っていうプロジェクトと、よりコンバージョンを上げましょう、みたいなところだと、どうしても事業部についちゃうとそっちが優先されるので、前者が置いてけぼりになってしまう。で、そうすると、マイクロサービスのいわゆるドメインというところがずれていっちゃう。それはすごくあるよね。難しいよね。
庄司：そう。で、もう一個よくなかったのが、一回、俺の技術部に戻したあとも、よくないのが、そのユーザーのサービスのグループリーダーに話が来るのは、立場が違うところから来ちゃうんだよね。向こうは部長からこういう依頼が来て、こっちはグループリーダーで受けるから、「じゃあ、部長の嘉織に相談して決めます」みたいになっちゃって。それもよくないな、と思ったから、これは同じ立場にしないといけないな、と思って、部として分割する、みたいな。だから、マイクロサービスとして組織を分割するんだったら、そのくらい結構ドラスティックな単位で変えていかないとダメないんだな、っていうのは学びなんだけれども、ここからさらに難しい話があってさ、今言ったユーザーとか課金っていうのは分けやすいのよ、ぶっちゃけ。
hidek：そうだね。うん。
庄司：でも、それぞれのサービスって、メルペイとかもそうなんだけど、いかに横との連携をうまくするかじゃん、サービスの価値ってさ。ってなった時に、「そんなに縦に分割していいの？」みたいなのは、いまだに答えがなくて、その答えが出る前に俺はもうCookpadを辞めちゃったので。
hidek：なるほどね（笑）。
庄司：例えば、そういうマイクロサービス的な、ツーピッツァチームみたいなのでうまくやっている例で出てくるのってAmazonじゃん。でもさ、AmazonのAWSのコンソールとか見てもらえばわかると思うんだけど、あれ、本当にマイクロサービスのクソのかたまりじゃん（笑）。
hidek：まあね（笑）。
庄司：全然、横の設計の統一取れてないしさ、みたいな。ホントにクソだな、みたいなのがやっぱりできるのよ。どうしてもサービスを完全に縦に分割しちゃうと。だから、横軸でもなんか見れるものとか入れなきゃいけないし、っていうのを、どう組織としてはやるべきかな、みたいなのは、まだ答えが出てない。
技術選定の自由とベストプラクティス
hidek：うん。なんかね、メルペイの今やっていることで言うと、マイクロサービスの組織論とはちょっと離れちゃうかもしれないんだけど、マイクロサービス、アーキテクチャの良さのひとつって、マイクロサービス単位で技術選定ができる良さ、みたいなところあるじゃない。だから極端な話、AというマイクロサービスはGoで書いて、BはJavaで書いて、CはRubyで書いてもいいよ、みたいな。
庄司：うん。
hidek：で、それをすることによって、技術の多様性も担保できるし、変化にも強くなる、みたいな話がよく語られると思うんだけど、これ、メルペイではやってないんですね。
庄司：はい。
hidek：で、これ、なんでかって言うと、当然、言語が増えてしまうと、今の規模だとコストが非常にかかってしまう。例えば、対応もそうだし、教育もそうだし。例えば、新しいマイクロサービスを立てる時に、そこの選定からするのもちょっとおかしいし。なので、そこのところは暗黙の規約として、それこそGCPの上でKubernetes、Golangで、あとはマイクロサービスのテンプレートみたいなのがあって、それをもとに作っていきましょう。で、デザインドックというものをちゃんと書いて、横で見れる、レビューできるようにしましょう、みたいな、どっちかと言うと、ちゃんと横のつながりもとか、あとレバレッジみたいなところも考えながら、今やっているので、純粋なマイクロサービスかって言われると、原理主義に言わせると違うと思う。
庄司：そうなのかな。それはそれで合ってる気がするけどな。
hidek：うん。
庄司：うん。技術選定の自由は、もちろんあるべきだとは思うけれども、デフォルトの、特別な理由がない限りはこっちを使っておいた方が便利だよね、は絶対にあると思うのよ。
hidek：うん。
庄司：例えば、分散システムをどんどん作っていった時に、「じゃあログってどこに集約するの？」とかさ、エラーが発生した時に「エラーってどこに集まるの？」とか、それこそ「オンコールってどうやってやるの？」みたいなのって決めなきゃいけないわけじゃん。
hidek：はい。
庄司：で、そうなった時に、エラーを集める仕組みみたいなのって、たぶん、一番使われている言語で書かれてるんだよね。
hidek：うーん。
庄司：Goで作るんだったら、このライブラリにぶち込んでおけば全部集まるよ、ってなるわけじゃん。
hidek：はい。
庄司：例えば、メルペイだとそうなってるだろうし、Cookpadだったら、「Rubyで書けば、こういう仕組みとこういう仕組みがあるから、これも入れておいてね」みたいなのがあったの。
hidek：はい。
庄司：っていうのは絶対に会社単位でできると思うんだよね。だから、デフォルトの技術は逆に言うと決まっているべきだと思ってて。
hidek：そうね。ベストプラクティス的なものはあった方が。フェーズによると思うんだよね。それこそ、Amazonだとか、Netflixだとか、何千というマイクロサービスになってたらちょっと違うのかもしれないけど、100とか、さっき数を聞いたのはそれが理由なんですけど、100とか200とかそれくらいであれば、ある程度、ベストプラクティスの上で。で、変化が必要な時に、小さく変化をできるっていうのは良さだと思うんですけど。その辺は、マクロサービスの良さでもあるし難しさでもあるのかな、っていう気はします。
庄司：はいはい。そうね。そこが楽しいところだな、と思ってて。だから、そういうのも含めて考えるのが、俺は結構楽しくて。だから、そういう意味では、アーキテクチャと組織とかマイクロサービスとかって楽しいよね、って思っちゃうんだよ。
1マイクロサービスに1チームでなくてもいい
hidek：なるほどね。でも、原理的に言うと、1マイクロサービスあたりにリソースを張って組織化していくっていうのが、コンウェイの法則とマイクロサービス、って話だと思うんだけど。これ、実際にやってると非常にコスト高というか。言うたら、枯れるマイクロサービスっていうのも出てくるわけですよね。
庄司：うん。
hidek：で、そうすると、そこにあまり人を張らないで良い、っていうのが出てくるわけですよ。
庄司：はいはい。
hidek：で、そうすると、3つくらいのマイクロサービスを5人くらいで見る、っていうのが一番コストにも見合うし、あと、チームでメンテナンスをしていくので、ナレッジの属人化も防げるしいいよね、っていうのが、今、メルペイの中でのプラクティスみたいなところはあって。純粋に1マイクロサービスに1チームというよりは、3つくらいのドメインに近いマイクロサービスを5人くらいで見る、みたいな。で、オンコールをその中で回す、みたいな。
庄司：はい。それはそれで、すごい正しいと思うよ。1マイクロチーム1チームじゃなきゃいけない、とは思っていなくて。
hidek：うん。
庄司：それこそ、ひとつのマイクロサービスを複数チームとかで見る、っていうのもよくないと思うし。
hidek：まあ、そうだね。
庄司：そうそう。それに比べたら、1チームが複数見るのは全然ありだと思うし、むしろ、標準の形なんじゃないかな、という気もするよね。
hidek：うんうん。ただ、その時の難しさは、マイクロサービスを束ねる単位とか、ドメインなんだけど、それを事業ドメイン的なものにするのか、より機能・ファンクションみたいなところにしていくのか、っていうが結構難しいかな、っていう。
庄司：そうなんだよね。それこそ、縦と横どっちで割ったらいいのか、マイクロサービス、みたいなのは結構悩んでて。それこそ、ユーザーフェイシングのサービスごとにゴンゴン分けるのか、それとも機能として分けるのか、みたいな。でも結果として、俺、それ、両方なんじゃないかな、って思ってて。
hidek：うん。あ、そう。たぶん、ハイブリッドだと思って。僕らも結構、プラットフォームっていうくくりと、あとは決済事業だったりだとか、信用情報、いわゆるクレジットスコアみたいなのだったりとか、あとはマーチャントね。こういう分け方をするのと、あと、プラットフォームがポンっとあって。さっき言った認証・認可みたいなところはプラットフォームのところに入れているし。あと、決済っていうところも、決済のよりユーザーに近いところは上の方に切り分けてるんだけど、より決済基盤みたいな、本当にお金の出し入れするみたいなシンプルなところはプラットフォームに寄せて、それこそいろんなところで使い回すだとか、そんなことをしてるかな。なので、大事なのはリソースをそこでちゃんと分けること。
庄司：そうね。
hidek：そこを、事業が忙しいからプラットフォームから人を軽々に抜くと、たぶん、その基盤がそもそもうまくいかなくなるので、その辺は握ってるかな。
庄司：そう。そうね。それが、まさにコンウェイの法則を利用しなきゃいけないところだと思ってて。
hidek：うん、そうだね。
庄司：今の話で言うと、ユーザーにもっと近い決済のところに、プラットフォームの決済の人が行っちゃうと、プラットフォーム側の決済のすごいベーシックなものが、ユーザーフェイシングなものと、ソフトウェアとして紐づき過ぎちゃうんだよね、たぶん。近くにあり過ぎちゃうから、そこは組織を分けておくことによって、ソフトウェアも分かれてる、みたいな風にしていくのがいいんじゃないかな、という気はする。
hidek：あと、たぶんね、モノの作り方がやっぱり違うんだよね。時間の流れというか。ユーザーに近いところって、PDCAサイクルをガンガン回して、よりフットワーク軽く進めていかなきゃいけないけど、プラットフォームのところって、それこそ認証・認可のところを進めていくって、結構、足の長い話だったりとかするじゃない。
庄司：そうだね。
hidek：なので、そこはもうちょっとプロジェクトとしてはロングタームになっていくので、まさに組織論になると思うんだけど。その辺はあるかな。
庄司：そうなっていくと、たぶんなんだけども、システム的にこのシステムは分けた方がいいな、みたいなのを考えた時に、たぶんシステムを分割するよりも先に組織を分割した方がいいんだろうな、と思ってて。
hidek：あー、なるほどね。そこもね、でも若干、それこそ今日、12月1日なんですけど、僕、メルペイのアドベントカレンダーの一発目を書いたんですけど。
庄司：おお、なるほど。ごめん、読んでないわ。
hidek：ごめんごめん。さっきね、本当は今日締め切りで今日出さなきゃいけないんだけど、さっきまで書いてたんで（笑）。
庄司：そっか。
hidek：そうなんですよ。で、去年も反省みたいなのを書いて、今年も反省を書いたんですけど、今年の反省としてあったのが、ちょっと大きめのプロジェクトが走ったんですよね。1年がかりのプロジェクトが走って。で、その対象となるマイクロサービスに結構めちゃくちゃ多くの人が、機能自体はそんなにあれなんですよ、ドメインとしては正しくて、これ以上できることはたぶんないと思うんだけど、そこにめちゃくちゃ多くの人が関わるってことが発生しちゃったんですよ。
庄司：はいはい。
hidek：ちょっと技術的負債になったので、技術的負債の返済をしながら、そこに対してのグロース施策だとか追加機能だとか、そういうのが、当然何が起きるかって言うと、コンフリクトが起きる、リソースの。
庄司：はいはい。
hidek：それでかなり開発が遅れてしまった、っていうのがあって。やっぱりひとつのマイクロサービスに関わる人の人数っていうのは制限した方がいいな、っていうのが学びだった。
庄司：はいはい。それはでも、よく言われてるよね。昔からさ、システム分割、ツーピッツァチームじゃないけどさ。
hidek：あー、そうそう。
庄司：っていうのは言われて、でも、本当にそうだと思ってて。俺もマネジメントとかしてて思うんだけどさ、俺が無能なのかもしれないけど、俺、ちゃんと部下として見られるのって5人までだと思ってるの。
hidek：あー、なるほど。
庄司：もしも、それ以上増えるんだったら、一段階つけた方がいいな、と思って。グループリーダーみたいなのをひとり作って、そいつに5人見させて、その上に立つ、とか。それをまた5人が見て、とかってしていった方がいいな、と思ってて、マネジメントって。だから、そういう意味で言うと、せいぜいツーピッツァチームだから10人くらいまでしか、1マイクロサービスに関わらせる人としては限界なんじゃないかな、っていう気はしてる。
hidek：うん、そうだね。まさにそうだと思う。それこそ、1チーム当たりの人数って、結構、メルカリ・メルペイでも、一応、そのツーピッツァルールっていうので対応してて。まあ、8人？ 10人？から、5人か6人？ っていうところをっていうところを目安にしてるんだけど、やっぱり、エンジニアリングマネジャーって少ないじゃないですか（笑）。
庄司：そうね（笑）。
hidek：そうすると、やっぱり、シニアのマネジャーには人数を寄せてしまったりとかして。
庄司：はい。
hidek：そこはちょっと申し訳ないな、と思いつつ。
庄司：うん。
この記事が気に入ったらサポートをしてみませんか？