開発コストが高すぎる理由を分解する — 開発生産性を診断する5つの観点
「開発にコストがかかりすぎる」「リリースが遅い」という訴えは、CTO不在のスタートアップでもVC支援先でも頻繁に出てきます。しかしこれは症状であり、原因ではありません。症状に対して「人を増やす」「ツールを導入する」と即断すると、かえってコストが増えます。
本稿では、開発コスト・生産性の問題を5つの観点に分解し、各観点ごとの計測方法と打ち手、そして着手優先度の判断基準を示します。
「開発が高い・遅い」の正体：5つの観点
開発コストの高さは、以下の5つのカテゴリに分解できます。それぞれ発生メカニズムが異なり、打ち手も違います。
多くの組織は⑤のインフラ・ベンダー費（最も可視化しやすい）にばかり注目しますが、実際に生産性の大きな損失を生んでいるのは①〜④の「隠れたコスト」であることが多いです。
① 手戻りコスト：作り直しが生む最大の浪費
手戻りとは、一度完成または着手した機能を、要件変更・認識齟齬・検証結果を受けて作り直す作業です。
発生要因
- 要件定義の不明確さ: 「なんとなくこんな感じ」でスタートし、実装後に「イメージと違う」が判明する
- 受け入れ基準の欠如: 「完成」の定義が共有されていないため、レビュー段階で大きく方向が変わる
- フィードバックループの遅延: 実装を長期間積み上げてからまとめてレビューするため、手戻り範囲が大きくなる
計測方法
タスク管理ツール（Jira・Linear・GitHub Issues）のチケットに「差し戻し」「再実装」「仕様変更」などのラベルがついた割合を集計します。管理ツールがない場合は、エンジニアへの直接ヒアリングで「先月、作り直しが発生した機能はいくつありましたか？」と聞くだけでも傾向が掴めます。
手戻り率が全タスクの20〜30%を超えている場合、要件定義プロセスに構造的な問題がある可能性が高いです。
着手点
小さく着手するなら受け入れ基準の明文化から始めます。「この機能が完成した状態とは何か」を実装着手前にPMとエンジニアが合意し、テキストで残す習慣だけで手戻りは大幅に減ります。
② 調整コスト：コミュニケーションが生む「見えない残業」
調整コストとは、会議・仕様確認・承認待ち・依存関係の解消など、実際のコーディング以外に費やされる時間のことです。
発生要因
メンバーが増えるにつれて、チーム内のコミュニケーション経路は人数nに対してn(n-1)/2で増加します。3人なら3経路、5人なら10経路、10人なら45経路。これが「人を増やすほど調整が増え、生産性が思ったほど上がらない」構造的な理由です。
また、意思決定権限が曖昧な組織では、些細な技術判断にも承認が必要になり、エンジニアの集中力が断片化されます。
計測方法
カレンダーを確認し、開発メンバーの会議時間の割合を計算します。実装者が会議・チャット対応に1日の40%以上を費やしている場合は、調整コストが生産性を圧迫しているサインです。
より精緻に計測したい場合は、集中できる時間（Deep Work時間）の確保率を週次で記録する方法もあります。割り込みがなく2時間以上連続して作業できた日の割合が目安になります。
着手点
まず定例会議の必要性を棚卸しします。「情報共有のための会議」はほぼすべてドキュメントと非同期コミュニケーションで代替できます。次に、エンジニアが自己判断できる技術決定の範囲を明確にし、承認フローを簡略化します。
③ 技術負債の利息：過去の選択が現在のコストを増やす
技術負債は元本（過去の設計判断）に対して「利息」を支払い続ける構造を持っています。技術負債の正体とスタートアップで問題になるパターンで詳しく扱っていますが、ここでは「利息がどう開発コストに影響するか」に絞って解説します。
発生メカニズム
技術負債の利息が「開発コスト」として現れるのは主に3つの場面です。
| 場面 | 具体的な症状 |
|---|---|
| 新機能追加 | 既存コードが密結合しており、小さな変更でも広い範囲に影響が出る |
| バグ修正 | 「直したら別のところが壊れた」が頻発し、修正コストが肥大化する |
| 新メンバーのオンボーディング | コードベースの複雑さが学習コストを増大させ、立ち上がりに時間がかかる |
計測方法
最も簡単なのは、同規模の機能を追加するのにかかる時間が、1年前と比べて増えているかどうかをヒアリングで確認することです。「以前は1週間でできたことが今は3週間かかる」という体感があれば、技術負債の利息が蓄積している可能性が高いです。
より定量的に把握するには、GitリポジトリのPRサイクルタイム（PRオープンからマージまでの時間）の推移を確認します。人員が増えているにもかかわらずサイクルタイムが長期化している場合は、負債による摩擦の増大を示すシグナルになります。
着手点
全面的なリファクタリングは現実的でないことが多いです。変更頻度の高いモジュールを特定し、そこから手をつけるのが費用対効果の高いアプローチです。変更されることのないコードの負債は、実質的に利息を発生させていません。
④ 過剰設計：善意が生む「やりすぎ」
過剰設計とは、実際には必要とされない汎用性・拡張性・機能を実装することで生まれる余分なコストです。
発生要因
エンジニアが善意で「将来のことも考えて」設計を複雑にするケースが多いです。具体的には以下の形で現れます。
- YAGNI（You Ain’t Gonna Need It）違反: 「いつか使うかもしれない」という仮定で抽象化・汎用化を進め、実際には使われない
- 早すぎるスケーラビリティ対応: ユーザーが100人の段階で100万人向けのアーキテクチャを構築する
- 過剰なフレームワーク導入: 小規模なスクリプトにエンタープライズ向けフレームワークを適用する
計測方法
コードの「使われていない部分」を特定することが計測の第一歩です。デッドコード検出ツール（TypeScriptであればts-unused-exports、Pythonであればvultureなど）を実行し、実際に使われているコードとそうでないコードの割合を確認します。
また「この機能を作るのにかかった時間」に対して「この機能が実際に使われた回数」の比率を確認することで、設計の過剰さを事後的に評価できます。
着手点
シンプルに「今使われる最小の実装」から始める原則を組織に定着させます。コードレビューで「これは今必要か？」を問い返す文化が、過剰設計の最も効果的な抑止力になります。
⑤ インフラ・ベンダー費：唯一「見えやすい」コスト増加
クラウド費用・SaaS費用・ライセンス費用は、財務的に可視化されるため最も管理しやすいカテゴリです。しかし管理ができていない組織では、驚くほど高額になっている場合があります。
発生要因
- 無秩序なSaaS導入: チーム・個人レベルでツールが乱立し、重複する機能に複数の料金を支払っている
- クラウドの最適化不足: 開発・検証用のリソースが本番並みのスペックで稼働し続けている
- スケールアウト時の設計ミス: トラフィック増加時に水平スケールではなく、垂直スケール（高スペックのインスタンスへの移行）で対応し続けている
SaaS/PaaS/IaaSの判断軸でも触れていますが、「何を自社で持つか・何を借りるか」の判断が初期段階で不明確だと、後から費用構造を変えるのが難しくなります。
計測方法
まずクラウドコスト管理ダッシュボード（AWS Cost Explorer・GCP Billing等）でサービスごとのコスト推移を確認します。サービス利用量が変わっていないのにコストが増加している場合は、最適化の余地があります。
SaaS費用については、全ツールのサブスクリプション費用を一覧化するだけで、即座に削減候補が見つかることが多いです。
着手点
クラウドの場合、未使用リソースの削除と開発環境のスケールダウン（夜間・週末の自動停止）は即効性が高いです。SaaSは月次での棚卸しを定例化するだけで、不要なサブスクリプションを継続的に整理できます。
どこから着手するか：ROIで判断する優先順位
5つの観点を把握したとして、実際にどこから手をつけるべきでしょうか。判断の軸は**「削減効果の大きさ」と「着手コストの低さ」**の掛け合わせです。
最初に着手すべきは①手戻りコストと②調整コストです。改善のコストが低く（プロセス改善が中心）、効果が出るまでの時間が短いです。インフラ費（⑤）も即効性は高いですが、削減効果の上限は比較的小さいです。
③技術負債は効果が大きいですが、着手コストも高いです。計画的に取り組む必要があり、「一気に解決」ではなく「継続的な返済」として位置づけるのが現実的です。
④過剰設計は過去の設計を変えるコストが伴うため、新規開発における設計レビューで予防するアプローチが合理的です。
人を増やす前に：ブルックスの法則
「開発が遅いから人を増やす」という判断は直感的ですが、往々にして期待通りの効果が出ません。
フレデリック・ブルックスが1975年に著した『人月の神話』で定式化されたこの法則は、**「遅れているプロジェクトに人員を追加しても、さらに遅れる」**という観察に基づいています。理由は2つあります。
- 立ち上げコスト: 新しいメンバーがチームに貢献できるようになるまで、既存メンバーのサポートが必要となり、一時的に生産性が下がる
- 調整コストの増大: ②で述べたように、人数が増えるほどコミュニケーション経路は二乗で増加する
これは「人を増やしてはいけない」という意味ではありません。**「現在の生産性の問題が、人数不足に起因しているかどうかを先に診断すべき」**という意味です。
5つの観点で原因を特定し、手戻り・調整コスト・技術負債が改善された状態でチームを拡大すれば、追加メンバーはより早く貢献できます。逆に構造的な問題を解決しないまま人員を増やすと、新メンバーが既存の問題に引きずられて同じ症状を繰り返すことになります。
開発コストを経営指標に接続する
最後に、5つの観点を経営指標に紐付ける視点を提供します。「開発が遅い」を経営判断に使える形に変換することで、CTO不在でも技術課題を事業課題として議論できるようになります。
| 開発の問題 | 経営への影響 | 経営指標 |
|---|---|---|
| 手戻りコスト大 | リリース遅延・機会損失 | 機能リリースサイクル（月次） |
| 調整コスト大 | 開発人員の実効稼働率の低下 | 人件費あたりの機能リリース数 |
| 技術負債の利息 | 新機能追加速度の長期低下 | 機能追加にかかる平均工数の推移 |
| 過剰設計 | 無駄な開発投資 | 実際に使われた機能の割合 |
| インフラ費高騰 | 売上対比のインフラコスト増加 | 売上に対するインフラ費率 |
これらを月次・四半期で追跡することで、「開発コストが高い」という定性的な訴えを、「どの要因が・いつから・どの程度」という形で特定できるようになります。
まとめ
「開発が高い・遅い」を5つの観点で分解すると、着手点と優先順位が明確になります。
| 観点 | 主な発生要因 | 計測方法 | 着手コスト |
|---|---|---|---|
| ① 手戻りコスト | 要件の齟齬・受け入れ基準の欠如 | 差し戻しタスクの割合 | 低 |
| ② 調整コスト | チーム人数・意思決定権限の曖昧さ | 会議時間の割合 | 低 |
| ③ 技術負債の利息 | 過去の設計判断の蓄積 | PRサイクルタイムの推移 | 高 |
| ④ 過剰設計 | 早すぎる汎用化・未使用機能 | デッドコード比率 | 中 |
| ⑤ インフラ・ベンダー費 | 無秩序なSaaS導入・最適化不足 | コストダッシュボード | 低 |
人を増やす判断は、この診断の後に行います。原因が特定されれば、追加すべきリソースが「エンジニア」なのか「プロセス改善」なのか「技術的負債の返済」なのかも自ずと決まってきます。
技術負債の詳細な分類と評価方法については技術負債の正体とスタートアップで問題になるパターンを、技術負債の定義から投資家・経営者向けの再解釈については技術負債とは結局何か：投資家・経営者向けの再定義を参照ください。
開発生産性の診断やバリューアップ支援についてはTiedPro スタートアップ向けサービス、またはお問い合わせからご相談ください。
よくある質問
Q. 5つの観点のうち、最初に確認すべきものはどれですか？
手戻りコスト（①）から始めることを推奨します。計測が比較的容易で、改善効果が早く出やすいです。まずエンジニアに「先月、一度完成させたのに作り直した機能はありましたか？」と聞いてみることから始められます。
Q. 技術負債の返済にはどのくらいの時間がかかりますか？
範囲と種類によります。局所化された負債であれば、開発リソースの15〜20%を3〜6ヶ月投じれば改善できるケースが多いです。全体設計に広がった構造的な負債は1〜2年の継続的な取り組みが必要になることもあります。技術負債の詳細評価については技術負債の正体とスタートアップで問題になるパターンを参照ください。
Q. ブルックスの法則に例外はありますか？
あります。「タスクが完全に分割可能で、並行処理できる」場合は人員増加が効果的です。例えば、独立した機能モジュールの開発を並行して進める場合や、技術スタックを分けてチームを分離できる場合がこれに当たります。問題は、多くの開発作業がこの「完全な分割可能性」を満たさない点にあります。