アーキテクチャ刷新の背景と成長を阻害する問題点
セッションの冒頭、「アーキテクチャ刷新は楽しそうに見えるが、実際には非常につらい」と成瀬氏は実感を交えてこう切り出した。一般的にアーキテクチャ刷新の必要性は多くの課題に起因しており、新しいアーキテクチャにはこれらの課題を解決する仕組みが求められる。成瀬氏はまず、自らの経験をもとに、システムの成長を阻害し、開発生産性を低下させるアーキテクチャの問題点について紹介した。
多くのシステムがまず直面するのは、「仕様の複雑化」である。サービスの成長に伴い、機能の追加が繰り返される中で、後から来た開発者が「こんな機能があったのか」と驚くケースは少なくないという。特定の少数ユーザーしか使わない機能であっても、ビジネス上必要であれば維持せざるを得ないのだ。さらに、担当者の退職による仕様の把握困難やドキュメントの不備も、複雑化を助長する要因となっている。
次に、「過渡期特有の難解なコード」も問題として挙げられる。過去に成功したコードが他のプロジェクトでも使い回され、無秩序に拡散することや、レビューをすり抜けて本番環境に入り込んだコードが、時間と共に"秘伝のタレ"のように継ぎ足されていく現象も発生しているという。
さらに、「技術スタックの相対的な老朽化」も深刻だ。成瀬氏の所属する会社のサービスでは、パッケージマネージャーが存在しなかった時代のレガシーコードも多く残っており、その維持管理が現場で大きな負担となっていたという。
成瀬氏にとって、「変更のハードルの上昇」も大きな課題だった。そもそも、同社のインフラチームは顧客向けのインフラ提供が主業務であり、その合間に開発者向けのインフラも手がけている状況だった。そのため、データベースやサーバーのメンテナンスを依頼しても対応に2～3週間を要し、開発スピードを著しく阻害していたのだ。成瀬氏は当時を振り返り、「アプリの開発者からすれば、変更の決定権はすべてインフラチームに握られていた。我々がやりたいことを進めるには、まずインフラチームにお伺いを立てる必要があった」と語る。
これらの問題点を踏まえて、成瀬氏が掲げたアーキテクチャ刷新の基本方針は、次の3点だ。第一に、システムを小さくし、わかりやすくすること。第二に、密結合なシステムを疎結合にして、変更に対する柔軟性を高めること。第三に、無意味なコードの多様性を排除すること。どれも実行には困難を伴うが、これらの方針こそがシステム改善への道筋となる。
さらに、インフラの主導権を開発者側に移す必要があったことも付け加える。「データベースのテーブル変更やサーバーの設定を、開発者の裁量で行えるようにしたいです。この方針のもとで進めたのが、マイクロサービスへの移行とクラウドサービスの活用です。マイクロサービスというバズワードをあいまいにせず、明確に定義し、戦略的に進めることが重要でした」（成瀬氏）
クラウド活用を進めるに当たっては、当初は成瀬氏が所属する「デベロッパータスクフォース」チームで取り組む予定だった。しかし、メンバー全員が他の業務を兼任しており、クラウド活用に集中できる状況ではなかったことから、成瀬氏は「1人でやります」と宣言。自らがプロジェクトを主導することを決断し、いよいよアーキテクチャ刷新に立ち向かっていくことになった。
