モジュール型アーキテクチャと開発チームの連携

兆候の認識

善意をもってしても、ソフトウェアは時間の経過とともに品質とパフォーマンスの両面で劣化することがよくあります。機能が市場に出るまでに時間がかかり、サービス停止がより深刻になり、解決に時間がかかるようになり、その結果、製品に取り組む人々は不満を抱き、疎外感を感じるようになります。これらの一部はコードとその保守に起因すると考えられます。しかし、コードの品質だけを責めるのは、多面的な問題であるため、ナイーブな感じがします。劣化は、製品の意思決定、コンウェイの法則、技術的負債、静的なアーキテクチャが複雑に絡み合って時間の経過とともに進行する傾向があります。

ここで、この記事の基盤となる組織を紹介するのが妥当でしょう。大企業であるこの企業は、リテールモバイルアプリケーションに新しい機能を追加するのに時間が徐々に長くなっているという問題に直面していました。

まず、組織は、アプリが成長するにつれて複雑さが増したことが摩擦の原因であると正しく認識していました。既存の開発チームは、既存の機能と一貫性のある機能を一貫して追加するのに苦労していました。これに対する最初の反応は、「単に開発者を増やす」ことでした。そして、これはある程度まで効果がありました。しかし、最終的に、開発者を増やすと、技術リーダーが増加した調整オーバーヘッドを感じ始めるため、コミュニケーションがより困難になることが明らかになりました。そのため、Amazonで推奨されている2ピザチームルールがあります。どのチームも2枚のピザで十分な人数であるべきです。この理論は、チームの規模を制限することで、コミュニケーション管理が実際の価値創造よりも時間がかかる状況を回避できるというものです。これは健全な理論であり、Amazonにうまく機能しています。しかし、単に大きくなりすぎた既存のチームを考えると、その負担を軽減するためにAmazonの例を「カーゴカルト化」する傾向があります。

認知負荷の制限

実際、この組織も例外ではありませんでした。かつては小さかったモノリスはますます成功を収めていましたが、機能、責任、チームメンバーが増加するにつれて、必要な成功率を再現することができなくなっていました。差し迫った機能デリバリーの締め切りと、視野に入っている複数のブランド市場を見据えて、既存のチームを複数の小さく接続されたサブチームに分割して対応しました。各チームは、個々の市場を管理するために隔離されました（顧客ジャーニーは似ていますが）。

実際には、これにより、技術リーダーシップから実際のチーム自体にコミュニケーションの負担が移行し、拡大するコンテキストの負荷が軽減されなかったため、事態は悪化しました。コミュニケーションと調整が実際の価値創造を担当する人々の時間をますます奪っていることに気づき、私たちの最初の提案には、Skelton & Pais（2019）が概説した「認知負荷の制限」という考え方が含まれていました。これには、単一の複雑なドメインまたは複雑なドメインにまたがってチームを分離することが含まれます。ソフトウェア内部のこれらの境界は、前述の「2ピザサイズのチーム」を構成するために使用できます。その結果、各チームのオーバーヘッドは大幅に減少します。モチベーションが向上し、ミッションステートメントが明確になり、コミュニケーションとコンテキストの切り替えが単一の共有焦点にまで縮小されます。これは理論上はクライアントの問題に対する素晴らしい解決策でしたが、単独で考えると実際には誤解を招く可能性があります。認知負荷の制限からのメリットは、アプリケーションのドメイン境界が本当に明確に定義され、コード内で一貫して尊重されている場合にのみ、真に実現できます。

ドメイン駆動の規律

ドメイン駆動設計（DDD）は、複雑なロジックを管理可能なグループに整理し、それぞれに共通の言語またはモデルを定義するのに役立ちます。ただし、アプリケーションをドメインに分割することは、継続的なプロセスの一部にすぎません。境界付けられたコンテキストを厳密に管理することは、ドメイン自体を定義するのと同じくらい重要です。クライアントのアプリケーションのコードを調べると、ドメインの責任を正確に定義および整理するという明確な初期投資の一般的な罠に遭遇しました。アプリケーションが成長するにつれて、その規律が侵食され始めたのです。関係者からの逸話的な証拠では、緊急の製品要件に駆り立てられた、常に多忙なチームが近道を取ることがチームの常態化していたことが示唆されました。これにより、技術的負債の蓄積により、価値提供の漸進的な遅延につながりました。これは、コードのリリースがより困難になり、問題のデバッグがより困難になるにつれて、アプリケーションの4つの主要指標の測定可能な低下によってさらに強調されました。

