Xapo Bankにおけるアーキテクチャの実践の分散化

はじめに

ソフトウェアシステムの構築におけるソフトウェアアーキテクチャの役割は、長らく議論されてきました。ほとんどの組織では、「エンタープライズアーキテクチャ」という名の下に、何らかの「アーキテクチャ」機能が見られます。これは通常、すべてソフトウェアが業界および会社の標準に準拠し、問題に合ったパターンとテクノロジーを使用し、問題領域に最適化され、必要に応じて拡張可能であり、不要な重複を回避することを目的とする、正当で善意のある集中チームです。実際、あらゆるドメインで、あらゆる意味のある規模で、価値のあるソフトウェアを構築する際には、これらの側面すべてを考慮することが不可欠です。

通常、このアーキテクチャ機能は、すべてのシステム変更に関するアーキテクチャ設計作業を、最終的にソリューションを実装する開発チームとは（必ずしもそうではありませんが）独立して行います。これらの設計が完了すると、開発者が実装するために引き渡されます。これは、多くの組織が数十年にわたって行ってきたやり方です。では、何が問題なのでしょうか？いくつか挙げてみましょう。

• 集中管理は、アーキテクチャ機能を構成する人々の頭の中に知識を保持し、実装チームから同じ責任を取り除きます。これにより、創造的な思考と好奇心、そしてシステムが実行されているのを見たときにそれに応じようとする意欲が損なわれます。実際にそれらを構築するチームにとって、アーキテクチャは文字通り「誰か他の人の問題」です。
• その結果、アーキテクチャ設計を作成するチームは、実装の最前線から遠く離れている可能性があり、特定のドメインに関連する真の課題を認識できない可能性があります。また、包含するエコシステム内で実行される際の設計の予期しない（そして予見不可能な）結果にもさらされません。
• これにより、開発者とアーキテクト間のフィードバックループが長くなり、デリバリーの遅延、そしてしばしば不十分または不適切なアーキテクチャと設計につながります。
• 最終的に、アーキテクチャ機能はボトルネックになり、組織全体からのアーキテクチャ変更を管理し、無数の結果から学習する必要があるため、キュー時間が長くなります。

2020年の世界的なパンデミック（およびシステムがますます分散化され、常に漸進的に進化しているという事実）を考えると、これらの課題は倍増します。よりリモートで柔軟な働き方に移行する組織の数が大幅に増加しました。知識が少数の個人グループ内に保持されていた従来の対面での共同フォーラムは崩壊しました。意思決定の背後にある根拠の理解が失われ、集合的な知識にギャップが生まれ、その結果、多くの場合、貧弱なソフトウェア設計やさらなる遅延につながります。

もちろん、これらの課題はパンデミック以前から存在していましたが、最近の働き方の全面的な変化は、ソフトウェアアーキテクチャに関する古い集中型の考え方の欠点を浮き彫りにしました。

Xapoは常に分散型で完全にリモートな方法で作業していましたが、パンデミックが発生した際に分散化をさらに強化しましたが、アーキテクチャの品質、変化への対応力、概念的な整合性を損なわないことを目標としていました。

いくつかの歴史的背景...

Xapoは2014年に設立され、当初は個人顧客と機関投資家向けにホスト型ウォレット、取引、支払い、コールドストレージを含むBitcoinサービスを提供し、世界最大で最も信頼されているBitcoinカストディアンになりました。「あなたの人生の貯蓄を守る」という使命に沿って、Xapoは2018年にGFSCの下でジブラルタルに拠点を置き、完全に認可された規制銀行およびVASP（仮想資産サービスプロバイダー）になることを目指しました。このアプローチの転換により、Xapoは完全に規制された環境から、USDデビットカードを含む従来の銀行サービスとBitcoinサービスを提供できるようになりました。2020年、Xapoは銀行およびVASPライセンスを取得し、新しいXapo Bankの構築が始まりました。

既存のXapoソフトウェア資産の多くは、Xapoが電子マネーから完全な銀行およびVASPビジネスモデルに移行するにつれて、転用することができました。ただし、予想されるように、Xapoが設立されてから6年間で、技術的負債、緊密な結合、およびサービスの一貫性の低さが、デリバリーと変更の速度に大きな影響を与えました。変更は多くの場合、複数のチームに影響を与え、複数の機能およびサブドメイン境界を越えました。さらに困難なことに、Xapoの人員は40か国以上、25以上のタイムゾーンに分散しています！

