なぜ「技術的負債」が積み上がるのか？ その背景と解消法を解説：CIO Dive

長年にわたって蓄積され、企業にダメージを与える技術的負債はなぜ発生するのか。そして、なぜすぐに解消できないのか。多くの企業が抱えるこの「時限爆弾」が発生する背景からその段階的な解消方法に至るまでを解説する。

[Kirat Sekhon，CIO Dive]

　近年、途方もない額の負債を抱えているのは世界経済だけではない。世界の大企業の技術部門はそれとは異なる「負債」を急速、そして確実に蓄積している。

技術的負債はなぜ発生するのか？　なぜすぐに解消できないのか？

　技術的負債は、企業が市場投入のスピードを重視するあまり厳密かつ慎重に計画されたインフラ開発を後回しにして何十年にもわたって技術インフラをショートカットしたり、ソフトウェアの修正やメンテナンスを延期したりした結果、積み上がるリスクだ。

　技術的負債が企業に何をもたらすかはよく知られているが、なぜ多くの企業がこの「時限爆弾」を抱えることを容認してしまうのか。時限爆弾の解除になぜすぐに取り掛かれないのか。トムソン・ロイターの技術トップが明らかにする。

　ここ数年のデジタルトランスフォーメーション（DX）や昨今の生成AIの成長や大規模言語モデル（LLM）利用といった技術トレンドへの対応は、レガシー技術のスタックを限界まで押し上げた。CrowdStrikeが引き起こした世界的なシステム障害（注1）や、大規模なサイバー攻撃（注2）、航空管制システムの重大な不具合などは根本的な問題の兆候だと言えるだろう（注3）。

　企業が技術的負債の蓄積という根本的な課題にいつどのように対処するかによって、現在のテック業界のリーダーと後発企業の順位が入れ替わる可能性もある。

「一度設定したら忘れる」マインドセットがもたらしたもの

　コードが書かれた瞬間から技術的負債は発生する。技術の進展スピードは速く、既存の設定を更新する際にはその時点の状況や流行しているベストプラクティスの影響を大きく受ける。

　10〜15年前に大手テック企業が開発したソフトウェアのほとんどはモノリシックアーキテクチャという、システム全体を一つの大きな塊（かたまり）と見なす設計方法によって書かれていた。ローカルサーバーに構築されたこれらのシステムは、設定に少しでも手を加えようとするとコード全体にその影響が波及するため変更が困難だった。

　従来型のこのようなITシステムは構築に高額な費用がかかる上に更新が難しかったため、2010年代前半は大規模なソフトウェアアップグレードまでの間は、「一度設定したら、その後は放置する」という考え方が主流だった。

　しかし、近年は主要なビジネス機能の多くがクラウドに移行した。ソフトウェアエンジニアリングの進化によって、プログラマーの間ではマイクロサービスアーキテクチャを前提とした開発手法が主流となった。

　マイクロサービスアーキテクチャでは、原則として1つのソフトウェアが単一の機能を実行する。共通のインタフェースを介して他のサービスと通信する小さな独立したコンポーネントまたはサービスとして開発される。このアプローチであれば、他の機能に影響を与えずに個々のサービスや機能のみを継続的に変更できる。

　では、なぜ全ての企業がマイクロサービスアーキテクチャを採用することで技術的負債を解消しようとしないのだろうか。基盤となるITインフラに大きな構造的変更を加えている間もビジネスを継続し、サービスを中断させることなく提供する必要があるからだ。

　こうした事情があるために、多くの企業はレガシーなアーキテクチャとアジャイルで開発された新しいシステムが混在して機能を実行し、パッチや回避策で全てをつなぎ合わせるという中途半端な状態に陥ってしまう。

　しかし、時間がたつにつれてこの「綱渡りのような運営」は限界を迎えるだろう。

モダナイゼーションの鍵は観測可能性

　このような混沌（こんとん）とした、どっちつかずの状態で事業を運営する企業でも、システムのモダナイゼーションを段階的に進めることは可能だ。ただし、継続的なメンテナンスと大規模な構造変更のバランスを慎重に取る必要がある。

　そのための鍵となるのが、観測可能性だ。ソフトウェアのパフォーマンスをリアルタイムで監視する能力を向上させることは、技術的負債の蓄積に対処するために企業が実施すべき唯一、かつ最も重要な投資である。

　多くの企業、特にスケーラビリティテストやパフォーマンス指標が組み込まれていないレガシー技術に依存している企業は、初期の警告システムを顧客からの問題報告に頼っていた。顧客から報告が入った時点で、技術チームは当面の問題を解決するための「火消しモード」に入らざるを得なくなる。

　しかし、アーキテクチャに観測可能性が組み込まれていれば、技術チームは問題が本格的な緊急事態に発展する前にその兆候を察知し、問題に対処するための最良の方法を探る時間と複数の選択肢を確保できる。

　新しいマイクロサービスを実装、更新する際にも、システムパフォーマンスに関してこうした可視性を確保することが重要だ。なぜなら、技術チームは通信に潜んでいる潜在的な問題がコードベース全体に波及する前にそれを発見し、修正できるからだ。

　重要なビジネス機能が堅牢（けんろう）なITインフラに依存し、DXが進展する中でソフトウェアの俊敏性はますます重要になる。それと同時に、ソフトウェアのアップデート失敗がもたらす結果も、問題を事前に予期できず、事前に対応できない企業にとってより深刻なものになるだろう。

（注）本稿はThomson Reutersのキラット・セクホン氏（税務・会計部門のエンジニアリング責任者）による寄稿だ。

（注1）Tech executives reassess IT resilience in CrowdStrike outage aftermath（CIO Dive）
（注2）Change Healthcare data breach officially affects 100M people（Cybersecurity Dive）
（注3）FAA has struggled to modernize computer, air traffic operations（Reuters）

（初出）CIOs must tackle the global tech debt crisis

原文へのリンク