「技術的負債」を作る判断は、間違っていないかもしれない

はじめに

ソフトウェア開発をしていると、「技術的負債」という言葉を耳にすることがある。技術的負債と聞くと、「できるだけ作ってはいけないもの」「コード品質が低い証拠」「いつかリファクタリングしなければいけないもの」という、ネガティブなイメージを持ちやすいだろう。

私自身も以前は、技術的負債はできるだけ発生させない方がいいものだと考えていた。もちろん、負債が少ないに越したことはない。しかし考えていくうちに、必ずしも「技術的負債が存在すること自体が悪い」わけではないと思うようになった。

問題なのは、負債を作ることそのものではない。負債があることを認識せず、返済もしないまま、さらに負債を積み重ねてしまうことだ。

技術的負債は、金融における借金とかなり似ている。うまく使えば現在の問題を乗り越える手段になるが、返済を続けなければ、やがて利息が開発チームを苦しめ始める。今回は、私が実際に保守しているシステムで遭遇した負債を例にしながら、技術的負債を単なる「悪いコード」としてではなく、時間の借用という観点から考えてみたい。

生きているのか死んでいるのかわからないコード

私は現在、SIerとして10年以上前に導入されたシステムの保守を担当している。あるとき、ある処理の調査をしていて、呼び出し元のコードが丸ごとコメントアウトされているのに、呼び出される側のモジュールはそのまま残っている箇所を見つけた。

呼び出し元が封鎖されているので、実際には動いていない。しかし呼ばれる側のコードだけを見ると、正常に動いているモジュールにしか見えない。「このモジュールは今も使われているのか、それとも死んでいるのか」を確認するだけで、呼び出し元をたどって回るという余計な調査が発生した。

さらに厄介なのは、コメントアウトされたコードが残っていること自体が、日常的な調査の邪魔になることだ。ソースコード全体をキーワードで検索したとき、実際には動いていないコメントアウト済みのコードまでヒットしてしまい、どれが今も生きている処理なのかを一つずつ確認しなければならない。最近はAIにコードを読み込ませて調査を手伝ってもらうこともあるが、コメントアウトされた不要なコードが多く残っていると、それだけAIが読み込む範囲も無駄に広がっているはずだ。結局、人が調べるにしても、AIに読ませるにしても、余計なノイズを増やしているだけの状態になっていた。

技術的負債は開発時間を奪っていく

技術的負債が増えていくと、まず影響を受けるのが開発速度だ。今回のコメントアウトのように、コードが整理されていない状態では、機能を追加したり調査したりする前に、まず「これは今も使われているのか」を確認するところから始めなければならない。本来であれば数分で終わるはずの確認に、想定以上の時間がかかることがある。

こうした状態では、影響範囲がわかりにくいため、「ここを変更して本当に大丈夫なのか」という確認にも時間がかかる。結果として、一つの小さな調査や修正に必要なコストがどんどん大きくなっていく。

障害対応にも負債の利息を払う

技術的負債の影響は、機能開発だけではない。障害が発生したときにも、その影響は現れる。コードが整理されていれば、「この処理でエラーが発生している」「このデータがこの条件のときだけ問題になる」と原因を絞り込めるかもしれない。しかし、生きているコードと死んでいるコードが混在していたり、処理が複雑に絡み合っていたりすると、障害原因の特定だけで多くの時間が必要になる。

さらに原因がわかったとしても、「ここを修正すると別の機能に影響しないか」という確認が必要だ。テストが不足していれば、修正後の確認にもさらに時間がかかる。つまり、技術的負債は単にコードを読みづらくするだけではなく、機能追加、調査、障害対応、テストといった、開発チームのあらゆる活動に利息を発生させる。 そして、この利息は一度払えば終わるわけではなく、同じコードを触るたびに、何度も支払うことになる。

気づいても、すぐには直らない

呼び出し元だけがコメントアウトされて呼び出される側が残っている状態は、私が調査で見つけた後、チームの課題として取り上げた。ただし、正直に言うと、まだ対応はできていない。優先度の高い別の作業があり、「気づいてはいるが手をつけられていない」という状態が続いている。

このこと自体は珍しくないだろう。開発には期限がある。予算もある。人員にも限りがある。ある問題に気づいても、すぐにそれを解消する時間を確保できるとは限らない。ただ、気づいた問題をそのまま忘れてしまうのと、課題として残しておいて「今は着手できていない」と認識しているのとでは、状況は大きく違う。少なくとも今回は、後者の状態を維持できている。

