技術的負債(Technology Dept)はソフトウェア開発上の問題に対して、根本的で徹底した解決策ではなく、安易で不完全な「その場しのぎ」の解決策を選択したために、組織が後で支払うことを余儀なくされる大きな潜在的コストのことです。コード負債とも呼ばれます。技術的負債については、プログラマーのWard Cunningham氏が1992年に発表した記事(英語)で初めて定義されました。その記事では、不完全なコーディングによって企業は短期的にはコストを節約できるものの、長期的には、金銭的負債と同様に技術的負債による「利息」が蓄積し、時間が経つにつれて最初の問題を修正するためのコストが増加すると述べられています。
技術的負債は悪いもののように思えるかもしれません。しかし、適切に管理されていれば、必要に応じて開発を迅速に進めるための手段となります。実際にMVP(実用最小限の製品)は、大きな技術的負債を抱えた状態で開発されることも珍しくありません。この場合、MVPに継続的な価値があることが証明された段階で、完全にリファクタリングや作り直しが必要になるということが想定されています。技術的負債とは、物事を迅速に行うことと、それを正しいやり方で行うことは、滅多に両立しないという認識に立った考え方であるといえます。
また、技術的負債は、意図せず発生することもあります。ずさんなプログラミング、手抜き、急なスケジュールの前倒しはすべて、どの企業も直面する共通の問題といえるでしょう。この用語の厳密な定義に従えば、これらの問題は真の技術的負債には分類されないものの、問題の修正には同様の作業が必要になることは変わりありません。
技術的負債とは?:目次
技術的負債の特定は非常に難しいです。また、低品質なコードが技術的負債になるとは限りません。技術的負債とは、コードそのものではなく、低品質なコードがもたらす損害と、後にそれを修正するためのコストを指します。
元来、技術的負債とは、トレードオフが必要となることがわかっている意図的なものです。コードは、後々修正されることを意図したうえで(MVPの一部として、または一時的な解決策として)、記述されることがあります。このような技術的負債を特定するのは簡単です。開発者の中には、ある解決策が一時的なものであり、将来の時点で何らかの手直しが必要になるということをコーディング中に積極的に文書化する人もいます。
その他の種類の技術的負債については、見抜くのがより難しい場合があります。偶然、怠慢、能力不足、適切なトレーニングの欠如などが技術的負債を招くこともあれば、ユーザーの要件が途中で変更され、それでも製品を予定通りに出荷しようとして、ミスが発生したり、急いでコードを記述したりしたために生じることもあります。また、数カ月あるいは数年後に別のプログラマーがプロジェクトを引き継ぎ、コードベースに変更を加えることで新たな問題が発生することもあります。
意図しない技術的負債を発見する主な方法の1つは、ユーザーの声に耳を傾けることです。問題を訴えることが多いのはユーザーです。たとえば、時間の経過とともにパフォーマンスが低下するという問題をユーザーが訴えているとしたら、そこに意図しない技術的負債が潜んでいる可能性があります。また、技術的負債を発見する別の方法として、クラッシュログやアプリケーションパフォーマンスデータの分析も挙げられます。
技術的負債は、本来は悪いものではありませんが、良い方向に作用することが少ないのも事実です。しかし、時間との勝負であるような場合や、完成したコードの最終的な品質が重要でない場合には、貴重な手段となり得ます。たとえばPoC (概念実証)や、どうしても必要なソフトウェア機能を市場に迅速に提供しなければならない場合などには有効な手立てです。
とはいえ、技術的負債が膨らんだり、無計画に使用されたりすると、問題が生じ始めます。実際、技術的負債という概念は、プログラミングの粗悪さやいいかげんさを隠すために使われることが少なからずあります。技術的負債という概念の背後にある中核的な考え方についても、年々誤解が深まっていると主張する専門家もいます。Ward Cunningham氏は当初、開発者が解決しようとしている問題への理解が不十分なために、最初に低品質なコードを記述したとしても、その理解が深まった後でより良いコードに書き換えるつもりであれば、技術的負債を肯定的に捉えることができると述べていました。しかし、今日の技術的負債の多くは、単にやり方がずさんなために発生しているといえるでしょう。「後で修正する」というのがいつも言い訳であったり、低品質なコードをすべて技術的負債と呼んでいたりするようでは、技術的負債は「悪」であると考えるべきでしょう。
金銭的な負債の場合も同様のことが言えます。良い技術的負債とは、なるべく迅速またはタイムリーに返済するように計画され、それを利用することで組織とエンジニアリングチームが何らかのリターンを得られるようにすることです。開発チームがプログラミングの問題に対する理解を深めるにつれて、低品質なコードをリファクタリングして書き直し、より持続可能で堅牢なソフトウェア製品を生産することで技術的負債を返済する必要があります。MVP(実用最小限の製品)にはほぼ必ず技術的負債が伴いますが、時間の経過とともにその改良を重ねていくことを計画している場合にのみ、「良い」技術的負債といえます。
技術的負債は、複数のカテゴリに分類されています。
技術的負債の管理は複雑な問題です。なぜなら、あらゆる種類の負債と同様に、技術的負債も返済が長引くほど悪化していくからです。組織が「返済」計画を立てずに技術的負債を負った場合、問題はすぐに悪循環に陥って制御不能になる可能性があります。
ここでは、技術的負債に対処するためのベストプラクティスをいくつか紹介します。
行動分析の結果から技術的負債がビジネスに及ぼす影響について、以下のことがわかっています。
技術的負債は、以下のような形でビジネスに数多くの財務的な悪影響をもたらす可能性もあります。
技術的負債は、売上の減少、サポート費用の増加、生産性の低下など、企業の財務実績に悪影響を及ぼす可能性があります。
継続的開発という固有の性質から、DevOps環境を技術的負債の回避に役立てることができます。継続的なテスト、自動化ツール、開発サイクルと運用の統合によって、短期的であっても、技術的な課題が脇に追いやられるようなことが起こりにくくなります。DevOpsチームは常に、企業にとって最大のメリットをもたらす方法で問題を解決するにはどうすべきかを考えています。そのため、技術的負債の課題に対しても、早期に、頻繁に、そして直接的に対処しなければならないことも多くあります。
問題は、すべてのコードのスニペットが高品質であるとは限らず、同じレベルのチェックを受けるわけでもない点にあります。最も厳格なDevOps企業であっても、緊急の問題に対処するために、開発者がちょっとしたコードをすばやく記述し、QAプロセスを省略しなければならないことがあります。
実際、迅速な開発と継続的なリリースサイクルを重視するあまり、このようなその場しのぎの解決策が結果的に容認されることもあります。なぜなら、開発者は自分のせいでリリースパイプラインを遅らせることは避けたいからです。さらに、DevOps体制が確立するよりも前から存在するサードパーティのライブラリやレガシーコードには、それ自体が抱えている対応が必要な技術的負債の問題が存在していることもよくあります。
基本的に、DevOpsは技術的負債を免除するものではありません。しっかりと管理されたDevOpsフレームワークは、技術的負債への依存を軽くすることはできますが、開発者の多くは、非DevOps環境で「危機的状況」を乗り切ってきたのと同じ回避策にこれからも頼るでしょう。
金銭的負債とは違って技術的負債には特有の代価があり、従業員や他のチームメンバーの多大な労働力によってこの負債を返済します。新製品や新機能の開発とは異なり、古いコードをリファクタリングして技術的負債を返済する作業は、やりがいのある仕事とはいえません。また、開発者が付加価値のある作業に取り組む代わりに、古いコードを修正することは、チームの他のメンバーのみならずビジネス全体にも影響を与えます。
技術的負債が重くのしかかると、開発チーム内で責任のなすりあいや非難の応酬が始まり、分裂や内輪もめにつながる可能性もあります。チームワークがすべてであるDevOps環境において、これはあってはならないことです。これにより、チームの士気低下や、生産サイクルに遅れが生じて新製品のリリースまでの時間が不足する可能性があります。また、新たな技術的負債が発生するため、ビジネスの状況がさらに悪化する可能性があります。
最終的には、管理できなくなった技術的負債が悪循環を生み出して、従業員の不満や高い離職率のほか、ビジネス成果にさまざまな悪影響をもたらすことになります。
多大な技術的負債が蓄積すれば、やがてはその負債を単に管理するだけでなく、返済しなければならないときがやってきます。多大な技術的負債を返済するための方法には、次のようなものがあります。
「技術的負債」という用語は誤用されることも多く、十分な理解を得られていません。そして多くの開発者は、品質の低いコードすべてに対してこの用語を当てはめています。これでは、技術的負債の有用性を活かすことはできません。技術的負債を適切に管理すれば、ビジネスに大きな柔軟性、俊敏性、実行スピードをもたらすことができます。その一方で、技術的負債が適切に管理されなかったり、過剰に使用されたり、誤用されたりすると、すべてが深刻な問題につながり、技術的負債が累積するにつれて状況はさらに悪化し、最終的には開発サイクルが停滞することになります。意図しない技術的負債や環境による技術的負債を回避し、意図的で詳細に文書化された技術的負債のみを利用するよう心がけることで、開発チームそしてビジネスを成功に導くことができます。