技術的負債についてもう一度整理する
休日だったのでちょっと長めです。
技術的負債は解消すべきか、許容すべきか
技術的負債は解消すべきか、許容すべきか。そもそも、みなさんは「技術的負債」についてあなたはどう捉えているでしょうか？
技術的負債はなるべく早く解消したい
技術的負債もある程度許容する
私が、この「技術的負債」というトピックで記事を書いているときに感じたのは、技術的負債をどのように捉え、どのように管理するかは、VPoEとCTO、つまり組織内の立場によって異なる見解となるだろう、ということです。
恐らくVPoEの視点では、技術的負債はチームの生産性を阻害し、将来的なリスクをもたらすため、できるだけ早く解消することが望ましいと考えるでしょう。一方で、CTOはビジネスの視野で技術的負債を評価し、リソースの割り当てや戦略的な優先順位に基づいて、ある程度の技術的負債を許容するのが正しいものと思います。
t-wadaさんは御本人のブログで言及している、
「負債」という言葉は、経営に近い人ほどポジティブな印象を持ち（資本のイメージ）、純粋な技術面に近い人ほどネガティブな印象を抱く（借金のイメージ）傾向があるように思われます。
この指摘と、まさに合致しているように思います。
技術的負債とはそもそも何だったのか
技術的負債の概念は、Ward Cunninghamによって提唱されました。彼が言及した「技術的負債」とは、短期的な解決策を選択し、将来的により良い設計に改善するために、そのコストを払うことを意味していました。
つまり、本来の技術的負債の意味合いは、「リリース後に実際に運用して分かったサービスと実装の乖離」であり、多くの人が認知している「リリース前に、期限を守るために仕方なく実装した雑な設計やコード」という意味ではありません。この理解は、技術的負債が単なるコードの問題ではなく、ソフトウェアとビジネスの関連性の中で考慮されるべき戦略的な要素であることを示しています。
技術的負債のメタファー
ここで取り上げる技術的負債についてもう少し掘り下げます。
元々の技術的負債は、私の見解では「負債」という表現は適切ではなく、これは「ソフトウェアの劣化」「老朽化」もしくは「時代遅れ」に相当するもののようだと考えます。（会計的に言えば、ソフトウェアの「減価償却」のようなイメージです。）
一方、昨今、一般的に使われる「技術的負債」の意味、つまり「自分たちが書いているコードの保守性の無さ」は会計的に言うと「修繕引当金」に相当すると考えられます。すなわち、適切な時期に適切に対処しない選択が、将来的に更にコストを発生する、ということを意味します。
「技術的負債を解消する」際に考えること
一般的なほうの「技術的負債＝自分たちが書いているコードの保守性の無さ」を考えたとき、この負債を解消するためにどれくらいの「負債の返済」をしなければいけないのでしょうか？
私はこれに対して下記のようにシンプルに考えています。
ある瞬間にて「ある工数で機能追加をした際に得られる価値」と「負債を解消しないと失われる価値」がそれぞれあったとき、これらをそのソフトウェアが提供するサービスの提供期間で積分し、どちらが大きいかで都度判断する。
ただ、この「ある瞬間」は幾度となく訪れ、その都度扱う機能や負債によって変わります。イメージとしては「新しくお金を借りたときに、それを新規機能に充てるか、既存サービスの改善に充てるか」に近いでしょう。即時の利益を追求することと、持続可能な発展のための投資をバランスよく行うことの間の綱引きなのです。
技術的負債と、メタファーとしての借金との違い
仮に「技術的負債」を「修繕引当金」ではなく「負債」として捉えて考えたとします。
このとき、技術的負債とは通常の負債ではなく、年々金利が上がる非常にたちの悪い負債だと言えます。後になればなるほど返済が困難になり、あるタイミングで破綻する。これはメタファーとしての借金とは異なるポイントでしょう。
サービスリリース後に技術的負債に対してアクションを怠っていると、新しい技術の取り込みや外部環境の変化によって「運用を行う」だけでも困難になります。さらに言えば、セキュリティ問題の発出などで一気に改修コストが上がると、コード改修コストが稼ぎを上回り、サービスを終了せざるを得なくなる、という可能性も孕みます。
技術的負債を解消するのではなく、コントロールする
しかし、技術的負債は経営と密接に関係することであり、単純に「今の実装が気持ち悪いから書き直したい」という現場の思いだけでは解消に繋げることができません。
ただ、技術的負債を完全にゼロにすることは現実的ではありませんが、無視しておくこともまたリスクとなります。そのバランスを見極め、組織の目標に応じて技術的負債を戦略的に管理することが重要です。
まとめ
結局のところ、技術的負債とはソフトウェア開発のある種の不変的な特性であり、常に発生するリスクでもあります。技術面から経営責任を負う人間（多くの場合はそれはCTOでしょう）は、この事実を受け入れ適切に対処しなければなりません。エンジニアリングとビジネスの両方の観点から、技術的負債を継続的に評価し、優先順位をつけ、計画的に対応する必要があります。そして、このプロセスを通じて初めて、技術的負債は、致命的な障害ではなく、成長と進化のためのステップとなり得るでしょう。