なぜ技術的負債が発生するのか

「よし、技術的負債を作ろう!!」そう思って開発する人は恐らくいないにも関わらず、世の中には負債が溢れています。
では、どのようなときに負債が発生してしまうのか?

1. 納期/コスト都合で設計やテストがおろそかになった
2. 増改築を繰り返し気がつけばサグラダ・ファミリアが出来上がっていた
3. 技術トレンドが変わり採用技術がマイナー化

「技術的負債」という言葉でイメージするのはおそらく1だと思います。
しかし、実は2, 3に起因して負債が発生するケースは少なくないのではないでしょうか。
ソフトウェアの生存期間が長くなり、その生存期間中に要求が変化していった結果複雑化したり
OSSの更新が途絶えてしまったり。
Kyoto Cabinetなどは3に相当しますね。

なぜ負債は多重債務化するのか

前述の項目のうち、特に2は多重債務化する危険性を孕んでいます。

・増改築で複雑化
・リファクタリングでも手に負えないためフルスクラッチで開発
・増改築モジュールの利用者が新規モジュールに移行しないため二重運用発生

書いていて辛くなってきますが、SaaSやASP提供しているものだとあるあるですね。

負債は防ぐことができないのか

「手がつけられないほどの負債」となることはある程度防げます。
正攻法としては以下になるでしょう。
・Sonarなどモニタリングツールを使い、複雑度や重複度を可視化
・設計レビューを徹底
・テストカバレッジ死守　
しかし、これらの手法は昔から存在しています。
それにも関わらず負債は生まれ続ける。
なぜなのか?これはシンプルに
・負債を返済する時間が確保されていない
というところがあると思います。
さすがに「技術的負債なんか返す必要ない!!」なんていう開発現場はあまりないと思いますが、
軽微な負債を「これくらいならいいだろう」と放置してしまうことはあるのではないでしょうか。

ここに技術的負債の恐ろしさがありまして、実際の借金と同様、少額だからと返済せずにいるとあっという間に利子が膨れ上がります。

技術的負債の債権者はどんどん貸してくれるので恐ろしい。

正攻法：返済を計画に織り込もう

ではどうすればいいかというと、これはもう計画的に返済するしかない。
たとえばスクラム開発をやっているチームなら、毎スプリント一定のストーリーポイントを返済にあてる。
なにかしらイテレーティブに開発しているチームなら、週1で返済日をつくる。
（余談ですが、私の所属するチームではこの返済日を「懺悔の日」と呼んでいます）

ただ、これがすんなりできるチームは恵まれていると思います。
「そんなこといわれても納期きついんですよ」「リファクタする暇あったら新機能作れっていわれる」そんな声が聞こえてくるようです。

奇襲：見積もり時にリファクタリング込みで見積もる

リファクタリングと明示すると受け入れられない、というのであればもう水面下にもぐすしかありません。
+20%くらいで見積もり、コードをクリーンに保ちながら開発しましょう。

終わりに：技術的負債への理解ある社会を

最後に紹介した奇襲はら正直なところあまりおすすめしたくありません。
なぜなら
・リファクタリング込みの見積もりなので開発スピードが遅いと認識されてしまう
・そもそもソフトウェア開発には技術的負債の返済が必要という共通認識がもてない
からです。
多少の軋轢を生みながらでも、返済を計画に織り込むことをちゃんと了承してもらうことが重要です。
そのときに、交渉相手がエンジニアであれば複雑度のような指標で訴えかければいいのですが
エンジニアでない場合はどうしたらよいでしょう。
これは実体験からですが、
技術的負債によりどれだけ開発効率が上がったかを定量的に示すことが重要です。
私が実際に行ったのは
・これまで3ヶ月かかってた開発と同規模の開発が1週間で完了するようになった
という時間軸での定量化です。
時間軸や工数、コストといった指標で示すことでエンジニア以外からも理解が得やすくなります。
上記の例ですと、それまで社内でもリファクタリングというものにはあまり投資されていなかったのですが
この結果をうけて様々なレガシーコードに対してリファクタリングの機運が高まりました。
（それはそれでいろいろあったので、機会があれば記事化します）

技術的負債への理解がないと、返済を行わないまま開発が進んでしまう。
そして技術的負債を返却すると何が嬉しいのか知っているのは、我々エンジニア。
「うちの偉い人たちはわかってくれない」ではなく、エンジニア側から必要性を伝え、技術的負債の返済が当たり前に行われる社会をつくっていきたいものだ。