詳細ガイド
技術的負債による開発速度低下シミュレーター：手戻りがエンジニアリングチームに要するコスト
業界のエグゼクティブ分析
技術的負債とは、近道の積み重ねたコストです。動くけれど変更が難しいコード、欠けているテスト、絡み合った依存関係、誰も理解していない古いシステムがそれにあたります。予算に現れることはめったにありません。代わりに、あらゆることが以前より時間がかかるという感覚として現れます。見積もりは遅れ、小さな変更が無関係な箇所を壊し、チームは何も新しいものを生まない作業にスプリントを費やします。この請求書は、課金としてではなく、同じ人件費で毎月リリースできる機能が減るという形で届きます。
この問題の構造は、処理能力にかかる税金です。すべてのスプリントの5分の1が回避策と手戻りに消えるなら、給与は変わらないまま、チームは5分の1小さくなったかのように振る舞います。負債は複利でも増えます。不安定な土台の上に作る新機能は、そのたびに複雑さを加えるため、返済に労力を割かない限り、失われる割合は増えていきます。負債を返すと、今の成果が犠牲になります。だからこそ先送りしたくなり、だからこそこの判断には数字が必要なのです。
ドミノモデルは、その損失を追います。負債で失われるスプリントの割合が、新しい作業に使える処理能力を減らし、リリースする機能を減らします。機能が減れば、人件費1ドルあたりに届ける価値が下がり、手戻り、火消し、離職の負担は負債とともに増えます。最後の箱は、リリースした価値とチームの本当のコストを比べます。人件費は固定でも価値はそうではないため、負債がわずかに増えるだけで、健全な収益が赤字に変わることがあります。
氷山は、人件費の行が隠しているものを示します。目に見えるのは人件費そのものです。水面下には、手戻りに費やされた人件費の部分、負債が本番環境で引き起こす火消し、疲弊したコードベースを離れるエンジニアの離職、そして作られなかった機能の価値があります。最後の項目は帳簿に現れない機会費用ですが、通常は最大です。シミュレーターで、チームが採算に合わなくなる負債の水準を探し、返済計画に価値があるかどうかを試してください。
計算式と方法論の設計図
このモデルは、製品チームの月次の見方です。人件費は、エンジニア数に諸経費込みの人件費を掛けたものです。スプリントの一部は負債に、一部は意図的な返済に使われ、残りが新機能の開発に充てられます。リリースした機能は、エンジニア数にエンジニアあたりの機能数と、その残りの割合を掛け、機能あたりの価値で評価したものです。負債は障害も引き起こし、それは手戻りコストの一定割合として計上され、離職も増やします。離職は、後任1人につき諸経費込み給与の4か月分で見積もります。予測では、返済に資金を投じない限り、負債は毎月増えていきます。
- 開発に使える割合
- b = 1 − 負債 − 返済
- スプリントのうち、新機能の開発に充てられる部分です。
- リリースした機能
- F = エンジニア数 × エンジニアあたりの機能数 × b
- 1か月に提供された新機能です。
- 手戻りコスト
- W = 人件費 × 負債
- 新しい価値を何も生まなかった人件費です。
- 離職コスト
- A = エンジニア数 × (1% + 0.06% × 負債のポイント数) × 4か月 × 人件費
- エンジニアの入れ替えにかかる、負債とともに上昇する月間の期待コストです。
- 純損益
- 純額 = F × 価値 − 人件費 − 0.15 × W − A
- 提供した価値からチームの本当のコストを引いたものです。破綻点は、これがゼロになるところです。
連鎖する弾力性
負債の割合が最も弾力的な入力値です。成果を減らすと同時に、障害と離職のコストを増やすからです。機能あたりの価値とエンジニアあたりの機能数は、収益全体に比例します。人件費は、価値が上回らなければならない固定の土台であるため重要です。
実例に基づく3つのケーススタディ
自己資金で始めるスタートアップ
クリーンなコードベースを持つ小さなチーム
3人のチームが負債を低く抑え、速くリリースし、人件費に対して各機能を高く評価しています。手戻りは小さい状態です。読み込むと、クリーンな土台の初期の優位性と、それが侵食され始めるのにどれほど少ない負債で足りるかがわかります。
成長中の中堅企業
返済に投資する大きなチーム
45人のチームが、適度な負債を抱えつつ、各スプリントの1割を整理に充てています。機能は良いペースでリリースされ、障害は少ないままです。読み込むと、規律ある返済が規模に耐える理由がわかります。
ブラックスワン級の危機
誰も変更できない急成長のコードベース
25人のチームが、何年分もの近道を引き継ぎました。すべてのスプリントの半分以上が手戻りと障害に消え、離職率は高く、返済に充てる時間はゼロです。読み込むと、大きな人件費がほとんど成果を生まない様子と、どの変数がその月を立て直すかがわかります。
業界ベンチマーク一覧
| 指標 | 危険ゾーン | 業界平均 | 上位10%のエリート水準 |
|---|---|---|---|
| 手戻りで失われるスプリントの割合 | 40%超 | 15〜25% | 10%未満 |
| 負債の返済に確保する時間 | ゼロ | 5〜10% | 必要に応じて15〜20% |
| 人件費1ドルあたりのリリース価値 | 1.0未満 | 1.2〜1.6 | 2.0超 |
| エンジニアの月次離職率 | 2.5%超 | 1〜1.5% | 1%未満 |
| 手戻りコストに占める障害対応の割合 | 25%超 | 10〜15% | 8%未満 |
変数とレバー
チームのエンジニア数
製品に取り組む開発者の数で、フルタイム換算で数えます。
レバー: 負債の重いチームには、まずエンジニアを増やさないでください。新しい人も同じ足かせを引き継ぎ、立ち上がりも遅くなります。
エンジニア1人あたりの月間人件費（諸経費込み）
エンジニア1人の1か月分の、給与に税金、福利厚生、機材、間接費を加えた額です。
レバー: 給与は市場水準に保ちつつ、隠れた間接費を削ってください。負債で失われる1時間は、諸経費込みの満額で支払われています。
負債と手戻りで失うスプリントの割合
新機能ではなく、回避策、バグ修正、遅いビルド、古いコードとの格闘に費やされるエンジニアリング時間の割合です。
レバー: 負債を見える化してください。最悪のモジュールを一覧にし、手戻りの時間を見積もり、最も多くの機能に関わるものから直します。
エンジニア1人あたりの月間機能数（負債なしの場合）
負債によって時間が失われなければ、エンジニア1人が1か月にリリースできる意味のある機能の数です。
レバー: ビルド、テスト、レビューの摩擦を取り除いてください。開発者体験が、1人がリリースできる機能の数を決めます。
リリースした機能の月間価値
典型的な機能がリリース後に毎月加える売上、節約額、継続率で、ご自身の見積もりを入力します。
レバー: 売上や継続率を動かす機能をリリースしてください。リリースした価値が低ければ、開発速度をどれだけ上げてもチームは黒字になりません。
負債の返済に投じるスプリントの割合
負債を減らすために意図的に費やすスプリントの割合です。今は成果を犠牲にし、後に負債を減らします。
レバー: 各スプリントの一定部分を、多くの場合1〜2割、今後の作業を妨げる負債のために確保してください。
このシミュレーターの使い方
- 1現実的なプリセットから始めるか、チームの人数、諸経費込みの人件費、見積もった手戻りの割合を入力します。
- 2五つのドミノの箱を見て、開発速度と負債の負担のどちらが先に赤くなるかを確認します。
- 3「破綻点を探す」を押して、チームが赤字になる負債の割合を確認します。
- 4現在の計画と返済の計画を、24か月のグラフで比較します。
- 5数スプリントにわたって手戻りを計測し、四半期ごとにモデルを見直します。
避けたい間違い
- 給与は固定だからという理由で、負債で失われた時間を無料とみなすこと。1時間ごとに、諸経費込みの満額のコストがかかっています。
- 遅いコードベースにエンジニアを加えて、開発速度が比例して上がると期待すること。
- 今後の作業を妨げる箇所で着実に負債を返すのではなく、大規模な書き直しを計画すること。
- 離職を無視すること。不快なコードがもたらす、現実で繰り返し発生するコストです。
よくある質問
負債で失われるスプリントの割合はどのように見積もりますか。
数スプリントにわたって、手戻り、バグ修正、回避策にあたるチケットやプルリクエストにタグを付け、その時間をエンジニアリング時間の合計で割ります。確認のために、チームにおおよその数字も聞いてみてください。
技術的負債はすべて悪いものですか。
いいえ。より速く学ぶため、あるいは期限に間に合わせるために近道を取るのは、記録して返済するのであれば、良い取引になりえます。負債が問題になるのは、管理されず、複利で膨らむときです。
返済にどのくらいの時間を割くべきですか。
負債の水準と今後の作業によります。1〜2割を安定して充てるのが一般的ですが、整理そのものを目的にせず、計画中の機能を妨げる負債に使ってください。
機能の価値はどのように評価しますか。
大まかでもかまわないので、その機能が加える月間の売上、継続率、コスト削減を見積もります。難しければ、平均の売上成長をリリースした機能数で割った値を出発点にしてください。
チームが赤字になる負債の水準はどのように見つけますか。
「破綻点を探す」を押してください。ツールは各入力値を悪化する方向へ動かし、月次利益がゼロになる値を報告します。
どのくらい正確ですか。
明示した前提に基づく教育目的のモデルであり、経営上の助言ではありません。実際のエンジニアリングの成果は多くの要因に左右されます。入力値をご自身のデータに置き換えてください。
これは前提条件を明示した、教育目的の計画モデルです。財務、税務、法律に関する助言ではありません。入力値はご自身の数字に置き換え、重要な判断は必ず資格を持つ専門家に確認してください。