技術的負債とは、急いで作ったコードや設計の問題が、後から開発を遅くする状態です。
借金と同じように、最初は小さく見えても、放置すると利息のように負担が増えていきます。
技術的負債とは
技術的負債は、短期的には動くけれど、長期的には扱いづらいコードや仕組みのことです。
たとえば、次のような状態です。
- 同じコードが何度も書かれている
- 変数名の意味がわからない
- どこを直すと何が壊れるかわからない
- テストがなく、変更が怖い
- 古いライブラリを更新できない
動いているから問題ないように見えても、変更するたびに時間がかかるようになります。
なぜ発生するのか
技術的負債は、怠けた結果だけで生まれるわけではありません。
- 納期が短い
- 仕様が途中で変わる
- 学習しながら作っている
- 最初の設計が実態に合わなくなる
- 一時対応をそのまま残す
初心者の個人開発でも、学びながら作るため技術的負債は自然に発生します。
放置すると起きること
技術的負債を放置すると、次のような問題が起きます。
- 新機能の追加に時間がかかる
- バグを直すと別のバグが出る
- コードを読むだけで疲れる
- 他人に説明しづらくなる
- ポートフォリオとして見せにくくなる
特にポートフォリオでは、完成画面だけでなく、READMEやコードの整理も評価されます。
返済する方法
技術的負債を減らす作業を、負債の返済と呼ぶことがあります。
- 変数名をわかりやすくする
- 重複コードをまとめる
- ファイルを役割ごとに分ける
- テストを追加する
- READMEに設計意図を書く
- 使っていないコードを消す
一度に全部直す必要はありません。機能追加の前後に少しずつ整えるのが現実的です。
初心者が意識すべきこと
初心者は、完璧な設計を最初から目指す必要はありません。
大切なのは、後から見直した時に「なぜこう書いたのか」がわかる状態に近づけることです。
迷った時は、まず次の3つを意識しましょう。
- 名前をわかりやすくする
- 同じ処理を増やしすぎない
- 変更前にGitで保存する
意図的な負債と偶発的な負債
期限のため一時的に重複実装を選び、場所、理由、返済条件を記録するのは意図的な判断です。知識不足で問題に気づかず、後で判明する負債もあります。どちらも責任追及より、影響を可視化して管理します。
返済は古さだけでなく、変更頻度、不具合risk、作業を遅らせる回数で優先します。TODO commentだけで放置せず、issueへ対象、影響、完了条件を残します。
確認問題
読みにくいが半年変更しない内部toolと、毎週修正し同じbugが出る決済処理では、通常は後者の返済を先に検討します。
優先順位の考え方は優先順位とは？も参照してください。
まとめ
技術的負債は、短期的な作り方のしわ寄せが後から開発を遅くする状態です。初心者は完璧を目指すより、少しずつ読みやすく、直しやすいコードにしていくことが重要です。
← 一覧に戻る
