技術的負債のリアル：現場の声から見えてきた共通認識

誤解を招きやすい「技術的負債」

いまの開発作業のスピードを優先するために、ソフトウェアの内部品質（ユーザーには見えない、内部の作り）を犠牲にするような妥協をしてしまうことはよくあります。リリース時期や納期を守れたことで一見すると得をしたようですが、その妥協がのちに、プロダクトの継続的な開発を困難にしてしまうことがあります。いまの妥協が将来のコストになるわけですが、その関係を非技術者に説明して理解してもらうことは難しいことがあります。

そんな、「いまの妥協」の負のインパクトを、お金の負債になぞらえて説明する「たとえ」が「技術的負債（technical debt, テクニカルデット）」です。1992年、デザインパターンやエクストリームプログラミング（XP）のパイオニアとして知られるWard Cunningham（ウォード・カニンガム）が初めて使用しました。

「今の開発を成功させるため、将来自分たちの足を引っ張ることになる借金（負債）を抱えた」と説明すると非エンジニアにもわかりやすいところが評価されて、用語として広く普及しました。

「技術的負債」にはわかりやすさという利点がある反面、定義が曖昧で人によって解釈が変わってくるという問題点があります。実際、2013年ごろには、いろんな人が「技術的負債」の様々な定義を披露したり、様々な主張を行うようになっていました。正統な定義がないまま、いわば「フォークロア（folklore, 民間伝承）」が乱立するような状況になっていたのです。

便利な「たとえ」である「技術的負債」ですが、エンジニアコミュニティの中である程度の共通認識がなければ、むしろ誤解を招きやすい表現として敬遠されることになっていってしまうでしょう。

そこで今回は、「技術的負債」に関してソフトウェアエンジニアが共通的に持っている認識を探った研究の成果を紹介します。ブラジルのUniversidade Salvador – UNIFACSのRodrigo O. Spínola、イタリアのPolitecnico di TorinoのAntonio Vetrò、ドイツのElsevier Information Systems GmbHのNico Zazworka、米国University of Maryland, Baltimore CountyのCarolyn Seaman、そしてFraunhofer USA Center for Experimental Software EngineeringのForrest Shullら5名の共同研究者たちが2013年に米国サンフランシスコで開催された技術的負債に関するワークショップ（International Workshop on Managing Technical Debt (MTD)）で発表したものです。

技術的負債のフォークロア

フォークロア（folklore）は古くから伝わる伝承のことです。Spínolaらは、「技術的負債」に関して様々な論者たちが繰り広げる様々な主張をフォークロアと呼んでいます。

Spínolaらはまずソフトウェアエンジニアリング実務者たちによる「技術的負債とは～だ」のような主張を、ウェブサイト、ブログ、研究論文などオンラインコンテンツから採集しました。具体的には、Googleで「technical debt」と検索した結果のうち、上位100件を分析対象としています。

こうした手続きで採集した様々な主張を分析し、類似したものをまとめ、最終的に１４のフォークロアを抽出しました。これらの日本語訳は後ほど紹介します。

ソフトウェアエンジニアたちの見解

次に著者らは、それぞれのフォークロアが一般のソフトウェアエンジニアの見解とどれほど一致するのかを分析するため、サーベイ（社会学的調査）を実施しました。

サーベイ回答者は、14のフォークロアそれぞれに対し、「強く同意する」から「全く同意しない」という5段階のリッカート尺度で回答しました。著者らは、そうして得られた回答データから、回答者集団としての同意の強さ（agreement） と回答者集団内の**意見の一致度（consensus）**を算出しました。

本研究では、オンラインサーベイと対面サーベイの2種類を実施しています。オンラインサーベイはソフトウェア開発の実務者17名が参加しました。対面サーベイの参加者は20名ですが、こちらは大学院生など非実務者が多く含まれています。この記事では、ソフトウェア開発実務者の意見を重視して、オンラインサーベイの結果に絞って紹介しようと思います。

同意も一致度も最高だったフォークロア

実務者対象のオンラインサーベイにおいて、同意の強さと意見の一致度が両方とも最高レベルだったフォークロアはこれでした：

