「技術的負債」は「成長痛」かもしれない。アーキテクチャーカンファレンス2025から学んだ、未来へ進むためのリアーキテクトへの向き合い方

こんにちは！
ディップ株式会社でSRE・インフラエンジニアを担当している藤井です。

今年のアドベントカレンダーは、ポエムでいきます！

私は、AWS と Google Cloud のマルチクラウド・インフラエンジニアとして、自社サービスの設計から運用までを担当しています。前職はSIerのアプリケーションエンジニアとして、SI案件の設計・開発をしておりました。

今担当している自社プロダクトの技術的負債を解決するヒントを得るため、2025年11月に開催されたアーキテクチャーカンファレンス2025へ参加してきました。

アーキテクチャーカンファレンス2025は初めての参加でしたが、目的としていたプロダクトの改善事例も聞くことが出来て、非常に有意義なカンファレンスでした。
今回はカンファレンスに参加して得られた気づきと、私個人が思っている「技術的負債」についての考えをまとめてみました。

この記事では、一般的な「技術的負債」の範囲をもう少し広げて話そうと思います。

• インフラの視点も追加
  • アプリの視点で語られることが多いですが、インフラでも負債は発生するので、その視点も追加してみます。
• 小さな負債の視点も追加
  • 大きな技術的な負債だけでなく、日々の活動で発生する小さな負債にも目を向けてみます。

「技術的負債」は、プロダクトの「成長痛」である

まずは、「技術的負債」の定義をおさらいしてみよう

Wikipediaから引用させてもらおうと思ったのですが、説明が長くなりそうなのでGeminiさんにまとめてもらいました。

技術的負債とは、短期的なリリース速度を優先した結果として生じる「将来の修正作業」を金融の借金に例えた概念であり、SaaS開発において戦略的な利用は許容されるものの、放置すると「利子」にあたる開発効率の低下が膨らみ、新規開発が困難になるリスクを指します。

つまり、技術的負債の課題を解決するためには、アーキテクチャを見直す、いわゆる「リアーキテクト」が必要になるということですね。

技術的負債は、立ち上げ時期だけに発生するものではなく、その後にも発生する可能性があると思います。

• 採用している言語やフレームワークのシェアが低下してきた
  • メンテの頻度が下がり、今後も使用し続けることに不安が出てきた。
• より優れた新しい技術やクラウドサービスが誕生し、時代遅れになった
  • 今より運用が楽になり、コストが安くなるので、乗り換えたい。
• 新しい視点のビジネス要件が発生し、対応するのが困難になった
  • 例えば別プロダクトと連携させようとしたら、仕様にズレがあり連携の効果が出にくい。
• 設計したエンジニアがいなくなって、ブラックボックスになってしまった
  • 今の仕様はコードから理解はできるが、なぜこの仕様を選択したのかの経緯や理由がわからない。

技術的負債がもたらす問題はなんだろうか？

発生する可能性がある問題を2つの視点であげてみます。

プロダクトへの影響

• 開発スピードが低下する
  • 小さな変更・修正なのに、影響調査とテストに時間が必要になってしまう。
• 品質が低下し、プロダクトの競争力が低下する
  • 予期せぬバグや障害が頻発するようになる。ユーザーからの信頼性が低下し、解約につながってしまう。
• インフラのコストや運用コストが増大する
  • （特にテナントの分離モデルがサイロモデルの場合）ユーザーの増加と比例してコストが増加し、スケールメリットが出ない。また管理対象のリソース数が増えるので、バージョンアップや障害対応等の運用作業も増えてしまう。

プロダクトチームへの影響

• エンジニアが疲弊する
  • バグ修正やコード解析調査が多くなり、モチベーションが低下する。
• オンボーディング・コストが増大する
  • 新しく入ったメンバーが、システムを理解し戦力になるまでの時間が長くなる。

ところで「技術的負債」という表現はどうなのだろうか？

エンジニアではない人からすると「負債」という言葉はネガティブで、誤解を招きやすい表現だと感じています。
「負債」＝「借金」のようなイメージがあり、「最初からわかっているなら、最初から負債を作らないでほしい」と思うのではないでしょうか？

多くの人が語っているように、プロダクトの最初の立ち上げ時期にはスピードに重点が置かれます。
スピードを高めるために、「きれいな設計」はある程度妥協せざるを得ないことになります。

しかし、プロダクトが多くのお客様に使われだすと、新しい機能の追加開発や運用・コストにひずみが出てきます。
個人的には「技術的負債」とは、プロダクトの 「成長痛」 なのではないかと思います。

技術的負債を解決するのはどうしたらよいのか？

「アーキテクチャーカンファレンス2025」でも、事例や手法について取り上げられていました。もちろんプロダクトによって課題や施策は異なりますが、大きい視点でみると以下のような共通点があるなと感じました。

1. アプリケーション視点：ソースコードの構成を見直して、メンテナンス性を上げる

• モノレポから、モジュラーモノリス や マイクロサービスへ移行する
  • 大きな一つの塊になったソースコードを分離し、人が理解しやすいサイズに小さくする。
  • どう分離するかを決める手法の一つに「ドメイン駆動設計 (DDD)」があり、よく出てくるキーワードの一つでした。

