技術的負債

友達が家に遊びに来る10分前を思い浮かべてみてください。床に散らかった物をきちんと元の場所に片づける時間がなければ、とりあえずクローゼットを開けて、手当たり次第に押し込んで閉めてしまいますよね。見た目には部屋が一瞬でスッキリしますが、クローゼットの中はぐちゃぐちゃです。

ソフトウェアを作るときも、これとまったく同じことがよく起こります。サービスのリリース日が目前に迫ると、開発者はコードをしっかり設計する余裕がなくなります。そのため、じっくり考えずに場当たり的でも、とにかく早く動くコードを先に書いてしまうことが多いのです。

こうして作ったプログラムも、その場ではユーザーの目にはまったく問題なくスムーズに動きます。しかし、慌てて問題に蓋をした代償は、自然には消えてくれません。いつか返さなければならない借金として、システムの奥深くにそのまま残り続けます。

クローゼットに物を押し込み続けると、最終的にどうなるでしょうか。あとで小さな靴下を1足取り出そうとしただけでも、扉を開けた瞬間にいろいろな物がどっと崩れ落ちてきます。結局、部屋全体をひっくり返して大掃除をするはめになります。

場当たり的なコードが何層にも積み重なったプログラムも、まったく同じ悲劇に見舞われます。時間がたってから新しい機能をひとつ付け足そうとするたびに、絡み合ったコードのせいで、思わぬ場所で次々とエラーが発生するのです。

銀行のローンに毎月利息がつくように、コードの整理を後回しにすればするほど、新機能を開発する時間が何倍にも膨らんでいきます。本来なら10分で直せたはずの小さなバグを退治するのに、何日も徹夜しなければならない。そんな状況こそが、技術的負債の利息なのです。

もう少し正確に言うと、技術的負債は常に避けるべき絶対的な悪というわけではありません。競争の激しいビジネスの世界では、ライバルより先にサービスをリリースして、市場や顧客の反応をいち早く確かめることが何よりも大切な場面が多いからです。

経営者が会社を急成長させるために、銀行からの借り入れを戦略的に活用するように、開発チームもリリースを早めるためにあえて負債を抱えることがあります。大切なのは、借りたものをいつ、どうやって返すかをあらかじめ計画しているかどうかです。

借りた負債は、見た目の動きはそのままに内部の設計をきれいに整えるリファクタリング(Refactoring)によって、期限内に返していく必要があります。返さずに長く放置すると、システム全体が手をつけられないほどガチガチに固まってしまうおそれがあります。また、技術的負債はわざと作るものだけではありません。最初は合理的だった設計も、要件が変わったり使っている技術が古くなったりして、あとから負債になることもあります。