✅「もし技術的負債が効果的に管理されなければ、保守コストは上がり続け、遂には顧客に提供している価値を上回るほどになってしまう」

If technical debt is not managed effectively, maintenance costs will increase at a rate that will eventually outrun the value it delivers to customers.

技術的負債の発生が意図的なものか、それとも意図しないものだったのかに関わらず、それを放置しているとプロダクトの価値を大きく毀損してしまうものなのだ、というのがソフトウェア開発者の一致する意見でした。

高い一致度で、強い同意を得たフォークロア

上記に次ぐレベルの同意を、最高の一致度で得ていたフォークロアは以下の5件でした：

✅「技術的負債はたいてい、長期的な影響を考慮しないで短期的な工数節約のための最適化を施すことから生じる」

Technical debt usually comes from short-term optimizations of time without regard to the long-term effects of the change.

✅「意図しない負債は、意図的な負債よりも大きな問題となる」

Unintentional debt is much more problematic than intentional debt.

✅「技術的負債を発生させることを選択している者と、その負債のツケを負うことになる者は、別人であることが多い」

The individuals choosing to incur technical debt are usually different from those responsible for servicing the debt.

✅「技術的負債は回避するより、管理すべきだ」

Technical debt should not be avoided, but managed.

✅「すべての技術的負債が必ずしも悪いわけではない」

Not all technical debt is bad.

一致して不同意だったフォークロア

サーベイ回答者が、高い一致度で「まったく同意しない」と答えたフォークロアは以下でした：

❌「すべての技術的負債は意図的だ」

All technical debt is intentional.

つまり、「技術的負債は意図しないで発生することがある」というのがエンジニアの一致した見解ということになります。

同意／一致度が高くないフォークロア

残る7件のフォークロアは、「どちらともいえない」という回答が多数のものや、回答者によって意見が異なるものです。これらはつまり、個々人の経験や置かれている状況によるもので、技術的負債全般にあてはまる性質とは言えないもの、ということになります。

🤔「よほど単純なプロジェクトでないかぎり、技術的負債の蓄積は避けられない」

Accruing technical debt is unavoidable on any non-trivial project.

🤔「技術的負債を解消させる作業は、開発チームの士気を向上させる」

”Working off debt” can be motivational and good for team morale.

🤔「いかなる状況でも、技術的負債を解消するコストは、その負債がシステム内にある時間とともに上昇し続ける」

No matter what, the cost of fixing technical debt increases the longer it remains in the system.

🤔「技術的負債の最大の問題は、付加価値や収益への悪影響ではなく、予測可能性 (predictability)の低下にある」

The biggest problem with technical debt is not its impact on value or earnings, but its impact on predictability.

🤔「個々のソフトウェアエンジニアにとって、自らが発生させている技術的負債の本当の影響を予見することは極めて困難だ」

It is very difficult for developers to see the true effect of the technical debt they are incurring.

🤔「ほとんどの技術的負債の根本原因は顧客からの圧だ」

The root cause of most technical debt is pressure from the customer.

🤔「技術的負債の解消の結果が顧客に見えることはない」

Paying off technical debt doesn’t result in anything the customers or users will see.

技術的負債の定義

2013年時点で様々なフォークロアが語られていた技術的負債について、本研究はエンジニアたちの意見を踏まえた共通認識を洗い出しました。意味づけが曖昧な「たとえ」を、できるだけ明確な意味をもった用語としていくために必要な作業だったと思いますし、エンジニアコミュニティの意見を知ること自体が面白い論文でした。

紹介した論文

• R. O. Spínola, A. Vetrò, N. Zazworka, C. Seaman and F. Shull, “Investigating technical debt folklore: Shedding some light on technical debt opinion,” 2013 4th International Workshop on Managing Technical Debt (MTD), San Francisco, CA, USA, 2013, pp. 1-7, doi: 10.1109/MTD.2013.6608671.

参考文献

• P. Kruchten,R. Nord, I. Ozkaya, “Managing Technical Debt: Reducing Friction in Software Development,” Addison-Wesley, 2019.

• IEEE Software Engineering Radio, “Episode 481: Ipek Ozkaya on Managing Technical Debt,” 2021.