2. インフラ視点：コストや運用の負担を軽減する

• テナントの分離モデルをサイロモデルから共有型のモデルへ変更する
  • ユーザーごとに環境を分ける「サイロモデル」から、SaaSのスケールメリットを活かすために「プールモデル」や「ブリッジモデル」といった共有型に移行する。
  • 場合によっては、特定のユーザ向けに独立した環境も提供するハイブリッドモデルを採用する。

3. 移行戦略：少しずつ変更していく

• 「ストラングラーフィグ・パターン」を採用する
  • 稼働中のプロダクトを一度にすべて変更するのではなく、変更のリスクを最小限におさえる方法が取り上げられていました。

まとめて返済する時は、"駅の再開発" をイメージしてみよう

カンファレンスでは、大きな技術的負債を解決する「リアーキテクト」の手法として、「ストラングラーフィグ・パターン」が取り上げられていました。
変更リスクや周りの理解の得やすさを考えると、少しずつ変更していく手法がやりやすいと紹介されていました。
小心者の私には心理的な面でも安心できる手法です。

ストラングラーフィグ・パターンは、直訳すると「締め殺しの木」と紹介されていましたが、私はこれを**"駅の再開発モデル"**で説明したいと思います。

首都圏に住んでいる人であれば、近年の渋谷駅の大規模再開発がイメージしやすいかなと思います。
渋谷駅では大きく構造を変更する再開発の工事を、何年もかけて少しずつ変更し続けています。
渋谷駅に行くたびにホームやルートが迂回路で変更になっていて戸惑うこともありますが、基本的にはいつも通り利用することができます。それでもどうしても電車を止めなければならない工事の時には、一時的に利用できない時間を設定して工事をしていますよね。

「リアーキテクト」の話に戻すと、ユーザーさんにはそのまま利用が継続できるように、小さな変更を繰り返しリリースすることで、段階的にゴールをめざしていきます。
小さな変更を繰り返すことで、何かあったときはすぐ戻すこともやりやすくなると思います。また、プロダクトチームが、変更に対するリスク（怖さ）に慣れることができ、心理的な負担を小さくできるメリットがあるかなと思いました。

もちろん、利用停止が必要な変更も時には発生するでしょう。その場合は、利用者が少ない時間に一時停止して作業することになります。

ストラングラーフィグ・パターンにもデメリットはあると思いました。

• 解決までに長い時間が必要になる。
• 変更中も利用できるよう「迂回路」が必要になるので、複雑な仕様が必要になる。
• 技術的な負債が大きすぎると、より難易度が高くなる。

「銀の弾丸はない」ので、再構築（リプレイス）するという選択肢もあると思います。
まずは状況にあわせてどれが最適なのかを判断することが必要だと思いました。

小さな技術的負債の返済は、日々の活動でもできるはず！

大きな技術的負債の解決には、ロードマップと相談しながら長期的な計画で実施する必要があります。

でも、日々のスプリントの中でも少しずつやれることがあるはず！と考えています。
いくつかピックアップしてみます。

• 不要になったソースコードや環境変数は、すぐに削除する
  • 残すと後日再調査が発生してしまう。不要になった時点で削除する。
• 連携や機能の追加対応では疎結合を意識する
  • なるべく密結合のポイントを増やさない。
    • 例）連携追加時には、DB直接参照ではなくAPI参照にする。
    • 例）機能追加時には、スパゲッティにならないように、どこに追加したほうがわかりやすいかを意識する。
• バージョンアップはこまめに実施する
  • 一度に複数のメジャーバージョンアップ（例：ver1 → 4）すると、変更差分が大きくなり、対応が大変になってしまう。
• ドキュメントのメンテナンスを怠らない
  • 新しいメンバーが迷子にならないように、ドキュメントを整備し続ける。

技術的負債を増やさない、小さくしようという日々の努力も大事かなと思います。

技術的負債は”成長の証”。喜んでもよいものだが、先送りするべきものではない

技術的負債が問題になるプロダクトは、一定のビジネス規模まで成長できて、これからもたくさんのお客さんに使ってもらうために機能追加や改善をやっていこうというプロダクトになった証です。

一生懸命に創り上げたプロダクトがそこまで成長できずに、夜空の星になる、もしくは塩漬けになってしまうことを考えると、逆に喜ばしいことなのかなと思います。

現在の視点で振り返ってみると、なんで「こんな設計になっているんだ！」と思うことがありますが、立ち上げ当時のメンバーには責任はありません。

技術的負債に取り組むことは、リスクが高く、人的リソースが必要になることから、機能追加のペースを下げることも覚悟しなければなりません。「やりたくないなぁ」というのが本音ではないでしょうか？
しかし、技術的負債をさらに先送りすると、今よりも解決するための労力とリスクが膨れ上がっていくことが予想されます。

技術的負債を解決することは、今の私達が未来のためにやらなければならないことでしょう。

ポエムのまとめ

今回この記事を書いた理由には、今自分がやろうとしている技術的負債の解決の進め方を整理することもありました。
さあ、"未来"のために始めていこう！

---

イラストは、Nano Bananaさんに作成してもらいました。
統一感があるイラストが作成できるので嬉しいのですが、微妙におかしい点まで修正しきれませんでした。
面白いので、そのまま採用しています。