「技術的負債」とは何か。原典とその対応策を探る

負債とは要するに借金のことですが、システム開発においても技術的な借金、つまり「技術的負債」（Technical debt）がある、という表現がしばしば使われます。お金の借金をすると利子を払い続けなければならないのと同じように、技術的負債を抱えると、そのツケを払い続けなければならなくなる、という比喩です。

「技術的負債」という表現は、WikiWikiの発明者で著名なプログラマとして知られるウォード・カニンガム氏が1992年に使ったのが原典とされています。しばしば目にするこの「技術的負債」というのはどういうものなのでしょうか？ 調べてみました。

カニンガム氏とファウラー氏による「技術的負債」

カニンガム氏が「技術的負債」という表現をはじめて使ったのは、1992年に行われたACM主催のイベント「OOPSLA '92 」(Object-Oriented Programming, Systems, Languages & Applications) だとされています。カニンガム氏のサイトで公開されている「The WyCash Portfolio Management System」から引用します。

Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object- oriented or otherwise.

コードをはじめて出荷することは、借金をしに行くようなものだ。少しの借金なら、リライトによりそれを埋め合わせることを促し、開発を加速することになる。オブジェクト指向は、こうした作業を許容可能にしてくれる。

危険なのは、この借金が返されなかったときだ。その適切ではないコードのために費やされた時間はすべて、借金の利子にあたる。そして技術部門のエンジニアの誰もが、からまった実装による借金の重圧を前に立ち尽くすことになる。オブジェクト指向だろうがそうでなかろうがだ。

マーチン・ファウラー氏も2009年に「Technical Debt」という記事で、カニンガム氏の「技術的負債」という比喩について説明をしています。

In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.

（技術的負債という）比喩は、やっつけ作業によって発生するものが、お金の借金に似ているということだ。お金の借金と同じように、技術的負債も利子が発生する。それは、やっつけ作業を選択した結果として、追加作業のような形でいずれ表れることになる。

私たちはその利子を払い続けることもできるし、どこかできちんと良い設計でリファクタリングし直すことによって、借金の元本を返すこともできる。元本を返すのにはコストがかかるけれども、その後の利子を減らすという利益がある。

カニンガム氏もファウラー氏も、技術的負債を抱えることによって「からまった実装による借金の重圧を前に立ち尽くす」「追加作業のような形でいずれ表れることになる」と説明しています。

できの悪いソフトウェアを作ってしまうと、あとからデバッグやリファクタリングなどの手間が大幅にかかるという指摘です。

なにが技術的負債なのか

技術的負債はお金の借金とは異なり、目に見えず、その量を計測することも難しいことから、いわゆるやっつけ仕事や納期のプレッシャーが高いときだけでなく、通常の開発においても気づかないうちに技術的負債が増えていくことがある、という困った特徴を備えています。チームで開発している場合には、どこにどのくらい自分たちが技術的負債を抱えているのか、さらに分かりにくくなるといえます。

InfoQ Japanの記事「技術的負債を管理する」には、ソフトウェアに技術的負債が含まれているかどうかを見分ける方法がいくつか紹介されています。一部を引用します（いくつかの項目は省略しました）。

• チームメンバ自身から明らかにされる通常の「におい」は、「このコードを変更できるのはCarlだけだ」、「このコードをだだコピー&ペーストしよう」、「私がコードを触れば、すべて壊れるだろう」という言葉や、コードの中にあまりにも多くのTODOやFIXMEがある(Nico Zazworka氏が上手に解説しています) ことで分かります。
• スクラムチームはベロシティを使います。チームが変わらず、外部環境も変わっていないけれども、ベロシティが減る場合、ソフトウェアシステムにおそらく沢山の技術的負債があります。
• ソフトウェアは古くなります。技術的負債の1つの指標は、もうメンテナンスされていないか、新しいバージョンの方がずっと生産性が高いような非常に古いライブラリを使う時です (例えば、EJB 2 対 EJB 3)。 最悪なのは、ライブラリがすでに古すぎて、ライブラリの開発者たちがそのライブラリをもうサポートしていない時です。
• コードカバレッジツールは、自動テストで実際にカバーしているコードがどのくらいあるのか検出できます。この測定基準は一般的なガイドラインがないので、注意して使うべきです。通常、90%以上のカバレッジは、十分なテストケースがあるという良い指標になります。逆に75%以下のカバレッジは、重大な問題を示しているかもしれません。
• 非常に悪い指標は、作成時に頻繁に問題が発生することです。これは、システムの問題が広範囲に渡るため信頼できる運用は不可能であることを意味しています。

