💭

技術負債と向き合う

2025/02/04に公開

はじめに

直近の業務で割と技術負債を扱うことが多く、昔から継続して提供しているサービスがいよいよ技術負債と向き合わないと開発運用がどうしようも無くなってきたとき、どう進めていくか。何度か向き合って、その都度実行せず時間が経過するという経験を多くの方が持っているのではないかと思う。
技術負債対応について、どのように進めていくのが良いか、自身の考えを整理する。

前提条件

多くの場合、サービスを提供している既存顧客に対して、「これまで通りの仕様でサービスを使い続けることができる」ことが前提となる。提供しているAPIに大幅な変更が加えられることになれば、顧客側システムに実装・改修を強いることになり、サービス解約のリスクを伴うことになるので、これまで通りの仕様で提供継続することが必須となる。顧客に提供しているインタフェースは変更することなく、技術負債の解消に向き合うことが必要となる。

基本方針決め

対象システムの更改に対する大方針を決める。特に「パッケージを採用するか、自社開発で作りこむかどうか」は重要なポイントになる。パッケージを採用した場合は、その機能を最大限活用して、改修部分を最小にし、運用を合わせていくアプローチとなる。

  • 「改修範囲を少なくする・既存運用の変更を許容する」のであれば、パッケージを採用し、運用を合わせる形にする。
  • 「改修範囲が広がることをある程度許容する・既存運用の変更を許容しない」のであれば、スクラッチで開発とする。
    で大きな方針決めが必要となる。

改修の実現性検討

前提条件で記載したとおり、提供しているAPIエンドポイントを変更すると顧客影響が出るため、エンドポイントを変更せずに技術負債を改修するユースケースが多くなる。まずは、システム間インタフェースをすべて洗い出し、整理する。例えばシステム間連携がSQL連携(クエリ発行)である場合は、クエリ修正の工数を算出し、インタフェース数 × 対象クエリ数でざっくり工数を算出する。またモノリスからマイクロでクラウドに移管を検討する場合などは、マイクロ分離するインタフェースも追加しておく。他のインタフェースも同様に、ざっくり工数を算出する。

このざっくり工数が必要最低減かかる工数である。見積ってみると開発規模の大きさがわかる。得てして想定よりも膨大な工数がかかることが多い。工数見合いのコストが許容できないのであれば、現行システムをEOL対応等で維持、もしくは部分的改修が現実解となる。

大抵は現実解をとることになる。理想論を語ろうが、それを実現するための工数と体力とコストがないと技術的負債は解消できないのである。

Discussion