アジャイルにおける技術的負債とは何か？

Shannon Jackson-Barnes | 20/11/2023

今すぐ何かを手に入れるためにローンを組み、後で利息を上乗せして返済するという行為だ。これは技術的負債の仕組みと似ている。ソフトウェア開発チームは、短期的な利益を得るために、最適とは言えないコードや設計の決定などの近道をし、後でコードを追加したり修正したりする。その結果、スピードとコスト削減と引き換えに品質が犠牲になる。もちろん、金融負債と同じように、未返済の技術負債も時間の経過とともに利息が増え、返済が難しくなる。

技術的負債の定義

ソフトウェア開発において、技術的負債とは、パフォーマンスよりも納期を優先することの結果である。この用語は、ソフトウェア開発者であり、アジャイルマニフェストの共著者であるウォード・カニンガム（Ward Cunningham）が、1992年のワイキャッシュ（WyCash）ポートフォリオ管理システムに関する記事で初めて使った造語である。

記事の中でカニンガムは、リファクタリング（既存コードの再構築）にリソースを振り向ける必要性を、技術者以外の聴衆に正当化しなければならなかった。彼は、技術的な複雑さを金銭的な負債に例えて、こう述べた。少しの借金は、それが書き換えによって速やかに返済される限り、開発を加速させる。

技術的負債の結果

それ以来、技術的負債はソフトウェア開発における一般的な慣行となり、激しい議論の的となっている。

悪いこと

批評家たちは、技術的負債の管理にはコストと時間がかかると主張している。マッキンゼーによると、新製品の技術予算の10〜20％が技術的負債に関する問題の解決に流用されているという。Stripeによる2018年のレポートでは、開発者は平均して週に41.1時間を仕事に費やし、そのうち13.4時間は技術的負債の管理に費やされていることが明らかになった。

良いこと

技術的負債を支持する人々は、技術的負債によって企業が開発をスピードアップし、いち早く市場に投入し、新機能や使い勝手の改善を着実に行うことで製品に付加価値をつけることができると主張する。多くの専門家は、特に熾烈な競争によって厳しい時間的制約の中で製品をリリースせざるを得ないソフトウェア市場においては、技術的負債が避けられないものであることに同意している。Stack Overflowのような大企業でさえ、顧客の需要に応えるため、ある程度の技術的負債を負っている。

現実

企業にとっての課題は、技術的負債を完全に回避するのではなく、技術的負債へのアプローチを戦略化することである。そうすることで、短期的に価値の高いもの、つまり製品や市場の適合性を見極め、顧客の需要を満たし、新たなチャンスをつかむために技術的負債を活用し、その後、タイムリーで効率的な方法で徐々に返済していくことができる。

技術的負債の種類

意図的と非意図的

2007年、Construx SoftwareのCEO兼チーフ・ソフトウェア・エンジニアであるスティーブ・マコーネルは、「技術的負債の管理」というホワイトペーパーを発表した。その中で彼は、意図的でない負債と意図的な負債を明確に区別することを提案した。彼自身の言葉を借りれば、意図的でない負債とは「……不適切な仕事をしたことによる非戦略的な結果」であり、意図的な負債とは「……組織が将来のためではなく現在のために最適化することを意識的に決定した場合」である。そして、意図的でない負債を最小限に抑え、企業が戦略的な理由から意図的な負債を安全に吸収できるようにすることの重要性を強調した。

このホワイトペーパーが発表された後、さらに多くの声が会話に加わり、それぞれが技術的負債についての独自の解釈や、技術的負債を分類するさまざまな方法を共有した。

技術的負債の象限

その2年後、英国のソフトウェア開発者マーティン・ファウラーは、マコネルの理論を発展させ、テクニカル・デット・クアドラントを提唱した。このクワドラントの目的は、意図とコンテキストに基づいて、技術的負債を4つの異なるカテゴリーで定義することであった。意図については、「技術的負債は意図的なものか、それとも不注意によるものか？そして、その技術的負債が慎重なものか（将来のことを考えて慎重に行ったものか）、無謀なものか（結果を顧みずに行ったものか）を問う。

テクニカルデット・クワドラントに基づき、テクニカルデットは4つのカテゴリーのいずれかに分類される：

慎重-計画的 - チームは意図的に負債を背負い、それを解決する計画を立てる。

慎重-不注意 - チームは意図せず負債を背負うが、それに気づき、修正する計画を立てる。

無謀-故意 - チームが意図的に負債を背負い、それを解決する計画がない。