適切に管理されていない境界付けられたコンテキストのさらなる警告サインは、一般的なコード分析ツールを通じて発見されました。密結合になり、凝集性に欠けるコードベースが見つかりました。高度に結合されたコードは、システム内の他の部分に影響を与えることなく変更することが困難です。凝集性の低いコードには、その範囲に適合しない多くの責任と懸念があるため、その目的を理解することが困難です。これらの問題は両方とも、クライアントのアプリ内の各ドメインの複雑さが成長するにつれて、時間の経過とともに悪化していました。他の兆候は、再び認知負荷に関連して示されました。アプリケーション内のドメイン間の境界または依存関係が不明確であるため、1つのドメインに変更を加えると、他のドメインに意図せずに影響を与える可能性がありました。このため、開発チームは、破損する可能性のあるものを解決するために複数のドメインの知識が必要になり、認知負荷が増加していることに気づきました。組織にとって、各ドメインの境界付けられたコンテキストを厳密に管理することは、知識と責任が同じ場所にあることを保証する上で漸進的な前進でした。これにより、変更の「影響範囲」が、必要な作業量と知識の両面で制限されました。さらに、技術的負債の発生と対処においてより厳密な管理を導入することで、短期的な「ドメイン漏えい」が拡大する前に拒否または是正できることが保証されました。

組織のモバイルアプリケーションで欠落していたもう1つの指標は、再利用のオプション性でした。前述のように、既存の成熟したブランド市場アプリケーションが複数ありました。これらのアプリケーション間での機能パリティは低く、個々の市場の自律性を望むため、単一のモバイルアプリに統合することは困難でした。システム全体の密結合により、他の場所でドメインを再利用する能力が低下していました。あるドメインを別の市場で再利用するために、既存のモバイルアプリのほとんどを移植する必要があったため、統合コストと継続的な管理コストが高くなりました。適切なドメイン境界付きコンテキストの管理の活用は、他のドメインへの直接的な依存関係を抑制することにより、モジュール化への第一歩として有効でした。しかし、私たちが知ったように、それだけが実行する必要のあるアクションではありませんでした。

アプリを超越するドメイン

シナリオ1 - 「整理されたモノリス」

単一のアプリケーションとして単独で考えると、単にアプリをドメインに分割し、チームを割り当て、その結合を管理する（境界付けられたコンテキストを侵害しないように）ことは非常にうまく機能します。個々のアプリケーションへの機能リクエストの例を見てみましょう。

機能リクエストは、関連するドメインを所有するアプリチームに渡されます。厳密に境界付けられたコンテキストは、変更の影響範囲がそれ自体の中に収められていることを意味します。つまり、機能の構築、テスト、さらにはアプリケーションの別の部分を変更することなくデプロイできます。市場投入までの時間を短縮し、複数の機能を同時に個別に開発できるようにします。素晴らしい！

実際、これは単一の市場コンテキストではうまく機能しました。しかし、2番目のスケーリング問題である再利用性の欠如から生じる市場機能の不一致に対処しようとした途端、問題が発生し始めました。

シナリオ2 - 「次の市場機会」

ドメインのモジュール化を追求する組織の次のステップは、「整理されたモノリス」の一部を既存の市場アプリケーションに移植することで、開発を迅速化することでした。これには、機能/ドメインが元の場所の外にあるモバイルアプリケーションで再利用できるようにする共通フレームワークの作成（後で触れます）が含まれていました。私たちの方法論をより良く説明するために、以下の例は、英国の市場アプリケーションと、米国を拠点とする新しいアプリの2つの市場アプリケーションを示しています。米国を拠点とするアプリケーションチームは、米国固有のドメインに加えて、アプリケーションの一部としてロイヤルティポイントとチェックアウトドメインの両方を利用したいと考え、それらをインポートしました。

組織にとって、これは市場チームが従来のドメイン機能を書き換える行動に比べ、開発コストを桁違いに節約できることを意味するようでした。しかし、これで終わりではありませんでした。モジュール化を急ぐあまり、私たちは組織の既存のコミュニケーション構造が、最終的に作業の優先順位を決定するということを考慮していなかったのです。以前の例を説明のために発展させます。アメリカのチームは、自分たちの市場でドメインを使用した後に、インポートしたドメインの1つに新しい機能のアイデアを思いつきました。彼らはそのドメインを所有しておらず、コンテキストも持っていないため、イギリスのアプリケーションチームに連絡して機能リクエストを提出しました。イギリスのチームはリクエストを受け入れ、「素晴らしいアイデアだ」と認めましたが、「現在はイギリスの利害関係者からのリクエストに対応しているため」、いつその作業に取り掛かれるかは不明確でした...

