技術的負債(Technical debt)とは何か?プロジェクト失敗に至る原因を解説

2020年1月5日

技術的負債の概要

技術的負債とは、ソフトウェアやアプリケーションを開発する上で先送りにされた修正作業を指す俗語です [1]和田 卓人(監修)、Kevlin Henney(編集)、夏目 大 (訳)『プログラマが知るべき97のこと』オライリージャパン、2010年、2頁及び TechnicalDebtQuadrant
例えばスパゲティコードと呼ばれる、長年整理されずに設計が複雑化してしまったコードは技術的負債の具体例と言えるかもしれません。

技術的負債の種類

技術的負債は大別して 「故意の技術的負債」「無謀な技術的負債」 、そして「不注意から発生する技術的負債」に分けられます[2]TechnicalDebtQuadrant
これら3つの技術的負債の内容を見ていきましょう。

故意の技術的負債

故意の技術的負債は、スケジュールなどの問題から、よくないこととはわかっていても修正を先送りにしたり、とりあえずは動くことを目標に質のよくないコードで対応したりしている状態を指しています。

無謀な技術的負債

無謀な技術的負債とは、故意の技術的負債と似ていて、よくないこととは知りつつも、時間がないことから「迅速かつ汚い」コードで開発を終えようとするものです。
無謀な技術的負債がたまってしまうと、製品はできるかもしれませんが、保守作業が難しくなってしまい、その負債を何年もかけて返済していくことになります。

不注意から発生する技術的負債

不注意から発生する技術的負債は、単に問題への無知からくる負債です。
「この機能の仕様はこんな感じだった気がする……」「時々画面が表示されないことがあるけどたまたまかな」
このような不注意から修正作業が累積し、あとから取り返しが付かないような状態になってしまいます。

技術的負債はなぜ発生するのか

問題の先送りから発生する技術的負債

技術的負債のイメージ図

技術的負債は不注意から発生する技術的負債以外は修正作業を先送りにすることで発生します。
例えばAというソフトウェアを開発するのに、a、b、cの3つの工程が必要であるとします。
工程aが完了した際に修正作業が必要であるとわかりましたが、スケジュールの都合で修正作業を先送りにしたり、質のよくないコードで間に合わせるようにしたりしました。
次の工程bが終わり、ここでも修正作業が必要だとわかりましたが、そもそも工程aの修正作業も終わっておらず、どこから手を付けてよいかわからないような状態になってきます。さらに工程cが終わりを迎えるころには、工程aと工程bの修正作業が残っているような状態になってしまいます。
このように先送りにされた技術的負債がたまり、結局は修正が不可能になってしまいます。

技術的負債は短期的な利益につながる

技術的負債は借金と同じだといわれることがあります。
つまり、短期的には利益になりますが、その負債を完済するまで利息を支払わなくてはなりません[3]和田 卓人(監修)、Kevlin Henney(編集)、夏目 大 (訳)『プログラマが知るべき97のこと』オライリージャパン、2010年、2頁。
なぜなら、本当は対応しなければならないタスクを後回しにしたり、質の低い仕事をしたりしているのですから、短期的には開発プロジェクトの負担は減り、 利益は増えるものの、製品をリリースした後に根本的な問題を修正するまでは、修正作業に追われることになります。
この「短期的な利益になる」というのが技術的負債の誘因になってしまい、目の前のITプロジェクトの完成を急ぐあまり、大量の技術的負債を抱えてしまうというのは少なくありません。

技術的負債の実害

技術的負債の実害は様々ありますが、例えば以下のようなものがあります。

  • 修正作業の難化
  • 改修作業のスケジュールの不透明化
  • 改修の見積りの精度の低下

修正作業の難化

技術的負債の実害として最も大きいのは修正作業の難化です。
修正作業を行おうとしてもプログラムの構造が複雑化しており、どこを修正したらいいのかわからなくなったり、修正できたと思ったら思わぬところからエラーがでてしまったりします。
このように技術的負債の蓄積により、修正作業が難化してしまうことになります。

改修作業のスケジュールの不透明化

技術的負債が蓄積されたITシステムは、それを改修しようとしてもスケジュールの見通しがたたなくなります。
こうして改修作業のスケジュールが不透明になることも、技術的負債の実害の一つです。
この実害が最も大きくなるのは、新しく加わったプロデューサーやプロジェクト・マネジャーが改修案件のスケジュールを作成する時です。
新しいプロデューサーやプロジェクト・マネジャーは改修しようとしているITシステムの技術的負債の状況を深く理解していないため、「一般的にこのくらいの改修だったらこのくらいでできるだろう」とスケジュールを立てようとします。
これを開発メンバーに相談すればよいのですが、何も相談せずにクライアントに提出してしまった場合は最悪です。
技術的負債によって10日かかる作業をプロデューサーやプロジェクト・マネジャーが「5日でできる」とクライアントに言ってしまえば、開発メンバーはこれにあわせて徹夜で作業をしないといけなくなるかもしれません。

改修の見積りの精度の低下

設計が複雑になり、改修作業のスケジュールも正確に見積もれない状況であれば、その改修作業の見積りの精度も低下してしまいます。
先ほどのスケジュールの例のように、「一般的に5日かかる作業だけど、技術的負債があるから10日かかりそう」という状況であれば、10日分の作業で見積りを出さざるを得ないのですが、この10日というのも本当なのかどうかわかりません。
その結果、見積りの振れ幅が大きくなってしまいますが、クライアントとしてはできるだけ低い金額で作業をしてほしいところです。
クライアントの要望によって、プロデューサーやプロジェクト・マネジャーが希望的観測の見積りを出してしまうと、赤字の案件になることが多くなってしまいます

参考

1和田 卓人(監修)、Kevlin Henney(編集)、夏目 大 (訳)『プログラマが知るべき97のこと』オライリージャパン、2010年、2頁及び TechnicalDebtQuadrant
2TechnicalDebtQuadrant
3和田 卓人(監修)、Kevlin Henney(編集)、夏目 大 (訳)『プログラマが知るべき97のこと』オライリージャパン、2010年、2頁。