技術的負債について

はじめに

技術的負債について考える事があったので、ポエムを書きました。

技術的負債とは

個人的には技術的負債とは、技術の構成要素で、それに関わるもののコストを増大させるものだと考えられると思います。

動作が保証されていなかったり、不必要に複雑さを増大させていたり、将来置き換える必要を孕んでいたり、外部に何らかの余分なリソースを要求します。

具体的には、テストのないコード、ソース複雑に絡まった無秩序なコードベース、既に非推奨となっている API に依存したモジュール、などです。

技術のライフサイクル

技術的負債についての話をする上で、必ず合わせて考えなければならないのは、技術のライフサイクルだと思います。

相手がこれを理解していない場合、 そもそも技術的負債がなぜ問題なのか理解されません。

技術的負債が問題なのは、ライフサイクルの全ての状態に置いてコストを増大させるためです。

技術は一般的に以下のライフサイクルを辿ります。

  • 必要に迫られて開発、試験、導入される。
  • 問題を解決し続ける為に、 制御、補修、運用、保守される。
  • 不必要になり、置換、棄却される。

一般的に技術は、さらに小さな技術の組み合わせで、再帰的に構成されています。

そして、それぞれが別個にライフサイクルを持ち、全体のライフサイクルを構成します。

つまり、全ての技術は作られるだけでなく、必ず運用・保守されて、部分として補修、置換、棄却を繰り返し、最終的には全体としても置換されるか、棄却されます。

これで今動けばいいわけではないことがお分りいただけると幸いです。

技術的負債は必ず存在する

バグのプログラムが存在しないのと同様、技術的負債が存在しないプロジェクトは存在しません。

もし技術的な負債が存在しないプロジェクトがあるとしたら、それはそこにあるはずの負債を認識出来ていないプロジェクトだと言ってほぼ間違いないです。

多くの負債に気づくことが出来るエンジニアは、優れたエンジニアだと言えるくらいだと思います。

それは、現在の状況よりもより良い方法を多く知っていることにほぼ等しいからです。

僕たちエンジニアは、現実逃避をせずに、現状をよりよくする方法を考える事から始めるべきです。

技術的負債は炙り出す必要がある

技術的負債は、通常そのままでは表面化しません。

つまり、何らかの方法で炙り出して、可視化する必要があります。

これは、プログラム中のバグのメタファーで考えるとわかりやすいです。

バグは、正しい仕様とテストがなければ表面化しません。

技術的な負債も、その定義と、何らかの見つけ出す方法が必要です。

例えば、テストコードがないプロダクトコードを技術的負債だとするなら、プロダクトコードに対するテストコードのカバレッジで定量化、ツールで可視化できます。

技術的負債の責任は技術者だけにない

技術的負債は、技術者だけではなくそれを抱えた組織が取り組むべき問題です。

技術的負債はそれは単に技術者だけの問題ではないからです。

技術的負債は、例えば揺れ続ける要件やそれによって定まらない仕様、リソースに余裕のない開発などから生まれますが、この責任は技術者だけにないでしょう。

技術的負債にどう対応するか

技術的負債は未然に防げればベストですが、これはヒューリスティックな問題です。

そのために、対応が曖昧なものになり、それは多くの部分で個人に依存します。

組織的には、何らかの指標を導入して、閾値などを定めるなどの取り組みも必要になると思います。

いずれにせよ、技術的負債に取り組む上で重要なことは、負債を発生させない事ではなく、全体の中での割合を少なく抑える事です。

テストコードがないプロダクトコードを技術的負債だとして、カバレッジを 100%にしようとするのは、誤りです。

過剰なテストコードは、メンテナンスコストを発生させる点でそれ自体が負債になりえます。

そうではなく、例えば全体的な負債の割合を少なく抑える為に、重要なコードに対するテストを優先するなどの判断が必要です。

さいごに

技術談義の中で、技術的負債に関する話題が出たので、個人的な考えをまとめました。

技術者として生きていく上で技術的負債は避けられないものです。

嫌なものですが、何とか上手く付き合っていきましょう。