開発が遅いとき、エンジニアを増やす前に確認すべきこと
「開発が遅いから、エンジニアを増やそう」——事業責任者やCTOがまず思いつく打ち手ですが、これは半分正しく、半分は罠です。原因を特定しないまま人を増やすと、コストが増えるだけでスピードは変わらない、あるいはさらに遅くなることすらあります。
この記事では、増員の前にまず確認すべき「開発が遅い本当の原因」を、それぞれの見分け方・具体的なサイン・増員前チェックリスト・よくある失敗パターンとあわせて、発注者・事業責任者の視点で整理します。
なぜ「増員」は最初の打ち手として危険なのか
ソフトウェア開発にはブルックスの法則という有名な経験則があります。「遅れているプロジェクトに人員を追加すると、さらに遅れる」というものです。
この機序は3段階に分解できます。
- 教育コストの発生: 新しく入った人は既存のコードベース・仕様・意思決定の経緯を理解するまで生産性がほぼゼロです。一般に、複雑な業務システムでは新メンバーが「一人で戦力になる」まで1〜3ヶ月かかると言われます。
- 既存メンバーの時間の収奪: その教育コストは、何もないところから湧くのではなく、既存メンバーの実装時間から奪われます。つまり増員した最初の1〜2ヶ月は、チーム全体の実効生産性がむしろ下がることが珍しくありません。
- コミュニケーションパスの組み合わせ的増加: チームの人数が増えると、情報共有の経路は n(n-1)/2 で増えます。5人のチームなら経路は10通りですが、10人になると45通りです。会議・レビュー・すり合わせのコストが増え、1人あたりの実装時間はむしろ減ることがあります。
つまり「遅い」という症状に対して「人を増やす」という処方箋が効くのは、原因が単純に人手不足である場合に限られます。まずはそこを見極める必要があります。
増員前に確認すべき6つのチェックポイント
それぞれ「どう見分けるか」の具体的なサインとあわせて見ていきます。
1. 要件が曖昧なまま実装に入っていないか
見分けるサイン: エンジニアから「これで合っていますか」という確認が1つの機能につき3回以上発生する。実装したものが「思っていたのと違う」という理由でやり直しになる頻度が月に1回以上ある。仕様書やチケットに「詳細は実装しながら決める」という記述が常態化している。
「何を作るか」が固まらないまま実装を始めると、手戻りが発生し続けます。人を増やしても、曖昧な仕様を解釈する人数が増えるだけで、認識のズレはむしろ拡大します。要件定義の設計に問題があるチームに人を足すと、「間違った理解」を持つ人が増えるだけで、手戻りの総量はむしろ増加します。
2. 意思決定が遅く、エンジニアが手を止めていないか
見分けるサイン: Slackやチケットで「この仕様、どちらにしますか」という質問への回答に2営業日以上かかることが常態化している。エンジニアが「保留」「要確認」というステータスのタスクを複数抱えている。決裁者が会議に出られず、承認が持ち越しになる。
開発速度のボトルネックが実装力ではなく意思決定のスループットにある場合、増員は無意味です。決裁者が忙しくて反応できない、判断基準が定まっていない、承認フローが多段階すぎる、などが典型的な原因です。人を増やしても、意思決定待ちのタスクが増えるだけで、手が止まる人数が増えるという逆効果すら起こります。
3. レビューやデプロイが滞留していないか
見分けるサイン: プルリクエストがオープンされてからマージされるまでの平均日数が2〜3日を超えている。レビュー待ち・QA待ち・リリース承認待ちのタスクが常に一定数溜まっている。「コードは書き終わっているのに世に出ていない」機能が複数存在する。
この場合ボトルネックは「書く速度」ではなく「通す速度」です。人を増やすと書かれるコードは増えますが、レビュー待ちの行列がさらに伸びるだけということもあります。レビュアーの数がボトルネックなのに実装者を増やす、というミスマッチはよくある失敗パターンです。CI/CDのパイプライン自体が遅くフィードバックが遅延しているケースもあり、その場合はCI/CDパイプラインが遅い時の改善手順が参考になります。
4. 技術的負債がスピードを削っていないか
見分けるサイン: 「小さい修正のはずが想定より時間がかかった」という報告が頻発する。1つの変更が複数のファイル・複数のモジュールに波及する。自動テストが薄く、変更のたびに手動確認の工数が発生する。「このコードを触れるのは1人しかいない」という属人化した箇所が存在する。
初期に速く作るために積んだ負債(テスト不足、密結合な設計、ドキュメント不在)は、時間が経つほど「1つの変更に触れる範囲」を広げ、見積もりの何倍もの時間を食います。新しいエンジニアが入っても、負債の多いコードベースでは理解に時間がかかり、むしろ既存メンバーがオンボーディングに時間を取られて全体の速度が落ちることもあります。テストが不十分なまま増員すると、レビューでの人力確認コストも比例して増え、負債返済より前に人が増えた分だけ負債が積み上がる、という悪循環に陥りがちです。テストが薄いコードベースの立て直し方はテストのないシステムを安全にリファクタリングする方法で扱っています。
5. 優先順位が定まっているか
見分けるサイン: 同時に着手中の機能・タスクの数が、エンジニアの人数より明らかに多い。「今週は何を最優先で終わらせるか」に即答できない。数週間前から「進行中」のままステータスが変わらないタスクがある。
「あれもこれも並行で」という状態では、どのタスクも中途半端に進み、完成に近いものがありません。マルチタスクはコンテキストスイッチのコストを生み、1人あたりの実効生産性を下げます。増員する前に、今動いているタスクの数を減らせないかを確認する価値があります。優先順位が定まらない組織に人を足すと、並行タスクの数がさらに増え、「手をつけているが終わらないもの」の総量が拡大するだけになりがちです。
6. コミュニケーション構造がボトルネックになっていないか
見分けるサイン: 「その仕様、〇〇さんに聞かないと分からない」という発言が頻出する。仕様や合意事項がドキュメントではなく口頭・DM・会議の記憶にしか残っていない。特定の1人が休むと開発が止まる箇所がある。
特定の1人しか把握していない仕様、口頭でしか共有されていない決定事項、Slackの奥深くに埋もれた合意——これらは「その人が対応するまで誰も動けない」状態を作ります。人を増やすと、この属人化されたボトルネックへの依存はむしろ強まることがあります。新メンバーは結局その1人に質問を集中させることになり、ボトルネック本人の負荷はさらに増します。
増員が正解なケース/そうでないケースの判断基準
上記6つを確認した結果は、大きく2つのパターンに分かれます。
増員が正解なケース: 要件は明確で手戻りが少ない、意思決定は数日以内に下りる、レビューは詰まっていない、技術的負債は管理されテストも一定水準ある、優先順位は明確で並行タスクは絞られている——それでもタスク量に対して人数が足りず、キャパシティの天井にぶつかっている状態。この場合、増員は素直に効きます。
増員が正解でないケース: 上記6項目のいずれか1つでも明確に問題があり、かつそれが「人を増やしても解消しない」性質の問題である場合。特に、意思決定の遅さ・レビュー滞留・コミュニケーション構造の3つは、人を増やすほど悪化する傾向が強い項目です。要件の曖昧さと技術的負債は、増員しても中立〜悪化程度で済むこともありますが、根本解決にはなりません。
判断基準をシンプルに言うと、「今のチームの手が、外部要因(承認待ち・レビュー待ち・仕様待ち)ではなく、純粋な作業量で埋まっているか」です。手帳が会議と待ち時間で埋まっているチームに人を足しても、会議と待ち時間が増えるだけです。
増員前チェックリスト
意思決定の前に、以下を実際に数値・事実で確認してください。
- [ ] 直近1〜2ヶ月の手戻り(仕様誤解によるやり直し)は何件あったか
- [ ] 「これで合っていますか」の確認往復は1機能あたり平均何回か
- [ ] 仕様確認・承認の平均リードタイムは何営業日か
- [ ] プルリクエストのオープンからマージまでの平均日数は何日か
- [ ] 「コードは書けているがリリースされていない」機能がいくつあるか
- [ ] 自動テストのカバレッジ・実行頻度はどの程度か
- [ ] 同時進行中のタスク数はエンジニア人数の何倍か
- [ ] 「あの人しか分からない」仕様・処理はいくつあるか
- [ ] 上記のいずれにも問題がなく、単純にタスク量 > キャパシティになっているか
最後の項目にYesで答えられて初めて、増員は自信を持って選べる打ち手になります。
失敗パターンの具体例
パターンA: 意思決定待ちのチームに増員した結果
決裁者への確認待ちで1機能あたり平均1週間止まっていたチームに、エンジニアを2人追加。結果、着手中タスクの数は増えたが、決裁者の処理能力は変わらないため、確認待ちの行列がさらに伸び、リリース速度は改善しなかった。むしろ新メンバーの1on1やオンボーディング対応で決裁者の時間がさらに逼迫した。
パターンA': 「AIで解決」に飛びついて別の停滞を招いた結果
意思決定待ちが原因と気づかず、「AIツールを導入すれば速くなるはず」と生成AI活用に予算を投じたが、ボトルネックは実装速度ではなく承認プロセスだったため体感速度は変わらなかった。原因の切り分けをせずに打ち手だけ変えても、増員と同じ失敗を繰り返すことになる。
パターンB: 技術的負債を放置したまま増員した結果
密結合な設計で1つの変更が5ファイルに波及するコードベースに、新メンバー3人を追加。オンボーディングに既存メンバー2人がかかりきりになり、3ヶ月間、実質的な新機能開発が停滞。負債返済を先にやっていれば、既存3人だけでも速度は改善していた可能性が高い。
パターンC: レビュー体制を変えずに実装者だけ増やした結果
レビュアーがCTO1人だけの体制で、実装エンジニアを倍にした。書かれるコードの量は増えたが、レビュー待ちのプルリクエストが積み上がり、CTOのレビュー時間が開発全体のボトルネックとして顕在化。結果的にレビュー体制の整備(レビュアー追加・レビュー基準の明文化)が先に必要だった。
発注者ができる最初の一歩
上記のチェックは、社内だけで行うと「自分たちのプロセスの問題」を客観的に見づらいという難しさがあります。特に開発チームの内部にいると、レビュー滞留や意思決定の遅さは「いつものこと」として見過ごされがちです。また、既存プロダクトの改善であれば、着手前に確認すべき基本項目を既存プロダクト改善の着手前チェックにまとめています。
外部の目で開発プロセス全体を棚卸しし、ボトルネックがどこにあるかを特定することは、増員よりも先に着手できる打ち手です。torcheees の要件整理・開発診断では、要件定義・意思決定フロー・レビュー体制・技術的負債の状況を確認し、「本当に人を増やすべきか、それとも別の打ち手が先か」を整理します。
まとめ
- 開発が遅い原因は人手不足とは限らず、要件の曖昧さ・意思決定の遅さ・レビュー滞留・技術的負債・優先順位の欠如・コミュニケーション構造など複数の可能性がある。それぞれに「確認の往復回数」「承認のリードタイム」「PRのマージまでの日数」など具体的な見分け方のサインがある。
- ブルックスの法則が示す通り、原因を特定しないまま増員すると、教育コストとコミュニケーションコストが増え、逆に遅くなることがある。特に意思決定の遅さ・レビュー滞留・属人化は、増員するほど悪化しやすい。
- 増員が正解かどうかは、「純粋な作業量で手が埋まっているか、外部要因の待ち時間で埋まっているか」で見極められる。増員前チェックリストで事実を確認し、切り分けを済ませてから判断するのが最初の一歩になる。
「開発が遅いが、原因が人手不足なのか別の要因なのか判断がつかない」という段階こそ、外部の視点が役立ちます。torcheees では開発プロセスの診断からお気軽にご相談ください。