blog.foresta.meこんにちは、 @kz_morita です。
今回は、 チームトポロジー という本を読んだので感想などを書いていきます。
書籍について
以下のような目次になっています。
PART I デリバリーの手段としてのチーム
Chapter1 組織図の問題
Chapter2 コンウェイの法則が重要な理由
Chapter3 チームファースト思考
PART Ⅱ フローを機能させるチームトポロジー
Chapter4 静的なチームトポロジーチームのアンチパターン
Chapter5 4つの基本的なチームタイプ
Chapter6 チームファーストな境界を決める
PART Ⅲ イノベーションと高速なデリバリーのため にチームインタラクションを進化させる
Chapter7 チームインタラクションモード
Chapter8 組織的センシングでチーム構造を進化させる
Chapter9 まとめ:次世代デジタル運用モデル
感想など
もともと、Platform Engineering まわりに興味がありその文脈で読み始めました。 書籍では、チームの種別やそのチーム間のインタラクションの種類について紹介されています。
チームの種別
- ストリームアラインドチーム
- プラットフォームチーム
- イネイブリングチーム
- コンプリケイテッド・サブシステムチーム
チーム間のインタラクションモード
- コラボレーションモード
- X-as-a-Service
- ファシリテーションモード
この書籍で初めてチームやその間のインタラクションの名前を知ったのですが、名前があるおかげでチームや組織内でどこを目指していくのかといった意識の統一ができるようになしろうで、とても良いなと感じました。
私は現在データ基盤を開発するチームでデータエンジニアをしていて、他のエンジニアにとって活用できるプラットフォームを作成することがミッションだと思っています。 プラットフォームとして X-as-a-Service として提供する際に重要になりそうな知見がたくさんありました。
特に学びになった部分を以下のような点です。
- 実際の活用できるプラットフォームにするために、実際の運用フローを正確に捉える
- 初期はコラボレーションモードでストリームアラインドチームと関わり解像度をあげる
- ストリームアラインドチームとプラットフォーム間の境界が重要
- DDD のコンテキストマップが活用できる
- 提供する最低限のプラットフォーム (TVP) を特定することが必要
- Wiki や簡単なツールなどかもしれない
- X-as-a-Service ではコミュニケーションは限定的にするべき
- 提供されたプラットフォームを使用するためにコミュニケーションコストを減らす
- そのために、ドキュメントの充実は必須
上記のような点について、特にデータエンジニアの文脈だと、データ自体もプロダクトとして使いやすい形で提供するというのと合わせてどう言ったプラットフォームが良いのか考えていく必要がありそうです。
ドキュメントでいうと、Diátaxis というフレームワークが良さそうで Service として提供するのであればこのレベルのドキュメントは必要だなと感じています。
下記はドキュメント観点で参考になった記事です。
まとめ
今回は、チームトポロジーを読んでその感想や学びをまとめました。
とくに基盤側の開発に携わっているエンジニアは読むと多くの知見が得られるかと思います。 良い基盤を作って組織の生産性をあげるためにどうしたら良いかという知見が詰まった良い本だなと思いました。