ITエンジニアにはおなじみの『技術的負債』についての記事です。
技術的負債の定義は「最善ではない設計や実装により内部品質が低下し、将来的な保守性やシステム性能としてのスケーラビリティに影響を与えるような課題」とこの記事内ではします。
コードを書くと多かれ少なかれ必ず負債が生まれます。そのため負債が生まれること自体は悪いことではないです。しかしその負債が返済されることなく溜まっていき、大きな問題として表面化してから対処することが多いため、よく開発現場では問題になるトピックです。
語り尽くされた話題ではありますが、負債が返済されない理由と返済する方法について改めて考えてみました。
負債が返済されない理由
負債が返済されない理由についてはいろいろな意見があると思います。例えば「品質よりも納期を優先しなければいけないから」というのは1つの大きな理由です。他に思いつく理由だと、、、
- 仕様や品質要求は変化し続けるため、負債は気づかぬ間に自動的に生まれているから
- 負債を認識するにはそのコード箇所への理解だけでなく技術力も必要なので、表面化するまで認識されていない負債がよくあるから
などなど、理由は色々あります。
しかし私個人の意見としては、突き詰めると負債が返済できない最大の理由は『負債は数値で管理できないから』だと思っています。
納期・予算・品質・スコープという開発プロジェクトでトレードオフになる4要素のうち数値などの見える形で管理できないのは品質だけです。納期は「日付」という形で見え、予算は「人件費（人数）」という形で見え、スコープは「機能ボリュームや機能数」という形で見えます。
『品質だけは数値で管理できないため、技術的負債の規模や返済価値が認識できず、その結果返済の着手はいつも遅れてしまう』というのが個人的な見解です。
返済するための方法
良し悪しはひとまず考えず、どんな方法があるのかについて考えてみました。
なおこれらの方法は複数組み合わせることも可能です。
1. 技術的負債がたまり問題が表面化してから着手する
よく行われている方法です。例えば新規事業のように立ち上げ当初は生きるか死ぬかの世界なだと、こういった判断にならざるを得ないことも多いです。
ただし技術的負債が簡単に返せないレベルまで貯まると、プロダクトの将来性を大きく損なうので、負債が返済可能なレベルの段階で着手する判断能力が求められる方法です。
2.品質に関わる間接的な指標を数値として管理する
品質自体は数値化できませんが、品質に間接的に関わるような指標（例えばテストカバレッジ）を数値として管理する方法です。例えば「このモジュールのテストカバレッジをX％以上にする」といった目標を定めるなどです。
あくまで直接的に品質を改善する試みではなく、また目標設定が適切でなければ効果的ではないなどの欠点はありつつも、最低限の品質改善に向けた行動を促すことができるため成果はあります。
3. 一定割合は継続的に品質改善活動に投資することを決めておく
「スプリント内のタスクのうち平均20%は技術的負債やデザイン負債の改善タスクにする」などを決めておくスタイルです。
エンジニア的には安心の方法ですが、杓子定規に20%の時間を使い続けると、ビジネス的に緊急度が高い開発タスクがあるときに80%の時間しか使えずチームの成果が少なくなるので、パーセンテージは状況に応じて柔軟に変えたほうがいいでしょう。
4.品質向上につながるような文化を醸成する
品質向上につながるような行動を良い行動だとみなすよう、皆で合意しておき、チームの文化にしてしまう方法です。
例えばリファクタリングなど、ビジネス成果が出ず地味だけれども重要な試みについて時間を使うことを積極的に推奨・称賛するなどが上げられます。
個人的にはソースコードに限らずあらゆるものをリファクタリングすることを推奨する文化があると良いと思っています。（過去に以下記事でその考え方について紹介しました）
==================
以上4つの方法を考えてみました。私がいるチームでは3, 4の方法を常時実行し、1, 2の方法を必要に応じて行っています。
状況に応じて最適な方法は異なるでしょうし、他の方法もあるかもしれませんので、是非技術的負債を返済し続ける方法について考えてみてはいかがでしょうか。
