大規模なアジャイル開発の現場と技術負債 / Technical Debt

Transcript

1. ⼤規模なアジャイル開発の現場と 技術負債 KDDIアジャイル開発センター株式会社
2. 1 KDDI Agile Development Center Corporation ⾃⼰紹介 経歴 ・⼤規模アジャイルチームの技術コンサル / 開発⽀援 ・社内新規事業⽴ち上げ ・コミュニティ活動の推進や OSS 活動の推進 ・海外スタートアップ: MomentoにてCommunity Advocateとして活動 資格・ポートフォリオ・参加コミュニティ YOSHITAKA KOITABASHI ⼩板橋 由誉 [資格・ポートフォリオ] aws solution architect professional 電⼦情報通信学会情報ネットワーク研究会 第5回情報ネットワーク若⼿研究奨励賞受賞 [コミュニティ] Jaws-ug コンテナ⽀部 X(Twitter) / Qiita/ Zenn: Yoshii0110 GitHub: Yoshiitaka
3. 2 KDDI Agile Development Center Corporation とある現場で⾒た技術負債となぜ技術負債が⽣まれ 改善できなかったのかを話します。
4. 3 KDDI Agile Development Center Corporation アジェンダ • 技術負債とは︖ • とある現場の話 • なぜこんなことになってしまったのか • 改善するためにやったこと • 懺悔タイム • 技術負債が解消されるということは︖ • 継続的な改善
5. 4 KDDI Agile Development Center Corporation 認識が違う技術負債 リリース優先で雑なコードを書き、アーキテクチャの設計をすること あとでやろうとほったらかされているもの 古くなってしまった技術(⾔語やインフラ、フレームワーク) https://t-wada.hatenablog.jp/entry/ward-explains-debt-metaphor
6. 5 KDDI Agile Development Center Corporation 技術負債の柱 1.時間経過と共に変化した最適化 2.時間/予算/スコープそして犠牲になった品質 3.天からの⼀声 4.意図的/無⾃覚
7. 6 KDDI Agile Development Center Corporation 時間経過と共に変化した最適化 ソフトウェア開発は変化する ◦ ⼈の⼊れ替わり ◦ ビジネスモデル, 業界, 顧客が求めるもの ◦ 技術 ◦ エンジニアの思想 https://speakerdeck.com/toricls/the-debt 結果、犠牲になったものは︖ 継続的な開発における⽣産性
8. 7 KDDI Agile Development Center Corporation 時間/予算/スコープそして犠牲になった品質 時間/予算/スコープ/品質を考慮した時に 何に優先度をつけますか︖ ⾮機能要件、特に品質は犠牲になりがち https://www.ipa.go.jp/publish/qv6pgp0000000wkj-att/000055008.pdf
9. 8 KDDI Agile Development Center Corporation 神からの⼀声 今この技術、 流⾏ってるから使って︖ リリース⽇は厳守したいし、 もっと早く機能追加して︖ ⼈たらなさそうだから 増員しといたよ 技術負債︖ リファクタリング︖ 何それ美味しいの︖ DDD︖ 今僕らのフェーズでは 早いからできないよ
10. 9 KDDI Agile Development Center Corporation
11. 10 KDDI Agile Development Center Corporation 意識的/無⾃覚 • 意識的 ◦ ある時点で最適と判断し、機能を削ったり品質を落とすこと ◦ 設計に割く時間がなく、過去にやったことがある⼿法で対応 • 無⾃覚 ◦ 負債を負っている⾃覚がない ◦ 技術⼒/設計⼒がない ◦ 怠慢
12. 11 KDDI Agile Development Center Corporation とある現場であった話 エンジニアキャリアの中で見た とある現場での話
13. 12 KDDI Agile Development Center Corporation エンジニアキャリアの中で見たとある現場での話
14. 13 KDDI Agile Development Center Corporation エンジニアキャリアの中で見たとある現場での話 • よくある3層(フロント, バックエンド, DB)の構成のWebサービス • エンジニアの総勢50名以上 • AWSで構成。神からK8sを使って欲しいという要望でEKSを使⽤ • マイクロサービスは崩壊。複数サービスが動くが、それらが全て 単独のクラスターで運⽤ • インフラとアプリ開発は完全にチームが分断され、IAMにより ReadOnlyの権限のみアプリチームは持っている
15. 14 KDDI Agile Development Center Corporation なぜこんなことになってしまったのか︖
16. 15 KDDI Agile Development Center Corporation 技術負債の柱 1.時間経過と共に変化した最適化 2.時間/予算/スコープそして犠牲になった品質 3.天からの⼀声 4.意図的/無⾃覚
17. 16 KDDI Agile Development Center Corporation なぜこんなことになってしまったのか︖ • 技術の選定、開発サイクルに関する ”意思決定権がチームにない” • 神を騙す者によるパワーワードに引きづられ “無⾃覚”なまま開発が進んでしまっていること • 意思決定層を納得させることができなかった • チームが当たり前と思っていたことが実は、 当たり前ではなかったこと
18. 17 KDDI Agile Development Center Corporation 理想は、どうあるべきだった︖
19. 18 KDDI Agile Development Center Corporation マイクロサービスとは
20. 19 KDDI Agile Development Center Corporation 理想のマイクロサービス
21. 20 KDDI Agile Development Center Corporation マイクロサービスに伴う技術選定は︖
22. 21 KDDI Agile Development Center Corporation チーム、サービス分割については︖
23. 22 KDDI Agile Development Center Corporation 具体的なアクション
24. 23 KDDI Agile Development Center Corporation 実際に改善するためにやったこと
25. 24 KDDI Agile Development Center Corporation 改善するためにやったこと① • 本プロジェクト内における重要⼈物へのヒアリング ◦ インフラを守る⻑⽼ ◦ 意思決定権持つ⻑⽼ ◦ エンジニアチームのリーダ的⻑⽼、SM、PO) • AWSリソースの確認 • コードの読み込み • 開発サイクルの中で感じるツラミの解き明かし • etc
26. 25 KDDI Agile Development Center Corporation 掘り下げてわかったこと 認識は⼀緒なのに、 要因の理解を互いができていない
27. 26 KDDI Agile Development Center Corporation 改善するためにやったこと② • マイクロサービスとはどんなもので、今の体制の⽋点や アーキテクチャによる⽣産性低下についてを意思決定層へ説明 • イベントストーミングの実施を⼀緒にやろうと提案
28. 27 KDDI Agile Development Center Corporation 改善するためにやったこと③ ⼤きな箇所からの改善ではなく、⼩さな改善をバックログ化 ◦ 例えば、ローカル開発環境の整備。 VS CodeにおけるDevcontainerの整備と展開 ◦ Mockサーバの再起動を⾃動化 https://qiita.com/yoshii0110/items/c480e98cfe981e36dd56
29. 28 KDDI Agile Development Center Corporation 改善するためにやったこと④ • 社内のGitHubにコンテナ/K8sについてをまとめた資料をパブリックに公開 • ⼀回1時間くらいの勉強会を数回、社内向けに開催
30. 29 KDDI Agile Development Center Corporation 懺悔タイム
31. 30 KDDI Agile Development Center Corporation 懺悔タイム 懺悔1: 返済すべき負債を絞るべきだったこと 懺悔2: 改善後、効果があったのかなかったのかを 評価しなかったこと 懺悔3: 新規機能開発を⽌めると意思決定層へ判断させるだけの 説得ができなかったこと 懺悔4: 意思決定層全員が理解するまで繰り返し、 説明を続けられなかったこと 懺悔5: 我々が介⼊した時点で負債を返済するプロジェクト化が 必要だったことに気づいたのが遅すぎたこと
32. 31 KDDI Agile Development Center Corporation 技術負債が解消されると 何が嬉しいのか︖
33. 32 KDDI Agile Development Center Corporation 技術負債が解消されるとは ⾼い⽣産性を維持し続けることができること
34. 33 KDDI Agile Development Center Corporation そもそも⽣産性とは︖ アウトプット量ではなく、質を含んだ価値 我々は、顧客が求めるもの、その結果として、 作ったソフトウェアを使う⼈間が便利になる/幸せになる ものを作ることが本質 そのためのアジャイル開発であり、 スクラムなんじゃないのか︖
35. 34 KDDI Agile Development Center Corporation 継続的な改善⽅法 Tips
36. 35 KDDI Agile Development Center Corporation 継続的な改善のためのTips 1.DesignDocsの作成 / ADRの作成 2.イベントストーミングの⾒直し 3.開発サイクルの変更
37. 36 KDDI Agile Development Center Corporation DesignDocsの作成 https://qiita.com/yoshii0110/items/32f93e0c8d24cb3207f7 開発者がコーディングに着⼿する前にソフトウェアシステム または、アプリケーションの開発する⼈が作成するドキュメント
38. 37 KDDI Agile Development Center Corporation ADRの作成 ADR - Architecture Decision Record アーキテクチャに関わる ドキュメントによる決定記録 https://qiita.com/e99h2121/items/f508ef4c9743b8fc9f5b
39. 38 KDDI Agile Development Center Corporation DesignDocs/ADRを作成することの効果 ⼈が⼊れ替わったり、過去に下したアーキテクチャの 判断を思い出す/確認することを補助する => 改善する際の助けとなる
40. 39 KDDI Agile Development Center Corporation イベントストーミングの⾒直し ビジネスモデルは時間と共に常に変化するもの 何が変化し、システムをどう改善しないといけないのかを ⼿探りで⾏うのではなく・・・ 常にドメインを意識し、改善することで最適化される
41. 40 KDDI Agile Development Center Corporation 開発サイクルの変更 もし今の開発サイクルの中で継続的改善ができないのであれば、 いっそのこと開発サイクルごと変えてみるのもありかもしれない。
42. 41 KDDI Agile Development Center Corporation フラクタルスプリント スクラムでやっていた場合、 フラクタルスプリントという１サイクルを切り分けた考え⽅もある。 これにより、より密にPOや意思決定層と会話ができ、ビジネスモデ ルの変化や開発の⽅向転換が効きやすくなる https://kyon-mm.hatenablog.com/entry/2020/09/21/115958 https://qiita.com/viva_tweet_x/items/3b796be727ad3bd3dfc0
43. 42 KDDI Agile Development Center Corporation 採⽤募集中︕ エンジニア・デザイナー
44. Be a Change Leader. アジャイルに⼒を与え 共に成⻑し続ける社会を創る