レックレス-うっかり - チームがうっかり借金を背負ってしまい、それを解決する計画がない。

技術的負債に関する用語のオントロジー

2014年、学者グループがそれまでの2つの理論を発展させた白書を発表した。

Software Engineering Institute によって発表された Towards an Ontology of Terms ontechnical Debt（技術的負債に関する用語のオントロジーを目指して）という論文では、負債を意図や文脈に基づいて分類するのではなく、負債の性質に基づいて分類している。この論文では、技術的負債について 13 の明確な分類を提案している。その中には、アーキテクチャ、ビルド、コード、欠陥、設計、ドキュメンテーション、インフラ、人、プロセス、要件、サービス、テスト自動化、テスト負債が含まれる。

これらのカテゴリーは、開発会社が特定のタイプの技術的負債を特定し、ターゲットとするのに役立つ。例えば、デザイン・デット。これは、ソフトウェア製品のユーザーインターフェースの不完全さを指す。アジャイルチームは、投資家に売り込むといった短期的な目標を達成するために、意図的に優れたデザインコンセプトやソリューションを省くことを選択するかもしれない。ピッチが成功すれば、チームは「借りを返す」ことができ、よりユーザーフレンドリーに、より視覚的に魅力的に、よりさまざまなデバイスと互換性を持たせるためにデザインを見直すことができる。

技術的負債比率

技術的負債比率（Technical Debt Ratio：TDR）とは、コードの一部を修正するのにかかるコストの差を、その部分を構築する場合と比較したものである。開発チームは、特定の負債を返済することが、負債を大きくするよりも価値があり、負債自体が価値ある投資であることを利害関係者に納得させるために、TDRを使用する。

最も一般的に受け入れられているTDR方程式は以下の通りである：

(浄化費用 ÷ 開発費用) × 100 ＝ TDR

修復コストはソフトウェア製品を修正するためのコストであり、開発コストはその製品を開発するためのコストである。適切なTDRは、プロジェクトの規模や範囲、チームの定義基準によって異なる。技術的負債測定ソフトウェア会社Stepsizeの共同設立者兼CEOであるアレックス・オメイヤーは、TDRは5％以下が理想的だと言う。

開発チームはどのように技術的負債を管理するか

賢いアジャイル開発チームは、技術的負債を科学的に把握している。彼らは、読みやすさの問題から、最適でない設計、技術文書の不足に至るまで、あらゆる種類の技術的負債を測定、監視、維持する方法を知っている。あらゆる手抜きが報告され、説明され、後日解決される。稚拙なプログラミング」や「怠惰な設計の選択」ではなく、予測された結果を意図的に妥協するのだ。

以下は、開発チームが技術的負債を削減または解消する多くの方法のほんの一部である：

技術的負債の基準を確立する

開発チームは、技術的負債について同じ見解を持つべきである。これには、技術的負債をどのように定義するか、技術的負債をどのように特定し、追跡し、管理し、解決するかが含まれる。稚拙な仕事と技術的負債を明確に区別すべきである。さらに、”完了 “の普遍的な基準を設けるべきである。

従来の開発チームにとって、”完了 “とは通常、QAがテストするのに十分なアイテムであることを意味する。このアプローチは、開発サイクルに忍び込むバグを引き起こし、それが時間とともに蓄積されていく。そのため、QAが製品を手にする頃には、バグが何層にも積み重なっている。

しかし、アジャイルチームは、”完了 “を、機能や機能がリリースできる状態になったときと定義する。つまり、チームは、現在のアイテムが顧客の準備ができるまで、次のステップに進まない。

自動テスト

自動テストは、技術的負債を減らす効果的な方法である。開発者がバグを発見したら、それを実証するために自動テストを行うべきである。そして、そのバグは速やかに修正されるべきである。その後、同じ自動テストを再度実行し、バグが修正されテストがパスしたことを確認する。

リファクタリング

コード・リファクタリングとは、コンピュータ・コードの外部動作を変更したり追加したりすることなく、コードを再構築することである。リファクタリングでは、新たなバグやエラーが発生する可能性が低いほど小さなコード変更を行う。その結果、既存のソースコードの動作や機能が維持される。

リファクタリングは、「ダーティ」なコード（読みにくく保守しにくいコードを表す非公式な用語）を「クリーン」なコード（読みやすく、理解しやすく、保守しやすいコード）に変換することで、技術的負債を減らすのに役立つ。コード・リファクタリングは、コードの動作や機能の問題を解決するものではないが、コードを読みやすくする。