00:04
5月19日、金曜日ですね。
遅刻早速10分になりました。
今日はまた雨が降るらしくて、東京はですけどね。
気温もちょっとだけ下がるっぽいですね。
はーい、おはようございまーす。
眠いのきーつことくんおはらです。
ではでは、本日も朝から始めていきたいと思います。
で、本日はですけども、
今日は記事のタイトルだなって、
ある勉強会のスライドのお話ですね。
30分で分かった気になるチームトポロジーっていうスライドですけども、
ずっとトゥートに残ってて、
社内でも1回何か展開されてるのを見てですね、
とても良かったよっていうお話を聞いたのと、
僕自身がチームトポロジーを、
なんだかんだふわっとしか理解できてなかったり、
そもそもあんまり理解できてなかった気がするので、
そのチームトポロジーを理解するっていう意味も含めて、
今日読んでいこうかなと思っております。
ではでは、早速書いていきましょう。
そもそもスライドですので、
記事じゃないので、途中途中僕の勝手な解釈が入るかもしれないですけど、
申し訳ないが、言っていきたいと思います。
はい、本スライドですね。
2022年3月16日ですね。
株式会社アトラクタの吉場龍太郎さんですかね。
あの、龍成さんですね。
っていう方が作られたスライドですと。
この方はアトラクタっていう会社の取締役CTOで、
アジャイルコーチもしてますと。
スクラムアライアンスとかもやられていて、
認定スクラムマスターのリージョナルですね。
CST-Rと。
あとは認定チームコーチでCTCってのもやられているということで、
すごいですね。
チーム周りのところはもうプロだという感じの人だと思います。
あとはたくさんの著書がありまして、
本当有名な書籍たくさんあるんで、
その辺も見てみてくださいというところですね。
で、今日の話チームトポロジーですけど、
2021年12月1日、
日本農立協会マネジメントセンターが観光した書籍になりますと。
マシュースケルトンやマニュエルパイスさんという方が
著者の方ですね。
本が教書の本ですね、これは。
あと原田さんと長瀬美穂さんと吉場龍太郎さんが
訳されていると。
で、担当編集は山地さんという方だそうです。
Kindle版もあるし、まだお持ちのない方はぜひお買い求めくださいと。
本スライドを掲載の図表は本書より引用しています。
ちょっと入りますと、
2022年の記事なのであれですけど、
今の世の中ということで、
技術とか人、ビジネスにおける変化の速度が
ますます早くなりました。
プロダクトの大規模化が進み、
モバイルとかクラウド、IoTなどの様々な技術の組み合わせが
必要にもなりましたと。
それに伴って、システムの構築や運用に多くの人が
必要になりました。
なおで、従来の組織構造や仕事のやり方というのは
この状況に対応できるようになっていません。
企業が存続されるためには、
価値を素早く生み出して、
顧客に届け続けなければいけませんと。
あと4つのキーメトリクスと、
LeanとDevOpsの関係ですね。
アクセラレイツのところですけど、
デリバリのリードタイムというのが1つ。
2つ目、デプロイの頻度。
3つ目にサービス復旧の所要時間、MTTRですね。
ラスト、変更失敗率というところですね。
はい、4つが語られています。
4つのキーメトリクスというやつですね。
つまり、何が言いたいかというと、
顧客に素早く頻繁に、
安定的に価値を届けるということですね。
問題があれば素早く復旧すると。
つまり、安定した早いフローを
03:00
というのをとにかく重視しましょうということですね。
早いフローを阻害する主な要因というのは
何があるかというところですけど、
いっぱいわかりますが、
コンフェの法則を無視したりとか、
間違った組織設計による混乱があったとか、
数年ごとの苦痛な組織再編があったりだとか、
チームが引っ張りだこだったり、
チームにとって大きすぎるソフトウェアだったり、
不足の事態の多発だったり、
モチベーションの低いチームだったり、
ボトルネックだったりなどなどという感じですね。
じゃあ、チームトポロジーとはそこから何でしょうか?
という話に入るんですけど、
フローを実現するためのものです。
適応型の組織設計モデルだったり、
普遍的な公式ではなくパターンであります。
チームの目的と責任を明確にし、
チーム間の相互の関係、
もしくはその効果というものの向上を目指す。
技術、人、ビジネスの変化に
継続的に対処できるようにする。
構造は静的なものではなく、
状況に応じて変化させていきましょう。
で、フローを実現の上でチームトポロジーが
中心に据えたものはいっぱいあるんですけど、
大きく7個ですね。
コンウェイの法則、チームファースト、
チームAPI、4つのチームタイプ、
3つのインタラクションモード、
組織的センシング、
そしてトポロジー進化というのが
チームトポロジーの中心に据えたものだそうです。
1つ目コンウェイの法則ですね。
メルヴィン・コンウェイという方が
1968年に語った言葉ですね。
システムを設計する組織というのは、
そのコミュニケーション構造を
そっくり生まれた構造の設計を
生み出してしまうというものですね。
もう皆さんすごくご存知だと思いますし、
有名なものです。
で、コンウェイの方、もうちょっといきますと、
組織設計というのはソリューション探索空間の
制約になりうるソフトウェア設計を
限定します。つまり、従来型
職能別組織では、
多くのコミュニケーションが
必要な複雑なシステムが
出来上がってしまうと。ルース・マランが
言った、システムのアーキテクチャと
組織のアーキテクチャが対立する場合、
組織のアーキテクチャが勝つよというのもあります。
これは本当、その通りだなと思って、
今弊社がまさに職能別の
組織になっているんですけど、
確かに多くのコミュニケーションが
ハッタハップしてますし、組織全体として
複雑なシステムだなと言われたら確かにそうだな
という気もします。では戻りまして、
コンウェイの法則による
組織構造とアーキテクチャの例というところですね。
ちょっとこれ図が示されているので、
音読だと分かりづらいかもしれないですけど、
例えばフロントエンド開発のところで
チームABCDって4つチームがあったとしましょう。
それに基づいするバックエンド開発の
チームABCDももちろんあります。
チームっていうか案件って思ってもいいかもしれないですね。
それぞれがDBAと言って、
コアのデータベースがあって、
最後にユーザー向けの運用に行くという感じですね。
こういうコンウェイの法則があるんですけど、
アーキテクチャのところも一緒ですね。
アプリケーションが1,2,3,4と4つあって、
UIがあって、アプリケーション層があって、
コアDBがあって、運用があると。
似たようなアーキテクチャの構造になりますよね。
じゃあ逆コンウェイ戦略というところで
次行きたいと思いますけど、
コンウェイの法則を踏まえて、
それを戦略的に活用した組織設計を目指すと。
組織があってそのまま設計に移っちゃうというところですけど、
それを逆転してしまうという感じですね。
組織はチーム構造と組織構造を進化させて
望ましいアーキテクチャを実現すべきと。
素早く価値を届けることを前提として
06:00
組織を設計する。
人的資源の効率的な活用よりも
価値の効果的なデリバリーという方を
優先する。
人資源の効率性よりも価値の効果的な
デリバリーを優先。これが逆コンウェイ戦略です。
さっきの図の話ですね。
逆コンウェイ戦略によるアーキテクチャから
組織構造の例というところですけど、
さっきはフロントエンド開発とか
チーム開発みたいな話をしていましたけど、
組織とかプロダクトではなくて、
今回はマイクロサービスABCDという風に
分けられていますね。
マイクロサービスだとクライアントが冒頭に
来て、その先にAPIがあって
データストアがあるみたいな感じですね。
チームにおいても同じような感じですね。
チームABCDだった場合、
それぞれのチームでアプリケーション開発があって、
API開発があって、データベース開発があって、
最後にマイクロサービスにたどり着くという
ところですね。ということはやっぱり
組織とかチームっていうのの区切り方でいうか
まとめ方っていうのが変わってくるよね
って話ですね。続いて
チームファーストの話です。
組織図やマトリックスに依存した
組織構造では素早いデリバリーや
イノベーションっていうのは不可能です。
権限とスキルを持つチームこそがアジェリティの
土台となります。つまりチームを
基本的な構成用として要素として扱いましょう。
続いて成果って何でしょうか
って話ですけど、顧客に
素早く継続的に価値を
届けること。これを組織全体で目指す
必要がある。たくさん作るって
ビルドトラップだと。不確実性の高い
世の中だからこそ良いチームっていうのが
必要です。確かに組織の最小単位
っていうのはチームになりますからね。
よくある落とし穴としてチーム間の
情報共有を増やそうとか、チーム間の
連携やコミュニケーションを活発にしよう
っていうものがあります。
これ自身が悪いわけではないけど
これは必ずしも良いとも限らないっていう話ですね。
コミュニケーションの
複雑性を抑えるというところで
1チームは10人程度までが適正。
2ピザチームみたいな
確かルールもありましたよね。
うちでは確か7名までって言ってますけど。
人数が増えるとコミュニケーションのオーバーヘッドが増えますよと。
段バー数ってのもあって
5人までとか15人までとかってありますけど。
あとチーム同士のコミュニケーションも
対象のチームが増えると複雑になり
動きがどんどん遅くなりますと。
プロジェクトの規模を小さくする必要がありますし
チーム間を疎結後にする必要もありますと。
チームで
お互いに相互に
やり合わなきゃいけない。ちょっと依存度が高い
チームだとそうなりがちなのでちゃんと
実装できるチームってのも結構重要かもしれないですね。
例えば3人の人がいたら
1000は3本ですよね。
4人の人がいたら1000は6本になっちゃいますと。
これよりコミュニケーションのパスの可能性ですよね。
5人の人がいたら
1000は10本に増えちゃいます。
6人いると1000は15本と。
言ってみますと
限界10人程度までって言ってますけど
10人いると1000は45本に増えるというので
すごいことですよね。
それだけ意思決定が遅くなるって話です。
ジェフ・ベゾスが言っている
The API mandateってやつですね。
ものがありますが
全てのチームは今後サービスインターフェースを通じて
データや機能を公開すると。
各チームはこれらのインターフェースを通じて
相互に通信しなければいけません。
他の形式のプロセス間通信は一切認めません。
ダイレクトリンクだったり
他のチームのデータストアの直接
読み込みだったり
09:00
共有メモリーのモデルだったり
バックドアなどは一切認めません。
唯一許される通信はネットワークを介した
サービスインターフェース
コールによるものとします。
どのサービスインターフェースを使用するかは問いません。
HTTPとかコールバだったり
PubSubだったりカスタムプロトコルなど
なんでも構わない。
全てのサービスインターフェースは例外なく
外部化可能なように
一から設計しなければいけない。
つまりチームは外部の開発者に
インターフェースを公開できるように
計画設計しなければいけません。
これに例外はありません。
これに従わない人は解雇します。
APIマンデイトという
Amazonのルールですね。
Amazonのチーム構造の例ですが
1チーム12程度までの
サイズで構成されています。
複数チームを兼任することはありません。
1つのチームが1つのプロダクト
もしくは機能群の塊を担当します。
例えば
EC2WindowチームとかEC2Linuxチーム
などなどという感じですね。
各チームは独立して開発した
機能群をリリース可能です。
多いときでAmazon全体で1時間に1万デプロイすることもある。
えぐいね。
1時間に1万デプロイはえぐいですね。
それだけ人とチームが多いんでしょうね。
チーム間の
人的コミュニケーションは原則として極力減らします。
結局それが遅くなる原因だからですね。
AWSの各サービスも
内部的にAWSを利用するが
一般ユーザーと同じAPIを利用すると。
これは良い話ですね。
CI、CD、グローバルへの展開
監視などは共通基盤というのがあって
利用が必須になります。
開発言語や開発プロセスは
各チームに裁量があります。
結構うちの組織構造は
こういうのを真似ている気がしますね。
あと
タックマンモデルという名前が出てきました。
久しぶりに聞きました。
形成機、混乱機、統一機、機能機、解散機
という5つのパターンですね。
形成機というのは
人が集まるがまだ独立しており
コミュニケーションが少ないパターンですね。
混乱機というところは意見を言うようになるが
一方で自分と違う意見に抵抗を示すようになる
というのが混乱機です。
統一機というのは一緒に活動し
異なる意見を受け入れるようなフェーズです。
目的や期待値などが一致しているということですね。
続いて機能機。
よく機能するチームとなってくるようになる。
チームには一体感があり、自立性も高い。
最後、解散機ですね。
目的を果たしてチームを解散する時期というのがあります。
この5つの段階に分けている
タックマンモデルというものがあります。
あと機能しているチームは
長く保つというところですけど
アラン・ケリーが
プロジェクト
マイオピアという書籍で
歌っている言葉があって
ハイパフォーマンスなチームを解散するのは
単なる破壊行為では進まない。
企業レベルのサイコパスと呼ぶべきものだと。
これはでも本当そうですよね。
ハイパフォーマンスなチームを解散する理由って
よっぽどのことない限り
基本的には悪でしかないですからね。
あとはチームに仕事が流れ込むようにしましょうと。
チームを安定させて
チームに仕事が流れ込むようにする。
必要に応じてゆっくりメンバーを入れ替える。
ピボタルでは
9から12ヶ月ごとにチームは
メンバーはチームを移動していると。
9から12ヶ月ごとに
12:00
メンバーはチームを移動している。
最低1年以内にチーム移動をするということですね。
これをルールにするのは確かに
一つありかもしれないですね。
いろいろ飛び交っていくというところで。
うちはあれですね。
チームごとに案件がアサインされているので
簡単にチームを移動するっていうのが
できるかっていうとその状況だったり
お客さんとの相談になってしまいますけど
でもこれがもしできるんだったら
やっぱりチームを移動して
いいと思いますね。
チームがソフトウェアのオーナーシップを
持ちましょうと。
同一箇所について複数のチームが
オーナーシップを持つのを避けるということですね。
これは確かにそうですね。
チームが重要であり個人のニーズより
チームのニーズを優先しましょうと。
チームの認知負荷を考慮するというのは
人間が脳に留めておける情報の量には限りがあります。
同じことはチームにももちろん言えます。
それはそうだよね。
チームの責任範囲や担当範囲が広がりすぎると
コンテキストスイッチというのが
ありますし、優先順位がつけられづらくなりますし
結果としてモチベーションも低下します。
内発的動機の3要素
ダニエル・ピンクというものがありますけど
自立・熟達・目的
というのが3つの
内発的動機というところですけど
ここが低下していくということですね。
認知負荷の種類のお話が
次に続きます。
課題・内在性負荷
課題・内在性負荷
問題領域のタスクに
関連するもの、例えば研修、
適切な技術選定、雇用、ペアプロなどを通じて
負荷を下げていきましょう。
あとは課題・
外在性負荷ですね。
タスクが実施される環境に関連するものとか
自動化などによって負荷を下げるものですね。
あとは
学習関連負荷というものですけど
学習を進めたり、高性能を
実現したりする上で特別な注意が
必要なタスクに関連するものです。
ビジネスのメインもこれに含まれます。
ここになるべく時間を使えるようにしたいということですね。
認知負荷に合うように
責任範囲を制限しましょう。
チームが扱うソフトウェアのサブシステムの
サイズを制限します。
チームの認知負荷に合わせてソフトウェア境界というのも選びましょう。
チームの認知負荷とか
チームの認知できる領域とか
記憶できる領域とか
限界量というのが数値化できるのであれば
この辺結構
簡単にできたりするんですけど結構難しいところですよね。
ソフトウェアの認知負荷の
計測にはドメイン複雑度に
特に注目する。もちろんそれだけではないですけど
チームが扱うドメインの種類を
制限しましょう。まずシンプル
これは1チームで複数担当できることも
ありますけど。あとは半雑だと
これに該当する複数ドメインに
大きなチームで取り組むよりチームを分割
していきましょう。ついに複雑だと
このドメインはもう集中して
取り組む必要があるってことですよね。
シンプルであれば別に
1チームで担当できたりすることも
ありますけどね。
問題を切り分けましょうというところですかね。
あとはチームの境界を決める
設立面、いわゆるドメイン以外にも
というところですね。
ビジネスドメインのコンテキスト境界が
あったりとか、規制遵守をするとか
変更のケイデンスとか、そういう
話ですね。チームの地理的な
配置ですね。あとはリスクパフォーマンス
技術ですね。依存関係が残る
ためフローが低下する可能性が
15:01
あるための限定的な技術って話ですね。
あとユーザーペルソナ。他にも
あるかもしれないけど今パッと浮かぶのはこの辺
だという話ですね。しっかり
チームの境界を決める設立面ですね。
いろんなものがありますよね。
確かに。技術ももちろん
チームの境界になりますけど、パフォーマンスだったり
規制遵守っていうのも結構大事かもしれないですね。
続いて
3つ目。チームAPIという
お話ですけど、チームの周りを
取り囲むものをAPIとして定義します。
自分たちのコード、ドキュメント
ユーザーエクスペリエンス、仕事のやり方
などなどってところですね。っていうような
APIとしてこういうものを定義しましょうと。
あとは他のチームとのやり取りにも
APIの考え方を用いてみましょうと。
他のチームが自分たちのチームと
一緒に働くときにやり方が明確で
簡単でしょうかと。Amazonはそれの激しい
例だと言ってます。なるほどね。
やっぱ改めてAmazonの
組織構図とか組織設計の
ドキュメントとか
あればそれ読んでみたいですね。
かなり激しいというか
過激と言いますか、強い
ルールになってるっていうのはよく聞きますのでね。
ジェフ・ベゾスの思想っていうのはそこに反映されてるので
それはそれで読んでみたいですけど。で、あと
チームAPIの例ですね。他にも言いましたけど。
例としては、例えばチーム名とか
注力領域、いわゆる
ミッションのところですね。あったり
チームのタイプですね。あと
プラットフォームの一部かっていうところですね。
他のチームにサービスを提供しているか
っていうところだったり、他のチームは
私たちに対してどんなサービスレベルを期待しているか
このチームが所有し進化させている
ソフトウェアはとか。あと
バージョニングの方法ですね。やっぱ
チームって言ってもあれですね。この
話はあくまで
プロダクトを持っている会社
とか組織におけるチーム戦略の
話な気がしますので。だから
このチームはこういうソフトウェアやってますよ
っていうのが言えるわけですよね。
僕らでいうクライアントワークをしている
会社でいうとどういう案件かっていうか
どういうお客さんかっていうのがプロダクトの
代わりになるものだと思いますけど。あとは
ウィキでの検索キーワードだったり
チャットツールのチャンネルだったりとか
日時の同期ミーティングの時間だったりとか
いろんなものがありますけど
そういうのをチームAPIとして
公開しているかどうかってところですね。
続いて4つのチームタイプの話に移ります。
4つあります。
多くの組織には様々な種類のチームがあって
チームの役割を無計画に拡張して
誰も全体が分からないみたいなことが
よくありがちです。チームの種類を
4つに絞ることでこの課題に対処
していきましょう。1つは
ストリームアイランドチーム。2つ目に
プラットフォームチーム。3つ目に
イネーブリングチーム。ラスト4つ目に
コンプリケーティッドサブシステム
チームだと。
チームタイプに応じた
目的とか役割責任を担っていきましょうと。
この辺が結構
すぐに導入できたりとか
今の会社とか組織に当て込められるような
切り分け方ですかね。
1つ目にストリームアイランドチームからですけど
これはビジネスの主な変更フロー
つまりストリームに沿って配置するチームだと。
ストリームは
ビジネスやサービスのこともあれば
機能群のこともあれば特定のユーザージャーニーや
特定のペルさんの場合もありますと。
つまり組織の中では
様々なストリームが並存するということですね。
職の横断型で
18:01
他のチームを待たずにデリバリーできる
というのがポイントです。
要求探索から本番運用まで
デリバリーに代わる能力一式を持っている必要があります。
一番中心となるチームがこのタイプですと。
残りの種類のチームは
全てのストリームアイランドチームの負荷を減らすためにも
存在すると。
本当中心はこのストリームアイランドチームなんですね。
これが主となって
他のやつはもう枝派なチームになってくる
ということですね。
ストリームアイランドチームということでした。
続いてプラットフォームチームですね。
いわゆるインフラとかツール
共有サービスなどの内部サービス
プラットフォームを提供するチームです。
プラットフォームといったのは
セルフサービスAPIやツールサービス
サポートなどから構成される基盤の話です。
仕様が共生される内部プロダクトと言ってもいいでしょう。
これによって
ストリームアイランドチームというのは
詳細を知る必要がなくなり認知負荷が下がると。
プラットフォームチームは
サービスが使いやすくて信頼性が高くなるように
しましょうということですね。
他のチームが
新しい技術やスキルを身に付けるのを支援するためのチームです。
特定の技術や
製品ドメインのスペシャリストから
構成されるものです。
ツール、プラクティス、フレームワークの調査や提案
オプションの探索などを行います。
テクニカルコンサルティングチームと言ってもいいでしょう。
実作業をするのではなくて
ガイダンスの提供を行うということですね。
永続的に支援するのではなくて
短期的な支援となるのが普通です。
テクニカルコンサルティングチームと言った方が
イメージがしやすいかもしれないですね。
とはいえ、新しい技術やスキルを身に付けるのを
支援するチームというところなので
このチームのメンバー自身が
そういうのに精通しておかなければいけない
という気がするので
結果的にテックリードみたいな人たちが
集まりそうな気がしますね。
次にラスト4つ目のチームですけど
コンプリケーティッドサブシステムチーム
と言われるものです。
名前の通り複雑なサブシステムやコンポーネントを
専門とするチームです。
ほとんどのメンバーがその分野の
スペシャリストでなければ理解や変更が
難しいような領域を担当すると。
動画処理とか数理モデルとか機械学習
特殊技術特殊パッケージほげほげみたいな
ものですね。
これによってストリーマイラーのチームの認知負荷を減らします。
必要なときだけ構成する。
タスクフォースに近い感じですね。
パッと集まってパッと解散するようなチームかな。
初期の段階は
ストリーマイラーのチームとコラボレーションするが
サブシステムの境界が明確になって
安定してくれば
サブシステムに集中するようなチームだということですね。
名前通りComplicatedで複雑という
名前がついてますからね。
以上4つのチームで運用していくのはどうでしょうというのが
チームの分割の方法ということでしたね。
これはでももうちょっと咀嚼したり
自分たちの組織に落とし込めるかどうかというのを
考えていったらいいかもしれないですね。
続いて5つ目です。
3つのインタラクションモードという話です。
チーム間の関係性において
相手とコラボレーションするかサービスプロバイダーとして
相手とコラボレーションするかというのが結構判断の分かり道だよと。
全てのチームが他の全チームとやり取りするのは
避けなければいけません。
それはそうだよな。
チームがインタラクションする3つの基本的なモードというのがあります。
1つはコラボレーションで
1つはX as a Serviceだと。
21:01
1つはファシリテーションという話ですね。
これはちょっと1個ずつ
いきますけど、まずコラボレーションモード
と言われるものですが
2つのチームが探索を目的として
協力し合う。
責任境界が不明確で効率は悪いが
問題は進みます。
利点としては引き継ぎが少なくて素早いイノベーションと
探索が可能になります。
ペアワークかな。
人じゃなくてチームレベルでのペアワークという感じだと思います。
弱点としては
チーム間で責任を共有するため
責任分解点が不明確です。
チーム間でコンテキストや
詳細の共有というのは必要になり
認知負荷の増大を招く。
コラボレーション中はオーバーヘッドがあるので
生産性を落ちる。
予想できた感じですね。
制約として
1つのチームが同時にコラボレーションできるのは1チームまで。
ペアワークまで
3チームまで行くのは
NGだということです。
やるとしたら2チームまでだということです。
コラボレーションモードでした。
2つ目のモードとして
Xアザサービスモードというのがあります。
一方のチームが他方の
チームが提供するものをサービスとして
利用する関係性ということですね。
これでも先ほど読んできたチームAPI
というのが土壌として
作られているチーム組織に
適応できるモードだと思います。
利点としては責任境界が
明確なためオーナー支配も明らかです。
チーム間の詳細やコンテキストの
共有も減ることで認知負荷は全然制限されます。
弱点としては
境界やAPIのイノベーションが遅くなりがちですし
境界やAPIが
効果的でないとフロー全体に影響を及ぼす。
土壌がないと
できないということですね。
制約としては同時並行で
複数のチームとXアザサービスモードで
アクションする可能性もあります。
3つ目にファシリテーションモードと言われるものです。
一方のチームが
新しい技術を身に付けたり
学習したりするために
ファシリテーションをする。
チームがチームをファシリテーションする。
もしくは他のチームの障害を
取り除いたりする。
利点としてはメインとなる
ストリームアイランドチームの障害を
取り除きフローを増やしていきましょう。
コンポーネントやプラットフォームにおける
ギャップ整合性が取れていない能力や
機能を検出できたりもします。
弱点は経験豊富なスタッフが必要だと。
これもそうだよね。
ファシリするってことはそれだけの経験値が
あるはずですよねってことなので。
戦略としては同時並行で
複数のチームとファシリテーションモードでインタラクションする可能性も
もちろんあります。
チームトポロジーはそういう意味でいくと
チームを
醸成していって初めて
満たされる仕組みというか
フレームワークなんだなって気はしますね。
まずチームタイプの
チームタイプ別の
主なインタラクションモードという話ですけど
横軸に先ほど
分けました4つのチームですね。
ストリームアイランドチーム、イネーブリングチーム、
コンプリケティッドサブシステムチーム、プラットフォームチーム
っていうのが横軸で
縦軸にコラボレーション、Xアザサービス、
ファシリテーションモードっていうところで
3つのモードですね。
ストリームアイランドチームとコラボレーションは
典型的。ストリームアイランドチームと
Xアザサービスも典型的で
24:01
グー発的になっちゃいます。
イネーブリングチームの場合はコラボレーションは
グー発的、Xアザサービスは
空欄になっているので無いんでしょうね。
で、ファシリテーションモードでいくと
これは典型的なものになります。
で、コンプリケティッドサブシステムチーム
っていうところです。これはコラボレーションはグー発的です。
そもそもチーム自体が
グー発的に発生するものですからね。
で、Xアザサービスは典型的で
ファシリテーションは無いよと。これ多分実行する
チームだからでしょうねこれはね。
チーム構成の例が一応バッと画像で貼られているんですけど
これはさすがにオープニングチームの
ファシリテーションがあって
それを明確なものをどんどん実行していくっていうので
ファシリテーションすることはむしろないし
される方だと思いますね。
最後はプラットフォームチームも同様です。
コラボレーションはグー発的で
Xアザサービスが典型的で
ファシリテーションは無いという感じですね。
とあるチームとインタラクションするときに
一時的にモードを変えることももちろんありますけど
この一旦表に従って
チーム構成の例が一応バッと
画像で貼られているんですけど
これはさすがに音読すると難しすぎるし
画像が複雑な画像になっているので
これ皆さんも後で見てみてください。
あとは続いていきましょう。
6つ目に組織的センシング
ってお話ですね。
環境の変化を感知できなければ
やることは意味をなさないと。
本番環境のソフトウェアの動きから
学ばなければいけない。
運用中のシステムから情報を得ましょう。
つまり開発と運用の断絶は望ましくないと。
もちろんそうでしょうね。
運用ありきのシステムとか
アプリケーションなので。
そのための開発ですからね。
運用を無視した開発なんてありえない。
あとはチーム内外のコミュニケーションを
組織の感覚機関として利用しましょう。
チームのインタラクションから
情報を得てくださいということですね。
ラスト7個目ですね。
トポロジーを継続的に進化させましょう。
トポロジーは性的なものでなくて
動的なものです。
プロダクトやサービスの成長、
などに合わせて適応していきます。
チーム間の相互関係を明瞭で
動的なものにし続けましょう。
でもビッグバンで変えてはいけない。
これちゃんと赤字になってますね。
ビッグバンでやっちゃいけないとわかりました。
チームインタラクションの進化の例ですね。
こちらもちょっと画像がペッと貼られてるんですけど
密接なコラボレーションによって
素早く探索をしたり、プロダクト協会や
サービス協会が見えてくるに従って
APIを定義しながらXアザサービスに
ちょっとずつ移行していきましょう。
別の課題や探索のときにまた
コラボレーションすることも当然ありますので
このサイクルを繰り返していきましょうということですね。
わかりました。
結局自分たちのチーム、チーム間の
今の関係性とか役割、ミッション、スコープ
みたいなところをしっかりまず明確にしていきましょう。
そこから少しずつ
それぞれのチームで
ミッションとオーナーシップを切り分けていって
そこでAPI化をしていく。
最後にチーム間でのXアザサービスに
移行していくという、そういうお話ですね。
はい。
あとはチームトポロジーを見直すきっかけですね。
一つのチームで
扱うにはソフトウェアがやっぱり大きくなりすぎて
しまった場合とかですね、もしくは
デリバリのリズムが遅くなり始めてしまったなとか
複数の業務サービスが
大量の買いサービス群に依存してしまっている場合とか
こういうときはしっかり見直すをするきっかけだ
というところで、ここはガツンと
27:01
やるしかないんでしょうね。
以上まとめですけど
今日はそのカイツマで話したんですけど
チームトポロジーズってそもそも書籍があるので
そこから見てもらうといいかもしれないところですね。
ということで以上
チームトポロジーを30分で
分かった気になるというような
スライドでしたけどいかがでしょうか。
ちょっと僕も音読で申し訳なかったり
あとは画像がたくさん
貼られてますので、そっちを見ていただくのは
本当にいいと思いますので
この後ツイッターでシェアしますので
皆さんの方でも見ていただければと思います。
改めてチームトポロジーっていうのは
すごい機能的であり
スケールしやすい
組織設計とか組織構造になりそうだな
ってすごく読んでて感じました。
ただやっぱ土壌というかそれができる
知識とか
メンバーのタレントが必要だ
って感じはすごくしたので
導入ハードルもすごく高そうだって思いますけど
じゃあ敬遠するんじゃなくて
ここを目指していくってのは一ついいかなと思いますね。
チームを
チームトポロジーをやることがビジネスではないので
目的は違いますけどとはいえ
組織設計とか構造に悩んでるんであれば
一回チームトポロジーを目指して
作っていくのが一つありかもなって思いました。
ではでは
今日の朝方はここで以上にしたいと思います。
30分超えてましたね。
今日の参加者はねむさんとしきむおじさんと
れのわさんと
ろむせんさんですね。
あと見えてないんですけどすずさんですね。
おはようございます。ご参加いただきありがとうございました。
また明日は土曜日ですけど
ゆるくなんか読んでいきたいと思いますので興味あれば参加してみてください。
じゃあ週末金曜日ですね。
しっかりお仕事終了して
閉めていただいて
いただければと思います。
じゃあ今日も頑張っていきましょう。お疲れ様でした。
