技術的負債

「技術的負債」という言葉が一般的に使われるようになってきました。

この言葉が初めて使われたのは1992年だそうです。当時は、アジャイルもまだ少数の人々による試みだった時代です。

技術者たちはその前から問題の存在を認識していましたが、うまい呼び名がありませんでした。スパゲッティコードなんて言葉もありましたが、プログラムに触れたことがない人には、単に「美味しそう」と思われてしまうかもしれません。あの複雑なコードをなんとか解きほぐす苦労は、伝わりづらかったのです。

「汚いコード」という表現もありましたが、少し漠然としすぎていますね。

当然、このままでは上司や顧客に伝えるのは難しいです。技術者にしかわからない感覚で、「スケジュールが遅れるので調整が必要です」と言っても、納得してもらうのは至難の業です。

そこで、「技術的負債」という言葉が登場しました。あの「なんとなくわかっていたけど説明できなかったもの」が、言葉として形を持ったのです。

これは、上司や顧客にも説明しやすい言葉です。アジャイルには、経営者とプログラマーを直接つなぐ意図があり、このようにプログラマーの行動が経営者に理解される工夫が施されています。「技術的負債」という言葉の誕生も、その一環なのです。

しかし、技術者の間でこの言葉が定着するうちに、当初の意図から離れてしまっているようです。今や「なんとなくああいうもの」という意味に戻ってしまい、経営者に伝える際には使いづらいものになってしまいました。

本来は経営者にも理解しやすい言葉として生まれたのに、少し残念に思います。

技術的負債とは、経営者にとって負債のようなものです。技術者が理解しやすい特別な負債で、少なくともお金の流れに似た面があると言えるでしょう。

必要なときにはやむを得ない負債です。私も若いころは知らなかったのですが、企業は多くが借金をしているものだそうです。無借金を目指す企業も一部にはありますが、商売上、借りて増やすというのが一般的な考え方です。

技術的負債も同じで、納期が迫るときなどには増やすことが正しい場合も多いのです。

とはいえ、やはり負債なので、できれば増やしたくはありません。毎月の金利支出が続くからです。技術的負債も、できることなら増やしたくないのが技術者の本音です。これは経営者が借金を負うときの気持ちと似ているかもしれませんね。

負債が増えると、経営者の選択肢が減っていきます。他人に仕事を任せるにはお金が必要で、その分、利息が増えて使えるお金が減るからです。

技術的負債も同様で、負債が増えると修正にかかるコストが上昇し、ソフトウェアの改善が減ってしまいます。

そして負債が膨れ上がると、利益のすべてが利息支払いに充てられ、業務以外の改善に使える余裕がなくなります。最悪の場合、返済もままならず倒産に追い込まれる可能性もあります。

技術者も、技術的負債に埋もれたコードに手を焼き、効率改善どころか生産性が低下するだけという経験があるのではないでしょうか。

その結果、技術的負債が限界までたまると、何をするにも高い見積もりしか出せなくなり、バグの多いプログラムを書くしかない状況に追い込まれます。その苦痛を知っているからこそ、技術者は負債を恐れるのです。

よく、技術的負債を増やして納期を短縮するという決定がされますが、これは非常手段であり、積極的に選びたいことではありません。

負債と技術的負債の関係を考えれば、借金して現金が増えたと喜ぶようなもの。必要なことではありますが、喜ぶ理由はありません。

さて、負債に適切な量があるのと同様に、技術的負債も理想とする目標があります。それがゼロであると、次の要件実現が速くなる理想の状態です。

もちろん、現実には様々な事情がありますが、できるだけゼロに近い状態を目指したいところです。

では、「技術的負債ゼロ」とはどのような状況を指すのでしょう？これは負債と同じ比喩では測りきれないものです。

時代によって目指す場所は変わります。先端企業は膨大な研究費をかけて進化を続け、数年〜数十年の差が生まれます。

私は個人的に、8年程度遅れの最先端を目指すのが妥当と考えます。例えば、アメリカの大企業の取り組みが5年程度で書籍化され、それが日本で翻訳されるタイムラグも考えると、予算内で狙いやすいゼロと感じるからです。

具体的に、2024年時点でゼロにすべきと考える項目として、例外なくすべてのテストの自動化があります。近年、CI/CDを利用した本番環境でのカオスエンジニアリングが盛んで、すべてのテストを自動化する考え方も広まりました。

リファクタリングについても、言語機能が許す限りのDRY（Don't Repeat Yourself）を追求しており、今では負債ゼロを目指すことが当たり前となっています。

少なくとも私は、技術的負債ゼロを目指し、お客様の要望に「任せてください」と答えられる技術者を目指ています。そのために、日々技術の研鑽を続け、負債を増やさないための努力を惜しみません。

現代のソフトウェア開発では、技術的負債を意識し、管理することが開発者としての責務です。何かを実装するときには、常に将来のメンテナンスコストや改修のしやすさを考慮する必要があります。技術的負債を増やすのは、一時的な解決策かもしれませんが、長期的な視点で見れば、必ず自分たちに跳ね返ってきます。

プログラムの進化に伴い、私たちも成長しなければなりません。負債をゼロに近づけることで、将来のプロジェクトにも柔軟に対応でき、最終的には自分たちの作業負荷を軽減することができるのです。

負債がゼロに近い状態を保つことで、開発プロジェクトはよりスムーズに進行し、納期に余裕を持つことができ、バグの少ない高品質なソフトウェアを提供できるのです。技術者としての誇りを持ち、顧客の期待に応えるために、負債ゼロを目指すのは当然のことだと言えるでしょう。

結論として、私たちが目指すべきは、「できる限り技術的負債を減らし、未来に負担を残さない開発」です。これが長期的に見て最も効率的で、成功するプロジェクトの土台となるのです。

(編集協力：ChatGPT 4o様)
(当記事はQiitaにもマルチポストされます)
Qiita
(スライド全体はこちら)