技術的負債とステークホルダと説明責任と / The Debt

Talked at CloudNative Days Spring 2021 Online #CNDO2021.

https://event.cloudnativedays.jp/cndo2021/talks/801

Transcript

1. twitter.com/toricls
   技術的負債と
   ステークホルダと
   説明責任と
   Tori
   Mar. 12, 2021
   

   View Slide

2. twitter.com/toricls
   Tori /
   Sr. Product Developer Advocate
   Container Services, AWS
   ❤ AWS Fargate & AWS Lambda
   toricls
   

   View Slide

3. twitter.com/toricls
   技術的負債と
   ステークホルダと
   説明責任と
   

   View Slide

4. twitter.com/toricls
   継続的開発と技術的負債 - 個⼈での開発 -
   💁 負債ヤバイ
   

   View Slide

5. twitter.com/toricls
   継続的開発と技術的負債 - 個⼈での開発 -
   💁 負債ヤバイ → お⼿⼊れ
   

   View Slide

6. twitter.com/toricls
   継続的開発と技術的負債 - 組織での開発 -
   🙍 負債ヤバイ → ？？？？？？？ → お⼿⼊れ
   

   View Slide

7. twitter.com/toricls
   継続的開発と技術的負債 - 組織での開発 -
   🙍 負債ヤバイ → ⼯数確保を合意 → お⼿⼊れ
   難易度 ≒ 意思決定層の多重度
   

   View Slide

8. twitter.com/toricls
   継続的開発と技術的負債 - 組織での開発 (Before) -
   💁
   現場の⼈
   ✨
   イケてる Web サービス
   開発チョー楽しい
   

   View Slide

9. twitter.com/toricls
   継続的開発と技術的負債 - 組織での開発 (After) -
   🙍
   👀
   👤
   利⽤者を増やしたい
   意思決定者
   技術的負債に将来へのリスクを感じる
   現場の⼈
   第三者
   (本⽇の視点)
   💥 🔥
   かつて幸せだった
   Web サービス
   意⾒
   意⾒
   👥 神々の思惑
   💥
   

   View Slide

10. twitter.com/toricls
    本⽇のお題
    (意思決定が多層化された)
    組織での技術的負債の返済
    

    View Slide

11. twitter.com/toricls
    『技術的負債』？
    

    View Slide

12. twitter.com/toricls
    『技術的負債』とは？
    『前任者の⼿抜き実装がヤバくて…』
    ー 30代男性 SWE ⼭⽥さん(仮名)
    

    View Slide

13. twitter.com/toricls
    『技術的負債』とは？
    『前任者の⼿抜き実装がヤバくて…』
    ー 30代男性 SWE ⼭⽥さん(仮名)
    Nope
    

    View Slide

14. twitter.com/toricls
    本セッションにおける『技術的負債』
    実装当時に最適解と考えられたものが
    時間の経過とともに
    最適とは評価され得なくなったもの
    

    View Slide

15. twitter.com/toricls
    本セッションにおける『技術的負債』
    実装当時に最適解と考えられたものが
    時間の経過とともに
    最適とは評価され得なくなったもの
    

    View Slide

16. twitter.com/toricls
    『時間の経過』がもたらすもの
    ▶ ビジネスを取り巻く状況の変化
    ▶ ⾃⾝の持つ知識や理解、洞察⼒の深化
    ▶ システムに関わる組織・チームの規模や役割の変化
    ▶ テクノロジの進歩や進化、新たな技術的選択肢の登場
    →『最適』は変化していく
    

    View Slide

17. twitter.com/toricls
    『最適』を再評価・反映しないシステムは
    継続的開発における⽣産性を低下させる
    『技術的負債』がなぜマズいのか？
    See also: https://t-wada.hatenablog.jp/entry/ward-explains-debt-metaphor
    

    View Slide

18. twitter.com/toricls
    なぜ技術的負債を返済するのか
    ⾼い⽣産性を維持し続けるため
    

    View Slide

19. twitter.com/toricls
    技術的負債 と
    返済
    現場視点の
    

    View Slide

