はじめに
ソフトウェアと組織経営をめぐる問題で避けては通れないのが、「技術的負債」と言う言葉です。一般には、「早さ」を求めて構築されたシステムの構造的な課題が、徐々に蓄積し、債務であるように徐々に開発速度そのものを遅くして行くと言う現象のことを意味しているように捉えられます。
これは、技術組織を持つ経営者や、ソフトウェアエンジニアではない発注者にとっては理解しにくいものです。またソフトウェアエンジニアであっても「古くなってしまったコード」や「わかりにくコード」全般のことを技術的負債と呼び、それをもって何かを説明したかのように考えてしまうことはままあります。
これらに起因して、双方のコミュニケーションが破綻してしまうこともよく見られる景色です。
技術的負債の経済効果は毎年マイナス12兆円
このような構造的な問題をはらむ技術的負債は、老朽化したレガシーなシステムとして、事業の組織改革を遅らせてしまいます。
経済産業省 - DXレポートによると、2025年以降、毎年12兆円という負の経済効果をもたらすと試算されています。
これは、3兆円から4兆円と呼ばれる東京オリンピックの費用の3~4倍の金額で、毎年オリンピックを4回こなせるほどのムダが、レガシーなシステムによって生まれているということです。なかなかの衝撃的な数字です。
これらは耳目を集めるホラーストーリーではあるものの、「技術的負債」という言葉をめぐる議論は、前提や定義が揃っていなかったり、目的なそろっていなかったりと空論が展開されがちです。
本論では、まず巷にあふれがちな「技術的負債」論を整理するため、過去の議論をまとめていき、技術的負債に関する論についての出発点を揃えることを目的としています。
技術的負債をめぐる議論
技術的負債と言う言葉は、アメリカのコンピュータ技術者であるウォード・カニンガムによって、1992年に提唱された概念です。その言葉は瞬く間に流行し、システムとビジネスを繋げる用語としてもてはやされました。彼は、経験レポートの中で次のように語っています：
最初のコードを出荷することは、借金をしに行くのと同じである。小さな負債は、代価を得て>即座に書き直す機会を得るまでの開発を加速する。危険なのは、借金が返済されなかった場合である。品質の良くないコードを使い続けることは、借金の利息としてとらえることができる。技術部門は、欠陥のある実装や、不完全なオブジェクト指向などによる借金を目の前にして、立ち尽くす羽目になる
これは、ソフトウェア開発が段階を得るに連れて、それまでの構造によって機能追加が徐々に困難になって行く様子を見事に言い表してくれました。
ソフトウェア開発において、初期設計通りにプロダクトが成長していくことは少なく、多かれ少なかれ、次第に初期設計からの逸脱を要求されるようになります。
このような状態のプロダクトへの追加開発は、中身を知らない人々から見たときの予想に反して、時間のかかるものになってしまいます。本来はこのくらいでできるはずだと予想しているのに、時間がかかってしまうというソフトウェアの中身を知らない人々の感覚と、実際にソフトウェアを書いている人々にとって必要な作業との時間感覚に差が生まれることになります。
このような認識の差は、しばしばエンジニアの能力的な問題ではないかとか、努力の不足ではないかと言う邪推を生み出し、多くのハレーションが現場レベルで引き起こしています。
そんな中で、カニンガムの提唱した「技術的負債」という概念は、現場で働くエンジニアにとって、「我が意を得たり」という気持ちにさせる表現だったことは間違いありません。そして、この言葉は、エンジニアと非エンジニアのコミュニケーションのための言葉として、あるいはその現象の説明として使われ始めました。
こうして、「技術的負債」という言葉は、システム開発を進めるにつれて引き起こされる開発時間の増大という「現象」を巡って、それらを議論するためのコミュニケーションの言葉として広く使われることになりました。
しかし、「技術的負債」という言葉は、会計上も経営指標においても、計上されるわけではない空想上の概念に過ぎません。
「技術的負債」という言葉の定義も曖昧で、何をもって技術的負債ということができ、何を持って測定され、どのような返済手段があるのかといった議論も尽くされることなく、広く用いられるようになっていきます。
その結果、「技術的負債」という言葉の存在で何かを説明したと思い込む人々や、ソフトウェア開発における経営上の問題について関心を抱かない経営者によって、「技術的負債」という言葉は、むしろコミュニケーションを断絶する言葉になってしまっているケースがあるように思います。
そもそも「負債」という言葉は、どのように解釈されているのでしょうか。経営者ではない多くの人々にとって、「放っていてはいけない」「定期的に返済すべきもの」として、負債という言葉が用いられています。これは、日常的な家計の理解における「借金」と同じようなものだと考える人が多いのではないでしょうか。
ところが、経営者にとっての「負債」という言葉には、資本としての意味合いもあります。事業拡大を考えるにあたって、利子率が低い借り入れであれば、事業拡大において有利になるので、できるかぎり多く借り入れたいという心理も存在します。経営者にとっては、負債を多く借り入れることができることは、信用度の高さを意味していて、決して「借金」という日常語的な理解よりもポジティブな意味合いを見出しています。
このように、負債というアナロジーから抱く印象はそれぞれによって大きく異なるため、コミュニケーションが分断される恐れがあります。このようなアナロジーによる誤解が存在する中で、「技術的負債」だから解消しなければならないという主張は、空転してしまうこともあるでしょう。
不可解な開発速度の低下
まず、論点を整理するために、「技術的負債」という言葉が説明しようとしている「不可解な開発速度の低下」という現象について考えていきましょう。
このような現象は確かに存在しています。これは、システム開発というものが、「何かをできる機能を作る」ということと同時に、「何かできないところを作る」という作業であると言う理解が必要不可欠です。システムを開発する過程で、「ここは変えることがあまりないだろう」という部分を固定的に作り、「ここはよく変わるかもしれない」という部分を変動的に作るというのが、システムの設計作業です。
これは、ソフトウェア開発をやったことがない人にとっては、なかなかイメージしにくいかもしれません。開発初期においては、今まで積み上げてきたシステムもなく、単純な機能であることが多いので、新機能の実装も比較的簡単に行うことができます。
しばらく開発を進めると、同じような要求をしているつもりでも、「時間がかかる」ようになります。今まで開発してきたシステムが、逆に制約となって考えないといけない範囲が広がるからです。
仮にソフトウェアの複雑性に関する式が、指数関数C = A*exp(Kx)で表現できると仮定します。システムの構成要素が増えるほど、相互の関連性が増えていくため、あながちズレた表現でもなさそうです。ここに開発初期と開発後期で「同じ数」だけの機能開発を行うとします。実際には、ソフトウェアには同じ開発というのはありませんから、仮想的な数字です。たとえば、ファンクションポイントを想定してもらえるとよいかもしれません。そうすると、機能開発には「複雑性」と「機能数」がつくる面積だけの開発工数が必要になります。初期の開発工数に対して、後期の開発工数が大きくなっていることがイメージできると思います。
もう少し、想像をしやすく表現すると、システム開発が徐々に困難になって行く理由は、パーティゲームの「ジェンガ」のようなものです。
ゲーム初期段階でのジェンガは、簡単にブロックを抜き出したり、積み上げることができます。このとき、ゲームはスピーディに進んでいきます。ところが、ゲームをしばらく続けると、バランスを取るのが急激に難しくなっていき、テンポがゆっくりとなっていきます。慎重に抜き差しをしないと崩れてしまうためです。
様々な要件の変化によって形作られたジェンガは、徐々に不安定に、積み上げるのが難しく時間がかかるようになります。これが開発が遅くなる現象とよく似ています。
このように、システムを連続的にアップデートしながら作っていくときには、中身を知らない人からみると予想外のタイミングで、予想外の形で開発が進まなくなると言う現象が発生します。
中身を知っている人からすると、このようにシステムが徐々に新規開発をしづらくなっていくことが見え始めると、この複雑なシステムの構造を整理して、現状よりも高く積めるように変化させていきたいと考えるようになります。
そのためには、一度、機能を変化させない形で、中身の構造だけを将来像に合わせて再構築したいという風に考えます。このときに、経営者に対して、「技術的負債が溜まっていて、返済しないといけない」というようにコミュニケーションをとるのです。
しかし、技術的負債という現象のイメージを抱きにくい経営者にとっては、「機能を追加しないけど、障害が発生するリスクを背負って、時間を使いたい」という要求は、理解が難しく、また適正であるか判断することができないため、「とりあえず全て受け入れる」か「よくわからないので拒否する」かの二択になってしまい、フラストレーションを貯めることになりかねません。
コミュニケーションのための分類
このように「技術的負債」という言葉が、コミュニケーションの起点になったというところは評価をしつつも、具体的なレベルにおいて、技術者と経営者のコミュニケーションのツールとはなり得ませんでした。
その点から、高名なソフトウェアエンジニアのマーティン・ファウラーは、自身の記事「技術的負債の４象限」(TechnicalDebtQuadrant)の中で「何が負債であるか」という議論をするよりも、「技術的負債」になりうる要素がどのように生み出されたのかによって、マネジメントの手助けになるような議論を進めることに意味があると考えました。
「負債」の借入において重要なのは、元本どころか利息に関しても返済の見込みのない借入をしないことです。無鉄砲に、あるいは無意識のうちに借入をしてしまうことはマネジメントに悪影響を及ぼします。
(マーティン・ファウラー, https://martinfowler.com/bliki/TechnicalDebtQuadrant.html, 2009)
このような観点から、「無鉄砲な/慎重な」「意図的な/無意識の」という２つの軸を掛け合わせて、技術的負債の４象限を定義しました。
重要な点は、慎重かつ意図的に作られた負債であれば、問題なく返済することができるだろうと考えた点です。一方、無知や無鉄砲さから生まれた技術的負債は、予想しない利息を支払うこととなり、問題が大きくなってしまうため、避けるべきであるとしています。
１つ１つの問題がなぜ生まれたのかを検討することで、避けられるべき問題を避け、解消すべき問題をあぶり出そうとしました。
このことは、次のような考えを生みます。後の負債になることを意識的に理解して、慎重に行えば「開発を早くすることができる」し、後の負債になることを避けようと思えば、「開発時間を長くすることで回避することができる」という考えです。
果たしてこの考えは、正しいのでしょうか。
クイック＆ダーティの神話
「技術的負債」という言葉の背景に隠れた前提にあるトレードオフとして、コードを書く上で、「綺麗さ」と「速さ」は交換可能であるというものがあります。これは「速い」と「汚い」を合わせて、クイック&ダーティに作るというような慣用句と共に用いられます。
あるコードが、のちのち開発出力の遅滞を引き起こすような「技術的負債」になるかどうかを判別することは非常に難しいものです。ましてや、経営的な要求に合わせて、与えられた開発期間から柔軟に汚さと速さを選択すると言うような器用な芸当はほとんど不可能だと言えます。
これは、極めて基礎的なところであれば多少はできるかもしれませんが、実際には、ソースコードが汚くて遅い人もいれば、綺麗で速い人がいるということの方が多いと言えます。
そして、プロダクトの開発とは、継続的にさまざまな市場の不確実性を考慮して要件が変わって行くものです。それをあらかじめ予見して、このコードは負債になるとか、このコードは負債にならないとか、そのような点を設計に盛り込むというのは実質不可能です。
これは、負債として理解しておけば、汚いコードを書いても良いというわけではなく、その時できるかぎりの良いコードを書く重要さを表しています。
一般に考えられている綺麗なコードというものは、その要件を実現するのに適切なシンプルな構造をしているコードです。それに対して、汚いコードというのは、複雑で整理されていないコードのことを意味しています。
綺麗でシンプルなコードは、のちのち「技術的負債になりにくい」という性質を持っていることが多いのですが、汚いコードというものは、複雑であるがゆえに、全体を読み解くことがむずかしくなってしまい、「技術的負債になりやすい」という性質を持っています。
将来的に技術的負債になりにくいコードというものは存在していても、技術的負債にならないというコードが存在するわけではありません。予想外の機能追加や、ビジネス目的の方針転換、人員数の増加などさまざまな外的要因によって、技術的負債というものが蓄積されやすくなります。
開発者がその時点ですべきことは、YAGNI原則(you ain’t gonna need it )に代表されるように、「今必要な機能をシンプルに作る」ことで、あって将来的にシンプルであり続けると予測し、アーキテクチャを組むこと自体が、技術的負債の材料となる複雑性をシステムに組み込んでしまうことになります。
「シンプルに作るのか、複雑に作ってしまうのか」はトレードオフにはなりません。これはプログラマーの思考過程のシンプルさと複雑さの問題であって、時間をかけたからシンプルになるという性質のものでも、時間をかけなかったから複雑になるという性質のものでもありません。
このように、そもそも「クイック&ダーティ」というトレードオフというものが成立するのかというのは常に考えの中に入れておく必要があります。
技術的負債は「見ることができない」
このような「技術的負債」というアナロジーをめぐる議論の中で、フィリップ・クルーシュテンは、技術的負債をより具体的に定義するためにマーティン・ファウラーとは別の次のような4象限を定義しました。
「見える/ 見えないの軸」と「プラスの価値/マイナスの価値の軸」の２つによるマトリックスです。
(クルーシュテン、2012)
これは、内部構造を見ていない人にとって理解することのできない要素のうち、プラスの価値のあるものをアーキテクチャーといい、マイナスの価値になるものを技術的負債と定義したものでした。
この観点は、技術的負債がアーキテクチャと対になる要件であることを示しており、その特徴をよく表していると言えます。
「見ることができない」という非対称性
クルーシュテンの指摘するところの、「見ることができない」とはどういう意味なのでしょうか。本当に見ることができないのであれば、アーキテクチャもまた見ることができないので、修正も構築も不可能だということになります。
ここでいう「見ることができない」は、表面的な機能から発見することができないということを意味しています。ソースコードの中をじっと然るべき人が見れば、読み解くことができるが、システムの表面的な機能だけを見ていては、知りうることができないということだと解釈できます。
システムに関して、エンジニアと非エンジニアの視点は違います。それは、CTスキャンされた図像で人体を見ているか、肉眼で表面的に見ているかというくらいに違います。非エンジニアは外側から見たシステムの様子しかうかがい知ることができません
一方、エンジニアからはCTスキャンを通すように内部の構造を理解しています。であるからこそ気がつく病魔の兆候も、非エンジニアには伝わりません。
「技術的負債」というアナロジーが、経営者とエンジニアのコミュニケーションのために有用だと考えられ、生まれたのにもこのような非対称性が背景にあります。
つまり、この「見える/見えない」という情報の非対称性が、技術的負債が問題になる最大の理由だと考えることができます。
理想システムの追加工数との差による表現
技術的負債をめぐるもう一つの重要な観点として、クラウス・シュミットによる数学的定義が挙げられます。それは次のような数式です。
これは、技術的負債は、機能追加時の２つのシステムの工数(コスト)の差で表現できるのではないかという考え方です。１つは現状のシステム、もう一つは「理想的なシステム」です。それぞれにある機能eを追加しようとしたときに、かかる工数に差が生まれ、それが技術的負債の単位だとするものです。
たとえば、ある機能を追加する時に50人日かかるシステムが、もし理想的な場合は20人日で済む場合、差の３0人日という逸失コストが技術的負債を表しているというもので、技術的負債という言葉をあらたな観点で説明するものでした。
この考え方は、技術的負債が実体として何者であるかどうかというのを問わないという点で、画期的な考え方だと言えます。表面上表出するコストの差だけで表現できるため、経営的観点との結合のしやすさにも価値があります。
また、「技術的負債TD」というものを知るには、かならず「付け加えたい機能e」が必要であるという観点も重要な示唆を持っています。何も手を加える必要のないシステムの技術的負債は、「0」です。技術的負債とは、システム単独で成立しているわけではなく、新たに追加したい機能があって、初めて成立する観念だとわかります。
この考え方を使うと、「技術的負債の総量」は理想的なシステムというものを具体的にしないとわかりませんが、「技術的負債への対策」にどの程度のコストを費やしても良いのかということは考えることができます。
たとえば、あるシステムSに{ e1, e2, e3 }という機能追加をしていきたいと考えたとしましょう。このとき、機能追加の見積りをそれぞれおこなったところ、e1に30人日、e2に50人日、e3に60人日かかるということがわかりました。
ところが、あるエンジニアが技術的負債を返済したいと申し出、それには一定のコストが必要だということを提案してくれました。
このコストが適切であるか捉えるために、「技術的負債の返済策」を施したシステムS’に対して、{e1,e2,e3}の機能追加を行なった場合の見積りを依頼しました。
すると、e1に25人日、e2に35人日、e3に40人日であることが判明しました。図にすると以下のようになります。
それぞれに費やされるコストを足し合わせると
とわかりました。
このように計算することで、「技術的負債の返済策」のコストが、40人日以下であれば、合理的な決断であると考えることができ、判断を行うことができます。
しかし、この考え方も限定的な合理性になる可能性があります。それは、プロダクトオーナーにとって「e1の機能追加後の仕様変更オプション」の価値が非常に高いというケースです。
この想定シナリオでは、技術的負債を返済するケースにおけるe1のリリースは、x+25人日を費やしたあとになります。一方、元々のケースであれば、35人日を費やした時点で、このオプションを行使することができます。
このようにトータルコストの削減が、最も合理的でないというケースはプロダクトマネジメントにおいては、発生しやすい問題です。しかし、具体的な数字を持って「技術的負債」に肉薄できるという点で、メリットも多い考え方です。
アーキテクチャの資本コスト
シュミットの「工数の差」によって表現される「技術的負債」は、便利であったものの、その「負債」というメタファーが持つ、蓄積され、徐々に効率が悪くなるという特性をあまりうまく表現できてはいませんでした。
システムは、機能追加するごとに複雑性が増していきます。それにともなって、機能追加へのコストが増大します。このようなイメージを表現するために「これまでに費やされた工数」に対して、一定割合、負の価値を持つアーキテクチャが作られるとしましょう。
カニンガムの定義どおり、ソフトウェアの機能追加を「借入」として捉え、それに対する「資本コスト=利子」をシュミットの定義する「開発工数の差」として考えるとその関係がわかりやすくなります。システムは、開発するごとに複雑化していくので、その複雑さが利子として、「開発工数の差」を生み出していくとする考え方です。
たとえば、次のようなケースを考えてみましょう。開発人員を徐々に増やしていったチームがあったとします。それに対して、累積工数の4%が次の機能追加をするための利子として取り立てられ、それが開発出力を低下させます。
このシミュレーションにおいては、開発人員を追加していっても徐々に開発出力が伸びにくくなっていくことがわかります。
これは、「システムの複雑性の増加」と「開発出力」の関係性はうまく表現できています。しかし、この利子率ないし資本コストが何によってきまるのかはうまく表現できていませんでした。
シュミットの定義は、この穴を埋めてくれます。彼の数式の意味する技術的負債は、負債というよりもむしろ「資本コスト」として捉える方がわかりやすくなります。
アーキテクチャの資本コストは、現実には、様々な利子率の資本の組み合わせとしてポートフォリオを組んでいます。
具体的な例で考えてみましょう。ここに、４つのサブシステムA,B,C,Dによって作られているプロダクトがあったとします。
それぞれに対して、それまでに費やした累積工数を算出し、今後予定されている機能の見積りと、アーキテクチャのリファクタリングを行なった場合の見積りを算出します。その差分をとり、累積工数で割ると各サブシステムの利子率を得ることができます。また、全体の累積工数に対して、工数差分の合計の割合を見れば、全体の利子率が推定できます。
このようにすれば、今後やっていきたい改善とそれに対するざっくりとした見積りから、アーキテクチャの資本コストを把握することができ、どこからどれくらいのコストをかけて改善していけば良いのかという大まかな判断に使うことができます。
ところで、技術的負債というメタファーが必要とされた背景は、ただ単に「システムの複雑性が増加する」という現象を説明するためだけのものなのでしょうか。そうなのであれば、アーキテクチャの資本コストを決めるシュミットの定義を用いて、合理性を議論すればよいということがわかります。
しかし、さらに踏み込んで考えると、このような技術的負債というメタファーが必要であった、あるいは多くの人々に共感を得て、議論が活発に行われた理由は別のところにあるように思われます。
このメタファーが人々に必要とされた最大の理由は、システムの中身を見ることができるエンジニアチームと経営者とのコミュニケーションの問題です。根本にはシステムの複雑化という現象をめぐる実感の違いが両者にあります。そして、その実感の差が合理的な決断を見失わせ、コミュニケーションミスが累積した結果、技術的負債というキーワードが広まっていったのでしょう。
エンジニアと経営者の情報非対称性
シュミットの定義によれば、技術的負債(実際には、アーキテクチャ資本の資本コスト)はある機能を付け加えたいときに掛かるコストの差として表現されました。何との差であるかと言えば、「理想的なシステム」との差です。
ここで、注意したいのは「技術的負債」という言葉が、経営者とエンジニアのコミュニケーションのために生まれたという点です。システム内部に起こる「複雑性の増加」によって、機能追加が遅くなるという現象を経営者は理解しにくく、また数値化もしにくいので合理的判断がしづらいというコミュニケーション上の問題に、「負債」というメタファーを当てて、コミュニケーションを始めるために生まれた考え方でした。
つまり、「技術的負債」というキーワードで問うべきは、エンジニアチームと経営者の間に存在する認識の差であって、システムの複雑性の増加そのものではないと考えるほうが、より「技術的負債」という言葉をめぐるアプローチとしては適切だということです。
この観点で考えると、シュミットの定義における「理想的なシステム」とは、経営者(またはプロダクトオーナー)が考えるところの「理想的なシステム」であって、「空想上の理想的なシステム」ではないのではないかと考えることができます。
これは現実問題では、非エンジニアが想定する見積り工数とエンジニアチームの見積り工数との差として表出することになります。これこそが、「技術的負債」という言葉が必要とされた理由であり、「システムの複雑性」とは本質的に違うものと捉えることで、問題をよりクリアに捉えることができるだろうと考えています。
また、クルーシュテンの４象限からすると、技術的負債とはシステムにおいて、「見えない」「マイナスの価値」のある要素であるという定義を行なっていました。ここでの見えないというのは、表面上の機能からは見ることができないという意味です。ここに情報の格差が生じます。エンジニアはシステム内部の構造をCTスキャンの目でみています。しかし多くの経営者は、そうではありません。
さらに、経営者の頭の中には、「これから追加していきたい機能」があるかもしれませんが、それと同じものをエンジニアがイメージできているとは限りません。エンジニアが想定している追加機能は、実際には追加しないかもしれないのです。しかし、シュミットの定義する負債は、追加機能が明らかでないと判断はできません。ここに何を負債と捉えるのかの認識の格差が生まれます。
このように経営者とエンジニアの間において、想定する見積りに誤差がでる理由は、お互いの間に存在する情報の非対称性にあります。この格差が存在しなければ、お互いの見積りの間に差は生まれません。
このように経営者とエンジニアの間に存在する
- 追加機能の情報非対称性
- アーキテクチャが見えないという情報非対称性
という２つの情報非対称性がこそが、「技術的負債」を「技術的負債」と呼ばせている「隠れた原因」です。
情報の非対称性の解消は、本書の定義する「コミュニケーション」そのものです。「技術的負債」というキーワードをめぐるハレーションは、コミュニケーションミスの累積であり、組織的な構造の問題なのです。
見えてしまえば「技術的負債」ではない
技術的負債がコミュニケーション上の問題だと言われても、にわかには納得しづらいかもしれません。多くの場合それはテクニカルな問題だと思われているからです。
バグや機能追加をどう扱うかについて、プロダクトオーナーや経営者、ビジネス組織と大きな問題になることは少ないです。これは、バグや機能追加は彼らにも「見えている」ものだからです。
見えていて、管理できてしまえば、お互いに判断をつけることができます。単位が揃っていて、比べることができれば、議論が紛糾することはありません。優先順位の高いものから実行していけば良いからです。
ところが、「技術的負債の解消」に関するタスクは、メリットもなぜするかもいまいち見ることができないし、比べることもできません。そのため、議論は発散し、感情的なすれ違いを引き起こしてしまいます。
このことをもって、筆者は技術的負債とは「ブレーメンの音楽隊」の化け物のようなものだと考えています。「ブレーメンの音楽隊」はグリム童話の１つで、ロバ、にわとり、犬、猫が集まって、泥棒を家から追い出す話です。彼らは、泥棒を脅かす為に、４匹が重なり合って一つになった大きな影を泥棒に見せました。それが恐ろしい化け物に見えた泥棒は、家から逃げ出していきます。
もし、泥棒が窓を開けて、「それが４匹の動物が重なっただけ」だとわかったら、恐れることはありませんでした。しかし、それがなんであるかわからないので、恐ろしい化け物に見えてしまったのです。
この折り重なった化け物は、技術的負債という言葉そのものです。それがなんだかわからないので、恐ろしい。正体が見えて、１つ１つが明らかであれば、管理もできるし、恐ろしくもありません。１つ１つの問題を解決していくのは簡単なことだからです。
正体の見えてしまった「技術的負債」を構成するタスクは、一般に非機能要件と呼ばれます。これは、表面の機能には影響がないが、性能や拡張性、運用性といったことに関する要求によって生まれる要件です。
つまり、技術的負債は、「見えないからこそ」技術的負債と呼ばれるのです。その１つ１つが見えてしまえば、またそれが理解され、他の機能要件と同じように尊重されていれば、まだ満たされていない「非機能要件」のリストとして、管理可能なものになります。
このようにソフトウェアの見えない価値、見えない投資について、組織がコントロールできる状態にあるとき、そのソフトウェアには「技術的負債」と名付けられた問題は存在せず、漸進的で進化的なアーキテクチャ開発への1ステップだとみなされるようになります。
終わりに
本論は、拙著である「エンジニアリング組織論への招待」第5章の一部を抜粋・再編集・一部追記したものです。
今後の具体的なアプローチを知りたい方はこちらを：
あきらめるにはまだ早い！ソースコードの品質向上に効果的なアプローチ
更に踏み込んで「アーキテクチャ」とはなにかの理解を深めたい方はこちらを：
なぜ、組織のつくりとソフトウェアアーキテクチャは似てしまうのか
併せてご一読ください。