BTABoK Technical Debt ～アーキテクトは技術的負債とどう向き合うべきか～

川森脩平
2 日前
読了時間: 7分

はじめに

今回のコラムでは、BTABoKにおけるバリューモデルの一つであるTechnical Debtについて取り上げます。Technical Debt（技術的負債）という言葉は日本企業でも広く聞かれるようになりました。しかし、現場での使われ方を見ていると「未完了の作業」「気になるコード」「バグ」「古いシステム」など実に幅広いものがすべて技術的負債と呼ばれています。

本来の意味が曖昧なまま使われることで、かえって問題が見えづらくなる場面も多いのではないでしょうか。本稿では、BTABoKの整理を土台にアーキテクトとして技術的負債をどう捉え、どう扱うべきかを考えてみます。

技術的負債とは

もとはWard Cunninghamが示した比喩で、短期的に価値提供を優先するために、あえて最適でない設計を選ぶことを負債に例えたのが始まりです。本質は次の一点にあります。

短期的には便利だが、将来の変更を高価に、あるいはほぼ不可能にする構造的な選択であること。

コードをリファクタリングしてすぐに返済する限り、負債を一時的に抱えること自体は問題ありませんし、有益でさえあります。ところが実務の現場では、この「返済する」という後段が無視されがちです。返済前提の負債が、返済されないまま放置されていくことで、

変更がどんどん高価になる
機能追加が遅くなる
品質が不安定になる

といった問題が積み上がり、技術的負債が組織にのしかかっていきます。

技術的負債と誤解されがちなもの

便利な言葉であるがゆえに、完璧でないものを技術的負債と呼ぶ傾向があり、本来負債と呼ぶべきでないものまで含まれがちです。以下の項目は一般的に技術的負債とは見なされません。

未完了のユーザーストーリー

単にやり残しであって技術的負債ではありません。

バグ（欠陥）

すでに顧客価値を損なっている問題であり、負債ではなく今すぐ対処すべき品質問題です。

プロセスの欠如

プロセスの欠如自体は技術的負債ではありません。

ただし、プロセスの欠如、間違ったプロセス、またはプロセスに従わないことは結果として不必要な技術的負債を生み出す可能性があります。

未実装の機能

まだ実装されていない新機能は技術的負債ではありません。

ただし、初期要件が不十分なままギャップを埋めるための暫定対処を行うと、その近道が結果として技術的負債を生む可能性があります。

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

技術的負債は、必ずしも軽率な判断や不注意だけで生まれるわけではありません。多くの場合、ビジネスの現実に起因しています。

まず、ビジネスモデルが大きく変化し、急いで対応しなければ市場で生き残れない場面では、最適とは言えない技術選択を取らざるを得ないことがあります。

競合が激しく、顧客から新機能を求められるプレッシャーが強い場合も同様で、短期的な価値提供が優先され、結果として負債が積み上がります。

また、意外と見落とされがちな原因に「リライトやリプラットフォーム」があります。

新しいプラットフォームは新規顧客にフォーカスしますが、既存顧客は旧システムで長期間サポートする必要があります。この期間、IT部門は旧と新の両方に機能追加や保守を行う二重負荷を抱えるため、負債がむしろ増えてしまうことがあります。

さらに、M&Aも技術的負債の大きな要因です。

買収先の製品に内包された負債を意図せずそのまま引き継ぐことがあるためです。特にスタートアップ製品はスピード重視で作られるため、負債を内包していることが多く、それが後から顕在化します。

このように、技術的負債は単なる設計ミスではなく、

ビジネス環境・納期圧力・刷新プロジェクト・M&Aといった「ビジネスの現実」から自然に発生するものなのです。

技術的負債の種類ごとの向き合い方

技術的負債は放置しても自然には減りません。

しかし現実には、技術的負債を計画的に管理できていない組織も少なくありません。

加えて、技術的負債には種類があり、組織のどのレイヤで扱うべきかも異なります。

