組織は生き物、組織としての最適解の見つけ方_#2_今の組織を見直してみよう!
組織論に関する著書は数え切れないほど世の中にあると思います。
今回はそんな中でも
特に変化の激しいソフトウェアビジネスに特化した組織論です。
ただ、自分はソフトウェアビジネスじゃないから関係ないや、というわけでもなさそうです。
これだけ市場の変化が激しいので、静的な組織（組織図、マトリクス型
組織）では追いつかないです。
前回は、コンウェイの法則を足掛かりにしたチームトポロジーの概要についてまとめました。
ここからは実践寄りになっていきます。
楽しみです。
文字数：約6,400
参考図書
第2章 フローを機能させるチームトポロジー
④静的なチームトポロジー
■ソフトウェアシステムの変更フローに沿った組織
・静的なチームトポロジーとは、ある時点の組織の特定のコンテクストにあったチーム構造とインタラクション
◼️ チームのアンチパターン
1、場当たり的なチーム設計
・チーム間の相互関係というコンテクストを考慮していないことが多い
2、チームメンバーの入れ替え
・プロジェクトが終わればすぐに解散するチーム作り
◼️ 変更フローを考慮した設計
・さまざまな部署にまたがる職能型サイロ、外注の多用、チーム間の引継ぎの多さなど古い組織モデルでは、顧客やマーケットの進化に対応できない
・組織がチームインタラクションの設計を検討するとき、人を静的に配置する以上のことを考慮しなくてはならない
・多くの組織はシステムを構築、運用するときのチーム間のインタラクションの方法に重大な欠陥がある
・それはソフトウェアのデリバリーを「仕様から設計」「設計からコーディング」「コーディングからテスト・リリース」「リリースから通常業務」へと続く一方通行だと思い込んでいる
・同一のチーム内で「システムの設計、開発、テスト、デプロイ、運用を行うのに必要なスキルを全て兼ね備えていなければならない」
・本番環境から情報のフィードバックに価値を置く組織は、素早く改善できるだけでなく顧客への対応力も高まる
価値あるソフトウェアをすばやく届ける適応型組織設計
ISBN 978-4-8207-2963-1 C3055
P72〜P77
■DevOps （Development And Operations)
◼️ DevOpsとDevOpsトポロジー
・Devとは開発、Opsとは運用を意味する
・DevとOpsの摩擦が生じる中で、アジャイルが主流となり運用チームはデプロイ頻度を増やす圧力が高まったことに起因してできた組織形態
・DevOpsの貢献として、デリバリーチェーンにおけるチーム間のインタラクションの欠如が遅延、再作業、失敗、他のチームに対する理解と共感の欠如を引き起こしているという問題意識を高めたこと
・DevOpsはチーム間の根本的なズレに対処している組織だけがメリットを享受できる
・DevOpsトポロジーは2013年にマシュー・スケルトンが、チーム設計とインタラクションに関するパターンとアンチパターンをまとめたもので、オンラインで確認できる
・DevOpsトポロジーの重要な2つの考え
1、DevOpsを成功させるためのチームを構成するアプローチに万能なものはない
2、DevOpsの成功を妨げるアンチパターンとなるようなトポロジーとある
・DevOpsトポロジーはチームは時間と共に進化し変化することが暗黙の了解
価値あるソフトウェアをすばやく届ける適応型組織設計
ISBN 978-4-8207-2963-1 C3055
P77〜P80
※参考：DevOpsトポロジー 9つのタイプ
■成功するチームパターン
1、フィーチャーチーム
・エンジニアリングにおける高い成熟度と信頼が不可欠
・フィーチャーチームとは、職能横断型かつコンポーネント横断型のチームで、顧客向けの機能のアイデア検討から構築まで一貫して行い、顧客の使用状況やパフォーマンスを監視できるチーム
・職能横断型は、コンポーネントを横断し顧客中心の機能を素早くリリースし、高い価値をもたらす
・ただしこれができるのは、他のチームを持つことなく自給自足で本番リリースできる場合に限る
・エンジニアリングの成熟度が高くないと、技術的負債が増え、デリバリー速度が落ちていきチーム間の信頼が壊れる
2、プロダクトチーム
・目的と特徴はフィーチャーチームと同じだが、プロダクトの機能全体を担当する点が異なる
・チームが自律的でいるのに重要なことは外部への依存関係をなくす（ノンブロッキング）こと、すなわち新機能はできているのに外部の何かを待っている事がないようにする
・ノンブロッキングな依存関係は、他のチームが開発、維持するセルフサービス型の能力という形をとる事が多い
・チームが不慣れなタスクを行う時にすぐに頼れるスペシャリストを含むサポートシステムがないと機能しない
・プロダクトチームは結局インフラ、ネットワーク、QA（Quality Assurance）などの職能型チームに対する強い依存関係が必要になる
・必要に応じて新しいイメージやテンプレートを作り、自分たちの環境やリソースを*プロビジョンニングできる自律性が必要
3、クラウドチーム
・プロビジョニングプロセスを引き続き担当し、必要な管理やポリシーのて適用、監査が確実に行われるようにする
・クラウドインフラのプロセスを設計する責任（クラウドチーム）と、アプリケーションに必要なリソースを実際にプロビジョニングしたり更新する責任（プロダクトチーム）を分離する
4、SRE（Site Reliability Engineering）
・ソフトウェアアプリケーションの運用と改善のアプローチ
・SREはソフトウェアエンジニアに運用機能の設計を依頼した時に起こること
・SREに求められるのは、優れたコーディングスキルと繰り返し行うタスクを自動化し、*トイルを減らし続ける強い意志と時間の余裕
・SREは大規模システムの構築と運用におけるダイナミックなアプローチ
・SREとアプリケーションチームの関係は4つのステップがある（本書P85の図参照）
◼️ トポロジーを選択する場合に考慮すること
①技術的/文化的成熟度
②組織のサイズ、ソフトウェア規模、エンジニアリングの成熟度
③責任の分割によるサイロの解消
④チーム間の依存関係と待ち時間
*プロビジョニング（Provisioning）：IT インフラストラクチャをセットアップするプロセス。データとリソースへのアクセスを管理し、ユーザーとシステムによる利用を可能にするために必要なステップ
*トイル（Toil）：繰り返される手作業で自動化が可能なもの。戦術的、長期的に価値がないがサービスの成長に比例して増加する作業
価値あるソフトウェアをすばやく届ける適応型組織設計
ISBN 978-4-8207-2963-1 C3055
P80〜P94
⑤4つの基本的なチームタイプ
■根幹となるストリームアラインドチーム
(1) ストリームアラインドチーム（Stream Aligned Team）
・価値のある単一の仕事のストリームに沿って働くチーム
・ここでのストリームとは仕事やサービスもあれば機能一式のこともある
・チームだけで素早く安全に顧客に価値を届けるためにチームに権限が移譲されており、他のチームへの引継ぎは必要ない
・組織で根幹となるチームタイプで、後述する残りのチームタイプの目的は、ストリームアラインドチームの負荷を減らすこと
・このチームはデリバリー全体に関わるため、顧客と近く、本番環境を監視しながら顧客からのフィードバックを取り込む
・短期のプロジェクトではなく、長期的に維持される仕事のポートフォリオもしくはプログラムの一部として予算が割り当てられる
・Amazonが好例であり、ストリームアラインドチームは独立し、サービスにオーナーシップを持ち、開発したソフトウェアがうまく使われるようにする責任を持つ
・Googleが先駆けとなったSREは、ストリームアラインドチームの一種で、本番環境での大規模なアプリケーションの信頼性に責任を負い、ソフトウェアの変更がストリームに適切に沿ったものにする
＜ストリームアラインドチームが備える能力＞
＋アプリケーションセキュリティ
＋事業成長性分析と運用継続性分析
＋設計とアーキテクチャ
＋開発とコーディング
＋インフラと運用性
＋メトリクス（利用分析）とモニタリング
＋プロダクトマネジメントとオーナーシップ
＋テストとQA
＋UX理解 など
＜ストリームアラインドチームに期待される事＞
＋フィーチャーデリバリーの安定したフローをつくる
＋最新の変更に対するフィードバックに基づいて軌道修正する
＋プロダクトの進化に実験的なアプローチを用いて、常に学んで適応させる
＋他のチームへの引継ぎを最小限にすふ
＋変更フローの安定性とチームの健全性の観点での補助的なメトリクスで評価される
＋コードの変更が安全かつ簡単に行える状態を保つため、コード品質変化に対応するための時間を持つ
＋積極的、定期的に他のチーム（残り3つ）と連携する
＋自律、熟達、目的を達成しようとするか、達成していなければならない
価値あるソフトウェアをすばやく届ける適応型組織設計
ISBN 978-4-8207-2963-1 C3055
P95〜P104
■ストリームアラインドチームを支援する3つのチームタイプ
(2) イネイブリングチーム（Enabling Team）
・特定のテクニカルドメインのスペシャリストから構成され、能力ギャップを埋めるのを助ける
・複数のストリームアラインドチームを横断的に支援し、適切なツール、フレームワークなどに関する調査、オプションの探索、正しい情報に基づく提案を行う
・イネイブリングチームにより、ストリームアラインドチームは多大な労力をかけずに能力を獲得し進化できる
・第一の目的は、ストリームアラインドチームが使えるソフトウェアをタイムリーかつ持続可能に届けられるように支援すること
＜期待されること＞
＋積極的にストリームアラインドチームのニーズを探索し、定期的にチェックポイントを設け、より多くのコラボが必要なタイミングをつくる
＋良いニュースも悪いニュースも伝え、技術のライフサイクルマネジメントを支援
(3) コンプリケイテッド・サブシステムチーム（Complicated Sub-system Team）
・システムの中でスペシャリストの知識が必要となるパーツやモジュールを開発、保守する
・ストリームアラインドチームの認知負荷を減らすことが目的
・サブシステムの例として
＋動画処理コーデック
＋数理モデル
＋リアルタイム取引裁定アルゴリズム
＋顔認証エンジンなど
(4) プラットフォームチーム（Platform Team）
・内部サービスを提供することで、ストリームアラインドチームの下位のサービス開発必要性をなくす
・プラットフォームチームの知識はウェブポータルやAPIとして提供される
・下位の機能のプラットフォームの例
＋新しいサーバーインスタンスのプロビジョニング
＋アクセス管理のツール
＋セキュリティ強制ツールなど
価値あるソフトウェアをすばやく届ける適応型組織設計
ISBN 978-4-8207-2963-1 C3055
P104〜P121
⑤-2 チーム運用成功のテクニック
■変更フローとチームサイズ
◼️ 変更フローのなかでチームサイロを避ける
・単一職能からなるチームは避けるべき
＋テストまたはQA
＋データベース管理
＋UX
＋アーキテクチャ
＋データ処理など
・従来、組織は運用の専門チームを作ってきた。これにより変更フローを妨げ、開発チームからの引継ぎが必要となり、遅れが発生していた
・ストリームアラインドチームにすることで、多能工型または職能横断型チームを変更のフローに沿って配置できる
◼️ プラットフォームはちょうど良い大きさに
・良いプラットフォームは、「標準」「テンプレート」「API」「実績あるベストプラクティス」を開発チームに提供し、素早く効果的にイノベーションを進める
・プラットフォームにはユーザー（開発チーム）と運用対応時間（開発チームが使う時間）がある
価値あるソフトウェアをすばやく届ける適応型組織設計
ISBN 978-4-8207-2963-1 C3055
P121〜P127
■既存チームを成功するチームへ変換する方法
・まずは既存のチームを4つのタイプのどれかと認識するだけでもチームは最良の働き方を理解し、トポロジーのパターンにしたがって目的とふるまいを変えていく
変換①：ほとんどのチームを長続きする柔軟なストリームアラインドチームにする
・成功している組織から、ストリームアラインドチームとそれ以外の組織の比率は6：１から９：１くらいが適切
変換②：インフラチームをプラットフォームチームにする
・これまでインフラチームは稼働中のアプリケーション全てのインフラに責任を負っていた
・インフラチームをプラットフォームチームにすることで、変更フローをより安全かつ速くできる
変換③：コンポーネントチームをプラットフォームもしくは別の種類のチームにする
・例えばデータベース管理チームは、アプリケーションレベルの仕事をやめ、データベースのパフォーマンス、モニタリングの知見を広める活動にフォーカスすることでイネイブリングチームになれる
・あるいは、プラットフォームチームの一部にし、データベースのパフォーマンス、構成、可用性などについての専門的なサービスの提供にフォーカスさせることもできる
変換④：ツールチームをイネイブリングチームまたはプラットフォームチームに変換する
・往々にして、ツールチームはサイロ化した保守チームになりがち
・明確な目的を設定した短期間のイネイブリングチームか明確なロードマップを持つプラットフォームチームの一部にすると良い
変換⑤：サポートチームを変換する
・ソフトウェアが常に激しく変化する状況下では、以下の2つの特徴を意識する
1、サポートチームが変更のストリームに沿って配置
2、インシデントに関しては動的にチーム横断で活動
変換⑥：アーキテクチャーをアーキテクトと変換する
・アーキテクチャチームは、他チームに設計や技術選択を強制するのではなく、他のチームが効果的に働けるサポートチーム（＝短期的なイネイブリングチーム）となることが重要
価値あるソフトウェアをすばやく届ける適応型組織設計
ISBN 978-4-8207-2963-1 C3055
P127〜P135
＜所感＞
今回は実践ですが、すでに課題に直面している人が読むと脳天直撃かもしれないです。
あいにく、まだ私は当事者ではないので、パターンを後から見渡せるような備忘メモになりそうです。
後半の既存チームの変更手法はかなり詳細に記載されており、かなり勉強になりました。
が、しかし！
注意書きとして「トポロジーの選択検討時に組織の規模」は明記されているものの、
組織変更を人員数の問題でできない
今すぐにでも組織変更したいが、あと1名の採用が確定しないとできない
なんて状況が多いのが現実だと思います。
特にソフトウェアエンジニアの採用は日本では本当に難しいです。
私も採用をトライしましたが、結局某コンサルグループに高い年収提示で勝てずに採用できなかった経験があります。
ただ、あるべき組織像は常にリーダーは持っておくべきだし、それに向けて徐々に組織を変えていくことが使命だと思います。
この記事が気に入ったらサポートをしてみませんか？