Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

Talked at CloudNative Days Spring 2021 Online #CNDO2021.

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

Tori Hara

March 12, 2021
Tweet

More Decks by Tori Hara

Other Decks in Technology

Transcript

  1. twitter.com/toricls 継続的開発と技術的負債 - 組織での開発 (After) - 🙍 👀 👤 利⽤者を増やしたい

    意思決定者 技術的負債に将来へのリスクを感じる 現場の⼈ 第三者 (本⽇の視点) 💥 🔥 かつて幸せだった Web サービス 意⾒ 意⾒ 👥 神々の思惑 💥
  2. twitter.com/toricls 技術的負債の返済 - 現場視点 ▶ ボトムアップでの提案・実⾏が多い (本⽇のメイントピック) ▶ 技術的負債による悪影響を直接的に受ける⽴場 ▶

    もちろんトップダウンもある ▶︎ e.g. Amazon.com “API Mandate” by Jeff Bezos ▶ 🙋『機能開発を⼀度ストップして技術的負債の返済に取り組むべきです!このまま放置して おくと今に⾃分たちの⾸を締めることになります!』 ▶ では、提案してみましょう
  3. twitter.com/toricls 理解されないボトムアップの例 🙆 👤 意思決定層 現場 💥 🔥 かつて幸せだった Web

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

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

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

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

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

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

    ▶ 必要なリソースはいかほどか ▶ 他の⼿段はないか ー リスク分析も good to have ▶ 返済の効果測定⽅法 ▶ 悪影響を解消できているかを評価できる必要がある }技術的負債のサイズと難易度が⽐例 (難易度 = 技術的難易度 & 説明難易度) → ⼩さくはじめる → 効果が認められない場合はやめる → なぜ効果がなかったのか評価する
  10. twitter.com/toricls 継続的な負債返済は⾼い⽣産性維持の必要条件 ▶ 意思決定層・経営層 ▶ 返済対象の負債と効果測定指標が適切かを評価する ▶ 負債の返済に合意したのであれば、必要リソースの確保はあなたの仕事 ▶ 既存リソースだけで進める

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