チームは機能部門（製品、デザイン、アーキテクチャ、エンジニアリング、QAなど）を中心に組織化され、作業はかなりウォーターフォール方式でこれらの部門を通過しました。キューイングと長い待ち時間が一般的であり、これは、小規模な集中型アーキテクチャチームがすべての設計に貢献し、レビューし、承認する必要があるため、特に顕著でした。

経験豊富で才能のあるエンジニアは、斬新で高品質なソフトウェアを作成していました。ここでの課題は、彼らのスキルや努力とは関係ないことは明らかでした。プロセスと組織は、正しいことを行い、継続的な品質を確保するために開発されましたが、意図せずにそのシステムと関連する制御が進行を遅らせていました。Xapoは、個々の貢献者がその可能性を最大限に発揮し、ソフトウェアとアーキテクチャを維持し、さらに向上させながら、流れを改善し、摩擦を減らすことができる組織とシステムをどのように作成できるでしょうか？

最後に、アーキテクチャに関する決定を下す目的で、Xapoの集合的な知性を定期的に集めるための以前の取り組みがあったことに注意することが重要です。「アテナイウム」と名付けられたこの取り組みでは、エンジニアがアーキテクチャと設計の問題を提起、議論、決定することができました。当初は好評でしたが、失敗しました。議論はますます長くなり、結論に達することができず、その結果、進捗に必要な決定がほとんど行われず、行われたとしても、次の週の議論の後に取り消されました。

基礎の構築

開発ワークフローの摩擦を減らすための対策が必要であることは明らかでした。さらに、キューイングと引き継ぎを減らすために、チームが（可能な限り）独立して自律的に行動できる能力が、重要な成功要因になりました。

Xapoが最初に行ったのは、ソフトウェアを技術機能の観点ではなく、ビジネスドメインの観点から考え始めることでした。Noushと彼女のチームは、ドメイン駆動設計が最終的に進むべき道であることを知っていましたが、ソフトウェアが広範なビジネスサブドメイン（支払い、カード、銀行業務、コンプライアンスなど）にどのように適合するかについて大まかな評価を行うことから始め、チームトポロジーのMatthew SkeltonとManuel Paisの取り組みに大きく依存して、真にクロスファンクショナルなチームを作成しました。数か月間、製品および運用部門の同僚と協力して、Noushと彼女のチームは、デリバリー組織全体をビジネスに合わせたストリームアラインドチーム（SAT）に移行しました。

並行して、Noushは開発者のエクスペリエンスを大幅に向上させることを目指しました。以前の集中型運用と厳格な管理により、チケットを必要とせずにサービスの作成または変更、構成の変更、その他の操作を行うのが困難で、イライラさせられました。ペースを上げて移動するために、Xapoエンジニアリングは、チームの自律性とサービスライフサイクル全体での完全な所有権のために、プロセスとツールを最適化する必要がありました。Xapoは、これを満たすためにプラットフォームチームのミッションを変更し、それをサポートするためにインフラストラクチャとツールのリファクタリングに着手しました。

この段階で、NoushはThoughtworksを起用しました。組織全体でこの種の変革を経験した人々にアクセスできる目的は、エンジニアリングおよび製品担当者をサポートし、安全な方法でこれらの新しい原則について学ぶのを支援しながら、この変化を加速することでした。

私たちは、チームの自律性とハンドオフの削減に最適化されたソフトウェアを構築することを主な焦点とし、DDDを主要な組織概念として社会化することで、エンジニアリング全体にわたる基礎を築きました。この中で、私たちはSATへの移行から始まった取り組みを継続し、境界付けられたコンテキストについてより詳細に検討し、チームとの整合性を高め、ロードマップを策定し、基盤となるアーキテクチャを段階的に改善しました。

これらの基礎により、私たちはどこへ向かいたいのか、そしてそこへ到達するための大まかな方法を知っていましたが、完全にリモートで、急速に成長し、段階的に変化する組織としてそれをどのように実現するかが次の課題でした。