私たちは、ドメイン機能の優先順位付けにおけるこの利益相反が、共有機能の利用者が期待できる再利用の量を制限することを発見しました。これは、市場チームがインポートしたドメインからの進捗の遅さに不満を抱くことで明らかになりました。私たちはこの問題に対するいくつかの解決策を理論化しました。利用チームは、おそらく独自のドメインのフォークを作成し、それを中心にチームを編成することができるでしょう。しかし、すでに知っているように、少量の機能を追加するためにドメイン全体を学習/所有することは非効率的であり、分岐は市場間の将来のアップグレードや機能パリティの共有にも問題を引き起こします。私たちが検討したもう1つのオプションは、プルリクエストによる貢献でした。しかし、これは貢献チームに独自の認知負荷を課しました。つまり、2番目のコードベースで作業することを強制され、一方でプライマリドメインチームからのクロスチーム貢献のサポートに依存する必要がありました。たとえば、ドメインチームが、自分たちの市場の機能開発の合間に、アーキテクチャガイダンスやPRレビューを提供するのに十分な時間があるかどうかは不明確でした。

シナリオ3 - 「市場に依存しないドメイン」

明らかに問題は、私たちのチームがどのように組織化されていたかにありました。コンウェイの法則は、組織がそのビジネスシステムを、組織自身のコミュニケーション構造を反映するように設計するという観察です。以前の例は、機能は技術的な観点からはモジュール化されているが、所有権の観点からは依然としてモノリシックであるというシナリオを説明しています。「ロイヤリティポイントはもともとイギリスのアプリケーションのために作成されたため、そのチームに属しています」。これに対する潜在的な対応の1つは、逆コンウェイ操作で説明されています。これには、選択された技術アーキテクチャが出現できるように、開発チームの構造を変更することが含まれます。

以下の例では、以前のシナリオから進歩し、以前に行ったモジュール式アーキテクチャを反映するようにチームを構造的に変更します。ドメインは特定のモバイルアプリから抽象化され、代わりに自律的な開発チーム自体になります。これを行ったとき、アプリチーム間の関係が、市場間の機能に依存しなくなったため変化したことに気づきました。その代わりに、消費者とプロバイダーという観点からより適切に説明できる新しい関係が形成されていることがわかりました。私たちのドメインチームは、市場の顧客に機能を提供し、顧客はそれを消費し、ドメイン製品をより良く開発するための新しい機能リクエストをフィードバックしました。

この再編が以前のイテレーションよりも優れている主な利点は、焦点を明確にしたことです。以前は、ある市場が別の市場内で発生したドメインを変更するリクエストを行ったときに発生した利益相反について説明しました。ドメインを市場から抽象化することで、市場の利益のためだけに機能構築することから、より包括的な、消費者のニーズを満たす機能を構築するという使命に焦点を移しました。成功は、消費者の利用率とエンドユーザーからの評価の両方で測定されるようになりました。新しい機能は、ドメインとその消費者全体にもたらす価値の量のみに基づいてレビューされました。

モジュール性をサポートするための開発者エクスペリエンスに焦点を当てる

要約すると、組織は現在、市場全体でコンポーネントのモジュール化をサポートするトポロジカル構造を持つようになりました。自律的なチームは、所有および開発するドメインに割り当てられました。市場アプリは、構成コンテナに簡略化されました。概念的には、これはすべて理にかなっています。消費者からプロバイダーへのフィードバックの流れを簡単にプロットできます。また、「すべてのドメインは独立して開発/展開される」や「消費者は、アプリケーションを形成するために必要な再利用可能なドメインを「ただ」プルインする」といった、高いレベルのユートピア的な仮定を立てることもできます。

しかし、実際には、これらは解決が難しい技術的な問題であることがわかりました。たとえば、自律的なドメインチーム間でUX/ブランドの一貫性をどのように維持しますか？アプリケーション全体の一部のみを担当している場合、どのようにモバイルアプリ開発を可能にしますか？ドメインの発見可能性をどのように許可しますか？テスト可能性は？市場間の互換性は？これらの問題を解決することは完全に可能ですが、それ自体に認知負荷を課します。この責任は、現在の構造では明確な所有者がいませんでした。そこで、私たちはオーナーを作りました！

