スタートアップの開発体制は、フェーズごとに組み替える

事業案を説明できる創業者はいます。開発会社から見積もりも届きました。業務委託のエンジニアにも声をかけていますが、誰を最初のチームへ入れるべきか決められません。

スタートアップの開発体制は、最初の採用人数から考えないほうがよいと僕は思います。今の段階で答えるべき事業の問いを決め、問いに必要な役割だけを置き、次の段階へ進む条件まで先に書きます。

アイデア検証では外部の手を小さく借り、顧客の反応が繰り返し確認できたら知識を社内へ寄せます。利用者と運用量が増えた後は、担当領域と緊急時の動きを分けます。最初から完成した組織図を作る必要はありません。

スタートアップの開発体制は、未確定な問いから決めます

創業期に先に置くべきなのは、肩書きではなく責任です。創業メンバーは、誰のどの困りごとを解くか、何を作らないか、予算をどこまで使うかを決めます。顧客との会話や事業の優先順位まで外部へ渡すと、動く画面はできても、次に直す理由が社内へ残りません。

開発会社や業務委託のエンジニアには、決めた検証を形にする仕事を任せられます。技術選定や見積もりを評価できる人がいなければ、外部CTOが選択肢と危険を整理できます。ただし、予算を承認し、顧客へ出す範囲を決める役目は創業メンバーに残します。

技術そのものが競争優位になる事業では、外部の部分稼働だけでは足りません。独自の研究開発や日々の技術判断が事業価値を左右するなら、技術を担う共同創業者が経営にも参加する必要があります。CTO代行を社外から技術責任者の機能を借りる役割として整理した記事も確認し、外部CTOで足りる範囲と、共同創業者が担う範囲を分けてください。

一方で、業務知識、販売網、顧客との関係が強みであり、ソフトウェアが提供手段になる事業もあります。実装を外部へ頼んでも、創業メンバーが顧客課題と優先順位を持ち続けるなら、検証を始められます。外注か内製かを会社全体で一度だけ決めるのではなく、今月の問いごとに任せ方を変えます。

アイデア検証では、外注と業務委託を小さく使います

アイデア検証で知りたいのは、完成品を作れるかではありません。想定した顧客が課題を抱えているか、提示した流れを使うか、対価を払う理由があるかを確かめます。確認したい内容によって、紙の画面案、操作できる試作品、手作業を含むサービスのどれを作るかが変わります。

外注は、範囲を切った試作品や専門作業に向きます。業務委託のエンジニアは、創業メンバーと短い周期で会話しながら修正する仕事に向きます。どちらを選んでも、顧客へ聞く質問、合格と中止の条件、結果を決める人は社内で指定します。

発注書や業務範囲には、作る画面だけでなく、検証後に捨てる部分、追加依頼の扱い、終了時に返す資料とアカウントを書きます。会社名義のリポジトリとクラウド契約を用意し、外部メンバーには必要な範囲だけアクセスを付けます。ドメイン、請求先、本番環境の管理者が委託先だけになってはいけません。

納品時には、起動手順、使った外部サービス、未実装の機能、手作業で補った処理を受け取ります。コード行数やコミット数では評価しません。決めた検証を再現できるか、未確認の条件が文章で残っているかを見ます。

試作品を本番へ流用する前提も外します。試作の目的と残す成果物は、プロトタイプ開発を外注する前の決め方で具体的に書きました。検証用の近道と、顧客データを預かる運用は、同じ完成条件では扱えません。

PMFへ近づいたら、スタートアップの開発体制を社内へ寄せます

顧客から同じ要望が繰り返し届き、利用後の行動や支払いに一定の傾向が見え始めたら、開発知識を社内へ移す時期です。PMFを一つの数字で宣言する必要はありません。利用状況の画面、請求の記録、解約理由、問い合わせ履歴を並べ、同じ顧客層が同じ価値を選んでいるかを確認します。

社内へ最初に置くエンジニアには、実装だけでなく、顧客の声を設計へ反映し、運用中の不具合を追い、外部メンバーの成果物を受け取る役割を任せます。創業メンバーは事業の優先順位を決め、社内エンジニアは技術上の推奨を作ります。外部の開発会社や業務委託は、足りない実装量や専門領域を補います。