20. twitter.com/toricls
    技術的負債の返済 - 現場視点
    ▶ ボトムアップでの提案・実⾏が多い (本⽇のメイントピック)
    ▶ 技術的負債による悪影響を直接的に受ける⽴場
    ▶ もちろんトップダウンもある
    ▶︎ e.g. Amazon.com “API Mandate” by Jeff Bezos
    ▶
    🙋『機能開発を⼀度ストップして技術的負債の返済に取り組むべきです！このまま放置して
    おくと今に⾃分たちの⾸を締めることになります！』
    ▶ では、提案してみましょう
    

    View Slide

21. twitter.com/toricls
    どう提案するか？
    『フルスクラッチで⼤勝利です！』
    ー 30代男性 SWE ⼭⽥さん(仮名)
    

    View Slide

22. twitter.com/toricls
    どう提案するか？
    『フルスクラッチで⼤勝利です！』
    ー 30代男性 SWE ⼭⽥さん(仮名)
    Nope
    

    View Slide

23. twitter.com/toricls
    理解されないボトムアップの例
    🙆
    👤
    意思決定層
    現場
    💥 🔥
    かつて幸せだった
    Web サービス
    フルスクラッチで⼤勝利〜
    ⼤正義マイクロサービスだ〜🤘
    本番環境障害が多くて開発時間がない…
    この辺のコードがよくバグるけど直すのめんどい…
    ユニットテスト…？😇
    ？？？？？
    こちらをもっと掘り下げる
    

    View Slide

24. twitter.com/toricls
    ⽣産性低下の原因まで掘り下げる
    バグ起因での
    本番環境障害や
    ダウンタイムが多い
    障害対応に時間を取られる
    ダウンタイムによる
    逸失利益
    新機能開発や
    バグフィックスの遅れ
    デプロイ1回あたりの変更が
    ⼤きくテストしきれていない
    デプロイ頻度を
    なるべく減らしたくなる
    デプロイによる
    障害発⽣が怖い
    サービス競争⼒低下
    デプロイは上⻑承認(紙)を
    経て⼿作業で実施
    ユーザ離脱
    コードチェックイン前の
    レビュープロセスがない
    ・
    ・
    ・
    

    View Slide

25. twitter.com/toricls
    ⽣産性低下の原因まで掘り下げる
    バグ起因での
    本番環境障害や
    ダウンタイムが多い
    障害対応に時間を取られる
    ダウンタイムによる
    逸失利益
    新機能開発や
    バグフィックスの遅れ
    デプロイ1回あたりの変更が
    ⼤きくテストしきれていない
    デプロイ頻度を
    なるべく減らしたくなる
    デプロイによる
    障害発⽣が怖い
    サービス競争⼒低下
    デプロイは上⻑承認(紙)を
    経て⼿作業で実施
    ユーザ離脱
    コードチェックイン前の
    レビュープロセスがない
    ・
    ・
    ・
    神々の関⼼
    あなたの関⼼
    ステークホルダの
    共通認識
    

    View Slide

26. twitter.com/toricls
    ステークホルダの
    共通認識
    ⽣産性低下の原因まで掘り下げる
    バグ起因での
    本番環境障害や
    ダウンタイムが多い
    障害対応に時間を取られる
    ダウンタイムによる
    逸失利益
    新機能開発や
    バグフィックスの遅れ
    デプロイ1回あたりの変更が
    ⼤きくテストしきれていない
    デプロイ回数を
    なるべく減らしたい
    デプロイによる
    障害発⽣が怖い
    サービス競争⼒低下
    デプロイは上⻑承認(紙)を
    経て⼿作業で実施
    ユーザ離脱
    コードチェックイン前の
    レビュープロセスがない
    ・
    ・
    ・
    神々の興味
    あなたの興味
    神々の関⼼
    あなたの関⼼
    どう繋ぐか？
    

    View Slide

27. twitter.com/toricls
    技術的負債の返済コストを合意するために
    ▶ 返済すべき技術的負債とその影響の特定
    ▶ なぜその負債の返済優先度が⾼いのか
    ▶ その負債が⽣産性にどのような(悪)影響を与えているのか
    ▶ 返済⼿段・⽅法
    ▶ 必要なリソースはいかほどか
    ▶ 他の⼿段はないか ー リスク分析も good to have
    ▶ 返済の効果測定⽅法
    ▶ 悪影響を解消できているかを評価できる必要がある
    

    View Slide

