技術的負債（Technical Debt）

技術的負債（Technical Debt）とは、ソフトウェアの開発で、その場しのぎの作り方や後回しにした手入れが積み重なり、将来の修正や機能追加に余計な手間がかかるようになった状態のことです。急いで作るために借りた時間を、後から利子を付けて返さなければならない、という意味でお金の借金にたとえられています。

現実世界に例えると、技術的負債は片付けを後回しにして物を押し込み続けた物置のようなものです。そのときは早く済んでも、いざ何かを取り出そうとすると、ほかの物をどけるのに大きな手間がかかり、押し込むほどその手間は増えていきます。

技術的負債 図解

※画像をクリックすると拡大表示します。

言葉の由来

考え方の出どころです。この言葉は、1992年に米国のプログラマー、ウォード・カニンガム氏が、開発の判断を経営側に説明するために、借金のたとえとして使ったのが始まりとされています。早く出荷するために手を抜くことは、借金をして先に物を買うのと同じで、返済を先延ばしにすると利子がふくらむ、という説明です。

利子が増えていく仕組み

負債がやっかいな理由です。分かりにくいコードや、重複した処理、テストのない部分があると、その周辺を直すたびに余計な確認や調査が必要になります。この余計な手間が「利子」にあたります。放っておくと、その上にさらに継ぎはぎが重なり、利子が利子を生むように、開発の速さがどんどん落ちていきます。

負債の4つの分類

種類の整理です。技術的負債は、意図して借りたものか、知らないうちに生まれたものか、また、考えたうえでの判断か、無謀な判断か、という2つの軸で4つに分けて考えることができます。

すべてが悪いわけではない

誤解されやすい点です。市場に早く出すために、あえて簡略な作りで始め、後で直すという判断は、借金をして事業を伸ばすのと同じく、合理的な選択になりえます。問題なのは、借りたことを忘れて返さないことです。どこにどんな負債があるのかを記録し、返す計画を立てておくことが大切です。

たまっているサイン

気づくための目安です。小さな変更なのに時間がかかる、直すたびに別の場所が壊れる、特定の人しか触れない部分がある、新しく加わった人がなかなか理解できない、といった状態は、負債がたまっているサインです。開発の速さが少しずつ落ちていると感じたら、原因を探ってみる価値があります。

返済のしかた

減らすための取り組みです。代表的な方法は、動きを変えずに内部を整理するリファクタリングと、変更を安全に行うための自動テストの整備です。一度に全部を返そうとするより、機能を追加するついでに周辺を整える、開発の時間の一定の割合を返済にあてると決める、といった形で、少しずつ返し続けるのが現実的です。

経営の課題でもある

組織にとっての意味です。技術的負債は、開発の現場だけの問題ではなく、新しいサービスを出す速さや、システムの保守費用に直結する経営の課題です。古いシステムが足かせになって変革が進まないという問題は、日本でも国が報告書で警鐘を鳴らしました。返済の時間を確保するには、経営層の理解が欠かせません。

負債を増やさない工夫

予防の考え方です。コードレビューで分かりにくい作りを早めに指摘する、設計の判断や後回しにしたことを記録しておく、急ぎで作った部分には期限を決めて見直す、といった習慣が、負債の膨張を防ぎます。完全になくすことはできなくても、把握して管理できている状態を保つことが目標です。

あわせて知っておきたい用語

• リファクタリング：
  動きを変えずに、プログラムの内部構造を整理することです。
• レガシーシステム：
  古い技術で作られ、維持や改修が難しくなったシステムです。
• 単体テスト：
  プログラムを小さな部品ごとに動かして確かめるテストです。
• レビュー：
  成果物を本人以外の目で確かめ、問題を見つける作業です。