Movatterモバイル変換


[0]ホーム

URL:


Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥
Speaker DeckSpeaker Deck
Speaker Deck

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

Avatar for Tori Hara Tori HaraPRO
March 12, 2021

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

Talked at CloudNative Days Spring 2021 Online #CNDO2021.

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

Avatar for Tori Hara

Tori HaraPRO

March 12, 2021
Tweet

More Decks by Tori Hara

See All by Tori Hara

Other Decks in Technology

See All in Technology

Featured

See All Featured

Transcript

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

  2. twitter.com/toricls Tori / Sr. Product Developer Advocate Container Services, AWS

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

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

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

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

    お⼿⼊れ
  7. twitter.com/toricls 継続的開発と技術的負債 - 組織での開発 - 🙍 負債ヤバイ → ⼯数確保を合意 →

    お⼿⼊れ 難易度 ≒ 意思決定層の多重度
  8. twitter.com/toricls 継続的開発と技術的負債 - 組織での開発 (Before) - 💁 現場の⼈ ✨ イケてる

    Web サービス 開発チョー楽しい
  9. twitter.com/toricls 継続的開発と技術的負債 - 組織での開発 (After) - 🙍 👀 👤 利⽤者を増やしたい

    意思決定者 技術的負債に将来へのリスクを感じる 現場の⼈ 第三者 (本⽇の視点) 💥 🔥 かつて幸せだった Web サービス 意⾒ 意⾒ 👥 神々の思惑 💥
  10. twitter.com/toricls 本⽇のお題 (意思決定が多層化された) 組織での技術的負債の返済

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

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

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

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

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

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

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

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

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

  20. twitter.com/toricls 技術的負債の返済 - 現場視点 ▶ ボトムアップでの提案・実⾏が多い (本⽇のメイントピック) ▶ 技術的負債による悪影響を直接的に受ける⽴場 ▶

    もちろんトップダウンもある ▶︎ e.g. Amazon.com “API Mandate” by Jeff Bezos ▶ 🙋『機能開発を⼀度ストップして技術的負債の返済に取り組むべきです!このまま放置して おくと今に⾃分たちの⾸を締めることになります!』 ▶ では、提案してみましょう
  21. twitter.com/toricls どう提案するか? 『フルスクラッチで⼤勝利です!』 ー 30代男性 SWE ⼭⽥さん(仮名)

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

  23. twitter.com/toricls 理解されないボトムアップの例 🙆 👤 意思決定層 現場 💥 🔥 かつて幸せだった Web

    サービス フルスクラッチで⼤勝利〜 ⼤正義マイクロサービスだ〜🤘 本番環境障害が多くて開発時間がない… この辺のコードがよくバグるけど直すのめんどい… ユニットテスト…?😇 ????? こちらをもっと掘り下げる
  24. twitter.com/toricls ⽣産性低下の原因まで掘り下げる バグ起因での 本番環境障害や ダウンタイムが多い 障害対応に時間を取られる ダウンタイムによる 逸失利益 新機能開発や バグフィックスの遅れ

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

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

    新機能開発や バグフィックスの遅れ デプロイ1回あたりの変更が ⼤きくテストしきれていない デプロイ回数を なるべく減らしたい デプロイによる 障害発⽣が怖い サービス競争⼒低下 デプロイは上⻑承認(紙)を 経て⼿作業で実施 ユーザ離脱 コードチェックイン前の レビュープロセスがない ・ ・ ・ 神々の興味 あなたの興味 神々の関⼼ あなたの関⼼ どう繋ぐか?
  27. twitter.com/toricls 技術的負債の返済コストを合意するために ▶ 返済すべき技術的負債とその影響の特定 ▶ なぜその負債の返済優先度が⾼いのか ▶ その負債が⽣産性にどのような(悪)影響を与えているのか ▶ 返済⼿段・⽅法

    ▶ 必要なリソースはいかほどか ▶ 他の⼿段はないか ー リスク分析も good to have ▶ 返済の効果測定⽅法 ▶ 悪影響を解消できているかを評価できる必要がある
  28. twitter.com/toricls 技術的負債の返済コストを合意するために (例) ▶ 返済すべき技術的負債とその影響の特定 ▶ デプロイ1回あたりの変更が⼤きいため本番環境での障害原因特定が⻑時間化 ▶ 機能開発時間が削られ、リリースが遅れている ▶

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

    ▶ 必要なリソースはいかほどか ▶ 他の⼿段はないか ー リスク分析も good to have ▶ 返済の効果測定⽅法 ▶ 悪影響を解消できているかを評価できる必要がある }技術的負債のサイズと難易度が⽐例 (難易度 = 技術的難易度 & 説明難易度) → ⼩さくはじめる → 効果が認められない場合はやめる → なぜ効果がなかったのか評価する
  30. twitter.com/toricls 技術的負債 と 返済 神々視点の

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

  32. twitter.com/toricls 負債の返済に納得・合意したら 🙋 👤 意思決定者 技術的負債の返済に励む⼈ 🤝 🔥 かつて幸せだった Web

    サービス 合意 提案 👥 神々の思惑 ❌ 急ぎで開発して欲しいものが! ❌
  33. twitter.com/toricls 負債の返済に納得・合意したら ⼈的リソースの追加投⼊ あるいは新規開発を⽌める必要性を 意思決定層全員が理解する

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

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

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

    ▶ なぜ効果が出なかったのかちゃんと評価する
  37. twitter.com/toricls 継続的な負債返済は⾼い⽣産性維持の必要条件 ▶ 意思決定層・経営層 ▶ 返済対象の負債と効果測定指標が適切かを評価する ▶ 負債の返済に合意したのであれば、必要リソースの確保はあなたの仕事 ▶ 既存リソースだけで進める

    = 新規開発の停⽌であることを理解する ▶ 意思決定層・経営レベルでの合意形成と認識共有も当然あなたの仕事 ▶ 効果測定を注視し、結果が出ていない場合に正しくガイダンスを⾏う ▶ 負債返済タスクの遂⾏を組織の攻撃から守る \ thank you 🙌 /

[8]ページ先頭

©2009-2025 Movatter.jp