ちいとぽ（チームトポロジー）と私
本も2周して、いろんな人とディスカッションしたりで一段落したので、今の理解を書き出しておこう。
目次
ちいとぽとの出会い：チームの成熟度を向上させるには？
はじめてちいとぽの概念を知ったのは、State of DevOps Report 2021でした。4 key metricsやHigh / Lowパフォーマーの分類は知っていたのですが、じゃあHighに近づくにはどうする？に悩んでいたときに、レポートを読んで「あ、これ参考になるかも！？」と思ったのでした。
- クラウドの利用や自動化を導入するだけでは、DevOpsの成熟度Highにはなれない
- チームのアイデンティティと明確なコミュニケーションの枠組みが重要
- これらのモデル（※：チームトポロジー）をうまく組み込んでいる組織ほどDevOpsの成熟度がHighになっている
State of DevOps Report 2021を日本語で解説 ーTeam Topologies Model、プラットフォームが重要な要素ー | TC3株式会社
ちいとぽの理解：ちいとぽから感じたことや、活かせそうなこと
ちいとぽは、現状を表すモデリングツール
ちいとぽのモデルは、最初から何か課題を解決しよう・パターンに当てはめようとするのではなく、まずは現状をモデル化するためのツールなのかな、というのを感じました。ちょうど、UMLのような感じ。UMLも、最初から何かを当てはめようとして使うものじゃないですしね。
「速いフローを実現する」に向かって、判断する
現状をモデリングした後は、必要ならばよりよい改善の方向を考えることになります。その際、認知負荷だったり、チームタイプ・インタラクションモードなどの単語にとらわれ過ぎると、何を軸に判断していいかが迷うことに。
そういうときは、まず実現したいこと「速いフロー」に立ち戻ると話がぶれにくいなというのを、いろんな人とディスカッションしてて感じました。極端な話、十分に速いフローが実現できているなら、チームを分けたりも不要ですしね。
（まあ、通常は人数が増えたり、認知負荷が大きくなったりすると速いフローを妨げることになるので、その辺を紐解いていくことになるでしょうが）
LeSSとちいとぽのかみ合わせ
複数チームの連携といえば、LeSSもありますよね。今の現場では、LeSSの枠組みも取り入れようとしてますが、LeSSとちいとぽは思想がちょっと違うのかなと感じました。
- LeSS：プロダクト全体思考で、プロダクト全体の全体最適からの優先順位・柔軟性を最大にするようにし、よってたかって対応できるようにする
- ちいとぽ：個々のチームのフローを効率化にする、そのために複数のチームが必要ならばチーム・人を増やす（↓の図が典型的）
どちらかしか使えないというわけではなく、併用はもちろんできます。ストリームアラインドチームは複数チームでLeSSを構成しつつ、共通インフラをプラットフォームチームに切り出してLeSSチームをインタラクションする、など。
ただ個人的には、まずはLeSSの思想でなんとかできないかを押さえておきたいなーとも思いました。ちいとぽは「大きいものを、大きいまま効率的に扱えるようにしよう」と見えるのですが、その前に「大きいものは、本当に必要なドメインにのみ注力して小さくしよう」が必要だと思ってます。LeSS（スクラム）のように、プロダクトバックログで優先順位を考えて必要なものに絞りつつ、それでも最大限の成果を発揮できることに頭を使いたいかなー。
イネイブリングチームで、チームに新しいスキルの習得を加速
今までは、新しい技術を導入する際は、チーム自身でその能力を獲得してほしいと思って動いてました。ただ、現実的には認知負荷などの問題で、ストリームの業務をこなしながら新しいことを学ぶのは難しいこともありそうだなと感じていました。
そういうときに、イネイブリングチームでストリームアラインドチームの外から技術支援するのは、一つの手としてありそう。例えば、以前自動テストの環境を導入したときは、今思い返すとイネイブリングチーム的な動きをしてたのかなーとも言えますし。
また、現在はその延長線上として、今までの自動テストをよりよい形で見直していこうという動きがストリームアラインドチームから出てきています。そのこと自体はすごくいいことなのですが、チームの中だけだとなかなかうまく進められていない。そこで、ちょっとチーム外から有識者がイネイブリングチーム的に支援することによって、チームのフローが加速するのであれば、よさそうかなと感じてます。
ちいとぽを深める：他の実践者とのディスカッション
書籍を読めば各用語の知識は分かるけど、どう実践するかがいまいちつかめない。ということで、各実践者とディスカッションしながら、理解や活用イメージを深めていきました。
Chatwork with daiksy さん
Scrum@Scaleを推し進めているchatworkさん。Scrum@Scaleの各チーム間の目的やインタラクションの設計に、ちいとぽが相性いいらしいと教えてもらった。ほーなるほど。
Retty with TSUNEMATSU さん
稲野さんがチームトポロジーを用いたRettyプロダクト開発体制の解説 #ちいとぽ - Retty Tech Blogを肴にディスカッションするという場に、誘ってもらいました。
「ちいとぽは、モデリングツール」は、このディスカッション中で出た話題。
その他、「逆コンウェイの法則はあるけど、組織図を先に変え過ぎると失敗したときに大変。なので、非公式に変えてみてよさそうなら組織図に反映させるのがよさそう」みたいな話題も。
atama plus with かわきん さん
またまた稲野さんに、atama plusにおけるチームトポロジーとは？（読書会の感想＆考察）｜かわきん（ちゃんかわ）/atama plus スクラムマスター｜noteを肴にディスカッションする場を設定してもらいました。
『LeSSのようにあえて分業しない方法』と『チームトポロジーによる分業の方法』
は、薄々感じてたことを、いい感じに言語化してもらって「それだ！」となりました。
その他、「精神と時の部屋があれば、中長期的にScrum / LeSSでやっていけるけど、現実時間として難しいこともある。その場合に、もう少し現実的に分業などをやりやすくするための一つの方法がちいとぽ」などなど。
Timee @ちいとぽStudy
つい先日開催された、ちいとぽStudyでの事例。節理面をどう切るかが参考になりました。Phase3のようにステークホルダーで切るのは自分も考えてたけど、Phase4のように業務で切るのはなるほど。自分の現場にも当てはめて考えてみたい。
