
DevOpsDays ビデオ鑑賞会 #7
Agile Developer Communityでの海外のDevOpsDays動画視聴の感想です。
今回の動画
今回も、前回に引き続きDevOpsDays London 2024 から。
Team Topologies の著者の1人、Matthew Skeltonさんの DevOps Topologies 10 years on: what have we learned about silos, collaboration, and flow? です。 以下スライドのページに動画リンクもついてます。
2013に書かれた DevOps Toplogies と 2019のTeam Topologies の対比、そしてそれを踏まえたチームのあり方をお話しされる講演でした。
DevOps Topologies と Team Topologies
DevOps Topologiesの解説記事はこちら、Matthew さんの投稿を編集したものとあります。記事先頭に、本へのリンクもついています。
DevOpsを始めるときにどんな体制で始めるか? と言ったときに置きがちなアンチパターンと、あるべき形を整理しています。アンチパターンには以下の例が。
Devと、Opsと、DevOps に分かれたサイロ化チーム (アンチパターンB)
シスアドの看板を付け替えただけのチーム (アンチパターンE)
OpsをSREと呼び換えた、偽SREチーム (アンチパターンH)
あー、なんかあるあるという感じ。
これらを、Team Topologies での考えを含めて「こうありたいね」というのを解説されていました。
Team Topologies の考え方が並んで、より具体的にイメージしやすくなった感じ。6年の思考を感じますね。
Team Topologies へのリンクも前述 DevOps Topologies のページにありますが、パッとわかるところでクイックリファレンス公開いただいてる記事をここではつけます。
ただ、以下の注意書きとともにこのシリーズの説明は終わります。Team Topologies はその時々の一時的な状態であり、恒久的なものではない。
「確かに、これを組織でじっくりやると形骸化していきそう」というのは会の中でも話題に上りました。Enabling Teamも、期限付きであって取り込まれてしまってはその効果は持てない。
Team Topologie diagrams are always just "snapshots in time", never fixed designs.
Team Topologies って AWSのドキュメントでも、Azureのドキュメントでも言及されているんですね。講演内で紹介されていました。
Success Factors
講演の後半では、6つの Success Factors をあげていました。
0) Address the dynamic interections between teams and groups, not just static structure.
1) Organizing faster flow helps us to remove inter-team dependencies, improving financial efficiency and time-to-value.
2) Evolving at speed requires a set of core principles and practices, with people trained up and engaged.
3) Decouple, not coordinate.
4) Multiple, loosely-coupled flow of value, with significant automation & helper tooling, aware team cognitive load.
5) Fast flow organizations need active knowledge diffusion across flow boundaries to create trust, allignment, and learning.
以下に、ざっくり和訳した言葉を。
0) 静的構造だけでなく、チームやグループ間の動的相互作用に働きかける。
1) 迅速なフローの整理は、チーム間の依存関係を排除し、財務効率と価値実現までの時間を改善できる。
2) 速いスピードで進化するには、人材の育成と参加を伴う、一連の核となる原則とプラクティスが必要である。
3) 調整するのではなく、分離する。
4) チームの認知負荷を考慮しつつ、大規模な自動化とサポートツールを備えた、複数の疎結合された価値のフロー。
5) 高速なフローを持つ組織では、信頼、方向性の一致、学習を生み出すために、境界を越えた活発な知識の普及が必要。
スピード感のある組織にする、疎結合にしてチーム間の待ちをなくすなどのこれらの関係性の考えの繋がりを説明した内容でした。
最後の項目は「生成AIが取り組んでくれる?組織の知識共有は以前として必要だ!」ということを主張されていました。詳しくはまた別の場で話すとのことで。
次回
次回も、DevOps Days London 2024から。London 続きます。
「AI, You complete me」
生成AI x DevOpsのコンサルタント、Patrick Debois さんの講演です。