Xapoは、組織としてさらに非同期的に業務を遂行できるようになる必要がありました。グローバルで完全にリモートな組織であることは、少数の統合されたオフィスに拠点を置く組織には存在しない多くの課題を提示します。すべてのチームメンバーが同じ全体的な目標と理解を共有していることをどのように保証できるでしょうか？エンジニアが自分にとって最適な方法で労働日を最適化できるように、どのように時間を管理できるでしょうか？新しいチームメンバーのオンボーディングをどのようにサポートし、私たちが下したアーキテクチャの決定の背景、理由、制約を理解させるにはどうすればよいでしょうか？Thoughtworksの技術原則であるAndrew Harmel-Law氏と協力し、彼のブログ記事を強く参考にしながら、私たちは、チームが独立して意思決定を行うことを可能にし、主要な関係者や専門家からの助言を確保する、分散型で会話型の助言アプローチをアーキテクチャに実装することを目指しました。Xapoのアーキテクチャ諮問フォーラム（AAF）が誕生しました。分散型金融へのアクセスという原則に基づいて設立された会社が、中央の承認機関を必要とせずに、完全に分散化された方法でアーキテクチャを管理することを選択したのは、ある意味当然のことと言えるでしょう。

仕組み

私たちが従ったアプローチは、Andrewのブログ記事「会話を通じてアーキテクチャの実践を拡大する」で説明されています。このアプローチのすべての事例と同様に、Xapo組織の具体的な詳細、私たちに所属する人々、ソフトウェア、ビジネスの目標、そして文化の性質が、最終的に物事がどのように機能するかに重要な役割を果たしました。

注目すべき3つの主要な要因があります。まず、Xapoはピボットした会社であり、大規模なグローバルスケールアップの初期段階にありました。次に、Xapiensはあらゆる場所に拠点を置いていました。Xapoは真にグローバルな企業であり、そのため、デフォルトのコミュニケーションモードは非同期で書面によるものでした。3つ目に、このグローバルな人材プールは、Xapiensが豊富な経験を持つ優秀な人材であり、多くの意見やアドバイスを提供できることを意味していました。過去にこれが迅速な意思決定を妨げていたと指摘されたこともありました。

私たちは当初、3つの主要分野に展開を集中しました。それは、アーキテクチャアドバイスプロセス、ADR（アーキテクチャ決定記録）、およびAAFです。私たちはこれらすべてのコア要素を同時に開始し、アーキテクチャアドバイスプロセスを紹介するセッションでAAFを設立しました。いくつかの回顧的なADRで議事を事前に開始しました。これらは、最近行われた、特定の主要サービスをサードパーティサプライヤーに移行するという重要な決定を網羅した、実に充実したものでした。これは、すべての参加者が少なくとも部分的に関心を持つであろうことでした。

AAFへの招待者リストは慎重に作成されました。すべてのチームからの意見が反映され、アーキテクチャ、情報セキュリティ、インフラ、製品、デリバリー、規制、運用、財務、さらには幹部も出席しました。焦点を明確にする常設の議題も重要でした。スパイクに続いて進行中のADRを検討するという標準的なAAF活動に加えて、次のような追加の枠を設けました。

• チーム結合の問題（製品とデリバリーは特に重要でした。前述のように、XapoはThoughtworksが関与したまさにその時に、フローを整えるためのチームトポロジー主導の再編成を開始していました）、
• 4つの主要な指標（DORA State of DevOps Reportと書籍「Accelerate」[1]で概説されているように）、
• クラウド支出

AAFを数回繰り返した後、ADRの進捗状況について議論する追加の枠を追加しました。私たちは、意思決定がどれほど迅速に行われているかだけでなく、それらの決定がどれほど迅速にコード化され、本番環境にリリースされているかを知りたいと考えていました。その結果、標準セットに「採用」というADRのステータスをさらに追加しました。これは、ADRが実装され、本番環境で実行されていることを示すものです。これについては、後で詳しく説明します。

Xapo AAFの一般的な側面に関するいくつかの注記がここで役立ちます。 「非同期ファースト」企業として、Noushは常に実装の非同期性を最大化するようにAndrewに働きかけました。Andrewは当初これに反対しました。会話は、直接会話している人だけでなく、すべての人にとって価値があることを認識していたからです。しかし、彼は心配する必要はありませんでした。対面要素（毎週のAAF会議）は、通常の1時間から半分に短縮されましたが、同じ頻度を維持しました。AAFは常に十分な出席者がおり、会話に焦点を当て、価値がありました。事前作業（初期のアドバイスのために進行中のスパイクと提案されたADRを共有すること）と事後作業（AAFでの集中的な対面会話で出てきたアドバイスを追加すること）は、勤勉に行われ、非常に貴重なアドバイスセクションを含むADRの書面記録は、すぐに優れたリソースになりました。Andrewが退職した後、プロセスの運営を引き継いだXapoアーキテクトが、テクニカルライティングの経験、優れた組織能力、そして細部への卓越した注意力を備えていたことも、良い影響を与えました。

