開発チームとの定例で、「そろそろ技術的負債を返す時間がほしい」と相談される。一方で、商談中の見込み客や既存ユーザーからは新機能の要望が届いている。どちらの言い分も正しく聞こえるのに、限られた開発リソースをどちらへ割くべきか判断がつかない——プロダクトマネジメントを兼務する経営者が、繰り返し直面する場面です。
やっかいなのは、技術的負債の話が「エンジニアの言葉」で説明されがちなことです。「あのモジュールが密結合で」「テストがなくて」と言われても、それが事業にどれだけ効いているのかが見えず、判断を先送りにしてしまう。あるいは逆に、開発チームの熱量に押されて全面的な作り直しに合意し、数ヶ月間まったく機能を出せなくなる。
本記事では、技術的負債を機能開発と同じ土俵に載せて相対的に比較し、返済の順序と入れ方を決めるための考え方を、4つのステップで解説します。
技術的負債とは何か——PdMの言葉で整理する
技術的負債とは、「早く形にするために、あるいは知識や時間が足りずに、後で手を入れる前提で残した設計・実装の未整備」のことです。金銭の負債と同じで、放っておくと「利息」——つまり、その領域を触るたびに余計にかかる時間やリスク——が積み重なっていきます。
判断の前に、似て非なるものと切り分けておきます。
- バグ：仕様どおりに動いていない不具合。これは負債返済ではなく、通常の開発タスクとして扱います。
- 技術的負債：動いてはいるが、構造上の無理があり、変更・拡張のたびにコストがかかる状態。
- 好み・こだわり：「この書き方のほうが美しい」という開発者個人の趣向。事業への影響が説明できないものは、負債の一覧から外します。
負債の成り立ちも3種類に分けると、対応の緊急度を見積もりやすくなります。
- 意図的な負債：スピードを優先して、あえて簡易な作りにした。当時の判断としては妥当だったもの。
- 不注意による負債：設計の見通しの甘さや、当時の経験不足から生まれたもの。
- 環境変化による負債：作った時点では適切だったが、要件やユーザー数が変わって合わなくなったもの。
意図的な負債は「返す前提」で作っているため計画に載せやすく、環境変化による負債は事業の成長に伴って必ず出てくるものだと捉えておくと、開発チームからの相談を「後ろ向きな話」ではなく「成長の証」として受け止められます。
なぜ機能開発との天秤が難しいのか
判断が進まないのは、経営者の決断力の問題ではなく、いくつかの構造的な理由があります。
1つ目は、コストもリターンも見えにくいことです。 新機能なら「開発に3週間、成約率が上がるはず」とおおまかな見積もりが立ちます。一方、負債返済は「直すのにどれくらいかかるか」も「直したら何がどれだけ良くなるか」も曖昧なまま提案されがちです。数字で語れないものは、数字で語れるものに負けます。
2つ目は、声の非対称性です。 新機能の要望は、営業・顧客・投資家など多方面から届きます。負債返済の要望は、開発チームからしか上がってきません。そして「負債を返さなかったことによる損失」——半年後に開発速度が落ちる、ある日大きな障害が起きる——について、事前に声を上げる人は誰もいません。声の大きさで優先順位を決めると、負債は永遠に後回しになります。
3つ目は、全か無かで語られやすいことです。 「このままでは限界です、作り直しましょう」という提案と、「今は機能開発を優先しましょう」という判断の、両極だけで議論が進んでしまう。実際には、その間に「重要な部分だけ、機能開発を続けながら少しずつ返す」という現実的な選択肢があります。
技術的負債の優先順位を判断する4ステップ
STEP1：負債を「事業への症状」で棚卸しする
最初にやるべきは、開発チームに、技術用語ではなく「これのせいで、事業やチームに何が起きているか」という形で書き出してもらうことです。
たとえば、次のような粒度にします。
- 決済まわりのコードが複雑で、料金プランを1つ変えるたびに検証を含めて2週間かかる
- 自動テストがほとんどなく、リリースのたびに半日を手動確認に使っている
- サーバー構成が古く、アクセスが急増すると停止するリスクがある（直近で1度、実際に落ちた）
- 管理画面のコードが密結合で、新しいメンバーが担当できるまで1ヶ月以上かかる
この「症状」の形にすると、経営者にも影響が理解でき、機能開発と比較できるようになります。そして書き出す過程で、事業への影響を説明できない項目——実は「好み」だったもの——が自然に落ちます。一覧は、次のステップで見積もる対象になります。
STEP2：各負債の「痛み」を4つの観点で見積もる
棚卸しした負債の一つひとつについて、痛みの大きさを次の4つの観点で見積もります。厳密な数値でなくて構いません。大・中・小の3段階で十分です。
- 開発スピードへの影響：この負債があることで、関連する機能開発がどれくらい遅くなっているか。「本来3日で終わる改修に、毎回1週間かかっている」といった実感を開発チームから引き出します。
- 障害・品質リスク：放置した場合に起こりうる最悪の事態と、その起こりやすさ。「決済が二重に走る可能性がある」「復旧に丸1日かかる構成になっている」など。
- 変更の頻度：その領域を、これからどれだけ触るか。ロードマップ上、今後も繰り返し改修が入る場所なのか、めったに触らない場所なのか。
- 人への影響：その負債が原因で開発者が疲弊していないか。新メンバーのオンボーディングや、採用の足かせになっていないか。
このなかで特に重視すべきは変更の頻度です。きれいにする価値があるのは、これからも何度も手を入れる場所だけです。今後ほとんど触らない領域の負債は、多少不格好でも動いているなら、優先度を大きく下げて構いません。
優先順位づけのフレームワークを負債にも当てる考え方は、以下の記事が参考になります。
STEP3：機能開発と同じ土俵に載せて相対比較する
ここが最も重要なステップです。負債返済を「別枠の特別な作業」として扱わず、機能開発の候補と同じバックログに、同じ物差しで並べます。
具体的には、負債返済のタスクにも「これをやると、どんな価値が、どれくらい生まれるか」を書きます。
決済まわりのリファクタリング（見積もり：2週間） → 料金プランの変更にかかる時間が2週間から3日に短縮。今期中に想定している3回のプラン改定で、あわせて約20人日を節約。
このように「返済によって取り戻せる時間」を、できる範囲で機能開発の期待価値と比較可能な形にします。すべてを正確に数値化する必要はありません。「この負債返済と、この新機能なら、どちらを先にやるべきか」を同じテーブルで議論できる状態になれば十分です。
社長が握っている優先順位の判断を、開発チームと共有できる基準に落とし込む手順は、次の記事で詳しく扱っています。
STEP4：返済の「入れ方」を決める
優先順位がついたら、上位の負債をどう返していくかの方式を決めます。負債の大きさによって、3つの入れ方を使い分けます。
- 相乗り方式：その領域の機能開発をするとき、ついでに直す。小さな負債は、専用の時間を取らず、関連する開発のなかで少しずつ返します。
- 定期枠方式：開発時間の10〜20%を、負債返済に固定で割り当てる。中くらいの負債を、機能開発を止めずに継続的に減らしていく方法です。
- 集中返済方式：大きな負債を、期間を区切ってまとめて返す。この間は機能開発がほぼ止まるため、事業の足を明確に引っ張っている大物1つに限って、経営判断として実施します。
原則は、「小さい負債は相乗り、中くらいは定期枠、事業インパクトの大きい大物だけ集中返済」です。すべてを集中返済でやろうとすると開発が長期間止まり、すべてを相乗りだけで済ませようとすると大物がいつまでも残ります。
返済枠をロードマップにどう組み込み、どの頻度で見直すかは、以下の記事とあわせて考えると設計しやすくなります。
よくある判断の落とし穴
進め方を誤りやすいポイントを3つ挙げます。
「全面的な作り直し（リライト）」に安易に合意しない。 開発チームから「一から作り直したほうが速い」という提案が出ることがあります。しかし作り直しは、その間まったく新しい価値が出せず、しかも当初の見積もりを超えることがほとんどです。まずは「動いているものを、機能開発を続けながら部分的に直す」道がないかを一緒に検討します。作り直しを選ぶなら、それは大きな経営判断であり、期間・停止する開発・撤退ラインを明確にしてから着手します。
負債をすべて先送りにしない。 負債の利息は複利で効きます。今は「開発が1.2倍遅い」程度でも、放置すると新しい負債がその上に積み重なり、ある時点から急に「何をするにも時間がかかる」状態になります。四半期に1度は、上位の負債を1つでも返す枠を確保しておくのが安全です。
判断を丸投げしない、逆に抱え込まない。 「技術のことは分からないから任せる」と全面委任すると、事業インパクトの観点が抜け落ちます。逆に経営者がすべての返済判断を握ると、開発チームが細かい負債を返すたびに承認待ちが発生します。「事業に大きく影響する大物の返済は一緒に決める、日常的な小さい返済は開発チームの裁量」という線引きが現実的です。
PdMを兼務する経営者が現実的に回すには
最後に、限られた時間でこの判断を続けるための進め方をまとめます。
四半期に1度、負債リストを開発チームと一緒に更新する。 新しく生まれた負債を足し、返済が済んだものを消し、各負債の「痛み」を見直します。この定例がないと、負債返済は「開発チームが不満を溜めたときに、まとめて相談される案件」になってしまいます。
「今後もその領域を触るか」で、8割は判断がつく。 4つの観点をすべて厳密に評価しなくても、変更の頻度が高く、かつ開発スピードを明確に落としている負債から手をつければ、大きく外しません。
数値化にこだわりすぎない。 STEP3の見積もりは、順位をつけるための道具です。桁が合っていれば十分で、正確な人日を出すことに時間をかける必要はありません。
集中返済は、一度に1つの大物だけ。 複数の大きな返済を並行させると、開発がほぼ止まります。最も事業の足を引っ張っている1つを選び、それが片づいてから次に移ります。
技術的負債の判断は、場当たり的な機能開発から抜け出し、プロダクトを中長期でどう伸ばすかという戦略と地続きです。目の前の要望と負債のあいだで毎回消耗している場合は、その手前の戦略の解像度を上げると、判断が楽になることがあります。
まとめ
技術的負債と機能開発の天秤が難しいのは、負債のコストとリターンが見えにくく、返済を求める声が開発チームからしか上がらず、議論が「作り直すか、放置するか」の両極になりがちだからです。
判断は、(1)負債を「事業への症状」の形で棚卸しし、(2)開発スピード・リスク・変更頻度・人への影響の4観点で痛みを見積もり、(3)機能開発と同じバックログに同じ物差しで並べて相対比較し、(4)大きさに応じて相乗り・定期枠・集中返済を使い分ける、という4ステップで進めます。
原則は、「これからも何度も触る場所の負債を優先し、小さいものは相乗りで、大物だけ経営判断として集中的に返す」こと。四半期に1度リストを更新し、集中返済は一度に1つに絞れば、限られた工数でも判断を回し続けられます。
プロダクトマネジメントについてお気軽にご相談ください
プロダクトマネジメントの顧問支援や、1人目のPdM採用・育成のサポートを承っています。 「経営者が兼務してきたが、そろそろ限界かもしれない」という段階からでもお気軽にご連絡ください。 おおむね2営業日以内にご返信します。
