春の始まりと雑談
こんにちは、エンジニアの博崇です。
こんにちは、エンジニアの三ツ永です。
ゆるテクは三ツ永と博崇が、ゆるーく技術の話をするポッドキャストです。よろしくお願いします。
よろしくお願いします。
はい。
はい。
三ツ永さん、今何月でしょうか。
今は3月になりました。
はい、春ですね。
まだちょっと寒いんですけどね。
三ツ永さん、ちなみに花粉症とかはどうですか。ある人ですか。
僕、ない人なんですよ。
僕も無敵。
なので、今のところすごい何も感じてないですね。
自分もたまに、これは花粉症か、みたいになることあるんですけど、今のところ来てないから、やっぱり春は来ないのかも。
じゃあ、秋前とかその辺とかですか。
秋、結構来てる記憶あるんで、秋だけかも。
いやー、なんか、なったら怖いんですけど、あんま対策も思いつかないので、祈るだけ祈ってようかなって感じですね。
そうですね。来ないことを祈りましょう。
はい。
チームトポロジーの再読
はい、ほいで、今日はもう一度読むジームトポロジーズという大層なお題目を掲げて。
いいですね。
先週だっけ、先々週だっけ、三ツ永さんに、これあるんでもう一回読んでおいてくださいと。
先週でしたね、多分。先週にやるからもう一回読んでおいてくださいが来ましたね。
なんかこう、そうやって大層なお題目をぶちかましたのはいいんですが。
ちなみにこれもう一応読みました?
はい、読みましたし、実はちょうど今僕が所属しているチームで、このチームトポロジーの臨読化をやってたんですよ。
なんだと。
なんで、ここ直近に2回は読んでます。
なんだって。それはタイムリーすぎたな。
自分も一応読んだんですけど。
はい。
あれでしたね、そんなに、実はこんなことが書いてあって、見ました?みたいなそういう話はできそうになさそう。
そうですね、1回目に読んだ時ほどの発見はあまりなかったというのは正直なところではあります。
そうでしたね、自分の記憶通り重要なところはチームのトポロジーが4つあり、インタラクションモードが3つありみたいな。
ですね、内容に対しては一定改めて自分たちの認識ってずれてないなっていうのは読み直してみてもわかったんですけど、
実際なんかこれ読んでみて、これまでの初めてこの本読んでから今に至るまでで何か行動変化とか思考の変化ってあったのかなって振り返ってみたんですけど、
でも一定は影響を与えてくれたっぽいなって思っているところはありまして、というのも結構マネジメントとか今やらせていただいてるんですけど、
割と立場上チームの体制とか枠組みを考える機会をいただけることが多くてですね、
その時にもやっぱり新しいサービスに対してだけじゃなくて、既存の仕組みとかサービスに対して考えるパターンも結構あって、
その時にすごく逆コンウェイを、チームトポロジーで出てくる逆コンウェイの考え方を参考にチーム組は考えるようになってるんだなっていう振り返りができました。
ドメイン特性の理解とチームの組み方
いいですね。その時って、さっき輪読会をしてるみたいな話もありましたけど、やっぱりチームのメンバーもこれを読んでるといいって感じますか?
いいって感じます。というのも結局この本で書かれてるところって認知負荷のところであったりとか、
ドメインに応じてトポロジー考えてチーム分けしてねとかいろいろ書いてたと思うんですけど、
よく僕のケースであるのって、あるサービスのドメインがあって、どこが担当しようかみたいな話がやっぱり出る時ってあるんですよ。
チューブラリーになっちゃうみたいな。
チーム自体はすでにあってってことですか?
そうです。そうなった時に一番やりたくないのって、サービスが3個あるから平等に3等分してやりましょうとか、
あるいは1箇所のチームがとりあえずその時間かかんないから全部検認しちゃっときましょうとか。
もちろん選択肢としてあるんですけど、それを最優先で考えてやりたくないなってずっと思ってて、
なった時にそのサービスがどういうドメイン特性があるかを考えた上で、
このドメイン特性であればちゃんとした専任チームがいないとよくないよねとかを考えるようになってたんですよ、自分が。
いいですね。
特に嬉しかったのが、それをチームの人たちと一緒に輪読会してたおかげで、
その理由を述べたとき、述べてサービスを引き受けてきたよってメンバーに話すときに、
すごくすんなりみんなが受け止めてくれるっていうのはありがたいなって思いました。
確かに説明が大変ですからね。
マネージャーがまた面倒くさい仕事を新しく取ってきたなじゃなくて、
そういうドメイン特性があって自分たちのチームの立ち位置がこうだから、
それは確かに自分たちが持つのが適切だよねって納得してくれるところは、
輪読会やっててよかったなってすごい思いましたね。
でもその口ぶりだと、ストリームアラインドなチームではないチームの話ですか?
おっしゃる通りです。どちらかというとプラットフォーム系のチームなので、
これって特性はどっちかというとプラットフォームだからみたいな話もしつつ、
引き受けてきてって感じですね。
なるほどな。確かにそれで、それこそ例えばなんだろうな。
ファシリテーションのインタラクションモードで、
このチームをサポートしてやってよみたいな話とかっていうのは、
この辺の前提がないと伝わらないですよね、動きが。
ですです。未来像を語るときも、今はファシリテーションだけど、
将来的なXアザサービスにしたいよねとかも、
共通の土台があるとすごく話がしやすいので、
マジこれやるならチームで読んだほうがいいなって思いますよね。
そうですね。読んで、さっきあんまり発見は新しい発見なかったんですけど、
結構随所にチームファーストっていう言葉出てくるなと思いましたね。
確かにそうですよね。出てきてますよね。
こんな押してたっけっていう、チームファーストっていう言葉が出てくること自体は
分かってたんですけど、めっちゃ出てくるなと思いました。
なるほど。でもこうやって話してみると意外と発見というか、
こうだったねっていうのは出てきますよね。
そうですね。特に三長さんはマネージャーやって、チームを生んだみたいなことやってるから、
めっちゃ出てきそう。
出てきました。
これを例えばそのものづまりのチームトポロジー的なチームで運用して、
しばらくしてこういう問題というかが起きたみたいな話って何かあります?
僕はまだそういう経験はないかもですね。
そこに至るまでがまだまだ遠いというか、
至って安定したケースというかがまだあまりないはないですね。
最近ね、プラットフォームチームとかってSRE系だとよくある話ですけど、
あの辺とかもその動き方に迷っているみたいな話ってたまに見たりするんで。
そこで行くとどうなんでしょう?
多分その動き方って僕は段階的に切り替えていくタイミングって毎回来てるなって思ってて。
今のプラットフォームとかの話で言うと、きっとSRE文脈で注力しなきゃいけないタイミングと、
プラットフォームないしはDevOps文脈で注力しないといけないタイミングって、
支援するプロダクトのフェーズによって全然違うじゃないですか。
そうですね。
多分そこを誤るとめちゃめちゃ噛み合わないんだろうなって思ってます。
その辺の認識が揃ってないとちょっと動き方迷ったり。
あとチームのトポロジーはあんまり変わるみたいなこと確か書いてなかったけど、
インタラクションモードは段階的に変わっていかなきゃいけないから。
そうですよね。それって読んでて思ったんですけど、
最終的に目指した方がいいのって結局Azure Serviceなのかどうかって結構疑問で。
そうですね。X Azure Serviceに持っていくみたいな話ばっかり書かれてますね。
確かにスケーラビリティとかエンジニアリングで仕組みを構築した先は、
Azure Serviceぐらいのインタラクションであったほうがいいとは思うんですけど、
本当か?みたいな。
そうですね。確かにちょっと納得しちゃってるけど、
そう言われると全部これが答えだみたいに言われると確かにそんなわけないって思っちゃいますね。
そうなんですよね。
そうだよな、確かに。
チームインタラクションのモード
あんまり自分がそういうX Azure Serviceで事足りる経験をしたことがないのかもしれないんですけどね。
それこそ遥か昔というか新人の頃によく自分が経験してた開発チームと
すごいオフィスの向こう側にいるインフラチームみたいな関係性だったときこそ、
むしろAzure Serviceっぽくしか対話してなかったんじゃないかって思っちゃうんですよね。
そうですね。それマジのアンチパターンですよね。
そう、マジのアンチパターン。
そうなんだよな。
ただ一番出力が出せるのはコラボレーションモードなわけで、
でもあれ、その認知不可能面とかでもきついから、
そういう意味でAzure Serviceに持っていくけど、
行ったり来たりがいいっていうのもどっかに書いてあった気もしますけどね。
なんかありましたね。どこだっけな。
集計じゃなくて、どっかに書いてあった気がする。
でもそうなりますよね。結局チーム間の目的によってどうインタラクションするかは
つどつど違うっていうわけだし、
違う中のパターンをちゃんと言語化したのが結局この3つのインタラクションモードって話だと思うんですよね。
そうですね。
個別の例えば何々機能みたいなのを作るときには最初はコラボレーションでガッとやっちゃって、
段階的にAzure Serviceになり、次のときになればまたそれが繰り返しみたいな感じだから、
それの話でいくと結局でもAzure Serviceが最終形になっちゃうのか、機能単位で見ると。
平常時はAzure Serviceでみたいな感じはありそうですよね。
そうですね。
あとはあれですよね、この本ってチームが解散しない、チームがあまり変わらない前提で話し進んでるから、
それってそのまま僕らの環境に当てはめられるんだっけ感はありません?
チームが全く解散しない会社を自分は見たことないですね。
ダイナミックリチーミングの考察
そうですよね。
その辺が実際どうなんだろうなとはちょっと思ってます。
その話でいくと、最近出ると話題のダイナミックリチーミングの第2版がありますね。
オラエリーの。
これはダイナミックリチーミングって特徴的な単語なんで覚えてたんですけど、
あれですね、去年のRSGT、2024年のRSGTの基調講演で話されてた話だったはずです。
あれってことは。
三田さんから聞きました、自分は。
長い、覚えてなかったぞ。
この翻訳版の方じゃなくて、原著の方をパラパラと読んでみた時に、
この無限の図が出てきて、これ見たことありますと思って。
今、自分のRSGT参加メモを見直してたんですけど、めっちゃダイナミックリチーミング書いてますわ。
この我々のポッドキャストでも話していて。
話してましたね。記憶が蘇ってきた。
もうね、我々は何もかも忘れてしまう生き物だね。
多分この時にチームの解散とかも話してるはず。
本当だ。僕のメモにチームの歴史を残すとかって書いてるから。
ああ、そういうことだ。そうっすね。そうだね。
でもあれなのかな。多分これもチームの解散自体をざっくり読んだ感じ、解散自体はやっぱりダメで、
それを自分たちの意思でやるのが良い、みたいな感じのことをざっくり書いた気がします。
そうっすね。今メモ見たんですけど、解散という表現はあまり使ってなくて、
どちらかというと、ハクタケさんの言葉を借りると、自分たちの意思でチームを組み替えるみたいな表現をメモってるっぽいですね。
チームの中身をスイッチングして定期的に学びを広げる機会を作ったりとか、
歴史をちゃんと残したものを他のところで広げる練習をしたりとか、みたいな表現でいろいろメモを取ってるので。
特定の人がチームAからチームBに留学というか行って帰ってくるみたいな、そういう話がされていた記憶がありますね。
ですね。そういうことか。僕、この優的でも解散するじゃんみたいな話をしたときに、
ダイナミックリチーミングよりも、多分これハクタケさんが以前、優的で紹介してくださったと思うんですけど、
チームレジリエンスのキーワードを思い出してて。
チームレジリエンスの回をさっき見直したんですけど、
おおって感じ。何を言っていたか全然思い出せない。
今貼っておきましたけど。
我々のメモ、ちょっと見てみようかな。
ちなみにハクタケさんの感想には、
広く浅くという感じなので、詳しいことは別の本を読むと良さそうって書いてます。
なんということだ。
でもこれもやっぱり、チームを解散とか壊すみたいなことは書かれていなかったと思うんだよな。
書かれていなくて、どちらかというとチームに問題が起こったときの、
それこそレジリエンス、回復性を高めるにはっていう本の話でしたよね。
割と日頃からのチームの取り組みとしてこういうことやってると、
チームレジリエンス自体が高くなっていくよね、みたいな方向性の本だったかと思います。
なるほど。そんな感じですか。
そんな感じです。
私この収録始める前、全然何も発見できんかった話すことないぞと思ってたんですけど。
同じく同じくです。
意外と話せましたね。
良かったですよね。
良かったです。
では今週はこの辺で。
今回はもう一度読むGM Topologies について話しました。
感想などは、ハッシュユールテックをつけてポストお願いします。
Googleフォームからも送れます。
今日はありがとうございました。
ありがとうございました。
