専任チームによる継続的デリバリの実現

BCG Digital VenturesのリードエンジニアであるRobin Weston氏が、先日のContinuous Lifecycle Londonで、独立した開発サポートチーム(enablement team)の支援によって、変革への抵抗が強く、サイロ化した(結果、リードタイムが3ヶ月となっていた)企業への継続的デリバリ(CD)プラクティス導入に成功した、自らの経験について講演を行った。新たなテクノロジやツールの導入よりも、チームが重視したのは、優れたプラクティスの共有とチームの教育だった。その対象となったプラクティスは、継続的インテグレーションからテストピラミッドの採用、あるいはアクティビティの計測とムダの特定によるサイクルタイム短縮まで、広きにわたる。

Weston氏は、専任CDチームがアンチパターンであることは認めている。製品チームの(デリバリに対する)オーナシップの喪失につながるからだ。それでも氏のチームは、新たな知識のサイロになることなく、新たな文化を創造する第1ステップとして、その関与を受け入れるという道を選択した。氏のチームが望んだのは、プロダクトチームと現代的な開発プラクティスを結び付けて、そこからイニシアティブを獲得し、継続的な改善アプローチに持ち込むことだった。

Weston氏のチームが最初に行ったのは、日々の作業を行なうエンジニアたちとのバリューストリームマッピングを通じて、それまでは見えなかったボトルネックを明らかにすることだった。例えば、違うタイムゾーンの従業員による承認の必要なプルリクエストのために、コードコミットからコード統合までに長い遅延を発生させていることがあった。この大きなボトルネックは、単に承認先を同じ場所にいるエンジニアに移すことで解消された。 同じように、多くの変更を運用に移行するパスの合理化が図られた。

いくつかあった問題のひとつは、Weston氏によると、このチームに対するビルドやテスト、あるいはデリバリといった開発実務への要求を回避することだった。開発チームが機能をより早く、より高品質で提供できるようにする、というチームのミッションを守る上で、バックログを公開し、チームの作業の重要なメトリクスに影響することを示すデータを収集することが、日々の雑務に引き込まれることを防ぐために重要であった。実際に、イシューや進捗を(定期的なショーケースやデモの記録、モブプログラミング、Wikiの更新を通じて)絶えず伝達することと、新たなプラクティス(トランクベース開発など)に関して開発チームを教育することが、チームの時間の大半を占めていた。

サポートチームが目標としていた継続的デリバリの指標を示すダッシュボード

遠隔地のプルリクエスト排除のような手短な成果を得た後、チームは、継続的インテグレーションのプラクティス(および原則)をまず達成した。次には、ほぼUIベースのみであったアプリケーションテストをテストピラミッド型アプローチに移行し、最後に、パイプラインアクティビティの成熟と安定を図るという、明確なアクションラインを定義した。最新技術へのジャンプアップは、当然ながら優先事項ではなかった。

例えば、それまでの開発チームはビルドの問題に積極的に関与していなかったため、継続的インテグレーションの基本が存在していなかった。デリバリプロセス全体に対するオーナシップが全般的に欠如していたのだ、とWeston氏は述べている。CDの準備状況に関する調査によって、ほとんどのチームがビルドより遅れており、環境管理、テスト、データ管理、サイクルタイム、場合によってはバージョン管理さえも、一貫して適用されていないことが明らかになった。一方でこの結果は、開発チームにとって、システムの開発やデリバリの方法を変革する必要性を理解する上で有効であった。

パイプラインの変更については、パイプラインを通じて提供されるアプリケーションと同じリポジトリに対して、各チームが自身で定義したパイプラインの維持に責任を持つという、パイプライン・アズ・コードが採用された。

Weston氏がプロジェクトを離れる時には、リリースの分離とデリバリ頻度の向上を目的として、マイクロサービスや契約テストの試行に着手するチームが現れる一方で、他のチームは、依然としてリリースブランチと連結リリーススケジュールによる開発を続けている状況だった。