組織は生き物、組織としての最適解の見つけ方_#3_超えるのが簡単な境界を作る
現在手にしている参考図書は
特に変化の激しいソフトウェアビジネスに特化した組織論です。
これだけ市場の変化が激しいので、静的な組織（組織図、マトリクス型
組織）では追いつかないということが始点になっています。
前回は、チームの構成単位の詳細説明と既存組織への適用方法についての説明でした。
第2章も1つまとめようと思ったのですが、あまりに長くなったので分けました。（それでも長いですが）
今回は、各チーム間の役割・責任を明確にする方法についてです。
文字数：約3,700
参考図書
第2章 フローを機能させるチームトポロジー
⑥チームファーストな境界を決める
■目指すべきは分離が容易な”疎結合”
・早い変更フローを実現するには、チーム間の引き継ぎをなくし、ほとんどのチームを組織内の主要な変更のストリームに沿って配置しなければならない
・適切な境界を定義することで、フローを促進するようなやり方でシステムの一部を効果的かつ持続的に保有し進化させることができる
◼️ ソフトウェアの責任と境界に対するチームファーストのアプローチ
・ソフトウェアのデリバリーにおける多くの問題は「チーム間の境界」と「チームごとの責任」が不明瞭になったことに起因する
・モジュール間の結合度が高い（蜜結合）ソフトウェアとなって現れることが多く、このようなシステムを『モノリス（monolith）』と呼ぶ
・モノリシックなソフトウェアを蜜結合から疎結合に変える場合、新しいアーキテクチャが関係するチームにどう影響を与えるかを考えなければいけない
価値あるソフトウェアをすばやく届ける適応型組織設計
ISBN 978-4-8207-2963-1 C3055
P136〜P138
■隠れモノリスと結合
・疎結合に変換する前に、自分達がどんなモノリスを扱うのかを十分に認識しておく
1、アプリケーションモノリス
・多くの依存関係や責任を持つ単一かつ巨大なアプリケーション
・ユーザーはデプロイの間、アプリケーションを使えない
・運用担当者は、本番環境が安定せず予期せぬ問題に悩まされる
2、データベース結合モノリス
・同一のデータベースに複雑なアプリケーションやサービスが結合しており、それぞれ別々に変更、テスト、デプロイすることが難しい
・データベース管理に人手が不足してボトルネックになることが多い
3、モノリシックビルド（すべてをリビルド）
・コンポーネント（モジュール、コンテナ）間の依存関係を管理する標準的な仕組みを使うのではなく、コードベース全体でビルドするような場合
4、モノリシックリリース（すべてをまとめてリリース）
・共有の固定環境でしかテストできない場合、全コンポーネントの最新バージョンをまとめて同一の環境に導入している
・QA人材が不足しており、まとめて変更する方が効率的と考えているため発生する
5、モノリシックモデル（画一的な視点）
・単一のドメインとフォーマットを多くの様々なコンテキストに強制的に適用しようとするソフトウェア
・組織内のドメインやチームの数が増えると収拾がつかなくなる
6、モノリシック思考（標準化）
・チーム内の画一的な考え方のこと
・エンジニアは新しい技術を学習したがっているのに、単一のツールを強制しチームの選択肢を奪うとモチベーションを阻害したりする
7、モノリシックワークスペース
・地理的に同じ場所にいるすべてのチームや個人に適用する単一のオフィスレイアウトのこと
・重要なことは居る場所を同じするのではなく、目的を揃えること
※モノリシック（Monolithic）：[形]一枚岩の組織：頑丈だが変化しにくい
価値あるソフトウェアをすばやく届ける適応型組織設計
ISBN 978-4-8207-2963-1 C3055
P138〜P141
■ソフトウェアの自然な継ぎ目「節理面」の理解
・ソフトウェアを（疎結合のために）複数チームで分割する場合にも注意が必要
・節理面とはソフトウェアシステムを簡単に分割できる自然な継ぎ目
・通常はビジネスドメインとソフトウェアの境界を合わせる事が最善
・しかし複数のドメインにまたがるモノリスの境界と合わせるのは難しい
・ビジネスドメイン以外にもソフトウェアの節理面が複数ある
節理面1：ビジエネドメインのコンテキスト境界
・コンテキスト境界とは、大きなドメインモデルやシステムモデルを小さなパーツに分解する単位のこと
・コンテキスト境界がドメイン領域において内部で一貫したモデルを持たなければいけない（次の引用分参照）
・DDD（ドメイン駆動設計）とは、下位のドメインのモデルに基づいてソフトウェア設計すること
・音楽ストリーミングサービスを例にすると
ドメイン1：メディアディスカバリー（新曲を見つける）
ドメイン2：メディアデリバリー（音楽を届ける）
ドメイン3：ライセンス（権利管理とロイヤリティの支払い）
という3つのサブドメインを持ち、ビジネスに沿っている
・コンテキスト境界を特定するのは容易ではなく、間違いやすい。コンテキスト境界を理解できるようになったら躊躇なく改善をすることが重要
節理面2：規制遵守
・金融業界や医療業界のような規制が厳しい業界では、規制の要件が境界になることが多い
・規制遵守という節理面に沿うことで、監査とコンプライアンスが容易になり、監視の範囲を減らすことができる
節理面3：変更のケイデンス（Cadence：頻度、リズム、言葉の抑揚）
・モノリスの場合は、全体の速度が一番遅い部分の速度になる
・システムを変更の頻度別に分割することで、変更を速くできる
・モノリスが固定の速度を強いるのではなく、ビジネスニーズが変更の速度を決めることができるようにする
節理面4：チームの地理的配置
・チームが効率的にコミュニケーションを取るためのオプションは
1、メンバー全員が同じ物理スペースで共有する形で、同じ場所にいる
2、完全なリモートファーストのアプローチで、いつでもアクセス可能なツールを強制する
節理面5：リスク
・多くのリスクを取ることは、アウトカムの失敗確率が高くても変更を素早く顧客に届けることを意味する
節理面6：パフォーマンス
・大規模な需要のピークにさらされるシステムでは、残りの部分には必要ないレベルのスケーリングとフェイルオーバー（過負荷でサーバーが停止した場合に自動的に待機システムに切り替える）の最適化が必要となる
節理面7：技術
・従来型でも技術で境界を作ることが多かった（フロントエンド、バックエンド、データ層など）
・技術主導で境界を分割すると、全体的な視野でチーム作業の透明性は低くなり、チーム間のコミュニケーションは遅くなる
・また技術主導の場合、プロダクトの依存関係が残り続けるためチームの自立性も低くなってしまう
・技術主導による分割が有効なケースとしては古いシステムや自動化しにくい技術（手書きテストや手動介入など）
節理面8：ユーザーペルソナ
価値あるソフトウェアをすばやく届ける適応型組織設計
ISBN 978-4-8207-2963-1 C3055
P141〜P156
④～⑥の要約
④静的なチームトポロジー
・小手先や頻繁なチーム変更はソフトウェアのデリバリーを遅くする
・どのトポロジーを選択するかは、技術面、文化面での成熟度、組織の規模、技術面での規律という観点が必要
・チームの責任を明確にすることでサイロを壊し、他のチームの能力を高める
⑤4つの基本的なチームタイプ
・4つのチームタイプによって、ソフトウェアチームのインタラクションを単純化できる
・中心となるチームはストリームアラインドチームであり、残りの3つはストリームアラインドチームを支援する
・その他のチームとして、イネイブリングチーム、コンプリケイテッドサブシステムチーム、プラットフォームチームがある
⑥チームファーストな境界
・ソフトウェアのデリバリーチェーンにおいて、隠れモノリスや結合に気をつける
・境界をビジネスドメインとソフトウェア境界以外にも複数あるので、状況に合わせて境界をどこにおくかを検討する
価値あるソフトウェアをすばやく届ける適応型組織設計
ISBN 978-4-8207-2963-1 C3055
P71
＜所感＞
正直今回の内容は、頭で理解していても実施するのはとても難しいと思いました。
理想的には、長続きする柔軟なチームが前提になっているので
・メンバー交代を実施する機運が働きづらい
・人は慣れた環境を変えるのを嫌う
・機能別の価値提供貢献度の違いによるパワーバランスが生じる
・パワーバランスが生じると政治力が働く
・結果として組織変更はDynamicにできなくなる
人は何かを守り、変化へのアレルギーがあるものです。（特に日本人？）
なので「変化することの正当性＋説明責任」と「各チームのベクトルが合わさった時に価値が織りなされる」という文化を作り上げないといけないと思いました。
文化は一朝一夕にしてならずですね。
難しそうだ・・・
この記事が気に入ったらサポートをしてみませんか？