翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# 組織と作業方法
すべてのアーキテクチャ戦略と同様に、マイクロフロントエンドは、組織が実装することを選択するテクノロジーをはるかに超えた意味を持ちます。マイクロフロントエンドアプリケーションを構築する決定は、ビジネス、製品、組織、運用、さらには文化 (チームの権限付与や意思決定の分散など) と一致する必要があります。見返りとして、このタイプのマイクロフロントエンドアーキテクチャは、真の俊敏性、製品主導の開発をサポートします。これは、独立しているチーム間の通信オーバーヘッドを大幅に削減するためです。
## アジャイル開発
アジャイルソフトウェア開発の概念は、ここ数年で非常に普遍的になり、事実上すべての組織がアジャイルに取り組むと主張しています。*アジャイル*の決定的な定義はこの戦略の範囲外ですが、マイクロフロントエンド開発に関連する主要な要素を確認する価値があります。
アジャイルパラダイムの基盤は [Agile Manifesto](https://agilemanifesto.org/) (2001) です。このマニフェストは、4 つの主要な原則 (プロセスやツールに対する個人とインタラクションなど) と 12 の原則を前提としています。Scrum や Scaled Agile Framework (SAFe) などのプロセスフレームワークは、Agile Manifesto を中心に出現し、日常的なプラクティスへの道を見つけました。ただし、その背後にある哲学は、ほとんど誤解されているか無視されています。
マイクロフロントエンドアーキテクチャでは、以下のアジャイル原則を採用することが重要です。
+ 「作業ソフトウェアを数週間から数か月の間で頻繁に配信し、より短いタイムスケールを優先します。」
この原則は、増分で作業し、ソフトウェアを可能な限り定期的に本番環境に配信することの重要性を強調しています。技術的な観点からは、継続的インテグレーションと継続的デリバリー (CI/CD) を指します。CI/CD では、構築、テスト、デプロイのためのツールとプロセスは、各ソフトウェアプロジェクトの不可欠な部分です。プリンシパルは、ランタイムインフラストラクチャと運用責任がチームによって所有されている必要があることも意味します。この所有権は、独立したサブシステムがインフラストラクチャと運用の要件を大幅に異なる可能性がある分散システムでは特に重要です。
+ 「意欲のある個人を中心にプロジェクトを構築します。必要な環境とサポートを提供し、ジョブを完了するために信頼します。」
「最高のアーキテクチャ、要件、設計は、自己組織化チームから生まれます。」
これらの原則はいずれも、所有権、独立性、end-to-endの責任の利点を強調しています。マイクロフロントエンドアーキテクチャは、チームがマイクロフロントエンドを真に所有している場合 (およびマイクロフロントエンドを所有している場合のみ) に成功します。構想から設計、実装、デリバリー、運用までEnd-to-endの責任により、チームは実際に所有権を行使できます。この独立性は、チームが戦略的方向性を自律させるために、技術的にも組織的にも必要です。ウォーターフォール開発モデルを使用する一元化された組織でマイクロフロントエンドプラットフォームを使用することはお勧めしません。
## チームの構成とサイズ
ソフトウェアチームが所有権を行使するには、組織が課す境界内で、チームが提供する方法と内容を含め、自らを管理する必要があります。
有効にするには、チームはソフトウェアを個別に配信でき、配信する最善の方法を決定する権限を持っている必要があります。これらの項目の計画に関与せずに、外部製品マネージャーまたは外部デザイナーから UI 設計から機能要件を受け取るチームは、自律的と見なすことはできません。機能は、既存の契約や機能に違反する可能性があります。このような違反には、さらなる議論と交渉が必要であり、配信が遅延し、チーム間で不要な競合が発生するリスクがあります。
同時に、チームが大きすぎないようにする必要があります。大規模なチームにはより多くのリソースがあり、個々の欠席に対応できますが、コミュニケーションの複雑さは新しいメンバーごとに指数関数的に増加します。普遍的に有効な最大チームサイズを記述することはできません。プロジェクトに必要な人数は、チームの成熟度、技術的複雑さ、イノベーションのペース、インフラストラクチャなどの要因によって異なります。例えば、Amazon は 2 つのピザのルールに従います。2 つのピザを食べるには大きすぎるチームは、小さなチームに分割する必要があります。これは難しい場合があります。分割は自然境界に沿って行われ、各チームに作業に対する自律性と所有権を与える必要があります。
## DevOps 文化
DevOps とは、開発ライフサイクルのステップを組織的および技術的な観点から緊密に統合するソフトウェアエンジニアリングプラクティスを指します。一般的な考え方とは対照的に、DevOps は文化と考え方に関するものであり、役割とツールに関するものはほとんどありません。
従来、ソフトウェア組織には、設計、実装、テスト、デプロイ、運用などのスペシャリストのチームがありました。チームがジョブを完了するたびに、プロジェクトを次のチームに引き渡します。ただし、専門チームのサイロ化によるソフトウェアの配信は、引き渡し中に摩擦を引き起こします。同時に、スペシャリストが狭い焦点で作業を強いられると、近隣のドメインに関する知識が不足し、製品の体系的なビューがありません。これらの障害により、ソフトウェア製品の一貫性が低下する可能性があります。
たとえば、ソフトウェアアーキテクトが別のチームの誰かによって実装されるソリューションを設計する場合、実装の固有の側面 (依存関係の不一致など) を見落としている可能性があります。その後、開発者はショートカット (猿のパッチなど) を使用するか、アーキテクトと開発チームの間で形式化されたback-and-forthが開始されます。これらのプロセスを管理するオーバーヘッドのため、開発はアジャイルではなくなりました (柔軟、適応的、段階的、非公式）。
DevOps という用語は主に文化に関連していますが、実際に DevOps を可能にするテクノロジーとプロセスを意味します。DevOps は CI/CD と密接に関連しています。開発者は、ソフトウェアの増分の実装を完了すると、Git などのバージョン管理システムにコミットします。従来、ビルドシステムはソフトウェアを構築して統合し、多かれ少なかれ統合され一元化されたプロセスでテストしてリリースしていました。CI/CD では、ソフトウェアの構築、統合、テスト、リリースが本質的に自動化されています。理想的には、プロセスは、特定のプロジェクトに合わせて特別に調整された設定ファイルを通じてソフトウェアプロジェクト自体の一部です。
できるだけ多くのステップが自動化されます。たとえば、ほぼすべてのタイプのテストを自動化できるため、手動テストのプラクティスを減らす必要があります。そのようにプロジェクトを設定すると、ソフトウェア製品の更新を 1 日に数回、高い信頼性で配信できます。DevOps をサポートするもう 1 つのテクノロジーは、Infrastructure as Code (IaC) です。
従来、IT インフラストラクチャのセットアップと保守には、ハードウェア (データセンター内のケーブルとサーバーのセットアップ) と運用ソフトウェアのインストールと保守を手動で行う必要があります。これは必要でしたが、多くの欠点がありました。セットアップに時間がかかり、エラーが発生しやすくなります。ハードウェアのプロビジョニングが過剰であったり、プロビジョニングが不足していたりすることがよくあり、過剰な支出やパフォーマンスの低下につながります。IaC を使用すると、クラウドサービスを自動的にデプロイおよび更新できる設定ファイルを使用して、IT システムのインフラストラクチャ要件を 記述できます。
これらはすべてマイクロフロントエンドとどのような関係がありますか? DevOps、CI/CD、IaC は、マイクロフロントエンドアーキテクチャの補完に最適です。マイクロフロントエンドの利点は、高速でスムーズな配信プロセスに依存しています。DevOps 文化は、チームがend-to-endの責任を負うソフトウェアプロジェクトを所有する環境でのみ実現できます。
## 複数のチームにわたるマイクロフロントエンド開発のオーケストレーション
複数の部門横断的なチームでマイクロフロントエンド開発をスケーリングする場合、2 つの問題が発生します。まず、チームはパラダイムの独自の解釈を開発し、フレームワークとライブラリの選択を行い、独自のツールとヘルパーライブラリを作成します。次に、完全自律型チームが、低レベルのインフラストラクチャ管理などの一般的な機能を担当する必要があります。したがって、マルチチームのマイクロフロントエンド組織に 2 つのチーム、つまり有効化チームとプラットフォームチームを導入することは理にかなっています。これらの概念は、分散システムを持つ最新の IT 組織で広く採用されており、[チームトポロジー](https://teamtopologies.com/key-concepts)で十分に文書化されています。
次の図は、3 つのマイクロフロントエンドチームにツール、ライブラリ、標準、テストを提供する有効化チームを示しています。プラットフォームチームは、同じ 3 つのマイクロフロントエンドチームにインフラストラクチャ、共有ランタイム機能、ドメインサービスを提供します。
プラットフォームチームは、マイクロフロントエンドチームを差別化されていない重労働から解放することで、マイクロフロントエンドチームをサポートします。このサポートには、コンテナランタイム、CI/CD パイプライン、コラボレーションツール、モニタリングなどのインフラストラクチャサービスが含まれます。ただし、プラットフォームチームを設定すると、開発がオペレーションからデタッチされる組織につながるべきではありません。逆に、プラットフォームチームはエンジニアリング製品を提供し、マイクロフロントエンドチームはプラットフォーム上のサービスの所有権とランタイム責任を負います。
有効化チームは、ガバナンスに重点を置き、マイクロフロントエンドチーム全体の一貫性を確保することでサポートを提供します。(プラットフォームチームはこれに関与しないでください）。有効化チームは UI ライブラリなどの共有リソースを維持し、フレームワークの選択、パフォーマンス予算、相互運用性規則などの標準を作成します。同時に、ガバナンスで定義されている標準とツールの適用に関するトレーニングを新しいチームまたはチームメンバーに提供します。
## デプロイ
マイクロフロントエンドチームの自律性の北の星は、他のマイクロフロントエンドチームから独立した本番稼働へのパスを持つ自動パイプラインを持つことです。共有なしの原則に従うチームは、独立したパイプラインを実装できます。ライブラリを共有したり、プラットフォームチームに依存するチームは、デプロイパイプラインの依存関係を管理する方法を決定する必要があります。
通常、各パイプラインは以下を実行します。
+ フロントエンドアセットを構築します
+ アセットをホスティングにデプロイして消費します
+ 新しいバージョンを顧客に配信できるように、レジストリとキャッシュが更新されていることを確認します
実際のパイプラインステップは、テクノロジースタックとページ構成アプローチによって異なります。
クライアント側の構成では、アプリケーションバンドルをホスティングバケットにアップロードし、CDN でのキャッシュを通じて消費に解放することを意味します。サービスワーカーでブラウザキャッシュを使用するアプリケーションでは、サービスワーカーキャッシュを更新する方法も実装する必要があります。
サーバー側の構成の場合、これは通常、サーバーコンポーネントの新しいバージョンをデプロイし、新しいバージョンを検出できるようにマイクロフロントエンドレジストリを更新することを意味します。Blue/Green または Canary デプロイパターンを使用して、新しいバージョンを徐々にロールアウトできます。