UGA Boxxx

つぶやきの延長のつもりで、知ったこと思ったこと書いてます

【システム開発】技術的な負債の対処の仕方

技術的な負債についてわかりやすいスライドを見てのメモ

speakerdeck.com

  • 借金のように短期間負債を抱えて大きなリターンを得ることはある
  • 問題となりそうな技術的負債は「影響度を知らない」こと
  • 「影響度を知らない」とビジネスに悪影響を及ぼすリスクになる可能性を保持する
  • リスクに対する許容度を把握しておく
    • 設計する時間がなく間に合わせの設計:影響度・発生可能性に応じて対応方針を決める、仮説であることを知りつつビジネスチケットと並べて潰していく
    • 負債かどうかもリスクかどうかもわからない場合は手の打ちようがない(環境の変化によってなっている可能性がある)
  • 技術的負債として事前に認知する仕組みを作る
    • 技術的負債が増えると、開発生産性が下がるので、開発生産性を測定する
      • Four Key Metrics
        • デプロイ頻度
        • 変更のリードタイム
        • サービス復元時間
        • 変更障害率
      • SPACE
        • Satisfaction and well being:開発者がどれだけ満足しているか
        • Performance:開発者のコードは正しく実行されたか
        • Activity:開発者の行動やアウトプットの数
        • Communication and collaboration:メンバーやチームがどのようにコミュニケーションをとり協力するか
        • Efficiency and flow:中断や遅延を最小限に抑えて進めて完了する能力
    • ただし、以下の法則があるので注意
      • グッドハートの法則:測定を目標にすると、適切な目標ではなくなる
      • キャンベルの法則:社会的な意思決定において重要な指標ほど操作されやすい