結果

モバイルアプリをどのようにモジュール化したかの話をしましたが、時間の経過とともにどれほど成功しましたか？経験的な証拠を得ることは困難です。私たちの経験では、同じ組織内で、両方の配信メトリックを使用して、レガシーアプリと新たにアーキテクチャされたアプリが同じドメインを使用するというシナリオは、あまり頻繁には発生しません。ただし、このケースでは幸運なことに、組織は一度に1つのアプリケーションを移行するのに十分な大きさでした。これらの結果については、機能的に類似した2つの小売アプリを比較します。1つは、結合度が高く、凝集度が低いレガシーアプリですが、非常に生産性が高く成熟した開発チーム（「レガシーモノリス」）を備えています。もう1つは、以前に説明したモジュール式リファクタリング演習の結果である、明確に定義され、管理された境界コンテキストですが、（「ドメイン境界コンテキストアプリ」）をサポートする「新しい」個々のドメインチームがあります。サイクル時間は、コードの変更を「作成」するのにかかる時間を表し、アプリをストアにプッシュする時間は含まれないため、ここでは適切な指標です。アプリの種類には影響しない可変長のプロセスです。

2番目のアプリのすべてのドメインチームでサイクル時間を平均した場合でも、経験の浅いチームがいるレガシーアプリと比較して大幅な向上が見られました。

2番目の比較は、再利用のオプション、またはその欠如に関するものです。このシナリオでは、組織内の同じ2つのモバイルアプリを調べます。ここでも、既存のドメイン機能を（自分で記述する以外に選択肢がない）必要とするものと、モジュール式アプリ（既存のドメインをプラグアンドプレイできる）を比較します。測定対象に影響しないため、本番環境へのパスの共通ステップは無視します。代わりに、開発チームの制御下にある側面に焦点を当て、プリプロダクションの「製品サインオフ」から、デザイナーとフルタイムで作業する1組の開発ペアの開発完了までの開発プロセスを測定します。

上記の劇的に異なる数値は、ビジネスニーズがある設定におけるモジュール式アーキテクチャの威力を示しています。

余談ですが、除外したこれらの外部要因も測定する価値があることに言及しておきます。開発パフォーマンスを最適化すると、全体的なプロセスにおける他のボトルネックが明らかになる可能性があります。たとえば、リリースを作成するのに6か月かかり、ガバナンス承認に1か月かかる場合、ガバナンスはプロセスのごく一部です。しかし、開発期間を5日に短縮できても、承認に1か月かかる場合、コンプライアンスが次に最適化すべきボトルネックになる可能性があります。

上記の成果には表れていませんが、ドメインを中心に組織されたチームが統合活動に与える影響も利点の一つです。自律的なドメインチームは、活動を迅速化するために、市場アプリケーションチームに自然に協力していることがわかりました。これは、ドメイン製品の成功がその採用によって得られるという、ドメインチームの焦点の変化に起因すると考えられます。

採用率に影響を与える2つの同心円状のフィードバックループを発見しました。外側のループは、ドメインの消費者（つまり、アプリコンテナ）からの優れた統合エクスペリエンスです。これは、消費者が全体的なブランド固有の製品提供の一部として、ドメインをどれだけ簡単に構成および実装できるかによって測定される、開発者中心のフィードバックループです。内側のループは、優れたエンドユーザーエクスペリエンスです。統合されたドメインを含む全体的なジャーニーが、消費者の市場顧客にどれだけ受け入れられているかです。消費者エクスペリエンスが悪いと、採用に影響を与え、最終的にはドメインチームがその機能の実際のユーザーから遮断されるリスクがあります。消費者チームと密接に連携し、エンドユーザーに直接アクセスできるドメインチームは、フィードバックループが最も速く、結果として最も成功していることがわかりました。

最後に言及する価値のある比較は、プラットフォームドメインから得られたものです。新しいドメイン機能の開始は時間のかかる活動であり、機能の全体的な開発コストを増加させます。前述したように、プラットフォームチームは、プロセスにおける問題点を特定し、それらを最適化することによって、開発者のエクスペリエンスを向上させ、この時間を短縮することを目指しています。このモデルをモジュール型アーキテクチャ内のドメインチームに適用したところ、チームごとの起動コストが80％以上削減されることがわかりました。ペアであれば、チーム開発の最初の1週間に見積もられていた活動を午後に達成することができました！

