フレームワーク活用ガイドひとことで言うと#
開発リソースを「新機能」「改善」「技術負債返済」「インフラ」の4カテゴリに意図的に配分し、短期の事業成長と中長期の技術健全性を両立させる投資設計手法。
押さえておきたい用語#
- Investment Ratio（インベストメント レシオ）
- 開発工数を機能開発・改善・負債返済・インフラにどの比率で割り振るかを定めた配分ルールを指す。
- Tech Debt（テック デット）
- 短期的な速度を優先した結果たまった技術的な借金。放置するとメンテナンスコストが膨らむ。
- Keep The Lights On（KTLO）
- システムを現状維持するために必要な最低限の運用・保守工数を指す。
- Feature Work（フィーチャー ワーク）
- ユーザーに新しい価値を届ける新機能開発である。
- Toil（トイル）
- 自動化可能なのに手作業で行われている繰り返しの運用作業。SREの文脈で使われる概念である。
エンジニアリング投資配分の全体像#
こんな悩みに効く#
- 新機能のリクエストに追われて技術負債が一向に減らない
- 「投資の何割が成長に使われているか」と経営から聞かれて答えられない
- 障害が増えているのにインフラ改善の工数が確保できない
基本の使い方#
具体例#
エンジニア60名のBtoB SaaS。事業成長のために新機能開発を優先した結果、3年で技術負債が蓄積。デプロイにかかる時間が1時間→4時間に増え、新機能の開発速度も初期の40%まで低下していた。
工数配分を計測すると実態は以下の通り。
| カテゴリ | 現状 | 目標 |
|---|---|---|
| 新機能 | 72% | 45% |
| 改善 | 12% | 20% |
| 負債返済 | 6% | 25% |
| インフラ | 10% | 10% |
負債返済枠を毎スプリント25%固定で確保し、影響度の高い負債から順に対応。6ヶ月後にデプロイ時間が 4時間 → 45分 に短縮。新機能の工数は減ったが、1機能あたりの開発速度が上がったため、リリース数は横ばいを維持できた。
エンジニア25名のモバイルゲーム開発会社。新タイトルのリリース前3ヶ月は機能開発に集中し、リリース後は運用安定にシフトする必要があった。
フェーズ別の投資比率を明示的に設計。
| カテゴリ | リリース前 | リリース後 |
|---|---|---|
| 新機能 | 65% | 30% |
| 改善 | 15% | 25% |
| 負債返済 | 10% | 25% |
| インフラ | 10% | 20% |
リリース後のインフラ枠を20%確保したことで、ローンチ直後のアクセス集中にも安定して対応。前作では3日間のサーバー障害があったが、今回はダウンタイムゼロで初月120万DLを処理できた。
職員5名のDX推進チーム。庁内の業務システム刷新と新しい住民向けサービス開発を並行して進める必要があったが、「何にどれだけ時間を使うか」の基準がなく、緊急対応に振り回されていた。
投資配分フレームワークを導入し、月単位で工数を管理。
| カテゴリ | 比率 | 具体的な内容 |
|---|---|---|
| 新機能 | 30% | 住民向けオンライン申請 |
| 改善 | 20% | 既存システムのUI改善 |
| 負債返済 | 30% | レガシーシステムの段階移行 |
| インフラ | 20% | セキュリティ対応・監視整備 |
レガシー移行に**30%**を確実に充てたことで、12ヶ月で対象システムの 60% をクラウド移行完了。以前は「いつ終わるかわからない」状態だったものが、経営層にも進捗が見える形になった。
やりがちな失敗パターン#
- 比率を決めても実際には守らない — 「今スプリントだけ特別」が常態化する。プランニングで先に枠を確保し、例外は月1回まで等のルールを設ける
- 全カテゴリを均等配分にする — 25%ずつは一見公平だが事業フェーズに合わない。成長期は機能開発を厚く、負債が限界なら返済を厚くする
- KTLO（運用保守）を計測しない — インシデント対応やオンコールの時間を投資配分に含めないと、実質の開発可能工数を見誤る
- 経営層との合意なしに負債返済を始める — 機能開発が減る理由を説明できないと、数スプリントで負債返済枠が削られる。投資対効果を数字で示す
まとめ#
エンジニアリング投資配分は、開発工数を 「新機能・改善・負債返済・インフラ」 に意図的に振り分け、短期成長と中長期の技術健全性を両立する手法。まず現状の配分を計測し、事業フェーズに合った目標比率を設定する。四半期ごとに実績を振り返り、比率を再調整するサイクルが定着すれば、技術負債の計画的な返済と安定した機能開発の両方が実現する。