シード〜シリーズBまで、フェーズ別スタートアップの働き方
フリーランスエンジニア｜エンジニア歴14年｜正社員 × フリーランス × 技術顧問
「スタートアップで働きたい」と思ったとき、多くの人が見落としていることがあります。
それは、スタートアップのフェーズによって、開発の環境もエンジニアに求められるものもまったく違うということ。
「シード期」のスタートアップと「シリーズB」のスタートアップでは、チーム規模も、技術スタックも、開発の進め方も、日常の雰囲気も異なります。同じ「スタートアップ」という言葉でくくるのは乱暴なくらい、別の世界です。
この記事では、各資金調達フェーズごとに、エンジニアの働き方がどう変わるかを具体的に解説します。
スタートアップのフェーズとは
スタートアップは資金調達の段階によってフェーズが分けられます。フェーズが進むごとに、組織・プロダクト・開発体制が変化していきます。
| フェーズ | 調達額の目安 | 社員数の目安 | プロダクトの状態 |
|---|---|---|---|
| シード | 〜数千万円 | 2〜5人 | MVP開発中 or ローンチ直後 |
| シリーズA | 数千万〜数億円 | 10〜30人 | PMF達成 or 達成直前 |
| シリーズB | 数億〜数十億円 | 30〜80人 | グロースフェーズ |
※ 目安は業界・ビジネスモデルによって大きく異なります。
参考
PMF（Product-Market Fit）とは「プロダクトが市場のニーズに合致した状態」のこと。PMF前はプロダクトの方向性を模索する段階、PMF後はその方向性を信じてスケールさせる段階です。このPMFの前後で、開発の優先度もエンジニアに求められるものも大きく変わります。
シード期 ─ カオスの中で0→1を作る
開発環境の特徴
シード期は、スタートアップの最初期です。何もない状態からプロダクトを生み出すフェーズ。
典型的な開発体制：
- エンジニア1〜3名（うち1人がCTO）
- デザイナーは兼任か外注。PdMは創業者が兼務
- 技術スタックは「CTOの得意な技術」で決まる（スタートアップの技術スタックトレンドも参照）
- ドキュメントはほぼゼロ。Slackと口頭がすべて
- CI/CDは最低限か、手動デプロイ
- テストコードは後回し（または存在しない）
エンジニアに求められること
一言で言えば「何でもやる」ことです。
- フロントエンドもバックエンドもインフラも一人でやる
- デザインのラフスケッチから実装に落とし込む
- 「ユーザーインタビューの結果、機能Aは不要になった。代わりに機能Bを来週までに作りたい」に対応する
- プロダクトの方向性についてCEO・CTOと議論する
技術力はもちろん重要ですが、それ以上に不確実性への耐性が求められます。先週作った機能が今週ピボットで廃止されることもあります。「せっかく作ったのに」と落ち込む暇はありません。
シード期のリアル
良い面：
- プロダクトへの影響力が最大。自分のコードが直接ユーザーに届く
- 技術選定の自由度が高い。新しい技術にも挑戦しやすい
- 組織の創成期を体験できる。ストック・オプションの可能性も
- 「何でもやる」ので、短期間でスキルの幅が広がる
厳しい面：
- 一人に対する負荷が大きい。休むと開発が止まる
- プロダクトの方向性が頻繁に変わる。昨日のコードが今日不要になる
- 「ちゃんとした開発」をする余裕がない。技術的負債が高速で蓄積する
- 事業が軌道に乗る保証はない。突然のサービス終了リスク
ポイント
フリーランスとしてシード期の案件に入る場合、「開発」だけでなく「プロダクトの方向性を一緒に考える」姿勢が重要です。CTOは孤独です。技術的な判断を一緒に議論できる仲間を求めています。「技術顧問」に近い立ち位置で価値を発揮できると、長期的に信頼されます。
フリーランスがシード期に参画するケース
シード期のスタートアップがフリーランスエンジニアを採用するのは、主に以下のケースです。
- CTOが一人で開発していて、手が足りない
- CTOがビジネス寄りで、技術力の高いエンジニアが必要
- CTOの経験が浅く、技術的な判断を任せられるシニアが欲しい — シード期はCTO自身が若手エンジニアというケースも多く、設計やアーキテクチャの意思決定を一緒にできるベテランの存在は大きい（CTOがエンジニアのどこを見ているかはCTO視点の採用ポイントを参照）
- 特定の技術領域（インフラ、セキュリティ等）で専門家が欲しい
- 正社員を雇う資金はないが、プロダクト開発は急ぎたい
単価は比較的抑えめのことが多いですが、「プロダクトを一から作る」経験は代えがたいものがあります。
シリーズA ─ PMFを目指して走る
開発環境の特徴
シリーズAは、プロダクトが形になり始め、本格的に市場に投入するフェーズです。
典型的な開発体制：
- エンジニア5〜15名
- フロントエンド・バックエンドの分業が始まる
- 専任のPdMやデザイナーがジョイン
- Figmaのデザインからの実装フローが確立
- CI/CDが整備され、デプロイが自動化
- テストコードを書き始める（カバレッジはまだ低い）
- スプリントやスクラムなど、開発プロセスの導入が始まる
エンジニアに求められること
「スピードを保ちながら、品質を上げる」バランス感覚です。
シード期の「とにかく作る」から一段階進み、「持続可能な開発」への移行が始まります。開発プロセスやカルチャーの変化についてはスタートアップの開発文化も参考にしてください。しかし、まだPMF前であることも多く、ビジネスの方向転換は起こり得ます。
- 自分の専門領域で深い貢献をしつつ、必要に応じて他領域もカバーする
- コードレビューを通じてチームの技術レベルを底上げする
- シード期に蓄積した技術的負債の整理に着手する
- 新しく入るメンバーのオンボーディングをサポートする
シリーズAのリアル
良い面：
- チームが拡大し、専門性を活かしやすくなる
- 開発プロセスが整備され始め、働きやすくなる
- プロダクトが市場に受け入れられる瞬間（PMF）に立ち会える
- エンジニアの意見がプロダクトに反映されやすい
厳しい面：
- 「シード期のノリ」と「組織としての規律」の間で軋轢が生じやすい
- 急速なチーム拡大で、コミュニケーションコストが増加
- 技術的負債の返済と新機能開発の優先度で葛藤
- PMF達成のプレッシャーが強い
ポイント
シリーズAフェーズは、フリーランスエンジニアにとって最もバランスの良い参画タイミングかもしれません。チームがある程度整い、開発プロセスも存在するため、比較的スムーズにキャッチアップできます。一方で、まだ組織が小さいため、一人ひとりの影響力も大きいです。
シリーズB ─ スケールの壁を越える
開発環境の特徴
シリーズBは、PMFを達成し、本格的にグロースさせるフェーズです。ユーザー数・トラフィックの急増に対応しながら、組織も急拡大します。
典型的な開発体制：
- エンジニア15〜40名
- 複数のチーム（プロダクトチーム、プラットフォームチーム、SREなど）に分化
- テックリードやEM（Engineering Manager）のポジションが生まれる
- コーディング規約、アーキテクチャガイドラインが整備
- テストカバレッジの基準が設定される
- インシデント対応フローが確立
- 採用活動が本格化（面接官としての役割も）
エンジニアに求められること
「技術的な深さ」と「組織への貢献」の両方です。
シリーズBになると、「何でもやる」フェーズは終わり、専門性を武器にした貢献が求められます。
- 特定の技術領域（パフォーマンス最適化、セキュリティ、データ基盤など）で深い専門性を発揮する
- アーキテクチャレベルの設計・改善を推進する
- 技術的な意思決定にリーダーシップを発揮する
- ジュニアメンバーの育成やコードレビューの品質向上
- 技術的負債の計画的な返済
シリーズBのリアル
良い面：
- プロダクトの成長を実感できる（ユーザー数・売上の急拡大）
- 技術的に難易度の高い課題に取り組める（スケーリング、パフォーマンス）
- 専門性を深める環境が整っている
- 開発プロセスが成熟し、安定した働き方ができる
- エンジニアとしての市場価値が上がる実績を積める
厳しい面：
- 組織の急拡大に伴い、「スタートアップらしさ」が薄れてくる
- 意思決定のスピードが落ち始める（承認フローの増加）
- 大企業出身者が増え、カルチャーの衝突が起きやすい
- コードベースが大きくなり、全体像を把握するのが困難に
- 「もっと小さなチームで働きたい」という気持ちが出てくることも
参考
シリーズBのスタートアップは、フリーランスエンジニアの単価も高くなる傾向があります。資金調達でキャッシュに余裕があり、即戦力のシニアエンジニアを積極的に探しているためです。「すぐにインパクトを出せる」専門性があれば、高単価案件を獲得しやすいフェーズです。
フェーズ別比較まとめ
| 観点 | シード | シリーズA | シリーズB |
|---|---|---|---|
| チーム規模 | 2〜5人 | 5〜15人 | 15〜40人 |
| 求められるスキル | フルスタック、何でもやる | 専門性 + 周辺カバー | 深い専門性 |
| 開発プロセス | なし or 最低限 | 導入・整備中 | 成熟 |
| 技術的負債 | 高速で蓄積 | 整理に着手 | 計画的に返済 |
| 裁量の大きさ | 最大 | 大きい | 中〜大 |
| 不確実性 | 非常に高い | 高い | 中程度 |
| 案件単価 | 低〜中 | 中〜高 | 高 |
| ドキュメント | ほぼゼロ | 徐々に整備 | ガイドライン整備 |
自分に合ったフェーズを選ぶ
シード期が向いている人
- カオスを楽しめる人
- 「0→1」の開発が好きな人
- 一つのことに縛られず、何でもやりたい人
- プロダクトの方向性から関わりたい人
- 安定より刺激を求める人
シリーズAが向いている人
- スピードと品質のバランスを取るのが得意な人
- チーム開発が好きで、仕組みづくりにも興味がある人
- プロダクトの成長を近い距離で感じたい人
- 専門性を活かしつつ、幅も広げたい人
シリーズBが向いている人
- 特定の技術領域で深い専門性を持っている人
- 大規模なシステムの設計・運用に興味がある人
- 安定した環境で、技術に集中したい人
- メンタリングやリーダーシップに興味がある人
- 高単価を目指したい人
ポイント
「自分に合ったフェーズがわからない」という方は、まずシリーズA前後の案件から始めるのがおすすめです。ある程度の開発基盤が整っていて、かつスタートアップの雰囲気も十分に味わえるバランスの良いフェーズです。
フリーランスならフェーズを「渡り歩ける」
正社員としてスタートアップに入ると、その会社がフェーズを進む過程に付き合うことになります。もちろんそれも貴重な経験ですが、すべてのフェーズを体験するには何年もかかります。
フリーランスなら、異なるフェーズのスタートアップを意図的に選んで参画できます。
- シード期の案件で「0→1」の力を鍛える
- シリーズAの案件で「チーム開発」の経験を積む
- シリーズBの案件で「大規模アーキテクチャ」に挑戦する
これをキャリア戦略的に組み合わせることで、フルスタック × スタートアップ経験という希少価値の高いスキルセットを短期間で手に入れることができます。フリーランスとしてスタートアップ案件に参画するメリットと注意点はスタートアップにフリーランスで参画するメリットと注意点で詳しく解説しています。
フェーズを見極めるための質問
エージェントや面談で、案件のフェーズを正確に把握するために聞いておくべき質問をまとめます。
| 質問 | 意図 |
|---|---|
| 「直近の資金調達ラウンドは？」 | フェーズの直接確認 |
| 「エンジニアは何名ですか？」 | チーム規模でフェーズを推測 |
| 「プロダクトのローンチはいつですか？」 | MVP前かPMF後かを確認 |
| 「開発プロセス（スプリントなど）はありますか？」 | 組織の成熟度を確認 |
| 「テストコードのカバレッジはどのくらいですか？」 | 技術的な成熟度を確認 |
| 「デザイナーやPdMは専任ですか？」 | 役割分担の状況を確認 |
まとめ
スタートアップのフェーズ別の働き方を整理しました。
- シード期：何でもやるフルスタック。カオスだが、プロダクトへの影響力は最大
- シリーズA：専門性とカバー力のバランス。チーム開発と仕組みづくり
- シリーズB：深い専門性でスケールに貢献。安定した環境で高単価
「スタートアップ」と一口に言っても、フェーズによって求められるものは大きく異なります。自分のスキルセットとキャリアの方向性に合ったフェーズを選ぶことで、最大限のパフォーマンスを発揮し、市場価値の高い経験を効率的に積むことができます。
フリーランスエージェントに登録すれば、各案件のフェーズや開発体制も含めて相談できます。「シリーズAくらいのスタートアップ案件を探している」と伝えてみてください。あなたの経験に合った案件を提案してもらえるはずです。
フリーランスエンジニア｜エンジニア歴14年・100超のプロジェクト経験｜Next.js / Laravel / AWS / GCP / Firebase / Supabase / OpenTelemetry
正社員 × フリーランス × 技術顧問のハイブリッド型で活動中。 得意領域はアプリケーション設計と、技術 × 戦略を一気通貫で回す 0→1 の立ち上げ。1→10 のブラッシュアップも数多く経験してきた。 営業出身からエンジニアに転身し、SES・受託・自社サービス・スタートアップ、合同会社の経営まで全部経験。省庁・金融・医療など業界も選ばず、14年で100超のプロジェクトに関わっている。エンジニア採用の経験もあり、採用する側の視点も持っている。