組織は生き物、組織としての最適解の見つけ方_#4_変化できる組織の作り方
#2と#3で『チームをどう編成するか』について学びました。
ここからは、『編成したチームをどう活動させるか』についてみていきます。
前回の所感でも記載しましたが、組織変更に当たりするリソースが確保できていることが大前提です。
採用は楽でないので、採用スキルは別途磨かないといけないです。
文字数：約6,200
参考図書
第3章 イノベーションと高速なデリバリーのためにチームインタラクションを進化させる
⑦チームインタラクションモード
■3つのチームインタラクションモード
・チーム間の関係性を考慮する際に重要なことは、
目的を達成するために
＋「他のチームとコラボレーションするか」
＋「他のチームをサービスプロバイダーのように扱うか」
の見極める
・最も避けるべくは、目標を達成するために、他の全チームとのやり取りが必要になってしまうこと
■3つのチームインタラクションモード
(1) コラボレーション：他のチームと密接に協力して作業する
(2) X-as-a-Service：最小限のコラボで何かを利用または提供する
(3) ファシリテーション：障害を取り除くために支援したり、されたりする
・ソフトウェアを構築する際にチームがインタラクションする方法を形式化することで、チーム間のインターフェイスを明確に定義でき、デリバリーにおける様々な側面の有効性が評価しやすくなる
(1) コラボレーションモード
＜特徴＞
・コストのかかるチーム間の引継ぎがない
・新しいものを素早く探索するのに向いている
・チームAとBの間にまたがる専門領域に大きなイノベーションがあるかもしれない
・新しい働き方や予期せぬ動作を素早く発見できる
＜弱み＞
・重点分野と責任分野の重なりが少なくとも多くても全体的なアウトカムに責任を持つ（責任範囲の拡大、境界が曖昧になる）
・認知負荷が高くなる
・コラボレーションの間は、従来のチームより生産性が落ちる可能性がある
＜制約・留意点＞
・コラボレーションした後でも1チーム15人を超えないようにする
・1つのチームが同時に2つのコラボレーションモードを利用してはいけない
(2) X-as-a-Serviceモード
＜特徴＞
・手間をかけずに「まずは動く」コンポーネント、API、プラットフォームを必要とする状況に適している
・システム開発の初期のアプローチ探索や後期よりも、予測可能なデリバリーが必要とされる時期に有効
・コラボレーションモードの発散的なアプローチで見つかったサービス提供の課題解決方法を、最も効果的なサービスとして構築・提供するのに適す
・どのチームがどのオーナーシップを持っているかが明確
・認知負荷はいずれのチームでも減る
・利用側のチームは、サービスの詳細を知らなくても高い価値を得ることができる
＜弱み＞
・境界やAPIのイノベーションが遅くなる
・境界やAPIが効果的でなければ効果が出にくい
＜制約・留意点＞
・1つのチームが同時に複数のチームとX-as-a-Serviceインタラクションを使う想定が必要
(3) ファシリテーションモード
＜特徴＞
・1つ以上のチームが別のチームから積極的に作業の一部をファシリテートしてもらう場合に適す
・イネイブリングチームの主な職務遂行モード
・ファシリテーション側のチームの責任は、他のチームがより効果的になり、より早く学習し、新しい技術をより理解し、チーム全体の課題や障害を取り除くこと
・ファシリテーションを実施するチームは、ソフトウェアの構築、運用を行う他のチーム間のインタラクションの品質に注目する
＜弱み＞
・構築や運用に従事しない経験豊富なスタッフが必要
価値あるソフトウェアをすばやく届ける適応型組織設計
ISBN 978-4-8207-2963-1 C3055
P160～173
■インタラクションモードを機能させるふるまい
・ライブバンドが求められる音楽や一緒に演奏する他のバンドに合わせて演奏スタイルを変えるのと同じように、チームトポロジーアプローチに従ってデリバリーするチームは、インタラクションする他のチームに応じて異なるふるまいを採用する
・人が他人と最もうまくやれるのは、その人の行動が予測できるとき
(1) コラボレーションモードでのチームのふるまい
・豊富なインタラクションと相互の尊重が不可欠
・コラボレーションの境界の架け橋という側面によって、未知の問題を発見し解決できる
(2) X-as-a-Serviceモードでのチームのふるまい
・サービスのUXを重視することが不可欠
・サービス提供側の環境がインタラクションにもたらす体験＝「API/プラットフォームの使いやすさ」「使用リソースの確認のしやすさ」などを重視する
(3) ファシリテーションモードでのチームのふるまい
・助け合う精神をもつことが不可欠
・新しいアプローチに対して心を開き認識する（ストリームアラインドチームとイネイブリングチーム間）
価値あるソフトウェアをすばやく届ける適応型組織設計
ISBN 978-4-8207-2963-1 C3055
P173～176
■最適なインタラクションモードの選択
・ストリームアラインドチーム → X-as-a-Serviceまたはコラボレーションモードを使用する
・イネイブリングチームはファシリテーションモードを使用する
・プラットフォームチームは、利用するチームのためにX-as-a-Serviceモードを使用する
・逆コンウェイ戦略を実施すると、ソフトウェアのアーキテクチャに必要なコミュニケーションに合わせて組織が設定される
・新しいチームが必要になると新しいアーキテクチャが必要となり既存のアーキテクチャに当面反発することになる
・この反発を乗り越えて新しい組織構造をまく機能させるには、一時的にソフトウェアを構築するチーム間を明示的にコラボレーションモードにし、イネイブリングチームもファシリテーションモードで参加するなど、早い段階で設計を調整する機会を得ることが重要
・チームトポロジーを計画的に進化させチーム間のAPIを発見する
価値あるソフトウェアをすばやく届ける適応型組織設計
ISBN 978-4-8207-2963-1 C3055
P176～186
⑧組織的センシングでチーム構造を進化させる
■変化に適応する組織の設計ルール
・勝ち組のモダンな組織になるためには、適応性を考慮して設計し、変化する環境に合わせて形を変えていく能力が必要
・組織自体の形でなく、重要なことは新しい課題に対して組織を適応させ変化するためのルールと経験
■どのくらいのコラボがチームインタラクションに適切か
・コラボレーションモードでは、双方が相手への理解を深める必要があるためメンバーが頭に入れておくべきことが増える（認知負荷が増える）
・ただ初速は遅くとも、引継ぎなしで素早い探索ができる効果は高い
・X-as-s-Serviceモードでは、オーナーシップをどこが持っているかが明確になり、認知負荷は減るが、イノベーションは遅くなりがち
・ハイパフォーマンスな組織はチーム間のインタラクションごとに必要なコラボの量を決めることが重要
価値あるソフトウェアをすばやく届ける適応型組織設計
ISBN 978-4-8207-2963-1 C3055
P187～190
■コラボの効果を出す具体ストーリー（コンテキスト）
・2つのチームのインタラクションを意図的にコラボするようにすると、組織が新しいプラクティスやアプローチを素早く学習し導入することを後押しする
例1）テストの自動化のようなプラクティスに経験豊富なチームAと別チームBを数か月間コラボレーションモードのチームインタラクションにすると
＋チーム間のAPIを改善し定義する
＋チームBの能力を段階的に変えていくことができる
＋2つのチームが利用技術やプラクティスの違いなど、これまでの経験が異なる状況で有益な効果が出やすい
例2）クラウドベースソフトウェアの構築に長けたチームAが組み込みソフトウェアを搭載したIoTデバイスからデータを受信しメトリクス収集分析ソフトウェアを構築する場合
＋チームBとして組み込みソフトウェア専門チームとコラボレーションモードのチームインタラクションにする
＋組み込み／クラウド技術の壁を超えて課題を深く理解できる
＋チームBはクラウドチームAがテスト環境を動的なものとして扱うことから、テストに素早くアプローチできる学習をする
＋チームAは組み込みソフトチームBからデバイスのメモリや処理制約を理解し、制約のあるハードウェアへのコード・プロトコルの調整を学習する
＋最終的にはストリームアラインドチームのペアとなる
価値あるソフトウェアをすばやく届ける適応型組織設計
ISBN 978-4-8207-2963-1 C3055
P190～195
■チームトポロジーの絶え間ない進化
・要求や運用のコンテキストが変わったり、チームが達成すべきことに応じてインタラクションモードも定期的に変わっていく
・一般的にチームトポロジーは密接なコラボレーションモード → 限定的なコラボレーションモード → X-as-a-Serviceモード → ストリームアラインドチームへと進化する
・これは探索によって技術やプロダクトへの理解が深まり、初期の密接なコラボは発展し、コラボする対象を徐々に減らしていく。
さらにプロダクト境界が確立されるとX-as-a-Serviceへと発展する
・組織内のチーム間の相互関係を明瞭で動的なものとし続けることは「内外の状況に対応する継続的設計能力」のベースとなる
・戦略は「検索、実行、学習、修正」が継続的に行われること。組織は戦略スキルを発揮すればするほど競争環境にうまく対応できる（ジョン・P・コッター）
価値あるソフトウェアをすばやく届ける適応型組織設計
ISBN 978-4-8207-2963-1 C3055
P195～201
■チームトポロジー進化のトリガーを認知する組織センシングを磨く
■チームトポロジーを進化させるきっかけ
(1) 1チームで扱うにはソフトウェアが大きすぎる
＜兆候＞
・スタートアップ企業が成長し、人数が15人を超える
・1チームを変更するだけで、他の多くのチームが待たされる
・変更がいつも同じ人に割り当たる
・システムのドキュメント不足が散見される
＜背景＞
・機能が増え、顧客が増えるとソフトウェアは巨大化する傾向がある
・時間が経つにつれてコンポーネントに関してチーム内で専門家・属人化を引き起こす
・チームがシステムの全体像を把握しきれなくなったとき、システムが巨大化してしまっていることにも気づかない
(2) デリバリーのテンポが遅くなり始めている
＜兆候＞
・チームのベロシティやスループットのメトリクスが低下している
・デリバリープロセスが複雑化している
・別のチームのアクションを待つ変更が多くなり、待ち時間が長くなる
＜背景＞
・他のチームが新しいインフラを作るまで待つといった、外部チームへの強い依存が発生している
・このレベルの自律性の達成は難しく、多くの場合新たなチーム間の強い依存を増やすような真逆の事態が発生する（QAチームを作るなど）
・組織全体のQAチームを作ってしまうと職能型サイロが形成され、機能追加ごとにQAチームのアクションを待つことになる
・技術的負債が増えてしまっている
(3) 複数の業務サービスが大量の下位のサービス群に依存している
＜兆候＞
・ストリームアラインドチームが自分たちのサービス領域においてフロー全体を把握できていない
・結合するサブシステムの数と複雑さが理由で、速い変更フローの達成が難しい
・既存のサービス群やサブシステム群の再利用が難しくなっている
＜背景＞
・規制の厳しい業界では、複数の上位サービスが、数多くの下位サービスやAPI、サブシステムに依存している場合がある
価値あるソフトウェアをすばやく届ける適応型組織設計
ISBN 978-4-8207-2963-1 C3055
P202～208
■自立操舵設計と開発
・かつての組織において、Dev:開発とOps:運用は別々と扱い、インタラクションはほとんどなかった
・SaaSビジネスの台頭などを背景に、運用部門は開発部門の活動に有益なシグナルとしてふるまい、それを開発にフィードバックしなければならない
・組織的センシングとは、チーム内外のコミュニケーションを組織の感覚器官として利用する
・チーム間に明瞭で安定したコミュニケーションがあれば、組織は組織内外からのシグナルを検出できる
・しかし多くの組織が不安定で不明瞭なチームで、主担当者に依存し、多くのメンバーの声を抑制してしまい、センスレスに陥っている
＜組織が感知すべきものを明瞭にする質問＞
1、ユーザーがどのようにふるまう必要があるのか？
2、組織がより機能するためにインタラクションモードを変更する必要はないか？
3、内製を続けるべきか？外注すべきか？
4、チームAとBの密接なコラボはまだ有効か？X-as-a-Serviceモードに移行すべきではないか？
5、プラットフォームはチームが必要とするものをすべて提供しているか？イネイブリングチームが一定期間必要ではないか？
・Ops:運用/保守をDev:開発へのインプットとして扱うには、分離されがちなOpsとDevの役割を根本的に見直す必要がある
・開発と運用のケアの継続性を向上させるためには、保守あるいは通常業務（BAU：Business As Usual）チームをそもそも作らないこと
・ストリームアラインドチームとして機能させることで、新規サービスと既存システムの両方を面倒を見る
これによってユーザーやシステムの動作について幅広い学習ができるようになり、組織のセンシングが働くようになる
価値あるソフトウェアをすばやく届ける適応型組織設計
ISBN 978-4-8207-2963-1 C3055
P208～214
＜所感＞
正直内容が濃すぎて1回読んでまとめたくらいでは理解できないです。
これは実際に課題に直面し、組織を見直すときに辞書のように開く本だと思います。
これが完全に頭に入ってからといって組織がうまく行くとは思いません。
なぜなら企業規模によってすぐに変更できない政治力、あるいはどんな規模の企業でもリソースCAPがあるからです。
ただ内容をうっすらでも知っておくことはとても有益です。
日本では多くの企業がチームトポロジーを適用できていないし、やってみながら学ぶのが一番良いと思います。
いずれにせよ、後から見れば見るほどこの本のありたがみを感じるはずです。
ちなみに今回のnoteにはChapter9（P216～P227）はまとめていません。
なぜならChapter9自体が本書のまとめてになっており、おそらくこのページを一番開くことになると思います。
リカーリングモデル、リレーション型コミュニケーション、SaaSなどこれからビジネスの主流なってくるNew Typeのビジネスの発展と合わせて、この組織論もスタンダードになると信じています。
素晴らしい本でした！
この記事が気に入ったらサポートをしてみませんか？