上記の指摘をざっくりまとめると、特定の人にしか理解できないコード、なにも考えずにコピペしたコード、古いライブラリなどに依存したコード、テストのカバレッジが不十分なコードなどが、技術的負債を抱えたソフトウェアだということでしょう。

しかし、これらに気をつけたからといって、つねに十分品質が高く、技術的負債の小さなソフトウェアが開発できるとは限りません。技術的負債を小さくする、あるいは発生してしまった技術的負債を返済するには、具体的にどうすればいいのでしょうか？

技術的負債を返済していくために

MSDNマガジンの記事「技術的負債の返済に役立つ 9 つの戦術」では、表題の通り技術的返済のための施策を紹介しています。重要だと思われる最初の3つについて引用しましょう。

1つ目は学習です。

学習、学習、学習

問題があることはわかっていても、それを解決する方法がよくわからないときは、コードを泥沼から救い出すために新しい知識やスキルを身につける時期が来たのかもしれません。よく言われるように、学習が基本です。

学習の方法は1つではありません。コンサルタントやスクールなどの形式で、外部からの助けが必要になることも考えられますし、書籍で対応できるかもしれません。

適切なコードを書いたり、チームの他のメンバーのコードを理解するにはスキルが必要です。いかにチーム全体で、あるいは企業全体で学習する機会を持つかは、技術的負債の問題だけでなく、エンジニアを仕事とする人たち全体に共通する課題でしょう。

外交手腕

対処しなければならない問題のあるコードを作成したのが自身の現チーム メンバーであることは大いに考えられます。このような状態でコードを検証するときは、十分な配慮が必要です。感情を傷つけると自己防衛本能が働き、そのため改善作業がなかなか先に進まなくなります。

技術的負債を返済するには、問題を指摘し、解決しなければなりません。ほぼ間違いなく、その問題は誰かが作り込んだものでしょう。ぎくしゃくせずにチームとしてどう解決するか。コミュニケーション能力なども含め、技術的スキル以外のものも要求されるわけです。

形にする

中には、あまりにもひどい状態で、まったく何がどうなっているかを理解するのが難しいコードがあります。おそらく、すべてのクラスが同じ名前空間に含まれています。依存関係が複雑にもつれ合い、履歴をたどっていくと、短期記憶の能力をはるかに超えて、自分の居場所がわからなくなってしまうようなコードベースです。

技術的負債がソフトウェアのどこでおもに発生しているのか、見極めることは対処するうえで重要でしょう。

技術的負債に対する選択肢

技術的負債はつねに完済すべきなのかというと、議論があるところです。前述したInfoQ Japanの記事「技術的負債を管理する」では、技術的負債を抱えたコードとともに生きることも選択肢の1つだとして、技術的負債に対して3つの選択肢を示しています。

• 負債の払い戻し: 技術的負債だと思われるコード、フレームワーク、プラットフォームをリファクタリングするか、置き換える。
• 負債の転換: 現在の解決策を「完璧ではないけれども良い」解決策と置き換える。新しい解決策は、より低い利率であり、完璧な解決策を構築すると非常に高価になるならば、よい選択肢かもしれない。
• 利息のみ支払う: コードとともに生きる。リファクタンリングは、それほど良くないコードに取り組むよりも高くつくから。

技術的負債を考えるとき、その負債の大きさ、言い換えればコードの品質やバグの可能性とそれに対処する手間を、定量的に数値などで示すことが難しいことに思い当たります。

ここで紹介した記事以外にも、技術的負債にはさまざまな議論が存在します。また別の機会にそれらについても紹介したいと思います。

以下の動画は、カニンガム氏自身が技術的負債という比喩について5分ほどで解説しています。2009年に投稿されたものです。