AWS Summit Japan 2024 Day2のセッション「チームのつながりをInfrastructure as Codeでデザインする」についてのレポートです。
スピーカーはアマゾンウェブサービスジャパン合同株式会社シニアソリューションアーキテクトの高野賢司様です。
こちらのセッション、現地で聴いていて思わず声が出てしまいそうなくらい衝撃的な感動がありました。
もう先にネタバラシしてしまいますが、普段から興味のあるIaCと、最近本を読んで勉強しているチームトポロジーを非常にうまく活用されたお話でした。
ソフトウェア開発におけるチームのつながり
- 魅力品質、顧客体験の良さを計画して作り込むことはできない→ユーザーからのフィードバックに基づいて継続的な改善を行うことで品質を上げていく
- そのためにはソフトウェアの変更フローに沿ったチームであることが理想だが、チーム編成、つながりが不適切だとチーム間で一度きりの納品となり「壁の向こうに投げ込んで忘れる」モデルとなってしまう。
- フロー効率の向上には開発者だけではなく周囲を巻き込んだ組織文化の変革が必要
組織文化を変えて行く上でまず最初にやるべきなのは、
関係者の思考方法を変えることではなく、
関係者の言動、つまり皆が何をどう行うかを変えることだ
John Shook(LeanとDevOpsの科学)
- Infrastructure as Codeはチームのコラボレーションの中心になる
この段階では私もどういうことか理解できていませんでしたが、以降で明らかになります。
IaCでチーム作りの５つの障壁を乗り越える
手動構築による環境のブラックボックス化
- 変更の追跡が複雑
- 条件分岐やロールバック操作の網羅
- 操作ミスの可能性
解決策：IaCで環境の一貫性を担保する
- コードを見れば現在の状態がわかる
- 操作ミスの可能性がなく素早く複製できる
- 条件分岐や作成順序、ロールバックはCloudFormationに任せる
アプリの状態と変更理由を追跡できない
- ドキュメント、コードの所在がわからない
- 結局何が正しいのかわからず現在の環境を確認することになる
- バージョン管理
解決策：CDKでアプリ全体をコードで定義する
- Gitリポジトリで管理して、認知負荷を軽減
- 引き継ぎが楽になる
- 変更の追跡がしやすい
役割の壁が行動の選択肢を制限している
- Ownershipが低下
- 運用、セキュリティ、コストなどチームや工程をまたぐ改善ができない
- クラウドネイティブなアーキテクチャではアプリとインフラが分けられない
- 新しいサービスやアーキテクチャが活用されない
解決策：CDKを共通言語としてチーム全員で扱う
- チームとして全ての能力をカバー
- 職能ごとに担当領域を限定しない
- CDKでセキュリティやデプロイの安全性、Observabilityを組み込む
スキルの拡張・転換が進まない
- 心理的な壁によって自分の領域からはみ出した有用な技術の習得が阻まれる
解決策：CDKをスキル転換の第一歩とする
- プログラミング言語で記述する第一歩
- タスクの透明性によるコラボレーションの促進
- 協働のためのベース知識の習得
クラウドなのに環境構築に時間がかかる
- チームがセルフサービスでクラウドを使えない
- サイロ化した組織では多くの待ちが発生する
- 組織のガバナンスが単一のチームや手動承認に依存している
解決策：CDKで安全なセルフサービスを実現する
- IaCでコード化されることで追加のセキュリティレイヤーと透明性のある変更管理が利用可能になる
- CI/CDパイプラインから自動デプロイすることで人をデータから遠ざける
この辺り首がもげるかと思うくらい頷いていました。そして話を聞きながら「」の書籍のカバーがチラチラしていました。
IaCでチーム間のインタラクションをデザインする
この辺りの話は先ほどお話ししたチームトポロジーの書籍に書かれていることがほとんどで、ここで説明することは割愛しますが、IaCのコードがプラットフォームに発展するという考え方が最後妙に自分の中でストン、と受け入れられて感動しました！
まとめ
今回のセッションで非常にいい気づきを得られました。何度でも見返したいですね。
参考文献
チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計
https://pub.jmam.co.jp/book/b593881.html
LeanとDevOpsの科学［Accelerate］ テクノロジーの戦略的活用が組織変革を加速する
https://book.impress.co.jp/books/1118101029
