アーキテクチャ刷新に向けた戦略と実践
成瀬氏は、CQRS（Command Query Responsibility Segregation）とイベントソーシング（ES）を基盤としたPub/Subシステムの構築を目指し、複数のサービスが非同期で連携できるアーキテクチャを提案した。
「従来のサービス連携では、中心サービスに依頼が集中し、優先順位の調整が難しくなり、リードタイムが増加していました。しかし、イベント駆動型アーキテクチャを導入することで、中心のサービスはイベントをパブリッシュ（公開）するだけで済み、他のサービスはそのイベントを基に自由にデータベースを作成・更新できます。これにより、依頼の集中やリードタイムの増加を防ぎ、各チームの作業負荷を軽減できます」と成瀬氏は説明する。
例えば、注文システムのコマンドをイベントとして保存し、Relay（中継）を経てKafkaなどのMessage Brokerに公開することで、他のサービスが非同期にデータベースを更新できる。この手法によって、サービス間の依存関係を緩和することが可能となったという。
業務の可視化手法として採用した「イベントストーミング」も、アーキテクチャ刷新では重要な役割を果たしたという。システムイベントを可視化し、チーム全体で仕様を共有することで、担当者の退職や仕様変更があっても、スムーズにキャッチアップできる体制が整った。「ドキュメントとコードがほぼ一対一で対応するため、業務知識の継承が容易になる点がメリット」と成瀬氏は解説する。
さらに、オンプレミス環境からクラウドインフラへの移行も進めた。「フルマネージドのクラウドサービスを利用することで、安定稼働し、迅速に復旧できるインフラを構築することを目指しました」（成瀬氏）
クラウドプラットフォームの選定にあたってはAzureとAWSを並行して検討したが、メンバーの意見を踏まえ、最終的にAWSを選択。マルチクラウド対応を視野に入れ、柔軟な運用を可能にするIaCツールとしてTerraformを採用したという。
Terraformの運用では、S3やDynamoDBを用いたプロバイダ設定や管理用シェルスクリプトが必要となるが、個別に対応すると管理が煩雑になる。そこで成瀬氏はまず基本形を作成し、それをもとに各開発者が開発、検証、本番環境を構築できる仕組みを整えた。「ここで決めたことは一生残る」と成瀬氏が述べるように、現在もその基本形は使われ続けている。
AWSのようなパブリッククラウドを使用する際、特に重要になるのがアカウント設計だという。当初、成瀬氏は「シンプルな設計で十分」と考え、開発環境用のアカウントを作成し、AWSのCodeCommit（GitHubのようなバージョン管理サービス）でコードを管理しようとしていた。しかし、本番環境を同じアカウントで運用するのは現実的でなく、最終的にステージングやテスト用に別のアカウントを作成。それぞれの環境でCodeCommitからコードを取得し、デプロイするCI/CDプロセスを構築した。成瀬氏は「最初からこの構成にしておけばよかった。しっかりした設計が、後々の運用に不可欠であることを痛感しました」と振り返る。
成瀬氏はまた、CI/CD環境の自動化にも注力した。「HQ」と呼ばれる中央管理システムを構築し、Web上で必要な情報を入力するだけで、CI/CD環境が自動的に構築される仕組みを整えたのだ。「このシステムの利点は、監査対応を考慮したフローをあらかじめ組み込んでいる点と、方針変更があった場合に後からでも柔軟に対応できることです。これにより、他の開発環境やCI/CDを構築する際の基盤が確立され、さまざまな施策をスムーズに展開できます」と成瀬氏は説明する。
アーキテクチャ刷新の一環として設置した「イネイブリングチーム」も重要な役割を担った。成瀬氏によると、この手法は『チームトポロジー』という書籍で紹介されているもので、「他のフィーチャーチーム（※）を支援し、新技術やプロセスの導入を伴走しながらサポートする役割」を担っているという。特に初期段階ではスキルの習得や他チームとの連携が課題だったが、成瀬氏は一人ひとりに丁寧に説明を行い、他チームとも積極的にコミュニケーションを図ることで、チーム間の協力体制を徐々に整えていった。
イネイブリングチーム内では役割分担を明確にし、認知負荷を軽減する工夫も施した。その結果、現在ではチームは円滑に機能しており、「放っておいても仕事が進む」状態になったという。成瀬氏は「チームを作って本当に良かった」と述べつつ、「最初の3か月は非常に大変でした。アーキテクチャ刷新を進める際には、このようなチームを組成するための余力があるか、事前に慎重に考えるべき」とも振り返った。
（※）本来はストリームアラインドチームであるが、読者向けにフィーチャーチームと表現している。