採用前に毎週の技術判断が増えた場合は、外部CTOを移行役として置く方法もあります。開発会社の提案を比較し、採用候補者の技術面を確認し、判断理由を社内の文書へ残します。CTOの業務委託で採用までの空白を埋める方法で扱ったように、外部CTOへ最終決裁まで渡さず、正社員が入った後に役割を縮められる形にします。

内製化は、外部メンバーを一斉に外す作業ではありません。リポジトリの管理、リリース手順、障害時の連絡、技術選定の理由を順番に社内へ移します。社内担当者が自分の端末で環境を作り、外部メンバーなしで一度リリースできれば、引き継ぎの不足が見えます。

採用を始める条件も言葉にします。たとえば、顧客要望の優先順位は決まるのに技術上の回答待ちで着手できない状態や、運用対応が増えて外部の契約時間では追えない状態です。求人票を先に書くより、毎週止まっている仕事を集めたほうが、最初の一人へ任せる範囲を説明できます。

スケール期には、スタートアップの開発体制を担当領域ごとに分けます

利用者、機能、エンジニアが増えると、一人の技術責任者が全ての変更を確認する形は詰まります。役職を増やす前に、認証、請求、顧客データ、基盤の各領域について、変更を承認する人と障害時に最初に連絡を受ける人を決めます。担当者の名前は、組織図だけでなく運用手順にも書きます。

本番へのアクセスも棚卸しします。リポジトリの管理者、クラウドの請求管理者、本番データへ触れられる人、リリースを承認できる人を画面で確認します。退職者や契約終了者のアカウントが残っていれば削除し、緊急用アカウントの保管場所と利用記録を決めます。

外部会社の役割は、開発全体を預ける形から、専門領域や一時的な増員へ変えます。社内チームが設計と受け入れを担い、外部メンバーが実装やレビューを補います。重要な運用手順や設計理由が外部のチャットだけに残らないよう、社内の文書と課題管理へ移します。

開発チームの評価をPR数やコミット数だけで決めても、顧客へ価値が届いたかは分かりません。リリースの頻度、変更後の不具合、復旧までの時間を見ながら、継続利用、解約理由、問い合わせも同じ期間で確認します。技術の数字と事業の数字を並べ、速く作った機能が実際に使われたかを経営会議で見ます。

一枚の設計図で、次に採る人を決めます

明日開く資料は、採用媒体ではなく開発体制の設計図です。設計図の上段に、現在のフェーズ、次に確かめる事業の問い、結果を決める日を書きます。アイデア検証なら顧客の行動、PMF前後なら継続利用や支払い、スケール期なら運用負荷と顧客への影響を置きます。

中段には、顧客課題の優先順位を決める人、技術案を作る人、実装する人、リリースを承認する人を書きます。人名が入らない欄は、肩書きではなく仕事が空いている箇所です。空欄の仕事が短期間で終わるなら外注、社内と継続して会話するなら業務委託、事業の競争力を長く背負うなら創業メンバーか正社員の候補になります。

下段には、リポジトリ、クラウド、ドメイン、仕様書、問い合わせ履歴の保管場所と管理者を書きます。外部メンバーしか開けない場所が残る場合は、次の発注や採用より先に社内アカウントへ移します。最後に、体制を見直す条件と確認日を入れます。

開発体制は人数表ではありません。今の問いへ答える人と、次の段階へ知識を渡す経路を示す資料です。設計図の空欄が見えた後なら、外注先へ渡す範囲、業務委託へ求める稼働、最初に採る人の役割を同じ基準で選べます。

次の経営会議では、最新の見積書、リポジトリのメンバー画面、クラウドの管理者画面、利用状況と解約理由を設計図の横へ並べてください。実装だけが空いているなら外部へ範囲を切って頼めます。顧客の優先順位や技術の推奨を作る人まで空いているなら、発注を急がず、創業メンバーか社内責任者を先に決めるべきです。