← エピソード一覧に戻る Episode 173 Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
0:00 / 0:00
スクリプト
Chapter 1 オープニング ― 作るほど遅くなるのはなぜか
タカシ
皆さんこんにちは、タカシです。今日は SaaS 開発の技術的負債を取り上げます。Stripe の調査では、開発者は平均で週 13.5 時間を技術的負債への対処に使っています。速く出したはずなのに、あとから毎週そのツケを払い続ける。これが今日のテーマです。
ミカ
ミカです。週 13.5 時間って、かなり大きいですね。感覚的には『古いコードの手直し』みたいに聞こえますけど、実際にはそれで新機能が遅れたり、障害が増えたり、採用した人が立ち上がりにくくなったりするんでしょうか。
タカシ
その通りです。技術的負債はコードの美醜ではなく、将来の変更コストを前借りしている状態です。前回のインシデント対応が『火事の消し方』だとすれば、今回は『なぜ火事が起きやすい構造になるのか』という話ですね。SaaS 経営では、負債は速度、粗利、信頼性の三つに効いてきます。
ミカ
なるほど。現場の気分としては『このリリースだけ乗り切ろう』でも、会社全体で見ると借金みたいに利子がつくわけですね。今日は、どういう負債が危険なのかと、経営者がどこまで口を出すべきなのかを知りたいです。
Chapter 2 原則 ― 技術的負債は成長税になる
タカシ
McKinsey は、多くの企業で新規プロダクト予算の 10 から 20 パーセントが既存の複雑さ解消に流れ、技術的負債の総量は技術資産価値の 20 から 40 パーセントに達しうると整理しています。つまり負債は、見えにくい原価として毎年利益を削るんです。
ミカ
うわあ、それって『今期の開発費』に見えていても、実は過去の近道の返済なんですね。経営会議では人を増やせば解決しそうに見えるけど、土台が複雑なままだと、新しい人が入っても早くならない気がします。
タカシ
そこが重要です。SaaS は継続的に機能追加しながら既存顧客も支えるので、負債の利子は毎週のリリースに乗ってきます。変更リードタイムが延びる、変更失敗率が上がる、問い合わせが増える。結果として売上を作るチームまで待たされ、成長全体が鈍くなるわけです。
ミカ
よく『技術的負債は悪だ』みたいに言われますけど、ゼロにするのも現実的じゃないですよね。創業期なら、多少の近道を取らないと市場に出せないこともある。その線引きはどう考えればいいんでしょう。
タカシ
答えは、借りることより無自覚に借り続けることが危険だ、です。短期で売上検証を優先して意図的に負債を負うのはありです。ただし、どの指標が悪化したら返すか、誰が owner か、いつ返すかを決めていない負債は、戦略ではなく放置になります。
Chapter 3 具体例 ― ShopifyとIntercomに学ぶ返済の仕組み
ミカ
具体的に強い SaaS 企業は、負債をどう扱っているんでしょう。気合いでリファクタリングするというより、運用ルールや投資配分を仕組みにしていそうです。公開事例があれば聞きたいです。
タカシ
Shopify は分かりやすいです。四半期キャパシティの 25 パーセントを debt、bugs、stability に使う 25% rule を置き、さらに日々 10 パーセントを改善へ回す考え方も示しています。つまり負債返済を『余ったらやる仕事』にしていないんですね。
ミカ
先に改善枠を確保してしまうんですね。売上プレッシャーが強いと、どうしても新機能が勝ちそうですけど、そこをルールで守ると。経営から見ると、負債返済も『将来の出荷能力を買う投資』として扱っている感じがします。
タカシ
さらに Shopify は、巨大モノリスの複雑化に対して Packwerk を作り、6 つの Rails アプリで使った後、Core モノリスにも 48 のパッケージと 30 の境界制約を導入しました。大改修より先に、既存コードの境界を守らせる。これは SaaS らしい現実解です。
ミカ
『負債があるなら全部マイクロサービス化だ』みたいな雑な話じゃないんですね。今ある土台を壊さず、まず混線を減らす。会社としても、そのほうが顧客影響を抑えながら返済を進められそうです。
タカシ
Intercom の事例も示唆的です。複数チームが似た UI や機能を別々に積み上げた結果、あるプロジェクトは当初見積もりの約 4 倍、5 カ月に膨らみました。さらに design debt によって customer confusion 付き会話が 2 倍に増えた。内部の重複が、そのまま顧客体験の悪化へ出たわけです。
ミカ
見た目の不統一とか実装の重複って、つい『あとで直せばいい』になりがちですけど、問い合わせ増や再実装で粗利を削るんですね。SaaS だと、一つのチームの小さな近道が、サポートや営業まで巻き込むのが怖いところです。
Chapter 4 失敗パターン ― 放置、例外実装、全面リライト
ミカ
じゃあ、技術的負債で崩れやすい会社には、どんな共通点があるんでしょう。現場が忙しいほど、良くないやり方を善意で続けていそうです。経営者が先に見抜ける危険信号があれば押さえたいです。
タカシ
典型例は四つです。借りた理由を忘れて返済計画がない、大口顧客向け例外実装を積み上げる、負債の利子を測らない、そして全面リライトを万能薬だと思う。このどれかがあると、負債は管理対象ではなく、会社の体質になっていきます。
ミカ
特に SaaS だと、売れる顧客を逃したくなくて個別要望を特注で飲みたくなりますよね。でもそれが増えると、マルチテナント前提の良さが消えて、保守も導入も重くなる。短期売上の成功が、後から原価爆弾になる感じがします。
タカシ
その通りです。GitLab Handbook が良いのは、技術的負債にも severity と priority を付ける点です。S1、S2 相当なら修正計画や期限を持たせる。つまり『障害ではないから後で』にせず、将来の障害や機会損失の予兆として扱っているわけですね。
ミカ
あと、全面リライトって夢がありますけど、実際は怖いですよね。現場は二重運用になって疲れるし、お客さん向けの新機能も止まりやすい。『全部作り直せば楽になる』は、たいてい気持ちが先に走っている気がします。
タカシ
全面リライトが必要な場面はありますが、まずは境界整理、テスト自動化、削除できる例外実装の特定からです。負債返済はドラマチックな大工事より、地味でも利子の大きい場所を潰すほうが効く。ここを外すと、返済のつもりで新しい借金を作ります。
Chapter 5 クロージング ― 負債を見える経営課題にする
ミカ
今日の話で、技術的負債ってエンジニアの愚痴ではなく、出荷力と粗利を削る経営テーマなんだと分かりました。きれいなコードを目指す話ではなく、会社が速く学び続けるための投資判断なんですね。明日から何を始めるのが良さそうでしょう。
タカシ
まず、技術的負債を信頼性、売上影響、開発生産性、セキュリティの四軸で棚卸ししてください。次に、改善枠を先に確保し、変更リードタイムや問い合わせ件数と結び付けて優先順位を決める。最後に、重い負債には owner と期限を置く。この三つで、負債は愚痴から経営管理へ変わります。
ミカ
借りるのはゼロにできなくても、借りたまま忘れないことが大事なんですね。皆さんの会社でも、『最近なぜか何を直すにも重い』という感覚があれば、それは気合い不足じゃなく負債のサインかもしれません。ぜひ棚卸しから始めてみてください。
タカシ
今回は SaaS 開発の技術的負債を扱いました。次回は、成長を先回りで支える設計余力、アーキテクチャランウェイを取り上げます。短期の近道と長期の備えをどう両立するか、そこを続けて見ていきましょう。それではまた次回。