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