28. twitter.com/toricls
    技術的負債の返済コストを合意するために (例)
    ▶ 返済すべき技術的負債とその影響の特定
    ▶ デプロイ1回あたりの変更が⼤きいため本番環境での障害原因特定が⻑時間化
    ▶ 機能開発時間が削られ、リリースが遅れている
    ▶ サービスを提供できない時間が毎⽉何時間も発⽣している
    ▶ 返済⼿段・⽅法
    ▶ デプロイ1回あたりの変更(差分)を可能な限り⼩さくできるようデプロイの頻度を⾼める
    ▶ 上記を実現するためにデプロイ作業の⼈間による内容確認や承認を極⼒なくす必要がある
    ▶ 同時にミスオペレーションの可能性も排除する必要がある
    ▶ 典型的なデプロイ処理を⾃動化する
    ▶ 変更がなくても1⽇に1回必ずデプロイフローを回すようにする
    ▶ 返済の効果測定⽅法
    ▶ 障害の原因特定にかける時間を削減できているか？サービスのアップタイムは改善しているか？
    

    View Slide

29. twitter.com/toricls
    技術的負債の返済コストを合意するために
    ▶ 返済すべき技術的負債とその影響の特定
    ▶ なぜその負債の返済優先度が⾼いのか
    ▶ その負債が⽣産性にどのような(悪)影響を与えているのか
    ▶ 返済⼿段・⽅法
    ▶ 必要なリソースはいかほどか
    ▶ 他の⼿段はないか ー リスク分析も good to have
    ▶ 返済の効果測定⽅法
    ▶ 悪影響を解消できているかを評価できる必要がある
    }技術的負債のサイズと難易度が⽐例
    (難易度 = 技術的難易度 & 説明難易度)
    → ⼩さくはじめる
    → 効果が認められない場合はやめる
    → なぜ効果がなかったのか評価する
    

    View Slide

30. twitter.com/toricls
    技術的負債 と
    返済
    神々視点の
    

    View Slide

31. twitter.com/toricls
    負債の返済に納得・合意したら
    ⼈的リソースの追加投⼊
    あるいは新規開発を⽌める必要性を
    理解する
    

    View Slide

32. twitter.com/toricls
    負債の返済に納得・合意したら
    🙋
    👤
    意思決定者
    技術的負債の返済に励む⼈
    🤝 🔥
    かつて幸せだった
    Web サービス
    合意
    提案
    👥 神々の思惑
    ❌
    急ぎで開発して欲しいものが！
    ❌
    

    View Slide

33. twitter.com/toricls
    負債の返済に納得・合意したら
    ⼈的リソースの追加投⼊
    あるいは新規開発を⽌める必要性を
    意思決定層全員が理解する
    

    View Slide

34. twitter.com/toricls
    ⼤事なこと
    邪魔しない
    

    View Slide

35. twitter.com/toricls
    技術的負債と
    ステークホルダと
    説明責任と
    

    View Slide

36. twitter.com/toricls
    継続的な負債返済は⾼い⽣産性維持の必要条件
    ▶ 現場の⼈
    ▶ 負債返済の必要性をステークホルダの理解できる価値と⾔葉で説明する
    ▶ 負債返済による⽣産性向上を⽰すのは現場の⼈間がやるのが最も低コスト
    ▶ ⼩さくはじめて、効果が認められない場合はすぐやめる
    ▶ なぜ効果が出なかったのかちゃんと評価する
    

    View Slide

37. twitter.com/toricls
    継続的な負債返済は⾼い⽣産性維持の必要条件
    ▶ 意思決定層・経営層
    ▶ 返済対象の負債と効果測定指標が適切かを評価する
    ▶ 負債の返済に合意したのであれば、必要リソースの確保はあなたの仕事
    ▶ 既存リソースだけで進める = 新規開発の停⽌であることを理解する
    ▶ 意思決定層・経営レベルでの合意形成と認識共有も当然あなたの仕事
    ▶ 効果測定を注視し、結果が出ていない場合に正しくガイダンスを⾏う
    ▶ 負債返済タスクの遂⾏を組織の攻撃から守る
    \ thank you
    🙌
    /
    

    View Slide