フィーチャーチームがコードに触れるべきでない時：複雑サブシステムチームの必要性

あなたのチームはECプラットフォームを構築している。チェックアウトフロー、商品カタログ、ユーザープロフィールページを担当している。すべてが順調に進んでいたが、決済モジュールに変更が必要になった瞬間、状況が一変する。単純な更新にも3回のコードレビュー、2回の承認、そしてデプロイ前の祈りが必要になる。1行のミスで顧客に二重請求が発生したり、取引が完全に消失したりする可能性がある。チームの速度が落ちる。エンジニアの能力が低いからではない。決済エンジンがまったく別種の存在だからだ。

この状況はよくある。どのアプリケーションにも、汎用的なフィーチャーチームが安全に扱うにはリスクが高すぎる、専門的すぎる、あるいは複雑すぎる部分がある。標準的なストリームアラインドチーム構成はほとんどの機能でうまく機能するが、コードに深く狭い専門知識が必要な場合には破綻する。そこで登場するのが複雑サブシステムチームである。

サブシステムが複雑になる条件

すべてのコードに専任チームが必要なわけではない。複雑なサブシステムには特定の特徴がある。変更頻度は低いが、変更時の影響範囲は広く危険である。習得に数ヶ月から数年かかる知識が必要である。動作が非自明で、エッジケース、競合状態、本番環境で初めて顕在化する微妙な状態依存性が存在する。

決済エンジン、コアデータベーススキーマ、課金システム、不正検知モジュールなどを考えてみてほしい。これらは単にコード行数が多いという意味で複雑なのではない。間違えた場合のコストが高く、正しく実装するための道筋が狭いという点で複雑なのである。商品ページを担当するフィーチャーチームが、新しい支払い方法を追加するためだけに決済ゲートウェイの癖を学ぶのに3週間も費やす余裕はない。

複雑サブシステムチームの働き方

このチームの目的はただ一つ、深い専門知識を必要とする特定のサブシステムを所有し、維持することである。ユーザー向け機能は構築しない。顧客からのリクエストに直接対応することもない。彼らの仕事はサブシステムを安定かつ安全に保ち、他のチームが利用できる状態にしておくことである。

インタラクションモデルはX-as-a-Serviceである。複雑サブシステムチームは明確なインターフェース、通常はAPIを提供し、ストリームアラインドチームは内部を理解せずにそれを呼び出せる。決済チームは支払い処理、取引状況確認、返金開始のためのエンドポイントを公開する。フィーチャーチームはそれらのエンドポイントを呼び出して先に進む。銀行との接続がどのように機能するか、重複取引を調整ロジックがどのように処理するかを知る必要は一切ない。

この境界線は極めて重要である。フィーチャーチームを不要な複雑さから守り、サブシステムを完全に理解していない人による変更から守る。

コラボレーションが必要な時

X-as-a-Serviceモデルはルーティン業務にはうまく機能するが、フィーチャーチームがサブシステムに新しい機能を必要とする場合もある。例えば、まだ存在しない部分返金機能が必要になるかもしれない。その場合、2つのチームは一時的に協力する。フィーチャーチームが要件を説明し、複雑サブシステムチームが変更を設計、実装し、APIを拡張する。新しい機能が利用可能になれば、コラボレーションは終了する。フィーチャーチームはAPIを呼び出す状態に戻り、複雑サブシステムチームはサブシステムの維持に戻る。

この一時的なコラボレーションはモデルの失敗ではない。モデルが有用であり続けるための仕組みである。重要なのは、コラボレーションに明確な範囲と定義された終了条件があることである。フィーチャーチームが小さな変更ごとに複雑サブシステムチームを待つような恒久的な依存関係に変わってはならない。

ボトルネックを避ける

複雑サブシステムチームの最大のリスクは、ボトルネックになることである。サブシステムへのすべての変更にチームの関与が必要なら、フィーチャーチームの速度は低下する。解決策はインターフェースに大きく投資することである。APIは柔軟で、十分にドキュメント化され、頻繁な更新を必要とせずに一般的なユースケースをカバーするように設計されていなければならない。チームは自身のサブシステムに対して、徹底した統合テストやブルーグリーンデプロイ、カナリアリリースなどの安全なデプロイ戦略を含む、堅牢なCI/CDパイプラインも維持すべきである。

インターフェースが優れていれば、ほとんどのフィーチャーチームは複雑サブシステムチームと話す必要すらない。APIを使って先に進むだけである。チームが関与するのは、本当に新しい機能が必要な時だけである。

複雑サブシステムを見極める実践的チェックリスト

複雑サブシステムチームを立ち上げる前に、コードが本当にそのプロファイルに合致するか確認しよう。

  • このコードの1つのミスが、金銭的、セキュリティ的、または運用上の高いコストを伴うか？
  • 習得に数ヶ月かかる専門知識が必要か？
  • 変更頻度は低いが、変更時の影響範囲は広いか？
  • フィーチャーチームがこのコードを所有した場合、著しく速度が低下するか？

ほとんどの質問に「はい」と答えたなら、複雑サブシステムチームを検討する価値がある。そうでなければ、コードはフィーチャーチームに残し、テストとドキュメントの改善に投資しよう。

まとめ

複雑サブシステムチームは、コードを囲い込んだり階層を作ったりするためのものではない。サブシステムとフィーチャーチームの両方を不必要なリスクから守るためのものである。フィーチャーチームは決済エンジンの内部を学ぶ必要がないため、速度を維持できる。サブシステムは、それを真に理解している人だけが変更を行うため、安全性が保たれる。両者の間のインターフェースが、これを機能させる契約である。そのインターフェースに投資すれば、両方のチームが勝利する。