Re: 19: Team Topologies Vol.Ⅱ - Middle Aged Developers #madevs

• Team API
  • うちの会社も似たような仕組みがある。ある程度の規模を超えるとそうせざるを得ないのだろうなあ。
    • チームごとにリポジトリがあって、README.md にチームの責務は何か・誰がメンバーか・どうやって連絡すれば良いか（Slack チャンネルはこれ、とか）。主にエンジニアだが、その他の職種でも幅広く同じコンセプトが採用されている。厳格に決まったテンプレートに沿っている感じではなくて、細かいところはチームごとに違っている。
    • チームのリポジトリは組織に注目した分類だが、システム・サービスに注目した分類もある。Service Catalog という社内ウェブサイトがあり、サービスコンポーネントごとに検索できるようになっている（Actions みたいな大きな括りから、actions-runner みたいな小さい括りまで色々）。どのチームが担当か、チームの SLO の状態、バグやエスカレーションの報告方法などがまとまっている。こちらはカチッと決まったテンプレートがあり（というかそもそも自由記述方式ではない）、エスカレーションのイシューを作成する際も統一的なフォーマットのテンプレートを使う決まりになっている。
• Squad とチームの関係性
  • Spotify モデルって事業部制組織の側面が強いマトリックス組織だと理解してる。ので、レポートラインも Squad - Tribe のラインが主なんじゃないかなあ。なのでありがちな「バックエンドが専門のエンジニアリングマネージャーがモバイルエンジニアの技量を正しく評価できるのか問題」が常にあり、なので Chapter という「横のつながり」「斜めのつながり」を作って、同じ専門性を持つ人からの評価をブレンドしてバランスを保つ、という組織デザインなんじゃないかな。
  • ただここで念頭に置くべきと思っているのは、彼ら（西洋の会社）はおそらく日本の一般的な会社の感覚よりはるかに「結果にコミット」なカルチャーなんじゃないかなあ、ということで、事業部制組織に所属する以上は事業目標（OKR であれなんであれ）達成の重要度、ウェイトがずっと大きいんじゃないかなあ、ということ。事業の数字を達成できたかどうかで評価されるので、評価者は個々人の細かいスキルの優劣に敏感でなくてもいいし、被評価者もそこはアピールするポイントじゃないと理解している、という前提があるのではという気がする。
• 「今回は話を広げられなかった〜」
  • こう言っちゃなんだが、聞いてる限りでは準備の出来よりもリスナーとしてその話題に関心を持てるかどうか、のほうが、聞いてて楽しめるかどうかに対して支配的だなあ・・
  • Team Topologies の話は食いつきやすいテーマなので、準備不足とか特に感じずに聞けた。「Spotify model とはどういうものか」みたいな議論の土台になる部分はある程度リサーチして共通理解を作ってあると議論がより噛み合うのではという気はした。
• その他感想
  • 本を読んで語り合うエピソードの感想・コメントを書くときは自分も読んだうえで何か言うのが筋のような気がするけど実際には読まないので、なんか若干の気まずさと後ろめたさ・後ろ髪引かれる思いがある。本読むのもっと速ければなあ・・