# 疎結合のアーキテクチャ ## 定義 疎結合のアーキテクチャ(loosely coupled architecture)とは、システムどうし、およびその構築・維持管理を担うチームどうしが、相互に独立した形で変更・検証できる状態を指す。『LeanとDevOpsの科学［Accelerate］』第5章は、この特性を「テスト容易性」(テストの大半を統合環境なしで実施できる)と「デプロイ容易性」(依存する他のアプリケーション・サービスから独立してデプロイ・リリースできる)という2つの具体的な事項に翻訳し、この2つに同意できる組織はハイパフォーマーである可能性が高いと報告する。重要なのは、システムのタイプ(SoE・SoR・メインフレーム・パッケージソフトウェア等)そのものはデリバリのパフォーマンスと有意な相関を示さなかったという点で、この結果はアーキテクチャの実装の詳細よりもこの2つの特性の有無に注目することの重要性を裏づける。パッケージソフトウェアやメインフレーム上の「レガシー」システムでもこの2特性は持たせられる一方、最先端の「コンテナによるマイクロサービスアーキテクチャ」を採用していてもこの2特性を見過ごせばパフォーマンス向上は保証されない。(Source: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 5 アーキテクチャのキーポイント]] ch.5 p.72-75) 第5章は疎結合アーキテクチャを、目標志向の創造的な組織文化・継続的デリバリを促進する技術的プラクティス・優れた指導力と並ぶ、パフォーマンスの高いデリバリの4つの予測要因の1つ(「モジュラーアーキテクチャ」)として位置づける。(Source: ch.5 p.78-79) ## テスト容易性とデプロイ容易性 2017年の調査研究では、カプセル化された疎結合アーキテクチャがITパフォーマンスを向上させる効果を持つことが判明した。同年の分析では、次のケイパビリティをチームが備えているか否かが「テストとデプロイの自動化」を凌いで、継続的デリバリの最強の促進要因となった。 - チーム外の人物の許可を得なくても、対象システムに大幅な変更を加えられる - 対象システムの変更作業で他チームに頼ったり、他チームに相当量の作業を課したりすることなく、対象システムに大幅な変更を加えられる - チーム外の人々とやり取りしたり協働したりすることなく作業を完遂できる - ソフトウェア製品やサービスを、それが依存する他のサービスに関係なく、オンデマンドでデプロイ、リリースできる - 統合テスト環境を必要とせずに、オンデマンドでテストの大半を実施できる - デプロイメントを、無視できるほどわずかな稼働停止時間のみで、通常の勤務時間内に完了できる (Source: ch.5 p.75) ## チームとアーキテクチャの疎結合 アーキテクチャ関連のケイパビリティでパフォーマンスが高かったチームは、デリバリ担当チーム間でのやり取りをほとんど必要とせずに作業を完遂でき、システムのアーキテクチャも担当チームが他チームに依存せずにテスト・デプロイ・変更を行える設計となっている――すなわち「チームとアーキテクチャが疎結合」である。これを実現するには、デリバリ担当チームが職能上の枠に縛られず、同一チーム内でシステムの設計・開発・テスト・デプロイ・運用に必要なスキルをすべて兼ね備えていなければならない。(Source: ch.5 p.75-76) 第5章はこの関係を [[コンウェイの法則]](Melvin Conway, 1968)――「システムを設計する組織は、その組織のコミュニケーション構造を反映した設計しか生み出せない」――に接続し、これに対して「逆コンウェイ戦略」(組織がチーム構造と組織構造を進化させて望ましいアーキテクチャを実現すべきだという考え方)を裏付ける結果が出たと述べる。目指すべきは、チーム間のコミュニケーションをさほど要さずに設計からデプロイまでの作業を完遂できる能力を促進するアーキテクチャを生み出すことである。可能にするアプローチとして「コンテキスト境界とAPIにより大規模なドメインをより小規模で疎結合なユニットに分割する」「テストダブルと仮想化によりサービス・コンポーネントを独立してテストする」が挙げられる。(Source: ch.5 p.76-77) 疎結合アーキテクチャの目的は「チームは協力し合うべきではない」ことではない。組織内のコミュニケーションの処理能力を実装レベルの細かな意思決定のやり取りに使い切らず、より高次な共通の目標やその達成方法に関する議論に使えるようにすることが目的である。(Source: ch.5 p.77) ## マイクロサービス・サービス指向アーキテクチャとの関係 第5章は、疎結合アーキテクチャを実現する具体的な実装形式としてサービス指向のアーキテクチャや(堅固なものであれば)マイクロサービスアーキテクチャがしかるべき成果を上げられるとしつつ、実現には成果の達成度の厳密なモニタリングが不可欠だと釘を刺す。あいにく現実には、サービス指向を謳っているにもかかわらず独立した形でサービスをテスト・デプロイできず、チームがパフォーマンスを高められない、というアーキテクチャが多いと指摘する。すなわち第5章の立場は、「マイクロサービス」という特定の実装形式そのものではなく、テスト容易性・デプロイ容易性というアーキテクチャの性質の有無を重視するものであり、マイクロサービスの採用はこの性質を得るための一手段にすぎず十分条件ではない。(Source: ch.5 p.76-77) ## スケーリング促進効果 カプセル化された疎結合アーキテクチャと、それに合った組織構造を実現すると2つの重要な効果が得られる: (1) 作業のテンポと安定性が向上し、バーンアウトやデプロイ関連の負荷が軽減されてデリバリのパフォーマンスが向上する、(2) 技術系部署をかなりの規模まで拡大でき、しかも生産性を直線的に(あるいはそれを上回る率で)高められる。 生産性の測定には「開発者1人当たりの1日のデプロイ件数」を用いた。最低でも1日1回デプロイを行っている回答者を対象に、開発者数とこの指標の関係をパフォーマンス群別に分析したところ(図5.1)、開発者数が増えるにつれて各カテゴリーのデプロイ頻度は次のように変化した: ローパフォーマーでは落ちる、ミディアムパフォーマーでは変わらない、ハイパフォーマーでは有意に上がる。ソフトウェア開発チームの規模拡大に関しては「開発者数を増やすと全体的な生産性は上がるが、コミュニケーションとインテグレーションのオーバーヘッドが増えるため個々の開発者の生産性は下がる」という見方が従来主流だったが、この結果はハイパフォーマーに限ってはこの通説が成立しないことを示す。(Source: ch.5 p.77-79) ## ツール選択の自律性 必要なツールをチームが選択できる場合、ソフトウェアデリバリのパフォーマンスが向上し、それが組織全体のパフォーマンスにも好影響を与えることが分析で立証された。あらかじめ承認されたツール・フレームワークしか選べない組織は、作業環境の複雑さの低減・技術管理スキルの確保・ベンダー購買力の強化・ライセンス管理の適正化を狙うが、こうした柔軟性に欠けるアプローチはチームが自分たちのニーズに最適なツールを選べず、新たなアプローチやパラダイムを試すことも妨げる。ただしインフラのアーキテクチャや構成に関しては標準化も悪くはなく、情報セキュリティの概念をデリバリのプロセスに組み込み、事前承認済みの使い勝手の良いライブラリ・パッケージ・ツールチェーンを用意することで自律性と標準化を両立できるとされる。(Source: ch.5 p.79-81) ## 横断的知見 - **第5章が提示する「疎結合アーキテクチャ」(モジュラーアーキテクチャ)と、第3章が確立する[[Westrumの組織文化類型]](創造的な組織文化)は、同一の調査研究が特定した「パフォーマンスの高いデリバリの予測要因」の異なる2軸として、第5章自身によって並置される**: 第5章は「パフォーマンスの高いデリバリの予測要因――目標志向の創造的な組織文化、モジュラーアーキテクチャ、継続的デリバリを促進する技術的プラクティス、優れた指導力――に焦点を当てれば」開発者1人当たりのデプロイ件数を直線的に増大させうると述べ、Westrumの組織文化類型(創造的な組織文化)とモジュラーアーキテクチャ(本ページ)を、開発者数拡大時の生産性向上という同じ帰結に寄与する並列の予測要因として扱う。両concept はそれぞれ独立した章(3章・5章)を出典とするが、同じ書籍内の別章どうしの突き合わせであっても、章ごとに全く異なる調査手法(3章はリッカート尺度による組織文化の測定、5章はアーキテクチャケイパビリティへの同意有無)で独立に確立された知見が、著者ら自身によって単一の予測モデルへ統合されている点は、2ソースを並べて初めて見える構造である。(Source: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 5 アーキテクチャのキーポイント]] ch.5 p.78-79, [[Westrumの組織文化類型]]) ## 未解決の問い - 現時点ではソースが第5章の1件のみのため、複数ソースの突き合わせによる横断的知見は今後の ingest で蓄積する。 - 「テスト容易性」「デプロイ容易性」という2つの特性への同意度を測定する具体的な質問文(リッカート尺度の文言)は第5章では明示されない。第13章(計量心理学)や原論文にあたって確認する必要があるか。 - 2017年調査で「テストとデプロイの自動化を凌ぐ最強の促進要因」となった6つのケイパビリティ(チーム外許可不要・他チーム非依存・オンデマンドデプロイ等)は、[[マイクロサービスアーキテクチャ]]概念が集約する Meta の実測データ(高チャーン・不均一トポロジ・浅く広いワークフロー)が示す「マイクロサービスの利点がそのまま診断困難性に反転する」という知見とどう整合するか。疎結合アーキテクチャがテスト・デプロイの独立性を高める一方で、診断(RCA)の困難性を高めるというトレードオフは、本ページのソースだけでは検証できない。 - 「逆コンウェイ戦略」を実際に採用した組織の事例研究は、本 wiki にどの程度蓄積されているか。[[コンウェイの法則]]概念が未解決の問いに残す同じ論点と接続する。 - サービス指向・マイクロサービスアーキテクチャの「成果の達成度の厳密なモニタリング」とは、具体的にどのような指標・手法を指すか。第5章はこの必要性を述べるが、測定方法自体には踏み込まない。 ## 関連 - 概念: [[コンウェイの法則]](チームとアーキテクチャの疎結合の理論的基盤) / [[マイクロサービスアーキテクチャ]](疎結合アーキテクチャの一実装形式、ただし十分条件ではない) / [[DORA]](疎結合アーキテクチャが向上させるデリバリパフォーマンスの計測フレームワーク) / [[Westrumの組織文化類型]](同一調査研究が特定する並列の予測要因) - ソース: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 5 アーキテクチャのキーポイント]] - 実体: [[Melvin Conway]] / [[Steve Yegge]] - 書籍: [[wiki/entities/LeanとDevOpsの科学［Accelerate］|LeanとDevOpsの科学［Accelerate］]] ## 出典 - Nicole Forsgren, Jez Humble, Gene Kim 著, 武舎広幸・武舎るみ 訳, 『LeanとDevOpsの科学［Accelerate］』, インプレス, 2018, 第5章.