緩やかに死んでいくシステム / You won't be in the team forever

Talked at Cloud Native Lounge #2「クラウドネイティブなシステムの継続的改善と企業文化」.

https://forkwell.connpass.com/event/215798/

Transcript

1. twitter.com/toricls 緩やかに死んでいくシステム Tori June. 30, 2021
2. twitter.com/toricls Tori Hara / Sr. Product Developer Advocate Elastic Containers, AWS ❤ AWS Fargate, AWS App Runer, AWS Lambda toricls New!
3. twitter.com/toricls https://speakerdeck.com/toricls/for-whom-that-platform-runs https://speakerdeck.com/toricls/the-debt Mar. 12, 2021 Sep. 9, 2020
4. twitter.com/toricls システムの継続的改善
5. twitter.com/toricls なぜシステムを改善していくのか 実装当時に最適解と考えられたものが 時間の経過とともに 最適とは評価され得なくなるから https://speakerdeck.com/toricls/the-debt
6. twitter.com/toricls 『時間の経過』がもたらすもの ▶︎ ビジネスを取り巻く状況の変化 ▶︎ ⾃⾝の持つ知識や理解、洞察⼒の深化 ▶︎ システムに関わる組織・チームの規模や役割の変化 ▶︎ テクノロジの進歩や進化、新たな技術的選択肢の登場 https://speakerdeck.com/toricls/the-debt
7. twitter.com/toricls 『時間の経過』がもたらすもの ▶︎ ビジネスを取り巻く状況の変化 ▶︎ ⾃⾝の持つ知識や理解、洞察⼒の深化 ▶︎ システムに関わる組織・チームの規模や役割の変化 ▶︎ テクノロジの進歩や進化、新たな技術的選択肢の登場 →『最適』が変化していくから、継続的改善が必要 https://speakerdeck.com/toricls/the-debt
8. twitter.com/toricls システムの継続的改善可能性と容易性
9. twitter.com/toricls システムの継続的改善可能性と容易性 ▶︎ ビジネスが⾦を稼いでいる、あるいは稼ぎそうである ▶︎ 適切な戦略に基づく優先順位 ▶︎ 疎結合なビルディング・ブロックの組み合わせ ≒ システム構成要素の⼊れ替え・追加可能性と容易性 ↔︎ フルスクラッチ💸 ▶︎ etc., etc.
10. twitter.com/toricls 『⼈間による』システムの継続的改善可能性 ▶︎ 継続的改善の必要性を理解するリーダー層 ▶︎ ステークホルダのシステムへのオーナーシップ ▶︎ 適切な粒度のゴール設定と効果測定、やり切る⼼ ▶︎ そのシステムのアーキテクチャ(とビジネスドメイン)への知⾒ ▶︎ AWS を使っているなら AWS 各サービスへの知⾒も ▶︎ etc., etc.
11. twitter.com/toricls 『⼈間による』システムの継続的改善可能性 ▶︎ 継続的改善の必要性を理解するリーダー層 ▶︎ ステークホルダのシステムへのオーナーシップ ▶︎ 適切な粒度のゴール設定と効果測定、やり切る⼼ ▶︎ そのシステムのアーキテクチャ(とビジネスドメイン)への知⾒ ▶︎ AWS を使っているなら AWS 各サービスへの知⾒も ▶︎ etc., etc.
12. twitter.com/toricls “今⽇から新しい会社で働くことになりました！” ✨ ✨ ✨
13. twitter.com/toricls 今⽇から新しい会社で働くあなた 🙋 ユーザー 🕵 リクエスト レスポンス 謎の⼒
14. twitter.com/toricls 🕵 今⽇から新しい会社で働くあなた 🙋 ユーザー リクエスト レスポンス 謎の⼒ Needs to be a “Detective” 🕵 ▶︎ ⻑⽼への(度重なる)ヒアリング ▶︎ コードの読み込み ▶︎ (もしあれば)過去イシューやプルリクからの解きほぐし ▶︎ (もしあれば)過去の障害情報や対応履歴からの解きほぐし ▶︎ etc., etc.
15. twitter.com/toricls 継続的な改善を殺すもの
16. twitter.com/toricls 継続的な改善を殺すもの (の⼀例) ▶︎ 主体的思考の⽋如と緩慢なオーナーシップ ▶︎ 「そうなっている理由」を説明できない ▶︎ e.g. 事情もサイズも能⼒も違うキラキラ他社事例を鵜呑みにしたコピー ▶︎ 肥⼤化した組織やチームによる緩慢かつ遅い(あるいは存在しない)意思決定 ▶︎ チーム開発意識の⽋如 ▶︎ 永遠に⾃分が開発・運⽤することが前提になってはいませんか ▶︎ 個⼈で開発しているつもりになってはいませんか ▶︎ 組織内で知⾒の共有ではなく、安易に “Wrap” していませんか ▶︎ ⻑⽼だけが知るシステム全体概要と退職・異動済みの⻑⽼たち ▶︎ etc., etc.
17. twitter.com/toricls 継続的な改善を⽌めないために
18. twitter.com/toricls 継続的な改善を⽌めないために at AWS ▶︎ 組織のスピードとスケーラビリティ ▶︎ チームを⼩さく保つ / 2-pizza team ▶︎ チーム内あるいは他チームとの依存関係を減らし、各チームが 主体的かつ迅速に意思決定と改善を⾏うことを可能にする (≒マイクロサービス) ▶︎ デザインドキュメント ▶︎ etc., etc.
19. twitter.com/toricls デザインドキュメント - Amazon ECS アーキテクチャ全体概要
20. twitter.com/toricls デザインドキュメント - Amazon ECS Exec
21. twitter.com/toricls なぜデザインドキュメントを書き、更新していくのか at AWS ▶︎ 改善の適切なアプローチを最短パスで発⾒するため ▶︎ 既存システムや仕組みがなぜそうなっているのか？を理解せずに適切なアプローチでの改善は 難しい ▶︎ ⻑⽼への不必要な依存度を減らし、⾃律的に改善タスクを進めたい ▶︎ コードから分からないことの情報としての重要性 ▶︎ (そもそも)初期デザイン時に適切なレビューを実施するため ▶︎ コラム: AWS における Principal Engineer の役割 ▶︎ e.g. 2019 年 CloudWatch での⽉あたりの観測メトリクス 1,000 兆、イベントのトリガー 3.9 兆、 受け取りログ 100 ペタバイト
22. twitter.com/toricls デザインドキュメントに何を書くか
23. twitter.com/toricls デザインドキュメントの項⽬例 ▶︎ プロダクト開発・機能開発・改善の背景 ▶︎ 課題は何か = 何を解決するのか ▶︎ システムの技術的全体概要やアーキテクチャー図 ▶︎ スコープ ▶︎ ⽤語集 ▶︎ 選定した解決⼿段について ▶︎ 選定の根拠、トレードオフ ▶︎ 詳細なアーキテクチャー図など ▶︎ PoC の内容と結果 ▶︎ 選定しなかった解決⼿段 x N について ▶︎ ⼿段の概要と不採⽤の根拠 ▶︎ 外部依存の概要 ▶︎ 機能そのもの、解決⼿段についてセキュリティ観点 からの考察 ▶︎ 現時点で考えられるリスク x N ▶︎ リスクの概要 ▶︎ 考えられるリスクへの対応策 ▶︎ 現時点で対応策をとらない理由 ▶︎ テスト観点からの考察 ▶︎ 運⽤観点からの考察 ▶︎ References ▶︎ etc., etc.
24. twitter.com/toricls デザインドキュメントの項⽬例 ▶︎ プロダクト開発・機能開発・改善の背景 ▶︎ 課題は何か = 何を解決するのか ▶︎ システムの技術的全体概要やアーキテクチャー図 ▶︎ スコープ ▶︎ ⽤語集 ▶︎ 選定した解決⼿段について ▶︎ 選定の根拠、トレードオフ ▶︎ 詳細なアーキテクチャー図など ▶︎ PoC の内容と結果 ▶︎ 選定しなかった解決⼿段 x N について ▶︎ ⼿段の概要と不採⽤の根拠 ▶︎ 外部依存の概要 ▶︎ 機能そのもの、解決⼿段についてセキュリティ観点 からの考察 ▶︎ 現時点で考えられるリスク x N ▶︎ リスクの概要 ▶︎ 考えられるリスクへの対応策 ▶︎ 現時点で対応策をとらない理由 ▶︎ テスト観点からの考察 ▶︎ 運⽤観点からの考察 ▶︎ References ▶︎ etc., etc.
25. twitter.com/toricls このセッションでは、システムの継続的改善を殺すものとして 主に「ドキュメンテーションの⽋如」に⾔及しました
26. twitter.com/toricls 『継続的に改善できる』システムにしていくために いま着⼿すべきことは何か？ あらためて、考えてはみませんか？ \ thank you 🙌 /