なぜ、初期段階でアーキテクチャ原則や技術レーダー（あるいはCFR）を含めなかったのでしょうか？簡単な答えは「緊急ではなかった」ということです。Xapoエンジニアリングにはすでに書かれた原則がありましたが、さらに重要なことに、それらはすでにXapien開発チームの心の中に存在していました。しかし、これは、アドバイスを提供する過程でこれらの暗黙の原則に対する課題や潜在的な改善点を無視したという意味ではありません。

また、技術レーダーは、潜在的な価値ある逸脱や「限定的な購入」の事例が明らかになるにつれて、自己管理が成長し、ますます分離されたチームに浸透し始めた後、導入されました。それ以前の時点では、技術環境は信じられないほど（特に元スタートアップにとっては）焦点を絞っていました。何か有用なものだと気づくと、Xapiensはそれを取り上げ、評価し、使い始めました。

ADRもまた、興味深い進化を遂げました。前述したXapienアーキテクトの1人の強力な情報管理スキルを活用して、wikiベースのADRリポジトリ（Confluence）からチケットシステムベースのリポジトリ（Jira）に迅速に移行しました。なぜでしょうか？意思決定から実装、展開までの処理量を改善したいという強い願望についてはすでに述べました。JiraをADRの拠点とすることで、「ステータス」フィールドとさまざまな値の間の移行をデータポイントにすることができました。新しいADRチケットがオープンされると、自動生成されたタイムスタンプと「下書き」に設定されたステータスが表示されました。AAFでは、「提案済み」ステータスを設定するだけで、別のタイムスタンプが追加されました。（議題の作成も簡単になりました。「提案済み」のすべてのクエリがページテンプレートにありました。）その後の「承認済み」への移行にもタイムスタンプがあり、さらに前述の「採用」ステータスを追加して、決定がコード化され、本番環境で実行されていることを示しました。このツールに移行することで、チームから何も奪うことはありませんでした。主要なADRセクションを自己判明させるチケットテンプレートは、リッチテキスト要素を失うことなく残っていました。また、ステータスが変更されたときにタイムスタンプを更新することを覚える必要もなくなりました。最も重要なことは、開発者が日常的に使用するツールにまだ存在していたことです。最も重要なことは、さまざまなクエリを実行し、さまざまなチャートを描画して、物事の進捗状況を把握できるようになったことです。

この追加データで何を探していたのでしょうか？作成されたADRの数は興味深いデータポイントでしたが、重要なのは、「下書き」から「採用」までの移行にかかる時間でした。集計ベースと個々のステップの両方でです。DORAの4つの主要な指標と同様に、「（意思決定の）リードタイム」は、プロセスとシステムの健全性の信頼できる指標であることがわかりました。これらのデータポイントはすべて、チームが段階的に改善し、自己修正できるように、たとえば「なぜこれがこんなに長く下書き/提案済み/承認済みのままなのか？」などの質問を促すために、チームと共有されました。

Jiraへの移行には、さらに別の利点もありました。Slackなどのコミュニケーションシステムとのシンプルな統合は、Xapoの非同期文化に適合するように、はるかにリッチで焦点が絞られていました。新しいADRは、Slackbotによって自動的にアナウンスできるようになりました。ステータスの変更も同じように処理できました。これらはすべて手動ではなく、透過性が無料で実現しました。それだけでなく、実装ストーリーをADRチケットに関連付けることで、ADRとそのステータスに関連する作業を確認できるようになりました。これは、多くのコアシステムにまたがる改善されたトレースルーティングを実装するような、チーム間のADRに特に役立ちました。

実現されたメリット

AAF/ADRアプローチは、早い段階からXapoで非常にうまく機能することが明らかになり、さまざまな要素がXapo文化に適合するように形成されるにつれて、メリットは増え続けました。私たちはすでにこれに起因するいくつかの勝利について述べましたが、他にどのようなメリットが実現したでしょうか？

このアプローチの一部ではありませんが、クロスファンクショナル要件（CFR）と技術戦略は徐々に表面化しました。前者はADRが提案されたときに自然に発生し、発生したときに明示的にキャプチャされました。それらが明示的になったことで、主要なAAF代表者が、必要が生じた時点で関係者のニーズを検討することができました。たとえば、規制部門の代表者と製品組織の代表者は、コンプライアンスの観点から正確なニーズが何であるかを技術的なフォーラムで明確にすることができました。

