Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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