天の月

ソフトウェア開発をしていく上での悩み, 考えたこと, 学びを書いてきます(たまに関係ない雑記も)

チームトポロジーを成功させる実践方法の探求 - Team Topologies Studyに参加してきた

forkwell.connpass.com

www.youtube.com

こちらのイベントに参加してきたので、会の様子と感想を書いていきます。

会の概要

以下、connpassのイベントページから引用です。

スタートアップを始めとするエンジニアリング組織では、より早く顧客に価値を届けるために「アジャイル開発」「DevOps」などの思想・手法が取り入れられてきました。しかし、いざ取り組んでみても上手くいかなかった経験をお持ちの方も多いのではないでしょうか。そのヒントはコンウェイの法則にあります。

システムを設計する組織は... その組織のコミュニケーション構造をコピーした構造の設計を生み出すことになる

2021年12月に発刊された「チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計」では、「チーム構造と組織構造を進化させて、望ましいアーキテクチャを実現する」という逆コンウェイ戦略を実現するための方法が紹介されています。

今回 Forkwell は「チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計」の共訳者であり複数企業のアジャイルコーチを務められる吉羽龍太郎(@ryuzee)氏をお招きし、「チームトポロジー」を実践するスタートアップ企業の1つ、タイミー社 CTO 亀田彗(@kameike)氏と共に、以下のような疑問に答えられる勉強会を開催いたします。

会の様子

基調講演「30分で分かった気になるチームトポロジー 」~ryuzeeさん~

まずはryuzeeさんから基調講演がありました。
30分でチームトポロジーを説明するということで、4つのチームタイプや3つのインタラクションモードの説明を中心に展開していくのかと思っていたのですが、最初に昨今の状況から考えるフローの概念の重要性から話を展開し、なんでチームトポロジーのような概念が重要なのか?という話や、チーム同士のコミュニケーションを過剰に重視する結果生まれる問題の話などを聴くことができ、本の流れがすっと整理されて頭に入ってきました。

個人的には、以下の一言が講演を通してもっとも刺さりました。

ハイパフォーマンスなチームを解散するのは、単なる破壊行為では済まない。企業レベルのサイコパスと呼ぶべきものだ

本当に30分でわかった"気になってしまう"基調講演でした。

事例講演「組織をチームトポロジーで振り返ると、よりよい未来が見えてくる」~kameikeさん~

続いて、kameikeさんからチームトポロジーの実践事例の話を聴いていきました。

チームトポロジーは内容が抽象的だからこそ、実践事例を聴いて面白くなるような本だと思うので、実際に300人規模の会社でどのように運用されているのかを聴くことは学びになりました。
特に、チームトポロジーの観点から、アンチパターンを踏んでいたというふりかえりをしたり、チームトポロジーを意識したことでどのように組織が変わったかを聴くことができた部分は面白かったです。

また、実際に起きた問題をはじめとして、かなりリアルな組織の話をされていたので、

「チームトポロジーを共通言語として用いる」という取り組みは非常に面白かったですし、リアルな実例の話が聴けたからこそ学びも多かったです。

視聴者Q&A / パネルトーク「チームトポロジーを成功させる実践方法の探求」~ryuzeeさん×kameikeさん~

最後にお二人のパネルトークを聴いていきました。
質問が膨大に来ていて、皆さんの関心の強さが伺えました。

どの質問も非常に面白かったのですが、ストリームアラインドチーム以外のチームを組成するタイミングはどのように見極めるのか?という部分について、お二人から意見が聴けたのが一番面白かったです*1

その他にも、機能を捨てるための議論の進め方など、学びが多い時間でした。
お二人の回答がめちゃくちゃ分かりやすかったし納得感があって震えました。

全体を通した感想

普段こうしたコミュニティのイベントでお話を聴ける機会が少ない印象のお二人だったので、今回そのお二人の話が聴けたのは非常に貴重な機会で、楽しかったです。

チームトポロジー、改めて議論向きな本だなーと感じました!

*1:ryuzeeさんは、今までのスピードが出なくなったタイミングや今までができなくなっているが考えるタイミングだということで、まずはプラットフォームが最初にできやすいのではないかという意見でした。kameikeさんは、認知負荷をベースに考えていくということで、本に書いていないような節合面であっても何かしらチームを切ることでどこかの認知負荷を下げ、何かしらのブレイクスルーは起きるので、やってみてフィードバックを基にして変化を起こしての繰り返しをするということでした。