はじめに

AWS Summit Japan 2024 の Day2 に参加してきました。「チームのつながりを Infrastructure as Code でデザインする」というセッションを聴講しましたのでレポートします。

ソフトウェア開発におけるチームのつながり

106023_1

IaC、特に AWS CDK のプラクティスを組織作りにどのように活用できるかを主題として話されていました。

チーム内のつながりをどのようにデザインするか

チームのつながりをデザインするには、チームメンバー間のインタラクション（会話や相互作用）を適正化する必要があります。またチームメンバーの心がけだけでは改善が難しいため、メカニズムが必要です。

考え方の切り口としてイノベーションの方法論であるリーンスタートアップを紹介されていました。まずは顧客に価値を提供できる最小限のプロダクトを作り、仮設を立てユーザーの反応を検証し、そのフィードバックを元に改善のループを回す方法論です。

フロー効率

ソフトウェアのほとんどの作業は実質的に変更であるといえます。このことから変更に強いチームを作る必要があります。設計、開発、テスト、リリース、運用のサイクルをひとつのチームで回し、機能を End-to-End で提供します。このため継続的な変更、およびデプロイを可能にする必要があります。

従来のような、設計、開発、テスト、リリース、運用がチームごとに分割された組織では多くの引き継ぎが発生し、各チームは自分たちのタスクをこなすことだけに集中し、他のチームへの関心をなくしてしまいます。リリースは一度限りの納品になり、デプロイ頻度は落ち、ユーザーに価値を提供し続けることは難しくなります。

フロー効率を高めるためには組織文化の変革が必要です。メンバー間のインタラクションを改善し、チーム間のつながりをデザインする必要があります。

このようなチーム間、チーム内のインタラクションを改善するためのメカニズムとして、IaC のプラクティスを導入することができるとおっしゃられていました。

IaC でチーム作りの 5 つの障壁を乗り越える

106023_2

ほかのチームとのやりとりや会話はコストの高いものですが、IaC を中心としてひとつのコードベースでコラボレーションすることで、コミュニケーションパスを限定できます。つまり IaC は単なるツールにとどまらず、チームのコミュニケーション方法に影響を与えます。このことから IaC は戦略的に導入すべきプラクティスの一つであるといえます。

障壁 1: 手動構築による環境のブラックボックス化

IaC を使って環境の一貫性を担保することが有効です。手順書は実は難しいものです。その手順が正しいか確認するためにはその環境を実際に構築してみる必要があります。IaC の場合はコードそのものがリソースの状態を表しているので、手順書のような難しさはありません。

障壁 2: アプリの状態と変更理由を追跡できない

CDK でアプリ全体をコードで定義することが有効です。CDK はアプリとインフラをひとつのリポジトリで管理する方針に向いています。「リポジトリを見ればわかる」状態はチームの認知負荷を軽減します。

障壁 3: 役割の壁が行動の選択肢を制限している

AWS Lambda のように、クラウドネイティブなアーキテクチャではアプリとインフラは分けらません。CDK を共通言語としてチーム全員で扱うことですべての領域をカバーできるようになります。

障壁 4: スキルの拡張、転換が進まない

CDK をスキル転換の第一歩にすることができます。アプリエンジニアは初歩的なクラウドの知識を、インフラエンジニアは Git やプログラミングの初歩をというように、CDK を足がかりとして協働のためのベース知識を身につけることができます。

障壁5: クラウドなのに環境構築に数週間かかる

アプリチームがクラウドを使うのに申請や依頼が必要な状況は、セルフサービス可能であるというクラウドの定義をそもそも満たしていないともいえます。

Iac でコード化することで、CloudFormation Guard や cdk-nag など追加のセキュリティレイヤーや透明性のある変更管理が利用可能になります。また CI/CD パイプラインから自動デプロイすることで、人をデータから遠ざけることもできます。

IaC を使ったチーム間のインタラクション

106023_3

ストリームアラインドチームという概念を使って説明されていました。これはビジネスの流れに沿ったチーム、ソフトウェアの変更に最適化されたチームを意味します。

ここで有名な Two-Pizza Teams が登場しました。

  • 9 名以下の自律的な小さなチーム
  • プロダクトを所有し、すべての説明責任と権限を持つ
  • チームの寿命は少なくともプロダクトの寿命以上

ストリームアラインドチームは少人数でプロダクトを所有して自律的にデプロイできるチームである必要があり、以下のように必然的に多くの能力を備えなければなりません。

  • 設計: プロダクトマネジメント
  • 開発: UX
  • テスト: 品質と信頼性
  • リリース: セキュリティ
  • 運用: Observability

このように、ストリームアラインドチームは認知負荷が高くなりがちです。しかし、9 人以下のチームでは認知不可の合計には上限があります。ものごとをチームの規模にとどめる戦略が必要になります。

ストリームアラインドチームを基本とし、彼らを支援するチームを作ったり、彼らの余計な認知負荷を軽減するためのアプローチが有効です。他のチームが内部サービス (プラットフォーム) を提供することも考えられます。

プラットフォームは「共通基盤」ではないというフレーズが印象的でした。常に最小限のプラットフォームを目指すべきです。CDK のサンプルコードのようなものも薄いプラットフォームの一例です。

Baseline Environment on AWS (BLEA)

106023_4

IaC コードからプラットフォームに発展させるのも有効です。例として、Baseline Environment on AWS (BLEA) があります。これは AWS アカウント上のセキュリティベストプラクティスを実装したサンプルテンプレートです。

  • CDK なのでセルフサービスでデプロイ可能
  • CI/CD パイプラインやサービスカタログで組織に対して継続的にデプロイすることも可能

おわりに

CDK は IaC のコードとアプリのコードを一緒に管理することでひとつのアプリとして扱うため、ソフトウェア開発のプラクティスをインフラ領域に持ち込むことができます。このため、ストリームアラインドチームのように少人数でプロダクトのすべてを担うといった組織体制との親和性は非常に高いと感じました。

このことから CDK を組織改善の足がかりにするというテーマは独特ではありますが、非常に納得感のある内容だと思います。私も CDK が好きで業務でも利用していますが、組織改善に絡めて考えたことはありませんでした。技術の側面から組織に影響を及ぼすプロダクトである AWS CDK をより好きになりました。