前回（といってもかなり時間が経ってしまいましたが）は「負債」というテーマのうち、

  • 負債一般的な話
  • 企業が借り入れをする事

について書きました。

負債-その1

前回の記事が結構長くなってしまったので、「技術的負債」に関しては今回別記事として投稿する事にしました。

なお、当社では本ブログ以外に技術ブログもあり、内容的にはそちらに投稿しようかとも考えたのですが、後述の理由により本ブログに書く事としました。

技術的負債とは

ソフトウェア開発者であればこの言葉を聞いた事が無い人は少ないかと思いますが、開発者以外の人もいると思いますので、ほかのサイトから説明を引用します。

技術的負債とは、ソフトウェア開発プロジェクトにおいて、急いで実装したり、修正せずに放置したりすることで、将来的に修正や改善が必要になる技術的な問題のことを指します。つまり、開発者が一時的に早急な対応を選んだことで、将来的に支払わなければならない「負債」ということです。

技術的負債とは？技術的負債に対処するための6つの方法

この説明で大体分かるかと思いますが少し補足します。

以下の2つの選択肢を考えます。

  • あまり良くない設計・実装だが、比較的短時間で済む
    • ただし、時間が経つにつれて問題となり得る
  • 本来あるべき形の設計・実装だが、比較的時間がかかる

ここで前者の選択をする事により、今この時点での時間を節約することが出来る代わりに、将来的には問題となり得ます。その将来的に問題となるかもしれない設計・実装の事を技術的負債と呼びます。

時間が経つにつれてその問題の修正に要する時間が増えていく事が多く、お金を借りると時間が経つにつれて利子分だけ返済額が増えていくという点で、本物の「負債」と似ています。

「問題となり得る」の「なり得る」を太字にしたのには意味があり、問題とならない場合もあるからなのですが、それについては後述します。

技術的負債は「悪」なのか

技術的負債は常に避けるべき悪いものなのでしょうか。そのあたりのキーワードで検索したところ、なかなか良いページを見つけたので、そこから引用します。

しかし近年では、「技術的負債は本質的に悪いものではない」という見解が一般的です。

【事例5選】「技術的負債」は「悪」なのか？ その定義や歴史、各社の向き合い方を徹底解説 | SELECK [セレッ

技術的負債とは、今現在の時間を節約する代わりに、後から節約した時間よりも長い時間をかけて直す（かもしれない）事を選択する事で生じます。

技術的負債が合理的となるためには、今現在の1時間（or 1日、1ヶ月）の方が将来の1時間（or 1日、1ヶ月）よりも価値が高い、という前提を満たす必要があります。例えば、以下のような場合です。

  • 競合よりも早く製品を出す事で、後から大きな利益となる
    • → そのお金で、後で本来あるべき姿に修正した方が良い
  • リリース期日に間に合わないと、今後の契約を切られる、あるいは損害賠償のリスクがある
    • → 現時点での大きな損害を避けるために、良くない設計・実装を受け入れた方が良い

以上から分かるとおり、技術的負債は通常の負債と同様、うまく付き合う事で事業の成長・継続に有益なものです。

技術的負債は返す必要があるのか

必ずしも返済の必要は無い

技術的負債はうまく使えば有益な事は分かったかと思いますが、その負債はいつ返せば良いのでしょうか。というか、そもそも返す必要があるのでしょうか。

技術系のサイトでは、技術的負債は返済する事が前提でどのように返すのか、という切り口の内容が大半ですが、私としては「必ずしも技術的負債を返す必要は無い」と考えています。本記事を技術ブログでは無くてこちらの会社ブログの方に書く事にした理由はこれです。

前回の記事で、企業の負債は完済を目指さない場合も多いと書きましたが、技術的負債に関しても同様だと思います。

技術的負債を返さなくて良い場合

どのような時に技術的負債を返す必要が無いのか、主要な場面としては以下だと思います。

  1. 長く使われる事が無い、使われる期間が決まっている、など
  2. 修正される事が無い

1番ですが、極端な話、一度だけしか使われないソフトウェアであれば技術的負債の返済は考える必要はありません。というより、この場合はそもそも技術的負債と呼んで良いのかも怪しいところです。また、一度だけでは無いにせよ短い期間しか使われないソフトウェア・機能、例えば期間限定のキャンペーン機能などでも、技術的負債については考える必要は無いと思います。

次に2番ですが、使われる期間は長期であったとしても修正される事が無い・修正される可能性が低いものも、技術的負債やその返済について考える必要はありません。なぜでしょうか。

上の方で、技術的負債は「時間が経つにつれてその問題の修正に要する時間が増えていく事が多く」と書きました。ある機能を時間優先であまり良くない形で実装した場合に、その機能に対する仕様変更を行おうとすると、それに必要な時間が時とともに増えていき問題になるという事です。逆に言うと、その機能を修正しない限りは問題が発生ないため、技術的負債を返す必要がありません。

技術的負債を返済する場合

いつ返済するのか

とはいえ、前項のように技術的負債を全く返す必要が無い場合というのは限定的で、通常はいつか返済する必要があるのですが、ではいつ返済するのが良いのでしょうか。

これは、どのような理由で技術的負債が発生したかにもよるかもしれません。

リリースやデモ等のマイルストーンに間に合わせるため、といった時間的制約が原因の技術的負債であれば、その期限を達成した後から返済を始めるのが良いと思います。1つのマイルストーンを達成した次のマイルストーンも期限が厳しいなど恒常的にスケジュールが逼迫しているのであれば、それは技術的負債云々よりもっと大きな問題を抱えているはずなので、そちらをまずは解決する必要があると思います。

時間の経過と共に、使っているライブラリーのバージョンが古くなってきてサポート期限が切れそう、今使っているサービスが廃止される、より便利なサービスが出てきて今使っているサービスが時代遅れになってきている（そのうち廃止されるかも）、といったタイプの技術的負債であれば、期限があればその期限より前に徐々に、で良いと思います。

要件や外部環境の変化などによって、今まで問題なかった設計が負債となる場合もあります。こうした負債の場合は、一般的には長い間放置するのが難しいため、優先して返済する必要があります。特に、修正の影響が大きいものを放置しておくとさらに返済コストが高くなるため、最優先で対応すべきでしょう。また、ビジネス的な影響が大きい部分も最優先で対応すべきです。

どう返済するのか

これは通常の借金・負債と似たような感じかと思います。通常の借金は金利が高いものから返済しますが、技術的負債も（前項である程度説明したような）優先順位に従って返済します。なお、優先順位は状況によって変動が生じるため、チケット管理システムなどで管理しておく必要があります。

また、新規機能の開発などで全ての時間が取られてしまい技術的負債の返済に時間がとれないという事例もよく見かけます。もちろん、ビジネス的な要請によって一時的にそのような状態になるのは仕方ないと思いますが、初期バージョンのリリース後などは、開発リソース・時間の一定割合を負債返済に割り当てて、スケジュールもそれを前提に組んでおくと良いと思います。

ちなみに、ビジネス側にその辺りに理解を示さない人もたまにいますが、そういう場合の対処の仕方などは検索すると色々情報が出てくると思います。

まとめ

本記事では技術的負債について説明しました。技術者界隈の記事では完済を前提としたものが多いですが、通常の負債と同様に技術的負債も完済を目指す必要は無いと言うのが私の立場です。また、技術的負債にも色々な種類があるため、返済が必要な場合も、状況に応じて優先順位をつけて返済していくのが良いと思います。