photo credit: miguelavg via photopin cc

技術的負債は少しずつ蓄積されていきます。
技術的負債が何を指すのか、相手によって一部しか理解されないことがあるので、まとめてみました。
基本的にシステムの「品質」を構成する要素を逆に捉えただけなので、ここでは品質の構成要素をまとめます。

参考：アプリケーション アーキテクチャ ガイド - 品質特性の章 by Microsoft

設計

システム構造

全体が一貫性のある構造になっているか。
たとえばUIにビジネスロジックが入り込んでいないか。

保守のしやすさ

機能拡張しやすい構造か。
また、バグを修正しやすい構造か。
たとえば必要に応じて必要なモジュールのみを修正すれば対応できるようになっているか。

流用しやすさ

他のシステムにも流用しやすい構造か。
たとえばそのシステム以外にも同じUIコンポーネントをそのまま流用できるか。

動作

稼働率

どれくらいの割合で正常動作するか。
たとえばユーザ利用が集中する土日でも通信エラーが発生せずにシステムが利用できるか。

パフォーマンス

実行速度が高速であるか。
たとえば定期的なバッチ処理が数分以内に終了するか。

スケーラビリティ

負荷が多くかかっても一定のパフォーマンスを維持するか。
たとえばユーザ利用が集中する土日でも数秒でレスポンスが返るか。

セキュリティ

通常の操作だけでなく、悪意を持った操作に対してユーザの資産が破壊されたりシステムが落ちないか。
たとえばSQLインジェクションへの対策ができているか。

システム監視

問題発生時に原因特定がしやすいか。
たとえば死活監視をしていたり、利用ログを抽出しやすい環境を用意しているか。

ユーザビリティ

ユーザ要求に対応できているか。
たとえばUXが優れているか。

最後に

システムを構成する技術決定時はもちろんとして、日々の実装によって、上記にあげたものの選択肢が広まったり狭まったりします。
これらはビジネスの継続に直結するので（特に「動作」に属するもの）、その場の実装スピードしか関心がなさそうなステークホルダーには開発者がきちんと主張しておきたいところです。

それにしてもアプリケーション アーキテクチャ ガイド の著作権が厳しい。
一部であっても電子的でも物理的でも転載には米MSの許可が必要って。。
MSも最近は変わってきているけど、巷にオープンソース系の話題ばかり目につく理由はこういうところなのかも。