Team Topologies / Matthew Skelton, Manuel Pais
いろいろ寄り道して調べていたので読み終わりに時間がかかった。
逆コンウェイの法則についてもっと深いものはないかと調べていて見つけたもの。とてもよかった。
チームの設計とチーム同士のインタラクションの設計について、パターンやアンチパターン、ケーススタディを使いながら解説したものです。
結局コンウェイの法則を無視していいアーキテクチャは作れない
マイクロサービスアーキテクチャのサービス分割段階で分割検討チームのメンバーの関係性がそのまま分割案になると言う話を別途記事にまとめました。
今度はこれを実装するときのチームをやっぱりきちんと設計しないと、せっかく綺麗に設計しても出来上がりは小さなモノリスの集合体になります。
この本は開発チーム、プラットフォームチームや運用チームなどの開発からリリースに至るまでのチームの設計が最終的にアーキテクチャに反映されてしまうので、その設計をどうしたら良いかを考察してまとめた本です。
一言でいうと逆コンウェイの法則を実践するときの考え方がまとまった本です。
元々はDevOps Topologiesというコンテンツだったようですが、チーム設計の問題はDevOpsだけではないよねと言うことで範囲を拡張して書き直したもののようです。
DevOps TopologiesはDevとOpsの関係性を具体的に説明したものとしてとてもわかりやすい。これも咀嚼できたら記事を書こう。
分割したらそのまま実装すればいいのに！と言うのは簡単
最初はなぜ設計は綺麗だったのになんでこんなにモノリスなんだろう？と思っていろいろ調べて見てたんですが、結局のところ実装段階で考慮できていなかった細々した話が出てきたときに、チーム間の力関係や物を言えない雰囲気などで、それに気がついた方が自分たちのドメインやサービスに実装してしまい、結果としてあちらこちらがドメインの枠を超えたものを実装し始めて小さなモノリスの集合体になってしまうのではないかと思います。
例えばこれはワークショップの題材の話です。
とあるサービスの利用後に決済をするとします。いろいろ検討した結果分割案とインテグレーションの案を作成しました。
シミュレーションをしてみたときに、外部の決済システムの障害などなんらかの理由で決済ができないと、決済完了まで部屋に閉じ込められる仕組みになってしまっていました。
こういう特定のシナリオをシミュレーションしてみたときに「あれ？」となることはやはり往々にしてあります。しかも大きなもの細かいものたくさん出てきます。実装に入ってもそうです。
出てきたものをきちんとドメイン/サービスの分割思想に立ち戻って綺麗に分けなおすことができるかどうかが、設計段階のアーキテクチャを維持できるかどうかの大きなポイントになります。
綺麗なアーキテクチャを設計するのは難しく、アーキテクチャを維持することはもっと難しいです。
別記事でよくアジャイル開発を大規模でやる場合に教科書的に出てくるSpotifyモデルを読んだ話を書きました。上級者向けだと思ったのは、疑問が起こったときにアーキテクチャの維持を考えて適切な判断ができるための関係性、メンバーの知見と意識、組織構造があって初めてSpotifyモデルで効率的な開発を実現できるんです。そこを無視して組織構造だけ真似してもうまくいきません。
4種類のチーム
Stream-Aligned Team
これがいわゆる開発チームです。なんらかの価値を利用者に対して届けるためのチームです。ストリームはバリューストリーム (Value Stream) です。
Stream-Alignedチームは価値のデリバリまでを役割として担います。したがってチームに必要なのは開発してテストしてリリースしてという全ての役割です。テストとリリースについては自動化されている前提で、パイプラインを使ってリリースまでたどり着くことを責務として持っています。
Enabling Team
Stream-Alignedチームは日々の開発からリリースに責任を持っている一方で、新しい技術にキャッチアップしないとテクノロジーの進化についていけませんし、新しいものを生み出し続けるためには新しいものの考え方を取り入れなければいけません。
Enablingチームはそこを支援するためのチームです。
例えばアジャイルコーチチームなどはこのEnablingチームにあたります。
Complicated-Subsystem Team
例えば顔認証など、Stream-Alignedチームが機能として欲しいが、技術が高度で自分たちで作ったり内容を把握することは難しいが、他のチームの作ったものや外のソリューションなどを利用して実現したいと思うことがあると思います。
この場合ソリューションの提供元はComplicated-Subsystemチームです。
いわゆるコンポーネントチームに見えますが、Complicated-Subsystemチームは特定の領域に特化した高い技術を使うときにのみ作ります。
Platform Team
これは例えばコンテナ基盤やネットワーク、既存のAPIなど、Stream-Alignedチームがプラットフォームとして使うものを提供するチームです。
あくまで開発したものを本番環境にパイプラインを使ってデプロイする責務はStream-Alignedチームにありますが、デプロイするためにプラットフォームをきちんと使えるように支援する責務がPlatformチームにあります。
大切なのはStream-Alignedチームの認知負荷をどうやったら下げられるか
最終的に本を通じて議論されているのは、どうやったらStream-Alignedチームの認知負荷 (Cognitive Load) を下げられるかということです。
人の脳の仕組みをコンピュータに例えたときに、メモリ (ワーキングメモリ) にかかる負荷のことです。
何かを学ぼうとするときに人の脳のワーキングメモリは容量が小さく、これをオーバーしないように教える側は教えるスピードを調整する必要があります。
詳細な説明はこちらの英語が詳しいです。
全ての領域が新しいと一つ覚えたらひとつ忘れるので、Stream-Alignedチームが適切なことができるよう、Stream-Alignedチームが効率的に適切なことができるような学習ができるようなチーム構成にする必要があります。
7章のインタラクションモデルを考慮に入れ、Stream-Alignedチームとその他のチームがどのように関わっているかを観測することで現在のStream-Alignedチームの負荷を把握することができそう。
個人的仮説: もうチームの設計はヘキサゴナルアーキテクチャでいいんじゃないか
Stream-Alignedチームをドメインモデルやドメインロジックとしたときに、チームの設計はヘキサゴナルアーキテクチャを意識して作ったらいいんじゃないか。外とのインタラクションはアダプター (EnablingチームとかPlatformチームとか) が担当し、チームの文脈に翻訳してからチーム (ドメインモデル) に渡す。
図はImplementing Domain-Driven Designより。日本語版は実践ドメイン駆動設計。
まとめ: 逆コンウェイの法則をちゃんとやるには一読を
とてもいい本でした！
組織構造からくるアーキテクチャの制約が最終的にどのような結果になるかなどのアンチパターンも多く盛り込まれていて、とてもわかりやすい本でした。今まで謎だったアーキテクチャーパターンの謎が解けました。
コンウェイの法則をどうにかしたい、チームの設計をきちんとしたいという場合にとても頼りになる本なので、英語が読めればぜひ。
この記事が気に入ったらサポートをしてみませんか？