技術負債って200種類あんねん

はじめに

タイトル間違えました、技術負債は200種類もありません。あと、別に技術負債を褒めたいわけでもありません。しかし、技術負債って言葉としてはシンプルなのに、中身が複雑すぎて深掘りすると意外と無限に出てくるやつです。実際には200種類あるかどうかは別として、技術負債をカテゴリ分けしました。

以前、技術的負債に言及した記事は以下になります。
https://zenn.dev/ficilcom/articles/tech-credit-rating
筆者は、技術負債について、もっと具体的かつ詳細に議論が行われるべきだと考えています。（どのタイプの技術負債か、そもそも解消すべきかどうか、解消するとしたらどれくらいのコスト/期間がかかるのか、など）

では、本記事の本題へGo

コードレベル

• 重複コードで迷路状態
• スパゲッティコードで胃もたれ
• 命名規則がカオス
• 魔法の数字（マジックナンバー）まみれ
• 使われてない関数やクラスが散らばる墓場

アーキテクチャレベル

• 「その時は良かった」設計
• モジュール間の依存関係がラーメンのように絡まる
• 拡張を一切考慮しない設計思想
• なぜか異常に多いレイヤー（責任転嫁構造）
• 「動いているからOK」の構造放置

インフラ・環境レベル

• 「いつかアップデートしよう」と言って10年(10年もサービスが正常に動いたら立派！)
• 非推奨ライブラリ依存症
• Dockerfileが呪文化
• セキュリティ設定がざるすぎて笑えない(事故ったらサービスが飛ぶこともある)
• バージョン管理すらされてないサーバ設定

テストの負債

• テストゼロ文化
• テストコードが本体よりバグる
• CI/CDが壊れて誰も直さない
• 手動テスト依存症（人海戦術最強説）←何のためにエンジニアやってるんだ？
• 「自動化は来月から」永遠の来月症候群

ドキュメントの負債

• 古代の碑文レベルのドキュメント
• 「詳しくはソース参照」の丸投げ文化
• 誰も更新しない仕様書
• Markdownでさえメンテできないチーム
• コードと実際の動きが完全不一致

プロセスと管理の負債

• 「レビューは忙しいから省略」スタイル
• 朝令暮改型の仕様変更
• 意思決定が誰かわからないプロジェクト
• 常に炎上モードのタスク管理
• 「今週やる」と言い続ける放置案件

技術選定の負債

• 流行りに乗っただけのフレームワーク採用
• 明らかにプロダクトに向いてない技術選択
• チームのスキルに合わないオーバースペック技術
• 流行遅れすぎて誰も触れない過去の遺産
• 「あの時は最先端だった」悲しい技術スタック

人的負債

• 超絶属人化したシステム（退職リスク増）
• 技術継承失敗で新人が詰む環境
• スキルの偏りが激しすぎるチーム編成
• 「あいつしか知らない」現象
• 技術学習への投資ゼロ

まとめ

「200種類」はさすがに冗談ですが、気持ちは本気で200種類くらいありますよね？技術負債に関して議論する際は、ぜひ参考にしてください。