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

Slide 1

Slide 1 text

⼤規模なアジャイル開発の現場と技術負債 KDDIアジャイル開発センター株式会社

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

2 KDDI Agile Development Center Corporation とある現場で⾒た技術負債となぜ技術負債が⽣まれ改善できなかったのかを話します。

Slide 4

Slide 4 text

3 KDDI Agile Development Center Corporation アジェンダ • 技術負債とは︖ • とある現場の話 • なぜこんなことになってしまったのか • 改善するためにやったこと • 懺悔タイム • 技術負債が解消されるということは︖ • 継続的な改善

Slide 5

Slide 5 text

4 KDDI Agile Development Center Corporation 認識が違う技術負債リリース優先で雑なコードを書き、アーキテクチャの設計をすることあとでやろうとほったらかされているもの古くなってしまった技術(⾔語やインフラ、フレームワーク) https://t-wada.hatenablog.jp/entry/ward-explains-debt-metaphor

Slide 6

Slide 6 text

5 KDDI Agile Development Center Corporation 技術負債の柱 1.時間経過と共に変化した最適化 2.時間/予算/スコープそして犠牲になった品質 3.天からの⼀声 4.意図的/無⾃覚

Slide 7

Slide 7 text

6 KDDI Agile Development Center Corporation 時間経過と共に変化した最適化ソフトウェア開発は変化する ◦ ⼈の⼊れ替わり ◦ ビジネスモデル, 業界, 顧客が求めるもの ◦ 技術 ◦ エンジニアの思想 https://speakerdeck.com/toricls/the-debt 結果、犠牲になったものは︖ 継続的な開発における⽣産性

Slide 8

Slide 8 text

7 KDDI Agile Development Center Corporation 時間/予算/スコープそして犠牲になった品質時間/予算/スコープ/品質を考慮した時に何に優先度をつけますか︖ ⾮機能要件、特に品質は犠牲になりがち https://www.ipa.go.jp/publish/qv6pgp0000000wkj-att/000055008.pdf

Slide 9

Slide 9 text

8 KDDI Agile Development Center Corporation 神からの⼀声今この技術、流⾏ってるから使って︖ リリース⽇は厳守したいし、もっと早く機能追加して︖ ⼈たらなさそうだから増員しといたよ技術負債︖ リファクタリング︖ 何それ美味しいの︖ DDD︖ 今僕らのフェーズでは早いからできないよ

Slide 10

Slide 10 text

9 KDDI Agile Development Center Corporation

Slide 11

Slide 11 text

10 KDDI Agile Development Center Corporation 意識的/無⾃覚 • 意識的 ◦ ある時点で最適と判断し、機能を削ったり品質を落とすこと ◦ 設計に割く時間がなく、過去にやったことがある⼿法で対応 • 無⾃覚 ◦ 負債を負っている⾃覚がない ◦ 技術⼒/設計⼒がない ◦ 怠慢

Slide 12

Slide 12 text

11 KDDI Agile Development Center Corporation とある現場であった話エンジニアキャリアの中で見たとある現場での話

Slide 13

Slide 13 text

12 KDDI Agile Development Center Corporation エンジニアキャリアの中で見たとある現場での話

Slide 14

Slide 14 text

13 KDDI Agile Development Center Corporation エンジニアキャリアの中で見たとある現場での話 • よくある3層(フロント, バックエンド, DB)の構成のWebサービス • エンジニアの総勢50名以上 • AWSで構成。神からK8sを使って欲しいという要望でEKSを使⽤ • マイクロサービスは崩壊。複数サービスが動くが、それらが全て単独のクラスターで運⽤ • インフラとアプリ開発は完全にチームが分断され、IAMにより ReadOnlyの権限のみアプリチームは持っている

Slide 15

Slide 15 text

14 KDDI Agile Development Center Corporation なぜこんなことになってしまったのか︖

Slide 16

Slide 16 text

15 KDDI Agile Development Center Corporation 技術負債の柱 1.時間経過と共に変化した最適化 2.時間/予算/スコープそして犠牲になった品質 3.天からの⼀声 4.意図的/無⾃覚

Slide 17

Slide 17 text

16 KDDI Agile Development Center Corporation なぜこんなことになってしまったのか︖ • 技術の選定、開発サイクルに関する ”意思決定権がチームにない” • 神を騙す者によるパワーワードに引きづられ “無⾃覚”なまま開発が進んでしまっていること • 意思決定層を納得させることができなかった • チームが当たり前と思っていたことが実は、当たり前ではなかったこと

Slide 18

Slide 18 text

17 KDDI Agile Development Center Corporation 理想は、どうあるべきだった︖

Slide 19

Slide 19 text

18 KDDI Agile Development Center Corporation マイクロサービスとは

Slide 20

Slide 20 text

19 KDDI Agile Development Center Corporation 理想のマイクロサービス

Slide 21

Slide 21 text

20 KDDI Agile Development Center Corporation マイクロサービスに伴う技術選定は︖

Slide 22

Slide 22 text

21 KDDI Agile Development Center Corporation チーム、サービス分割については︖

Slide 23

Slide 23 text

