ソフトウェアは、その成長とともに複雑性が増していきます。機能追加や変更が繰り返される過程で、自ずと技術的負債が積み重なっていくのは、避けられないものといえます。

私が関わっているソフトウェアにおいても例外ではありません。技術的負債に目からそらさず向き合い、解消していきたいと考えています。解消への取り組みにあたり、「技術的負債」というものとの向き合い方について、改めて自分なりに整理しておきたいと思います。

技術的負債を形作る複数の要因

これまで私は、この言葉の「技術的」という部分に引っ張られ、技術的負債を考える際にコードの品質や個人の設計判断といった側面に注目しがちでした。技術的負債を生む要因を、あくまで個人のスキルや判断の問題として捉えていました。

しかし、技術的負債について掘り下げていくと、それが単純な技術的問題ではなく、複数の要因が複雑に絡み合った結果であるという側面が見えてきます。代表的な要因として組織的要因やビジネス要因が挙げられると思います。

組織要因

技術的な意思決定は、決して独立して行われるものではありません。エンジニアは、組織から与えられた役割、KPI、予算、期限といった制約の中で決定を下しています。個人の判断に見える事象も、実はその組織構造やルールの中では、そう判断せざるを得なかったという構造上の帰結であることが少なくありません。個人の努力以上に、組織というシステムの持つ制約が、技術的負債を発生させる要因となることもあります。

ビジネス要因

また、技術的「負債」という言葉が示す通り、ビジネス上の価値と技術的品質とのトレードオフの結果として生まれる側面もあります。例えば、リリース速度を優先してあえて負債を背負い、市場での優位性を獲得するようなケースです。ビジネス上の戦略的な選択の積み重ねが、結果として技術的負債を形成していきます。

技術以外の領域に目を向ける

これらはあくまで例ですが、重要なのはコード上で見えているものはあくまで結果として表面化したものであって、本当の課題はその背後の要因にあるということです。コードを修正し、技術的負債を解消したつもりでも、根本的な要因を取り除かない限り、技術的負債は形を変えて再び現れます。

そのため、エンジニアは技術の範疇に留まらず、組織構造やプロダクト、ドメインなどに目を向け、理解を深めていくことが重要だと思います。そして、本質的な課題と向き合い続ける必要があります。

自分にできることを続ける

技術的負債の構造を捉えられたとしても、それだけで課題が一気に解決へ向かうわけではありません。背景にある要因は複雑で根深く、すぐに取り除けるほど単純ではないからです。

だからこそ、自分が今できる範囲で地道な改善を継続していくことが重要だと感じています。今日触れるコードを昨日より少しだけ良くしていく。時には周囲と協業しながら少しずつ品質を高めていく。こうしたボーイスカウトの法則にも通ずるような、現場での誠実な積み重ねを大切にしていきたいです。

こうした歩みの中で、できることを広げていき、大きな構造的な課題の解決にも取り組んでいきたいです。日々の改善の中でプロダクトをより良い状態へと導いていけるよう力を高めていきたいです。

技術的負債は悩みの種となりますが、それはサービスを今日まで支え、成長させてきた歴史でもあります。当時の状況で下された決定への敬意を忘れず、現在の最適解に向けてこれからも取り組み続けます。

参考資料

【翻訳】技術的負債という概念の生みの親 Ward Cunningham 自身による説明
 『Taming Your Dragon: Addressing Your Technical Debt』
『チームトポロジー』
『Tidy First? ― 個人で実践する経験主義的ソフトウェア設計』