技術戦略のポイントも浮上しました。ほとんどのAAFに出席したCTOであるNoushは、彼女が置かれている制約だけでなく、全体的な技術の方向性についても意見を述べることができました。これらは、特定の意思決定のコンテキストで議論することができ、全体的な戦略と整合しているだけでなく、戦略がチームの日常の現実という厳しい視点でストレステストされることも意味しました。それだけでなく、このような議論に触れ、参加することを奨励されることで、一般的な戦略が広く理解されるようになりました。

また、チームの経験と原則への整合性についてもストレステストを実施しました。チームと彼らのADR（アーキテクチャ上の意思決定記録）がコア原則に遭遇した最も顕著な例は既に強調しましたが、これはより小さな形でも何度も発生しました。戦略と同様に、チームがこれらの議論に触れることで、原則が現実世界でどのように形作られているかについて暗黙的なフィードバックを提供できるだけでなく、変更を提案することもできました。結果として、参加者は組織全体でのこれらの原則への整合性を、抽象的にだけでなくソフトウェアのデリバリーにおいても把握することができ、これは貴重なデータポイントとなりました。

AAFのこの一般的な「意味形成」能力は、より一般的な方法でも強力でした。既に述べたスケールアップ作業の重要な側面は、明示的なドメイン駆動アーキテクチャへの移行でした。作業が進むにつれて、週を追うごとに、ドメイン言語の普及が著しく増加しました。最初は必ずしも明確ではなく、境界づけられたコンテキストに沿っていませんでしたが、特定のADRに関連して使用されていたため、主要なDDDアプローチに関するアドバイスを実際の問題に関連付けて行うことができました。これにより、これらのさまざまなパターンの理解が加速しただけでなく、エンジニアリングチーム全体でのドメイン駆動設計のより深い理解が大幅に進み、ドメイン言語に注意を払い、結合やその他の主要な設計上の問題（例えば、2つのチームが同じドメイン概念について微妙に異なる方法で話していたり、両方が、片方のチームだけが実装すべきで、もう片方が委任すべきサービスの実装に向かっているように見えたりする場合）への洞察が得られたときにそれを記録し、設計上の問題に関する議論のポイントに到達するためにこれを利用し、そしてそれらを解決するために展開し、結果として個々のチームと全体的な速度を向上させるという好循環が始まりました。

AAFの導入は、組織内のアーキテクトの役割がなくなったことを意味しませんでした。とんでもないことで、私たちの小規模なチームは、これまでと同様に、Xapoにとって重要な影響を与えるプロジェクトに時間を集中させ、AAFをサポートし、アドバイスを提供することに忙殺されています。チームをエンパワーし、これらの分野の専門家によるコードベースに非常に近い場所で意思決定を行うように移行したことは、実際の変更を実行するのにかかる時間に大きな影響を与えました。以前は数週間（または数ヶ月！）かかっていた設計と意思決定が、今では数日で実行され、全員に十分に文書化され、理解され、技術コミュニティの集合知の一部を形成しています。アーキテクチャは現在、誰もがアイデアを共有したり、私たちの指導原則に沿ってアプローチに挑戦したりできる、集団的な責任となっています。

学んだ教訓

この一連の相互に関連するプラクティス、ツール、アプローチ、および考え方の採用が簡単であったり、課題がなかったりしたかのような印象を与えるのは、私たちの怠慢でしょう。その中心には、「常識」の新しいシステムへの移行の必要性があり、それは内部的、人間的、そしてグループレベルの変化です。

この最も明確な兆候は、コンセンサスの快適さを手放すことが難しいことにあるでしょう。アーキテクチャアドバイスプロセスには「誰でもアーキテクチャの意思決定を下すことができる」というルールが1つしかなく、合意に達する必要も、上位権限からの承認を求める必要もないことを思い出してください。それにもかかわらず、意識的な心がその考えに屈したとしても、「それで、全員が同意しますか？」というフレーズが、議論が終わりに近づくと、AAFの度に、つい口をついて出てきました。これは、新しい考え方への移行がまだ完了していないという信号でしたが、この無意識の必要性を声に出すことで、コンセンサスは必須ではなく、それなしに意思決定を行い、実行に移すことができることを参加者に思い出させることができました。

