技術的負債はどれから直す？ 改修費用と今後の変更負担で判断する

営業は次の機能を待っている。開発は「このまま継ぎ足すと、もう直せなくなる」と言う。どちらも事業を止めたいわけではないのに、会議は新機能か品質かという対立になる。

問題は、品質に価値があるかどうかではない。いま予定している変更を進める前に、どこを直せば、今後繰り返す手間を減らせるのかである。コードが古いことと、直す費用を回収できることは同じではない。

本稿は、近い将来に何度も変更する箇所で、同じ追加作業を生む原因が分かっているなら、そこを先に直す。変更機会が乏しく、作り直す危険が大きい箇所は、監視や小さな修正にとどめると提案する。研究から一律の返済率や予算比率は導けない。選ぶ単位はシステム全体ではなく、具体的な変更と、その障害になる設計である。

「開発時間の23％」を、そのまま削減目標にしない

Beskerらの2019年の研究は、43人の開発者への継続的な調査と16件のインタビューなどを通じ、技術的負債による追加作業を調べた。報告された無駄な時間は平均23％で、追加のテストが代表的な活動だった。これは開発者の報告に基づく結果であり、自動計測した全産業の損失率ではない。著者所属大学による論文要旨

この数字は、負債が開発現場の時間を使わせるという論点を支える。一方、「自社も23％を取り戻せる」「返済すれば同じ割合で売上が増える」という見積もりには使えない。返済に必要な時間も、新機能を遅らせる費用も別にあるからだ。

先に記録したいのは、直近の変更で何を余分に行ったかである。似た処理を複数箇所で修正したのか、影響範囲が分からず広く試験したのか、仕様を知る一人の到着を待ったのか。単に「コードが汚い」では、次の投資先を比較できない。

また、通常必要な品質確認を丸ごと無駄と呼ばない。設計を整理しても残る試験と、重複した実装のためだけに増えた試験を分ける。後者を減らす案なら、何を変え、どの確認を省けるのかまで説明できるはずだ。

行数より、変更のたびに困る場所を探す

CMUのSoftware Engineering Instituteは、三つの大規模組織の1,831人への調査と7人への追加インタビューを報告している。長く使うソフトウェアに関わる実務家が中心で、設計や構造に関する判断も技術的負債の問題として扱われている。単に短いコードへ書き直せば解消する、という狭い捉え方では足りない。SEIの調査報告

この調査も、返済した群としなかった群を無作為に比べたものではない。日本企業に最適な改修量を示した研究ではなく、どのような困り方を候補に含めるかの材料になる。

例えば、値引き条件が受注画面、請求処理、帳票に別々に埋め込まれているとする。条件を変えるたび、三つが同じ結果になるか調べなければならない。ここで直す対象は、最も長いファイルとは限らない。条件の正本をどこに置き、どこから参照するかという境界である。

ただし、共通化すれば必ず安全になるわけでもない。別々だった処理をつなげれば、一つの修正が複数の業務へ及ぶ。重複をなくす便益と、変更の影響を共有する危険を一緒に扱う必要がある。小さく試せる範囲が見つからない場合は、まず現行の振る舞いを確かめる試験を用意する案が残る。

直した箇所の点数が上がっても、別の品質が下がることがある

KaurとSinghの2019年の整理は、2017年末までの142研究を対象に、オブジェクト指向コードのリファクタリングと品質の関係を調べた。改善の方向は一様ではなく、学術的な環境と産業での検証でも結果に違いがあった。研究者による公開論文

これは効果量を一つに統合して「平均何％改善する」と示す分析ではない。また、コードの構造整理と、システムを別製品へ作り直すことは同じ介入ではない。技術的負債の存在を認める証拠と、特定の返済案が得になる証拠を分ける必要がある。

料金計算を共通化するなら、重複修正の減少とともに、関係のない商品へ変更が波及しないかを確かめる。処理を短くした結果、障害の切り分けが難しくなるなら、その代償を返済費用へ戻す。一つの品質指標が良くなったことだけで、次の全面改修を承認しない。

同じ改修でも、あと何回触るかで優先順位が変わる

ここからは説明用の仮想例である。ある料金計算の整理に、試験と切替を含めて延べ40時間かかるとする。その後の料金変更では、従来必要だった照合を一回当たり8時間減らせると見積もった。

今後六回変更するなら、単純な作業時間では8時間×6回＝48時間の削減候補がある。40時間の改修を検討する理由はできる。ただし、この差だけで採用とはしない。回収するのは将来であり、最初の新機能が遅れる影響と、改修で生む不具合の可能性がまだ残る。

一方、次の一回を終えたら製品を廃止する予定なら、同じ計算で減らせる時間は8時間にとどまる。見積もりが正しく、安全上の別問題もなければ、全面整理より、今回の変更を限定して確認する案が優先しやすい。古さは同じでも、残る利用期間が判断を逆転させる。

さらに、六回の変更が本当に確定しているかを問う。営業上の構想をすべて改修予定に数えれば、返済の便益はいくらでも大きく見える。契約済みの変更、検討中の変更、まだ仮説の変更を分け、少なくとも確かな予定だけでも案を説明できるかを見る。

40時間の改修と変更ごとの8時間削減を比較する際は、試験・切替・障害対応も同じ範囲で数えます。研究の自己報告による23％を、そのまま整理すれば消える時間とは扱いません。同じ変更課題と版で、減らせる負担を確かめる必要があります。

返済を延期するなら、次に見直す条件を残す

「今回は返さない」は、技術的負債を認めないという意味ではない。新市場の反応を先に確かめたい段階で、長期利用を前提とした構造へ投資し過ぎることにも費用がある。返済しない判断には、利用期間と、当面受け入れる追加作業を添える。

例えば、次の料金変更でも同じ不一致が起きたら、共通化を再検討する。廃止予定が延期されたら、残る変更回数を見直す。追加開発が別部署に広がったら、影響範囲を再評価する。日付だけの先送りより、判断の前提が崩れる出来事を決めておく方がよい。

これは編集上の運用提案である。SEIが紹介するデータに基づく管理も、変更履歴や不具合、構造などの複数情報から候補を絞る方向を取る。特定の分析ツールの点数が、そのまま事業の優先順位になるわけではない。SEIの管理手法の説明

また、既に悪用され得る脆弱性や、維持できない必須機能を、時短の回収だけで延期しない。本稿の比較は主に保守・変更を難しくする設計上の負担を対象にしている。安全性や事業継続の必要条件が満たせない場合は、その制約を先に扱い、任意の新機能と同列の点数に押し込めない。

経営が買うのは、きれいなコードではなく変更できる余地

投資案には、対象の設計、妨げられている次の変更、繰り返している作業、直す範囲、切替の危険を一組で示す。開発側にすべてを金額へ換算させる必要はないが、何をできるようにする支出なのかは共有したい。

実施後は、書き換えた行数より、次の同種変更にかかった照合や修正を追う。難易度や担当者が違う案件の前後差を、そのまま改修の効果としない。想定した追加作業が残ったなら、別の依存関係が原因だった可能性を調べる。

回収できなかったとしても、直ちに「負債返済は無駄」とはならない。事業計画が変わって変更自体がなくなったのか、見積もった原因を除けなかったのかでは、次の判断が違う。前者なら投資する範囲と時期を、後者なら原因の確かめ方を直す。

次の変更で繰り返す障害を取り除けるなら、返済を機能開発の一部として先に組み込む。長く使わない箇所や便益を説明できない全面整理は縮める。 技術的負債をゼロにすることより、今後必要な変更を、見通せる費用と危険の範囲で続けられる状態を選びたい。