技術的負債は「時間の前借り」

技術的負債を考えるとき、私は「時間の前借り」と考えると理解しやすいと思う。たとえば、本来であれば呼び出し元と呼び出される側を一緒に整理すべきところを、リリースを優先して呼び出し元だけをコメントアウトして終わらせたとしよう。その時点では、整理にかかるはずだった時間を節約できている。つまり、未来から時間を借りてきたようなものだ。

問題は、その時間が消えたわけではないということだ。後になって、そのコードを理解する時間、本当に不要なら削除する時間、残すなら整理する時間といった形で返済することになる。しかも、時間が経つにつれて、そのコードの存在自体を忘れてしまったり、別の担当者が「これは何のためのコードか」を一から調べ直したりすることになる。最初に節約した時間よりも、後から支払う時間の方が大きくなっていく可能性がある。これが技術的負債の「利息」だ。

問題は「意図的な負債」と「無自覚な負債」の違い

同じ技術的負債でも、大きな違いがある。それは、意図的に作った負債なのか、それとも気づかないうちに作られた負債なのかという違いだ。

たとえば、「今回はリリース期限を優先するため、呼び出し元だけをコメントアウトして処理を止める」「ただし、呼ばれる側のコードも含めて後で整理する」とチームで認識されているのであれば、負債は管理されている。一方で、「とりあえず動きを止めたからそのままにする」「誰も問題だと認識していない」「いつ直すのか決まっていない」という状態になると、その負債は放置される。

私が見つけたコメントアウトのケースも、おそらく最初は「一旦この処理を止めておこう」という意図的な判断だったはずだ。しかし、その意図がチームに引き継がれないまま10年以上が経過し、今の担当者からは「なぜこうなっているのか」がわからない、無自覚な負債に近い状態になっていた。負債そのものよりも怖いのは、負債が見えなくなることなのかもしれない。

技術的負債の悪循環

技術的負債は、一度発生すると、それ自身がさらに別の負債を増やす悪循環を生みやすいという特徴もある。コードが理解しにくい状態だと、機能追加や調査に時間がかかる。時間がかかるほどチームは忙しくなる。忙しくなると、負債を整理する時間を確保できなくなる。すると、さらに負債が積み重なる。そして次の調査には、もっと時間がかかるようになる、という流れだ。

私が見つけたコメントアウトの問題も、放置されている期間が長くなるほど、「なぜこうなっているのか」を知っている人がいなくなり、調査コストはさらに上がっていくはずだ。気づいた今のうちに、少なくとも「何が起きているか」を記録しておくことが、この悪循環に入り込まないための最初の一歩になると思う。

技術的負債をゼロにすることを目指さない

技術的負債について考えると、「コードをすべて綺麗にしたい」と思ってしまうことがある。しかし、技術的負債を完全にゼロにすることも現実的ではない。ソフトウェアは常に変化する。当時は最適だった設計が、要件の変化によって合わなくなることもある。10年以上前に書かれたコードであればなおさら、当時の判断を今の基準ですべて否定することはできない。

つまり、長期間運用するソフトウェアであれば、ある程度の負債が発生するのは自然なことだ。重要なのは、負債をゼロにすることではなく、負債によって身動きが取れなくならない状態を維持することなのだと思う。

まとめ

技術的負債という言葉を聞くと、どうしてもコード品質だけの話に見えてしまう。しかし本質的には、現在のスピードを得る代わりに、未来の時間を差し出すことという、もっと広い問題だ。だからこそ、必要であれば負債を作る判断もあり得る。重要なのは、その負債を認識し、返済する意思と仕組みを持っていることだ。

私自身、呼び出し元だけがコメントアウトされて呼び出される側が残っているという負債にまだ対応できていない。ただ、これを「気づいていない状態」から「チームの課題として認識している状態」に変えたことは、小さくても意味のある一歩だったと思っている。

借金と同じように、計画的に使えば大きな問題にはならない。しかし気づかないまま、あるいは気づいても放置し続ければ、やがて利息を払うだけで精一杯になる。だからこそ、技術的負債を忌み嫌う必要はない。必要なのは、負債を見える状態にし、意識的に借り、計画的に返すこと。 技術的負債とうまく付き合うことは、コードを綺麗に保つためだけでなく、開発チームが未来に価値ある仕事をする時間を守るために必要なことなのだと思う。

関連記事

• 技術的負債は、全部直すと逆に損をする