もう1つの信号は、原則に沿った「完璧な」（妥協のない）ソリューションの追求という形で現れました。これははるかに少なくなりましたが、当初は、意思決定の経験が少ない人々は、以前にこれらの責任を担っていた「アーキテクト」が、賢者のように知恵を持っており、すべての世界で最高の道を見つけることができるかもしれないと感じていたことが明らかでした。トレードオフへの明示的な焦点と、アーキテクトからの同様のアドバイスにより、この考え方は徐々に解きほぐされ、これらがADRに明示的にキャプチャされるようになったときに、真の解決に至りました。これを公にすることで、関係者全員が、この妥協がOKであるだけでなく、避けられないものであることを理解できるようになりました。たとえば、Xapoのサービスをチームの自律性のために最適化する過程で、努力が重複していることが認識されました。これは悪いことでしょうか？必ずしもそうではありません。調整と同期は、重複の削除がもたらすメリットよりも、頻繁に大きなオーバーヘッドを伴う可能性があります。議論で最前線に浮かび上がったのは、特定の状況では重複がユーザーエクスペリエンスのずれにつながる可能性があるという一般的な理解でした。このような場合、メリットは調整作業の欠点を明らかに上回りました。これを事前に、そして集団的に検討することで、妥協が行われる際にどこに重点を置くべきかを大いに助けました。

意思決定はまた、常にビジネス上の意思決定の文脈で語られることで、大きく恩恵を受けました。あるオプションが別のオプションよりも「最適」であるかどうかを決定する要因は、多くの場合、製品またはビジネス戦略に帰着しました。AAFの部屋に製品の代表者がいるということは、アーキテクチャに関する保留中の意思決定に必要なすべてのコンテキストが利用可能であり、それに応じてアドバイスを共有できることを意味しました。ここでの優れた例は、モバイルアプリがどこで使用されていても、誰が使用していても、そして最も重要なことにプラットフォームに関係なく、単一の普遍的なユーザーエクスペリエンスを持つという基本的な製品とデザインの決定です。iOSとAndroidのエクスペリエンスをあらゆる場所で整合させるには多大な努力が必要であり、この製品ガイダンスがなければ、大きな努力の無駄になっていたでしょう。しかし、それは製品全体の精神とエクスペリエンスの中心であったため、不可欠でした。このことを知っていたため、チームは複数の戦略的に整合した意思決定を非常に迅速に行うことができ、その副次的な効果として、出席者全員がその理由を知っていました。

この定期的な同期キャッチアップのより一般的なメリットについても指摘する価値があります。意思決定は必要なアドバイス入力を効率的に収集しただけでなく、（さらに重要なことに）意思決定が自分に関連しているかどうかに関係なく、出席者全員がXapoのビジネスと集団的推論プロセスの詳細に触れました。これは、非同期で作業に戻るときに非常に大きなメリットがあり、チームは週ごとにXapoがたどっている道の詳細と微妙な点について、はるかに意識していました。これは根本的に重要です。なぜなら、ガイダンスと指示のないチームの自律性は、混乱につながるからです。アドバイスプロセス（責任を含む）のような制約は、Xapoを解放し、エンジニアが考える必要のある膨大な数を減らすのに役立ちました。Xapoの技術的な柱と原則についてじっくり考える時間も、成功の重要な要因でした。この一般的な整合と共通の理解が整い、毎週短いAAFによって強化および更新されることで、すべてのチームがフォーカス時間で価値を提供できる能力は印象的でした。

これらの価値が高く、影響力の高い週次セッションには、別のメリットもありました。それは、人々が考えを変え、時には間違ったり失敗したりすることを安全にしたことです。これは、CTOを含む全員によってモデル化されました。たとえば、チームがドメイン駆動設計（DDD）のツールについて集団的に学習し、XapoのソフトウェアがDDDの多くのパターンをどのように示したかを確認したため、サービスを異なるチームに再割り当てしたり、より適切なチームとその境界づけられたコンテキストに合わせてリファクタリングしたりする必要が生じました。これは、チームトポロジートランスフォーメーションの開始時に行われた最初のチーム分割が理想からあまりにもかけ離れていたということではありませんが、段階的な改善を重ねることができました。[2]CTOは、これらのチームに関する最初の決定と、それらへのソフトウェアの割り当てを行った人物でした。ADRで生じた学習に基づいて、また一部駆動されて、これらの責任境界をリファクタリングすることで、人々は、組織設計を含む設計が、最初に正しくある必要はないことを直接理解しました。

