フェーズ別、開発の人数と外部比率

開発の人数について相談を受けるとき、最初に確認するのは事業の規模ではなく、今どのフェーズにいるかです。同じ売上規模でも、まだ作るものを探している会社と、作るものが定まって伸ばしている会社では、必要な人数も、外部に頼むべき範囲も違います。

本記事では、フェーズごとの人数の目安と、採用と発注のどちらを先に選ぶかの判断を整理します。役割の洗い出し方は少人数開発チームの体制設計、発注先の選び方は開発パートナーの選び方で扱っているため、本記事はフェーズ軸に絞ります。

人数は「判断の量」で決まる

開発の人数を決めるとき、作業量から逆算しようとすると、たいてい多すぎる数字が出ます。作業は分割すればいくらでも増えるからです。

現実的なのは、そのフェーズで必要な「判断の量」から考える方法です。判断とは、何を作らないか、どの技術を選ぶか、どこまでの品質で出すか、といった、あとから変更しづらい決定を指します。

判断の量が少ないフェーズでは、人数も少なくて済みます。判断の量が増えるのは、扱う顧客の種類が増えたとき、同時に走る施策が増えたとき、そして社内で役割が分かれたときです。

フェーズごとの目安

以下は目安であり、事業の内容によって大きく変わります。

プレシードで0名がありうるのは、この段階の多くがコードを必要としないためです。作らない期間に開発者を雇うと、作る仕事を探すことになります。

採用が先か、発注が先か

この判断は、次の一点で分かれます。

その役割は、一年後も必要か。

必要なら採用、そうでないなら発注が基本です。具体的には次のように分かれます。

採用が向くもの

• プロダクトの方向を決める判断
• 顧客の業務を理解したうえでの設計
• 継続的に触り続ける中心部分の開発
• 技術的な選択の責任

発注が向くもの

• 範囲が明確で、終わりがある作業
• 専門性が高く、常時は必要でない領域（インフラの初期構築、デザイン、特定の連携の実装）
• 一時的に量を増やしたい局面
• 社内にない知見を短期間で取り込みたい場合

判断と作業を分けるのがこの整理の要点です。作業は外に出せますが、判断を外に出し続けると、社内に根拠が蓄積しません。

採用が決まらないときの現実的な選択

スタートアップの採用は、計画どおりには進みません。最初のエンジニアを採ろうとして半年が経つ、という状況は珍しくありません。

このとき選べるのは、次の三つの組み合わせです。

1. 判断だけを確保する。技術顧問のような形で、選択と設計の妥当性を見てもらう関与を確保します。実装は外部に出しつつ、判断の場に社内の人が同席する形にします。この選択肢は技術顧問・外部CTOという選択肢で詳しく扱っています
2. 作る範囲を減らす。人が足りないことを、作るものを減らす理由として使います。フェーズに照らして本当に必要な範囲まで絞れば、必要な人数も下がります
3. 採用条件を見直す。求める経験の幅を狭め、その分を外部で補う設計に変えます

避けたいのは、採用が決まらないまま発注量だけを増やし、社内に誰も全体を把握していない状態が固定されることです。

比率を変える節目

外部比率は、下げること自体が目的ではありません。判断が社内にあり、資産が手元にあるなら、外部を使い続ける形も成立します。

それでも、比率を見直したほうがよい節目はあります。

顧客が増え、運用の割り込みが日常になったとき。運用の対応を外部に依存すると、対応の速度が契約の形に縛られます。この時期に社内の受け皿を作ります。

同時に走る施策が増えたとき。一つの施策を順に進める間は外部中心でも回りますが、複数が並行すると、優先順位の判断が頻繁に発生します。判断の頻度が上がると、社内に人がいないほうがコストになります。

引き継ぎに時間がかかると感じ始めたとき。説明のたびに背景から話す必要があるなら、その領域は社内に寄せる時期です。

資金調達の準備に入るとき。ソースコードと資料の帰属、体制の説明が確認対象になります。準備の全体像は資金調達前に整えておきたい準備にまとめています。

移行の具体的な進め方は開発の内製化ロードマップで扱っています。

比率より先に確認すること

人数と比率の議論に入る前に、次の三つが手元にあるかを確認してください。比率がどうであれ、これらがないと選択肢が狭まります。

• ソースコードと、その権利が自社に帰属していること
• 環境の構築手順と、外部サービスのアカウント情報
• 設計の背景と、決定の経緯が分かる記録

これらが揃っていれば、外部比率が高くても、必要になったときに社内へ移せます。逆に、比率が低くても、この三つがなければ引き継ぎで詰まります。契約上の帰属の扱いについては、個別の事案は専門家にご確認ください。

人数を増やす前に見るもの

最後に、人を増やす判断の直前に確認したい点を挙げます。

• 今、開発が滞っている原因は人数か、それとも判断の詰まりか
• 増えた人が最初の変更を出すまでに何日かかるか
• その状態で増員したとき、既存メンバーの時間がどれだけ教育に移るか

二つ目と三つ目に不安があるなら、増員より先に受け入れ環境を整えるほうが結果が出ます。この観点は調達後に返す技術的負債の順番とも重なります。

体制の設計や、採用と発注の組み合わせについては、開発チーム体制構築・内製化支援やWebシステム開発のページとあわせてお問い合わせからご相談ください。打ち合わせはオンラインで全国対応しています。

本記事は一般的な情報であり、個別の事案は専門家にご確認ください。