精読「マイクロサービスアーキテクチャ 第2版」(第三部 人 - 第15章 組織構造)
マイクロサービスアーキテクチャ 第2版
マイクロサービスの設計、実装、運用に必要なベストプラクティスや最新技術を解説した、実践的なガイドブックです。これを読めば、マイクロサービスに関してそれっぽい会話もできますよ。
関連記事
「ストリームアラインドチーム」を目指すアプローチでは、ユーザー向け機能提供にエンドツーエンドで責任を持つチーム構造が検討され、マイクロサービスがその実現を支援する役割を果たす。これらの概念をさらに具体化し、マイクロサービスを最大限活用するために必要な組織的な要件や課題についても考慮する必要がある。
疎結合の組織
疎結合の組織は、マイクロサービスを最大限活用する鍵。自律的に動けるチーム構造を構築し、権限と責任を分散させる必要がある。これにより、他チームへの依存を減らし、迅速なデリバリと高いROIを実現する。
コンウェイの法則
コンウェイの法則は、システム設計が組織のコミュニケーション構造を反映するという原則。この法則は、疎結合な組織が疎結合なアーキテクチャを生み出し、その逆も成り立つことを示している。そのため、疎結合アーキテクチャの利点を得るには、組織構造の検討が不可欠。
証拠
コンウェイの法則は、多くの実例や研究によって検証されている。たとえば、Microsoftの研究では、組織構造がシステムのエラー率に大きく影響することが示された。また、Amazonは「2枚のピザチーム」を採用し、小規模なチームがシステムのライフサイクル全体を管理することで効率を高めた。Netflixもこの考えを取り入れ、独立した小規模チームを基盤に組織を設計し、変化に対応可能なアーキテクチャを実現した。これらの事例は、システム設計が組織構造と密接に結びついていることを強調している。
チームサイズ
ソフトウェア開発チームは5～10人が理想で、9人以上になると生産性が低下する傾向がある。小規模チームはコミュニケーションや調整がしやすく、目標に集中しやすいのが利点。一方で、作業量が増えても人員追加だけで効率が上がるわけではないため、複数の小規模チームで連携する方法を検討する必要がある。
コンウェイの法則を理解する
組織構造はシステム設計に影響を与える（コンウェイの法則）。疎結合なアーキテクチャと、それに対応した組織構造を実現することで、以下の効果が得られる。
-
デリバリパフォーマンスの向上
速度と安定性が高まり、デプロイの負担が軽減。 -
スケール拡大の効率化
エンジニアリング組織の規模拡大に伴い、生産性が線形またはそれ以上に向上。
集中型の意思決定は大規模組織では対応速度を低下させるため、自律的で効率的な分散型チームが重要。鍵は、小規模で自律的なチームを構築し、それらを組み合わせて大きな組織を形成すること。
小さなチーム、大きな組織
小規模で自律的なチーム（例: Amazonの「2枚のピザ」チーム）が調整コストを減らし、効率的に動けると示されている。一方で、ブルックスの法則では、遅れたプロジェクトへの人員追加は逆効果と指摘。効果的な組織設計には、疎結合な構造やチーム間連携を明確にする「チームAPI」が重要。これをプロジェクトに活かせば、効率向上につながるだろう。
自律性
組織が成功するためには人に自信や自由を与え、自律性を持たせることが重要。自律性を持つ小規模なチームが他のチームに依存せず、自ら判断し、実行できる環境を作ることで効率的に成長できる。これを達成するためには、組織における自律性を理解し、他の組織のモデルを学びつつ、その理由を理解することが大切。
強い所有権と共同所有権の比較
マイクロサービスにおける所有権には「強い所有権」と「共同所有権」の2種類がある。
-
強い所有権
1つのチームがマイクロサービスを完全に所有し、変更はそのチームが決定。外部チームは変更依頼やプルリクエストが必要。 -
共同所有権
任意のチームがマイクロサービスを変更できるが、調整が必要で、競合のリスクがある。
強い所有権は自律性を高め、共同所有権は柔軟性を提供するが、調整が重要。
強い所有権
強い所有権モデルでは、1つのチームがマイクロサービスを完全に管理し、コード変更、技術選定、デプロイなどを独自に決定する。このモデルの利点は、チームの自律性を高め、外部との調整を最小限にすること。フルライフサイクル所有権では、マイクロサービスの設計から運用、廃棄までを1つのチームが担当し、さらに自律性が向上する。ただし、このモデルを実現するためには、必要なスキルやツール、文化の変化が求められ、特に大規模な組織では時間がかかる場合もある。
共同所有権
共同所有権モデルでは、複数のチームが1つのマイクロサービスを変更できるため、必要に応じて人員を柔軟に移動できる利点がある。例えば、ボトルネック解消のために追加の人員を投入できる場合がある。しかし、頻繁にチームが異なるマイクロサービスを担当する場合、技術選定やデプロイモデルにおいて一貫性を保つことが難しくなる。高度な調整が必要となり、結果として組織内の結合度が高くなる可能性がある。このような密結合は、マイクロサービスの本来のメリットである独立したデプロイ可能性を損なう恐れがある。
チームレベルと組織レベルの比較
チームレベルと組織レベルでの強い所有権と共同所有権の適用については、以下のような違いがある。
チームレベルでは、メンバーが同じ考えを持ち、効率的に連携するために高度な共同所有権を持つことが望ましい。例えば、チームの全メンバーがコードベースを直接変更できる状態が挙げられる。このようなチームは、エンドツーエンドのデリバリーに焦点を当て、多様なスキルを持ち、共同所有権を持つことに優れている必要がある。
組織レベルでは、チームに高い自律性を持たせることが重視される。この場合、チームが強い所有権モデルを採用していることが重要。自律性を高めることで、チームがより独立して意思決定を行い、効率的に動けるようになる。
モデル間のバランスを取る
共同所有権を追求するほど、一貫性が重要になる。大域的な一貫性と局所的最適化のバランスは、組織の状況に応じて変化する。強い所有権を目指すと、局所的な最適化が許容されるが、基本的には大域的な一貫性を高める方向に進む。優れた組織は、このバランスを常に評価し、最適化を模索している。
イネイブリングチーム
イネイブリングチームは、ストリームアラインドチームをサポートする役割を果たす。特に、複数のチームが直面する共通の課題を解決するために働き、チーム間での協力を促進する。例えば、異なるプログラミング言語の選択がもたらす影響や、テストデータの起動問題に対処するために、イネイブリングチームが介入し、問題を解決することが求められる。アーキテクトの役割もイネイブリングチームにおいて重要で、分散型組織では、アーキテクトが他チームの支援役として機能する。
EC／CRMの自社サービス開発をマネジメントするようになって1年でやってきたこととこれから #devio2022 by @masaru_b_clより
実践コミュニティ
実践コミュニティ（CoP）は、相互学習や知識共有を促進する横断的なグループであり、組織内で継続的に学習と成長を支える重要な役割を果たす。イネイブリングチームと実践コミュニティはどちらも組織の知見を深め、最適化のバランスを取るために重要な役割を担うが、イネイブリングチームは実行に移すためにフルタイムで関わることが多いのに対し、実践コミュニティは学習に重点を置き、比較的流動的な参加が一般的。両者は連携し、イネイブリングチームが必要とする知見を提供し合うことができる。
プラットフォーム
ストリームアラインドチームは、プラットフォームを活用することで、インフラ管理の手間を減らし、新機能のデリバリに集中できるようになる。プラットフォームは、開発者が自律的に作業できる環境を提供し、作業の効率化を支援する。プラットフォームは「舗装道路」のように、簡単で正しい方法を提供するが、強制せず、柔軟に使える道を開く。組織は、プラットフォームを使う理由を明確にし、その使いやすさを保つことが重要。
共有マイクロサービス
私はマイクロサービスの強い所有権モデルを支持しているが、複数チームでの所有が一般的。その理由を理解し、懸念に対応できる代替モデルを見つけることが重要。
分割が難しすぎる
マイクロサービスの分割が難しい理由の一つは、分割コストが高すぎるか、組織がその重要性を理解していないから。大規模なモノリシックシステムではよく見られる問題で、これに対処するためには、アーキテクチャの見直しやチームの統合を検討することが有効。
横断的変更
横断的変更を減らすことを目的とし、可能な限り調整を少なくする。しかし、横断的変更が避けられない場合もある。FinanceCoでは、単一アカウントで1人のユーザーを結びつけるモデルから、複数ユーザー対応のモデルに変更する必要が生じた。この変更には多くのマイクロサービスの修正が必要で、調整が非常に大変だった。最終的には、組織再編が必要となり、それが別の横断的変更を引き起こした。FinanceCoは、この変更を容認できる例外的なものとして受け入れた。
デリバリのボトルネック
マイクロサービスを複数チームで共有する主な理由の1つは、デリバリのボトルネックを回避すること。例えば、MusicCorpでは、ユーザーが楽曲ジャンルを閲覧できる機能を製品全体にロールアウトし、さらに着信音という新たな在庫を追加するために、Webサイトチームとモバイルアプリチームが共同でCatalogサービスを変更する必要がある。しかし、チームの半分が他の障害対応に追われ、もう半分が休養中の場合、どのように対応すべきかが課題となる。選択肢としては、Webサイトチームとモバイルアプリチームが別の作業を進めるか、カタログチームに人員を追加して作業を加速させる方法が考えられる。また、サービスを分割することも一つの手段であり、着信音関連の機能が積み上がっている場合、モバイルチームに所有権を持たせることが理にかなっている。
社内オープンソース
社内オープンソースは、共有コードベースの管理を効率化し、チーム外のメンバーも変更に貢献しやすくする仕組み。少人数のコアコミッターがコード管理の責任を持ち、他のメンバーはプルリクエストを通じて変更を提案する。担当者が異動してもコミッターとして関与を続けられる仕組みが重要で、適切なツールを整備することで、プルリクエストや協力がスムーズに進む。この仕組みは組織内でも有効に機能する。
コアコミッターの役割
コアコミッターは、コードの品質を維持し、一貫性のある構築方法を確保するために、変更を審査・承認する重要な役割を担う。審査では、提案者と協力し、コーディング指針に沿った変更を適用するため、適切なコミュニケーションと労力が求められる。
一方で、門番としての役割には時間がかかり、悪い門番は権力の濫用や技術論争を引き起こすリスクがある。信頼できないコミッターの提案を受け入れる場合、審査の負担がプロジェクト全体に利益をもたらすかを慎重に判断する必要がある。コアチームは、この役割に割く時間が生産的であるかを検討することが求められる。
成熟度
サービスの成熟度が低い段階では、適切な変更提案が難しく、コアチーム以外の貢献は制限されるべき。成熟し安定したサービスでは、他チームからの貢献を受け入れる時期となる。このモデルはオープンソースでも一般的。
ツール
社内オープンソースモデルを支えるには、プルリクエスト対応の分散バージョン管理や、パッチの議論・レビューを可能にするツールが必要。また、ビルド・デプロイのパイプラインや集中型リポジトリを整備し、技術スタックを標準化することで、他チームの貢献を促進できる。
プラグ可能なモジュラーマイクロサービス
FinanceCoでは、各国チームが中央マイクロサービスに大量のプルリクエストを送る現状があり、中央チームの負担が持続不可能。課題解決には、以下の2つの方法が提案されている。
-
モジュラーフレームワーク
共通機能を中央が提供し、各国がプラグインで拡張。柔軟性は高いが初期構築が困難。 -
ライブラリ方式
各国の機能をライブラリ化して中央に組み込む。軽量だが、中央に依存しやすい。
どちらも課題があり、慎重な選定が必要。
変更のレビュー
変更のレビューは、開発の重要な部分で、特にピアレビュー（同じチーム内のメンバーによるレビュー）が効果的。外部のレビューは時間がかかり、パフォーマンスに悪影響を与える可能性が高いため、一般的には避けるべき。ペアプログラミングでは即時レビューが行われ、効果的。レビューは可能な限り同期的に行うべきで、迅速なフィードバックが重要。また、アンサンブルプログラミングはグループ全体で変更を行う方法ですが、適切な環境を整える必要がある。
孤立したサービス
孤立したサービスは、活発なメンテナンスがされないと問題が発生する可能性がある。特に小さなマイクロサービスは、機能が少ないため、しばらく変更が必要ない場合もある。しかし、変更が必要になったとき、サービスの所有者が明確でない場合、対応が難しくなることがある。例えば、Shopping Basketサービスが数ヶ月間変更されていない場合でも、変更が必要になれば、その責任は元の担当チームにある。問題は、技術スタックが複雑になりすぎて、チームがその技術に対応できなくなる場合に顕著。
ケーススタディ: realestate.com.au
realestate.com.au（REA）の事例では、事業部門ごとにスクワッドを配置し、各スクワッドがサービスのライフサイクル全体を管理。AWSや自動化を活用してチームの自律性を高め、効率的なデリバリを実現した。この自律性が市場投入までの時間を短縮し、数百のサービスの運用に貢献した。システムアーキテクチャと組織構造の適応力が成功の鍵となった。
地理的分散
地理的に分散したチームの場合、同期コミュニケーションが難しくなり、調整コストが増加する。例えば、オーストラリアに拠点を置き、インド、英国、ブラジル、米国と連携していた経験では、会議は月1回程度で、重要な課題のみを議論した。それ以外は非同期でメールを使用したが、時間差による遅延が問題となった。最終的には、各拠点での作業の専門化が進み、異なる拠点のチーム間で粗い粒度のコミュニケーションが行われた。地理的境界を考慮して、チームとソフトウェアの境界を定義することが重要。分散チームを作る場合、同じまたは近いタイムゾーンにチームメンバーを配置することで、非同期コミュニケーションの必要性を減らし、円滑なコミュニケーションを促進できる。
逆コンウェイの法則
システム設計が組織を変えることができるかという点について、逆コンウェイの法則が成り立つ事例もある。例えば、ある大手印刷会社の事例では、最初はWebサイトが事業運営において重要ではなく、システム設計も独断的な判断で行われた。しかし、その後、事業の印刷部門が縮小し、デジタル部門が成長する中で、システム設計が組織構造に影響を与え、事業のIT部門が入力、コア、出力の3つの部分に分かれて連携するようになった。このように、システム設計が組織の成長を促進し、最終的に組織構造の転換を必要とすることに繋がった。
人
マイクロサービス環境では、開発者は他のシステムとの連携や障害の影響を意識する必要がある。自律性を高めるための権限移譲は慎重に行うべきで、段階的な変化が重要。また、メンバーの責任を明確にし、必要なスキルを補うためには適切な人材を採用することが重要。
まとめ
コンウェイの法則は、組織に合わないシステム設計を強制する危険を再認識させる。特にマイクロサービス環境では、強い所有権を持つモデルが標準であり、共有や共同所有を試みるとその利点が損なわれることが多い。組織とアーキテクチャが一致していない場合、緊張関係が生じる。この関係を理解することで、構築するシステムが組織にとって有意義か確認できる。さらに調べたい場合は、「Team Topologies」やJames Lewisの講演「Scale, Microservices and Flow」もおすすめ。
参考
Discussion