- 技術的負債とは - 保守性や拡張性を低下させ、開発速度や開発者体験を低下させている不適切な設計・実装のこと - 技術的負債が溜まると起こること - 開発速度の低下 - 品質の低下（バグやエラーの増加） - 新しい技術を導入できなくなる - 競争力の低下などにつながる - 開発者体験の低下、チームメンバーのモチベーションの低下 - セキュリティリスクの増加 - 古いコードは脆弱性を抱えている可能性が高い - 技術的負債の分類 - リリース時に認知していた負債 - ちゃんと設計する時間がなくとりあえず間に合わせて作ったもの - どの辺りで問題が起こりそうかある程度見えている負債 - リリース時には認知していない負債 - 仕様変更など環境変化によって負債になったもの - 技術的負債を計る指標 - [[技術的負債比率]] - 新しい機能を追加しようとした時の「実際の工数 - 理想の工数」 - 技術的負債が生まれる要因 - 技術的な理由 - 技術設計の不備 - テストの不備 - レビューなどプロセスの問題 - ビジネス的な理由 - 予想外の機能追加、仕様変更 - 綺麗でシンプルなコードは技術的負債になりづらい - 汚いコード、複雑なコードは技術的負債になりやすい - 解消すべき技術的負債 - 将来の変更が多いと予想されるところ - 今後の変更がなければ負債解消をしても効果がない - 技術的負債には利子がかかる - システムに機能が追加され成長するにつれて問題の対処はどんどん難しくなり修正コストが高くなる - 時間が経過することで負債を解消するための知識がチームから失われ対応が難しくなる - 技術的負債をめぐるエンジニアと非エンジニアの情報非対称性 - エンジニアはシステムの内部構造を知っている - 非エンジニアはシステムの外部的な部分しか見えていない - 技術的負債を許容するという考え方 - 技術的負債を許容することで早く市場にリリースしてユーザーにサービス提供することができる - 技術的負債の解消方法 - コストをかけてまとめて解消する: [[リファクタリング]] - コストをかけず開発しつつ解消する: [[ボーイスカウトルール]] - 技術的負債の対応・向き合い方 - 技術的負債を認知していないと将来大問題が起こる場合がある - 気づかないうちに問題が膨らみある時一気に爆発する - まずは今どのような負債を抱えているのかをきちんと把握することが大事 - その上でそれぞれの負債に対して対応する・しない、する場合はいつまでにするという対応方針を考える - 技術的負債は全て今すぐ対応しないといけないというものではない - ビジネス視点で考えた時に技術的負債の解消はそれ自体では利益を生まない - したがって負債を解消することで得られる効果を考えて機能開発をするのか負債の解消をするのかの優先度を決める必要がある - 技術的負債の返済が目的ではなく、事業戦略を達成することが目的。事業戦略を達成するための技術戦略や技術的負債の返済計画を立てる。 ## 参考リンク - [技術的負債が生まれる背景を理解して，アーリーからレイター向けの根本的なアプローチを考える](https://speakerdeck.com/memory1994/understanding-why-built-tech-debts-and-thinking-approaches-for-startup-on-early-to-later-stage)