制限事項

これで、モバイルにおけるモジュール型アーキテクチャの利点について、かなり良いイメージを持つことができたはずです。しかし、問題を抱えたモノリシックアプリにハンマーを振り下ろす前に、これらのアプローチの限界を念頭に置いておく価値があります。まず、そして最も重要なこととして、このようなアーキテクチャの変更には、多くの継続的な時間と労力が必要です。これは、市場投入までのスピードに関する深刻な既存のビジネス上の問題を解決するためにのみ使用する必要があります。第二に、ドメインチームに自律性を与えることは、祝福にも呪いにもなりえます。当社のプラットフォームチームは、適切なデフォルトの形で共通の実装を提供できますが、最終的な選択はチーム自身に委ねられます。当然のことながら、市場アプリに組み込まれたり、受け入れられたりすることを望む場合、共通のUI/UXなどのプラットフォーム要件に合致することは、ドメインチームの利益になります。ただし、類似の内部依存関係や折衷的な設計パターンから生じる肥大化を管理するのは難しいことです。この問題を無視して、アプリ全体が制御不能に成長することを許容すると、顧客の手でパフォーマンスが低下する原因になります。ここでも、強力なガードレールとガイドラインと組み合わせて、技術的リーダーシップへの投資が、アーキテクチャ/設計の監督、ガイダンス、そして何よりもコミュニケーションを提供することによって、この問題を軽減するのに役立つことがわかりました。

まとめ

まとめると、この記事の冒頭で、マルチアプリ戦略を持つ組織に見られる2つの重大な配信の問題を特定しました。新しい機能を本番環境に導入するのにかかる時間の長期化と、他の類似の社内アプリケーション間の機能の不均衡の増加です。これらの問題の解決策は、技術アーキテクチャ、チーム構造、または技術的負債に関する単一の戦略にあるのではなく、これらの側面すべてが同時に進化する複合体にあることを実証しました。まず、望ましいモジュール型およびドメイン中心のアーキテクチャをサポートするようにチーム構造を進化させることで、認知的およびコンテキスト上の負荷がどのように改善されるかを示しました。また、チームが他のチームから独立して開発する自律性をどのように提供するかを示しました。この自然な進展は、チームとドメインを、その発生元のアプリケーション/市場にとらわれないようにすることであり、これがアプリケーションモノリスに固有のコンウェイの法則の影響をどのように軽減するかを示しました。この変更により、消費者/プロバイダーの関係が自然に発生することがわかりました。最後に行った同時シフトは、チームとドメインの分離の結果として観察された中心的な問題を解決するための「プラットフォーム」ドメインの特定と投資でした。

これらの側面をすべて組み合わせると、市場アプリケーションのすべてのモジュール型ドメインで平均してサイクルタイムが60％削減されたことを実証できました。また、モジュール型ドメインを市場アプリに統合する場合、ゼロから作成するのではなく、開発コストが18倍向上したこともわかりました。さらに、エンジニアリングの効率性に焦点を当てることで、新しいドメインの起動コストが80％削減され、「プラットフォームチーム」が提供する継続的なサポートにより、モジュール型アーキテクチャが繁栄することができました。クライアントにとって、これらの節約は、以前は労力に見合うROIが低すぎると考えられていた市場機会、つまり、長年競合他社の独壇場であった機会を活用できることを意味しました。

重要なポイントは、チームに内在的にリンクされたモジュール型アーキテクチャは、適切な状況下では組織に非常に有益である可能性があるということです。強調した組織での私たちの期間からの結果は優れていましたが、それはこの個別のケースに固有のものでした。行動を起こす前に、自分の状況を理解し、兆候とアンチパターンを探してください。さらに、私たちが説明したようなエコシステムをまとめるには、先行投資と継続的な努力が必要になることを過小評価しないでください。拙速な取り組みは、解決するよりも多くの問題を引き起こす可能性が高いでしょう。しかし、自分の状況は範囲が独特であるため、「カーゴカルト」の引き付けに抵抗し、共感、自律性、および同時にアーキテクチャを可能にするコミュニケーションラインに焦点を当てることで、私たちが目にした成功を再現できるすべての理由があります。