段階的移行とスモールチームが切り拓く未来
藤井氏は、購入ドメイン再設計に向けたアーキテクチャ検討までの道のりを振り返り、「最初期はすべて一人で構想を練り、ステークホルダーとの対話を重ねながら前に進めていった」と語る。入社からわずか3カ月で構想を立ち上げ、翌1月には新チーム発足に向けた採用を開始。既存システムの改修・運用を止めることなく、ストラングラーフィグパターンに基づき「横に小さなチームを配置する」体制をつくり上げた。
藤井氏が選択したのは、2〜4名という「two-pizza teamよりもさらに小規模な」チーム構成だ。その理由について藤井氏は、「人数が増えると合意形成に時間がかかる。試行錯誤の速度を最大化するには、小さく動きの速いチームが最適」と説明する。立ち上げ期にはまず推進力を優先し、メンバー同士がオーナーシップとリーダーシップを積極的に奪い合う関係性をあえて設計したという。
この小さなチームに求められた最初のミッションは、合流時にチーム全体の認識基盤となる叩き台をつくること。「理論だけでも、ドキュメントだけでもダメ。動くプロトタイプがなければ共通認識は作れない」。そう語る藤井氏が特に重視したのは、腐敗防止層の設計だ。構造原理へ立ち返る支点を用意することで議論の迷走を防ぎ、アーキテクチャの根幹を揺るぎないものとすることに成功した。
今後の展望として藤井氏は、小さなチームで培った経験を踏まえ、エネブリングチームの形成に挑むという。
「デファクトとなったシステムを一緒にリライトしながら新メンバーを迎え入れ、共通体験を作り、オーバーエンジニアリングを早期に防ぐ」と藤井氏は話す。参考にしているのは『チームトポロジー』や、昨今注目されるダイナミックリチーミングの考え方だ。組織構造そのものを流動性のあるシステムとして捉え、継続的に学習するチームを作るという。
「もしシステムが混沌としているなら、構造から見直すべきだ。C4モデルやEBMは、共通認識を得るうえで極めて有効だった。小さく始め、仲間を増やし、関係者を巻き込みながら障害耐性を高め、リードタイムを短縮し、組織が学習できる状態をつくる。そして“創る時間”を取り戻す──それこそが、我々が決済基盤の技術的負債に立ち向かううえでのテーマだった」（藤井氏）
巨大システム刷新の本質は、単なる技術置換の作業ではなく、組織が再び前へ進むための時間と余白を取り戻すことにある。藤井氏の取り組みは、そのための方法論を現場で体現した実践知と言えるだろう。
