とても雑記。
チームトポロジーを読んだ。買ったときにはさらっと読んでたので、今回はゆっくり読んだ。
読み直そうと思った理由
以前に読んだときは「まぁ、そうだな。わかる」くらいの気持ちだったんだけど、それから2年くらい経って、チームトポロジーの用語が、少なくとも僕の周りでは、普通に交わされるようになってるなぁと感じたから、読み直そうと思った。
用語をある程度理解しておくと、相手の言っていることがよりよく理解できそうだなと思って。
読み直してみてどうだった？
まぁ、そうだな。わかる。という気持ち。（おい！）
それから、用語の整理もできた。4つのチームタイプと3つのインタラクションモード。これで、周りの会話もよく理解できそう。
そして、とてもよかった。これは、自分が成長したってことかな。
DevOpsにピンときてない
そもそも、前段にあるDevOps自体には、自分はピンときていない。これまで開発と運用を分けてたことがほとんどないから。
コードを壁の向こうになげてリリースしてもらう？何を言ってるんだろう？どうしてそんな大変なことをするんだろう？って気持ち。
つまり、たぶん自分にとってはDevOpsは普通のことなんだと思う。
チームを中心としたアプローチ
そして、チームを中心としたアプローチも、真横で見てきた。及部さんや川口さんが近くにいたからね。
彼らの活動を見たり、話を聞いたりしていくなかで「まず、チームがある」というのも、自分にとっては自然な考え方になっていた。
まぁ、そうだな。わかる
何が言いたいかっていうと、DevOpsやチーム中心のアプローチが自然な環境で育ってきたので、チームトポロジーで説明されている「ストリームアラインドチーム」は、僕も、僕の周りの人たちも、ずっと考えているチームのことだなと思った。
だから「まぁ、そうだな。わかる」と感じた。
全体を見ること
ところで、DevOpsや、フルスタックや、フルサイクル。そんな風に、より広い範囲を体験して、実感をもとにフィードバックループをすばやくまわし続けると、よりよいプロダクトづくりができる。
それはとてもよく分かる。
とはいえつらい
とはいえ、とても広い範囲を見るのは、とてもつらい。こういうのを、認知負荷が高いというのかな。
だから、プロダクトを小さくしなきゃ！というのもとてもよくわかる。大きいと手に負えない。
組織づくり
また話がとぶけど、組織の形がプロダクトに影響を与える、というコンウェイの法則は、これまでの経験から実感している。
チームの境界はコミュニケーションの境界。そこには自然にスキマができてしまう。
インタラクションの方法
だから、チーム間のスキマを超えるために、どのようなインタラクションを設計するか、も、組織づくりの一環だよなと思っている。
それによって、プロダクトやチーム（プロダクトとしてのチームかな）が影響を受ける。
境界づくり
組織づくりには、そんな風に「どうスキマを超えるか」という役割がある。それと同時に「どうスキマをつくるか」ということでもあるよなと思っている。
それは、プロダクトの境界に対してだけでなく、いろんな認知の境界に対して、そうなのかなと。
認知の境界を作ってくれて「ここまで気にしてたらいいんだよ。あとは隣のチームに任せてね」と言ってくれる。そういう役割。
それによって、認知負荷が許容範囲内に抑えられて、チームはフルサイクルのすばやいフィードバックループをまわせるようになる。
変化し続ける
この本には、その組織のスキマ超えのための要素と、上手なスキマづくりの方法が書いてある。
そして、そういった適切なスキマやインタラクションは、時間の流れとともに変わっていくということも書かれている。
だから、静的な設計をして終わりではなく、その目的やビジョンを見続けて、変化し続ける必要がある。
とてもよかった
全部が4つのチームタイプや、3つのインタラクションモードに当てはまるとは、僕はあまり思っていない。そんなにシンプルではないんじゃないかと疑っている。
でも、考える時間をとって、よく考えてみたら、実はそこにたどり着くのかもしれないなとも思っている。
それ以外ない、と言い切ってくれるというのは、とてもありがたい。そこから始められるから。そういう点で、とてもいいなと思った。
狙いを考えられて楽しい
僕自身は、組織を設計することはあまりないんじゃないかと思っている。
でも、僕の周りの人たちは、組織を設計し続けているので、それがチームトポロジーを基準として、そこに沿っているか、沿っていないか。それらの狙いはどこにあるのか。
そういったことを考えられるので楽しい。
そろそろ新大阪につくからこれくらいで！