22 KDDI Agile Development Center Corporation 具体的なアクション

Slide 24

Slide 24 text

23 KDDI Agile Development Center Corporation 実際に改善するためにやったこと

Slide 25

Slide 25 text

24 KDDI Agile Development Center Corporation 改善するためにやったこと① • 本プロジェクト内における重要⼈物へのヒアリング ◦ インフラを守る⻑⽼ ◦ 意思決定権持つ⻑⽼ ◦ エンジニアチームのリーダ的⻑⽼、SM、PO) • AWSリソースの確認 • コードの読み込み • 開発サイクルの中で感じるツラミの解き明かし • etc

Slide 26

Slide 26 text

25 KDDI Agile Development Center Corporation 掘り下げてわかったこと認識は⼀緒なのに、要因の理解を互いができていない

Slide 27

Slide 27 text

26 KDDI Agile Development Center Corporation 改善するためにやったこと② • マイクロサービスとはどんなもので、今の体制の⽋点やアーキテクチャによる⽣産性低下についてを意思決定層へ説明 • イベントストーミングの実施を⼀緒にやろうと提案

Slide 28

Slide 28 text

27 KDDI Agile Development Center Corporation 改善するためにやったこと③ ⼤きな箇所からの改善ではなく、⼩さな改善をバックログ化 ◦ 例えば、ローカル開発環境の整備。 VS CodeにおけるDevcontainerの整備と展開 ◦ Mockサーバの再起動を⾃動化 https://qiita.com/yoshii0110/items/c480e98cfe981e36dd56

Slide 29

Slide 29 text

28 KDDI Agile Development Center Corporation 改善するためにやったこと④ • 社内のGitHubにコンテナ/K8sについてをまとめた資料をパブリックに公開 • ⼀回1時間くらいの勉強会を数回、社内向けに開催

Slide 30

Slide 30 text

29 KDDI Agile Development Center Corporation 懺悔タイム

Slide 31

Slide 31 text

30 KDDI Agile Development Center Corporation 懺悔タイム懺悔1: 返済すべき負債を絞るべきだったこと懺悔2: 改善後、効果があったのかなかったのかを評価しなかったこと懺悔3: 新規機能開発を⽌めると意思決定層へ判断させるだけの説得ができなかったこと懺悔4: 意思決定層全員が理解するまで繰り返し、説明を続けられなかったこと懺悔5: 我々が介⼊した時点で負債を返済するプロジェクト化が必要だったことに気づいたのが遅すぎたこと

Slide 32

Slide 32 text

31 KDDI Agile Development Center Corporation 技術負債が解消されると何が嬉しいのか︖

Slide 33

Slide 33 text

32 KDDI Agile Development Center Corporation 技術負債が解消されるとは⾼い⽣産性を維持し続けることができること

Slide 34

Slide 34 text

33 KDDI Agile Development Center Corporation そもそも⽣産性とは︖ アウトプット量ではなく、質を含んだ価値我々は、顧客が求めるもの、その結果として、作ったソフトウェアを使う⼈間が便利になる/幸せになるものを作ることが本質そのためのアジャイル開発であり、スクラムなんじゃないのか︖

Slide 35

Slide 35 text

34 KDDI Agile Development Center Corporation 継続的な改善⽅法 Tips

Slide 36

Slide 36 text

35 KDDI Agile Development Center Corporation 継続的な改善のためのTips 1.DesignDocsの作成 / ADRの作成 2.イベントストーミングの⾒直し 3.開発サイクルの変更

Slide 37

Slide 37 text

36 KDDI Agile Development Center Corporation DesignDocsの作成 https://qiita.com/yoshii0110/items/32f93e0c8d24cb3207f7 開発者がコーディングに着⼿する前にソフトウェアシステムまたは、アプリケーションの開発する⼈が作成するドキュメント

Slide 38

Slide 38 text

37 KDDI Agile Development Center Corporation ADRの作成 ADR - Architecture Decision Record アーキテクチャに関わるドキュメントによる決定記録 https://qiita.com/e99h2121/items/f508ef4c9743b8fc9f5b

Slide 39

Slide 39 text

38 KDDI Agile Development Center Corporation DesignDocs/ADRを作成することの効果⼈が⼊れ替わったり、過去に下したアーキテクチャの判断を思い出す/確認することを補助する => 改善する際の助けとなる

Slide 40

Slide 40 text

39 KDDI Agile Development Center Corporation イベントストーミングの⾒直しビジネスモデルは時間と共に常に変化するもの何が変化し、システムをどう改善しないといけないのかを⼿探りで⾏うのではなく・・・常にドメインを意識し、改善することで最適化される

Slide 41

Slide 41 text

40 KDDI Agile Development Center Corporation 開発サイクルの変更もし今の開発サイクルの中で継続的改善ができないのであれば、いっそのこと開発サイクルごと変えてみるのもありかもしれない。

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

42 KDDI Agile Development Center Corporation 採⽤募集中︕ エンジニア・デザイナー

Slide 44

Slide 44 text

Be a Change Leader. アジャイルに⼒を与え共に成⻑し続ける社会を創る