これがすべて機能するためには、ADRバックログの一貫した定期的なキュレーションと、明確に定義されたADR所有権が重要であることが明らかになりました。さらに、技術内外の両方で完全なアプローチを社内でマーケティングするメリットにより、人々はそれを常に念頭に置き、メリットを理解することができました。Xapoの非同期かつグローバルな性質のため、これを確実にするために、エンジニアリング部門全体およびそれ以外でのコラボレーションを推進するために、専任の担当者を1人置くことに決定しました。

これが有益に現れた例は、さまざまなADRが再検討されたときに発生しました。すべての意思決定はある時点で行われ、可能な限りそのコンテキストの詳細を把握するように努める必要があります。この意思決定コンテキストが将来のある時点で予測可能に変化することが明らかな場合、再評価をスケジュールできます。これは、当時利用可能な唯一の実行可能なオプションであったため、戦略的ではないホスティングの決定が下されたときにXapoで発生しました。一定期間が経過した後、この決定は再検討され、別の後続のADRが、物事を元に戻し、戦略的なクラウドプロバイダーに移行するために実施されました。

このセクションを締めくくる前に、1つの重要な事実を強調することが重要です。AAFとアーキテクチャアドバイスプロセスは、決して単独で存在したわけではありません。Xapoでは、事前に築かれた土台が大きなプラスの影響を与え、既存のXapien文化の強みも同様でした。チームは、チームトポロジー形式の組織構造への移行、製品思考への同時的な焦点、継続的なデリバリーインフラストラクチャ、およびDORAの4つの主要メトリクスによって提供されるデータから明らかに恩恵を受けました。機能的なチームモデルからストリームアラインドチーム（SAT）モデルへの移行は、紙の上では簡単に見えます。実際には、それはどの組織にとっても大きな変化であり、Noushと仲間が時間をかけてそれを定着させ、うまく機能させ始めたことが重要でした。

Thoughtworksが私たちを去った後、AAFの採用中にNoushとKamilがXapoで学んだ重要な教訓は、継続的な注意とケアが必要であるということです。フォーラムや構造を作成するだけでは、その継続的な成功を確保するのに十分ではありません。むしろ、勢いと影響力を維持するためには、定期的な評価とサポートが必要です。これは、参加を促し、リソースとガイダンスを提供し、発生する可能性のある問題に対処し、変化する状況に適応する必要があることを意味します。アプローチと成果を常に育成し、洗練することによってのみ、長期にわたってXapoにとって効果的で価値のある状態を維持することができます。

今後の展望

AAFとアドバイスプロセスは、間違いなくXapoに多くのメリットを提供してきました。しかし、エンジニアリングチームの私たちは、自己満足に陥ることは許されず、改善を続ける方法を模索しています。これは、ソフトウェア開発の実践と文化を向上させ続ける機会であり、公開時点ではいくつかの機会が検討されています。

カミルは、チームが境界のあるコンテキストを越えて貢献できる、社内オープンソースモデルを正式化しようとしています。これにより、開発者はチーム間でコードとベストプラクティスを共有し、作業の重複を減らし、知識共有のための素晴らしい機会を提供できます。開発者の集合的な知識と専門知識を活用することで、イノベーションを加速し、コードの品質をさらに向上させ、待ち時間や摩擦を減らすことができます。

カミルとチームは、開発者エクスペリエンス（DevX）とツールを改善し、反復する作業を継続することの重要性も認識しています。開発を合理化し、摩擦を減らすツールとプロセスに投資することで、Xapoは開発者がさらに効率的かつ効果的に作業できるようにすることができます。

Xapoのエンジニアリングチーム全体は、進化するビジネス目標と優先順位に確実に合致するように、技術原則の開発と洗練を継続します。原則を定期的に見直し、更新することにより、それらが関連性を維持し、開発作業の指針となるようにすることができます。

全員が、AAFの実装を、ソフトウェア開発の実践と文化を継続的に改善するための道のりの始まりに過ぎないと考えています。これらのイニシアチブを追求することにより、開発者はより協力的に作業し、新しいアイデアを試し、より効率的に作業し、より多くの情報に基づいた意思決定を行うことができるようになります。これにより、最終的により優れたソフトウェアをより迅速に提供し、より広範なビジネス目標をサポートすることができます。