短期メリットと長期コストのトレードオフ（チームレベル） 短期の価値を優先するために、本来あるべき設計や実装を後回しにした暫定的な作りが発生するケースです。こうした負債は、記録・優先付け・リファクタリングによって、チームレベルで十分対応できます。
雪だるま式の負債（プロダクト／プログラムレベル）
技術的負債が積み重なり、製品全体の保守や拡張が難しくなる状態です。
この段階では、個別チームではなく、プロダクト／プログラム単位での改善施策や投資が必要になります。
時間とともに陳腐化する負債（事業部レベル）
システムや製品が古くなり、得られるビジネス価値に見合う投資が難しくなる段階です。
この状態では、事業部レベルで投資を見直し、場合によってはシステムを廃止する判断が求められます。
レガシー負債（事業部〜会社レベル）
使われている技術やアーキテクチャが古く、サポートが難しくなっている一方で、そのシステムが提供する機能は依然として事業にとって不可欠な状態です。
このような負債には、慎重な移行計画や投資判断が求められ、事業部〜会社レベルでの意思決定が必要になります。安易なリプラットフォームは新たな複雑性を生むため、注意が必要です。
コードの肥大化（チーム＋全社IT原則）
コードが無秩序に膨らんで複雑化していくタイプの負債です。
チームでの自律的な管理に加え、全社的なIT原則による統制が必要になります。

技術的負債への対応は、プロダクトの成熟度や組織の意思決定構造によっても変わります。

種類に応じて、どのレイヤで扱うべきかを見極めることがコントロールの第一歩です。

技術的負債は「可視化とガバナンス」がなければコントロールできない

金融負債と同じように、技術的負債も見える化しなければ適切に扱えません。

どれだけ負債があるのか
時間とともに増えているのか減っているのか
どの負債がどのビジネス価値やリスクに紐づくのか

これを判断するために、SonarQubeやSQALEなどで負債を定量化するアプローチがあります。

しかし、計測だけでは技術的負債をコントロールすることはできません。

大切なのは、技術的負債をどう扱うかについて組織としての期待を明確にし、その基盤を整えておくことです。

例えば、

完了の定義（DoD）
コーディング標準
アーキテクチャの原則
技術的負債に関わる重要な判断を記録する仕組み（ADR：Architecture Decision Recordなど）

といった環境を整えることで、不要な負債の発生を抑え、必要な負債だけを戦略的に負うことができます。

アーキテクトは「技術的負債というローン」を設計する役割を担う

BTABoKでは、Technical Loan Request Cardというキャンバスが提示されています。これは、意図的に大きな技術的負債を負う決定を行う際に、ビジネス価値・影響範囲・返済コスト・返済計画をセットで記録するためのものです。

「なぜ今この負債を許容するのか」「いつ・どのように返すのか」を最初からワンセットで設計するイメージです。

アーキテクトはプロダクトオーナーやビジネス側と対話しながら「どの負債は戦略的に許容し、どの負債は即時返済するか」を設計する役割を担う存在とも言えます。

負債をゼロにすることが目的ではなく「ビジネス価値と将来コストのバランスが取れたポートフォリオ」にしていくことが狙いです。

技術的負債は複雑なテーマですが、その本質は「将来の変更性を損なう構造的な選択」にあります。

負債には種類があり、対処すべき組織のレイヤも異なります。そして何より、負債は返済計画がなければ雪だるま式に増えていきます。アーキテクトの役割は、この負債を見える化し、ビジネスと技術の両面から最適な判断を下すことです。技術的負債という概念を正しく使いこなすことが、ビジネス価値、将来のコスト、そして組織全体の持続的な変化能力のバランスを取るうえでの鍵となります。

ご一読いただきありがとうございました。

Iasa日本支部では情報交換や勉強会の場を設けており、システムの視覚化についても研鑽を深めていますので、今後のIasa日本支部の活動へのご参加、ご協力をよろしくお願いいたします。