「TypeScript と React はチュートリアルや個人開発で一通り書けるようになった。だけど、副業エージェントに登録ページを開くと『実務経験3年以上』『Next.js での開発実績』という文言が並んでいて、自分が本当に応募できるレベルなのか分からない」——本業のエンジニア経験が2〜4年で、副業に踏み出そうとしている方の多くが、ここで立ち止まっています。
学習教材を買い足してもいいし、新しいフレームワークを触ってみてもいい。けれど「次にどの技術へ投資するのが副業参入に直結するのか」という判断基準がないまま手を動かすと、半年たっても案件応募に踏み切れない、ということが起こりがちです。
副業案件を取るために本当に必要なのは、「実務経験3年」という文字面ではなく、その文言の裏側でクライアントが何を確かめたいのかを理解し、その項目に応えられる具体的な根拠を揃えることです。チーム開発の経験、TypeScript の型を活かした設計力、React のコンポーネント設計、そしてそれらを証明できるポートフォリオ。要素を分解すれば、実務経験が浅くてもポートフォリオで補える領域が見えてきます。
本記事では、TypeScript・Reactで副業案件を取るまでのスキルアップを「案件参入ラインの可視化」「案件タイプ別の必要スキルマップ」「12〜24週間の週次学習ロードマップ」「評価されるポートフォリオの作り方」「月20〜30万円の複業スタイルへの移行戦略」の5段階に分けて解説します。読み終えた直後から、今週の学習タスクを1つに絞り込める状態を目指します。
TypeScript・Reactで副業案件を取れる最低レベルとは
副業エージェントの案件票に並ぶ「実務経験3年以上」という文言は、検索者を最初に止める壁になります。けれど、この文言を文字通りに受け取って学習を諦めるのは早計です。まず、案件参入ラインを判断するための具体的な軸を整理しましょう。
案件票の「実務経験3年以上」を文字通り受け取らない理由
案件票に書かれている「実務経験3年以上」は、多くの場合「3年分の自社開発経験」を厳密に意味しているわけではありません。発注側が確かめたいのは「3年という時間そのもの」ではなく、その期間で身につく以下の3点です。
- チームの開発フローに合わせて自走できるか(コードレビュー・PR運用・進捗共有が成立するか)
- 既存コードベースを読んで影響範囲を把握し、壊さずに改修できるか
- 仕様の曖昧さや想定外の挙動に直面した際、自分で問題を切り分けられるか
逆に言えば、実務経験が2〜3年でも、これら3点を別の形で示せれば応募の土俵に乗ります。GitHub の OSS コントリビュートで他者のコードベースに PR を出した経験、個人プロダクトで実ユーザーからのフィードバックを受けて改修を回した経験、技術ブログで実装上の判断を言語化した経験は、いずれも「3年」の代替材料として機能します。
副業参入ラインを判断する4軸
「自分は今、副業案件に応募できるレベルか」を採点するために、次の4軸で現在地を見立ててください。
- チーム開発経験: Git/GitHub での PR・コードレビューの往復経験、Issue ベースでの作業管理、複数人のコードベースでの開発経験
- TypeScript の型システム理解:
interface/typeの使い分け、Generics、ユーティリティ型(Partial・Pick・Omit等)、unknownとanyの使い分け、型ガードの実装 - React のコンポーネント設計力: 状態を持つコンポーネントと持たないコンポーネントの分離、props 設計、カスタムフックの抽出、再レンダリング最適化(
useMemo・useCallback・memoの使い所) - ポートフォリオで証明できる成果物: 公開済みの個人プロダクトまたは OSS コントリビュート実績、整備された GitHub リポジトリ(README・テスト・CI)、技術発信の蓄積
実務経験が浅くても、4軸のうち2〜3軸を高い水準で示せれば、参入難易度の低い案件(既存 SPA の改修案件・小規模な機能追加案件)には十分に応募できます。
自分の現在地をチェックするセルフ診断リスト
以下のチェックリストで、いま自分がどの軸を埋められているか把握してください。
- 個人 GitHub に Star 3 以上、または直近 3 ヶ月で 30 コミット以上ある公開リポジトリがある
- TypeScript で書いた React アプリを、
anyを使わずに型エラーなくビルドできる -
useEffectの依存配列で警告が出る理由を説明でき、適切に依存を渡せる - PR を受けて修正対応した経験がある(仕事・OSS・チーム個人開発いずれでも可)
- 自分の書いたコードに対してテストコード(Jest・Vitest・React Testing Library のいずれか)を最低1つ書いた経験がある
- Vercel・Netlify などにデプロイした個人プロダクトが1つ以上ある
チェックが3つ以下の場合は、まだ学習フェーズです。本記事の中盤で示すロードマップのフェーズ1から着手するのが現実的です。チェックが4〜5つなら案件応募の準備段階に入れます。6つすべて埋まっていれば、すでに参入ラインに到達しているので、最後のセクションで紹介するポートフォリオの仕上げに進んでください。
フロントエンド副業案件の種類と必要スキルマップ
副業案件は、すべて高い実務経験を要求するわけではありません。案件のタイプによって、必要スキルも参入難易度も大きく異なります。自分のスキルレベルに合った案件タイプから入ることで、最初の案件獲得までの距離を縮められます。
案件4類型の比較表
フロントエンド副業案件は、おおよそ次の4類型に整理できます。
案件類型 | 内容 | 時給目安 | 週稼働目安 | 必要スキル | 参入難易度 |
|---|---|---|---|---|---|
Web制作系 | HTMLテンプレ修正、WordPress テーマ調整、LP コーディング | 2,000〜3,500円 | 週1〜2日 | HTML/CSS、jQuery、WordPress 基礎 | 低 |
SPA改修系 | 既存 React アプリの機能追加・バグ修正、UI 改善 | 3,000〜5,000円 | 週1〜2日 | React、TypeScript 基礎、Git 運用 | 中 |
新規開発系 | Next.js による新規 SaaS 開発、要件定義からの実装 | 5,000〜8,000円 | 週2〜3日 | Next.js、状態管理、API 設計、テスト、CI/CD | 高 |
技術顧問・レビュー系 | コードレビュー、設計相談、技術選定支援 | 6,000〜15,000円 | 週0.5〜1日 | アーキテクチャ設計、複数フレームワーク経験、技術ブログ等の発信実績 | 最高 |
時給目安は2026年時点の各エージェント公開情報(【2026年】TypeScript案件の年収レポート、Reactの副業事情!週1-3案件の探し方等)を参考にしています。実際には案件単位で大きく変動するため、応募時には個別に確認してください。なお、技術顧問・レビュー系(6,000〜15,000円)はスキルセット・発注規模によって変動幅が特に大きく、表内の他類型と比べて個人差が大きい点にご注意ください。
経験年数・スキル別の推奨参入類型
セルフ診断のチェック数と、推奨される参入類型の対応関係は以下の通りです。
- チェック0〜2個: まずは学習フェーズ。副業応募の前に基礎固めを優先する
- チェック3〜4個: SPA改修系から狙う。既存コードベースを読む練習にもなり、最初の実績作りに最適
- チェック5〜6個: SPA改修系と並行して新規開発系にも応募可能。Next.js の経験があれば一気に選択肢が広がる
- 実務経験5年以上+技術発信あり: 技術顧問・レビュー系も視野に入る
学習中のエンジニアが「いきなり高単価の Next.js 新規開発案件」を狙うと、書類選考で落ち続けて自信を失うパターンがよくあります。最初は SPA改修系で1つ実績を作り、それをポートフォリオに加えてから新規開発系に挑む、という段階を踏むのが結果的に近道です。
単価相場の概観
2026年時点で、React・TypeScript の副業案件の時給は3,000〜5,000円がボリュームゾーン、月額換算では週2日稼働で20〜45万円が目安です。実務経験3年以上 + Next.js 経験ありで時給5,000円超、設計経験ありで時給6,000円超の案件も現実的に存在します。
単価相場の詳細(週稼働別の月収シミュレーション・スキル別の単価差・エージェント別の傾向)については、React・TypeScript複業案件の単価相場と週稼働別の月収シミュレーション【2026年版】で詳しく解説しています。
本記事ではこの後、案件参入ラインへ到達するためのスキルアップロードマップに集中して話を進めます。
TypeScript・React副業案件を取るまでの実践ロードマップ(週次計画付き)

ここからが本記事の中核です。「副業参入ラインに到達するまで」の学習計画を、3つのフェーズに分けた合計12〜24週間の週次プランとして提示します。各週で「何を学ぶか」「何を作るか(成果物)」「次フェーズに進む判定基準」をすべて明示しているので、自分の進捗を採点しながら進められます。
学習時間の前提は、平日夜に1〜2時間 + 土日に3〜5時間(週合計10〜15時間)です。時間が確保できない週は、無理にスケジュールを進めずに同じ週を2週かけて消化する方が、結果的に身につきます。
フェーズ1:基礎固め(4〜8週間)— TypeScript型システム・React Hooks の実務レベル習得
このフェーズの目的は、業務で書く TypeScript・React コードに「自信を持てる状態」を作ることです。チュートリアルレベルから一段上の、実務で求められる型設計とコンポーネント設計を習得します。
週 | 学ぶこと | 成果物 |
|---|---|---|
1〜2週 | TypeScript の型システム( | 既存 JavaScript プロジェクトの一部を TypeScript に書き換えた PR、または型定義のみのリポジトリ |
3〜4週 | React Hooks 全種( | 各 Hook の用途別サンプル集(Storybook・Stackblitz で公開) |
5〜6週 | カスタムフックの設計・抽出パターン | API 呼び出し・フォーム状態管理・デバウンス処理のカスタムフックを実装した小規模アプリ |
7〜8週 | コンポーネント設計(プレゼンテーショナル/コンテナの分離、props 設計、再レンダリング最適化) | TODO アプリ・タスク管理アプリ等を TypeScript + React で実装。コンポーネント分割の設計意図を README に記述 |
次フェーズへの判定基準: 以下を満たしたらフェーズ2へ進む。
- 自分の書いた React + TypeScript コードを
anyを一切使わずビルドできる useEffectの依存配列警告(react-hooks/exhaustive-deps)の意味を説明でき、自分で解決できる- カスタムフックを最低3つ自作し、テスタブルな形に切り出せている
- GitHub に公開した個人リポジトリが1つ以上ある(README・依存ライブラリの選定理由を記載)
フェーズ2:実務想定スキル習得(6〜10週間)— Next.js・状態管理・テスト・Git運用
このフェーズで、副業案件で実際に求められる「現場の道具」を揃えます。フェーズ1までは自分1人で完結する技術でしたが、ここからはチーム開発・本番運用を意識した技術が中心になります。
週 | 学ぶこと | 成果物 |
|---|---|---|
1〜2週 | Next.js(App Router・Server Components・Server Actions・データフェッチ戦略) | Next.js で実装したブログサイトまたはダッシュボード(Vercel デプロイ済み) |
3〜4週 | 状態管理ライブラリ(Zustand・Jotai・TanStack Query のいずれか) | フェーズ1で作ったアプリを、状態管理ライブラリで書き直したリファクタリングコミット |
5〜6週 | テスト(Vitest・React Testing Library・Playwright のいずれか1つ以上) | カスタムフック・主要コンポーネント・主要ページに対するテストコード追加。カバレッジ60%以上を目標 |
7〜8週 | Git/GitHub の実践運用(PR テンプレ・Conventional Commits・GitHub Actions による CI) | リポジトリに |
9〜10週 | ESLint・Prettier・Husky 等の開発体験整備、エラーハンドリング・ログ設計の基礎 | プロジェクトの開発体験設定一式をテンプレ化。README に「このリポジトリの開発手順」を整備 |
次フェーズへの判定基準: 以下を満たしたらフェーズ3へ進む。
- Next.js でデータフェッチを含むページを1つ以上、Vercel にデプロイして公開済み
- CI(lint + test + build)が緑になる状態を維持できている
- テストカバレッジが60%以上、または主要機能に対してテストが書かれている
- 自分のリポジトリで PR ベースの開発(feature ブランチ → PR → セルフレビュー → merge)を回している
フェーズ3:案件応募準備(2〜6週間)— ポートフォリオ整備・職務経歴書・エージェント登録
技術スキルが揃ったら、それを「評価される形」に整えるフェーズです。スキルがあっても伝え方を間違えると応募が通りません。
週 | 学ぶこと | 成果物 |
|---|---|---|
1週 | ポートフォリオサイトの整備(自己紹介・成果物・連絡先・技術ブログリンク) | ポートフォリオサイトを公開(Next.js で実装すること自体がアピール材料になる) |
2週 | GitHub プロフィール README の整備、ピン留めリポジトリの選定 | プロフィール README に「使える技術」「直近の成果物」「連絡手段」を記載 |
3週 | 職務経歴書の作成(本業の経歴 + 副業として提供できる価値の明文化) | PDF 形式の職務経歴書。本業と副業の役割分担を明示 |
4週 | 副業エージェント2〜3社への登録、案件票のリサーチ | 登録完了、面談実施、最初の応募案件1〜2件決定 |
5〜6週(予備) | 面談での技術質問対策、応募書類のチューニング | 面談フィードバックを反映した応募書類の改善版 |
応募準備完了の判定基準: 以下を満たしたら案件応募に進む。
- ポートフォリオサイトに、主要成果物3つ以上が掲載されている
- 各成果物に「使用技術」「工夫した点」「直面した課題と解決方法」が記述されている
- GitHub プロフィール README が整備されており、ピン留めリポジトリが選定されている
- 副業エージェントへの登録が完了し、面談で自分の強みを30秒で説明できる
各フェーズの「次に進む判定基準」と詰まったときの軌道修正
ロードマップは目安です。週次計画通りに進まないことは普通に起こります。詰まったときの軌道修正パターンを覚えておくと、挫折を避けられます。
- 同じ週で2週連続で詰まったとき: 学習リソースを変える。書籍 → 動画教材 → 公式ドキュメント → ハンズオン記事の順で試すと、自分に合う形が見つかりやすい
- 理解はできるが手が動かないとき: 写経 → 改造 → ゼロから実装、の3段階を意識する。写経で全体像を掴み、改造で勘所を掴み、ゼロから実装で定着させる
- 学習が孤独で続かないとき: X(Twitter)や Zenn で学習ログを公開する。リアクションがモチベーションになり、後述するポートフォリオの「技術発信」要素にもなる
- どの技術を優先するか迷ったとき: 「現時点で副業案件に応募して通らない理由」を1つ挙げ、その理由を解消するスキルを最優先する。すべてを完璧にする必要はない
Reactフロントエンド案件で評価されるポートフォリオの作り方

実務経験が浅い段階で副業案件を取るには、「実務経験の代替材料」としてのポートフォリオが極めて重要です。けれど、ただ個人プロダクトを公開しただけでは評価されません。発注側・エージェント側が見ているポイントを押さえた整備が必要です。
評価されるGitHubリポジトリの4要素
GitHub リポジトリの URL を提出された側が、最初の30秒〜1分で見る箇所は決まっています。以下の4要素を満たすリポジトリは、それだけで「実務感覚がある」と判断されやすくなります。
- READMEの完成度: プロジェクトの目的、使用技術、セットアップ手順、ディレクトリ構成、デモへのリンクが整備されている。スクリーンショットや GIF があるとさらに良い
- コミット履歴の粒度: 1コミット1関心事の原則が守られている。
fix: ボタンクリック時のフォーカス制御を修正のように Conventional Commits 形式で書かれていると好印象 - テストの存在:
__tests__ディレクトリや*.test.tsファイルがあり、最低1つは実行可能なテストが書かれている。カバレッジバッジが README に貼られているとなお良い - CIの設定:
.github/workflows/配下に lint + test + build を回す CI が設定されており、main ブランチが緑になっている
これら4要素は、難易度の高い実装スキルというより「開発の作法」を示すものです。だからこそ、ここを丁寧に整備しているリポジトリは「チームに入って自走できる」という信号になります。
個人プロダクトの選び方
ポートフォリオに載せる個人プロダクトは「実務シナリオに近いテーマ」を選ぶことが重要です。以下のような観点で選ぶと、評価につながりやすくなります。
- 業務系SaaSに近いテーマ: タスク管理・顧客管理・在庫管理・スケジュール管理など、フォーム入力・一覧表示・検索・更新が含まれるもの。BtoB 案件と相性が良い
- データフェッチを伴うもの: 外部 API(公開API・自前 Mock API)からデータを取得して表示する構造を含む。Server Components・TanStack Query 等の知見をアピールできる
- 認証を含むもの: NextAuth.js や Auth0 を組み込んだ実装は、本番運用を意識している証拠になる
- 実ユーザーがいるとさらに強い: 友人・家族でもよいので実際に使われているプロダクトは、フィードバックを受けて改修した経験が語れるため評価が大きく変わる
逆に避けたいのは、チュートリアルをなぞっただけのプロダクト(典型例: チュートリアル通りの TODO アプリのみ)です。差別化が難しく、評価ポイントが薄くなります。
OSSコントリビュートの始め方
OSS への PR マージ実績は、「他者のコードベースで作業できる」という最大級の証明材料になります。けれど、いきなり大規模 OSS の機能追加を目指すと挫折します。次のような小さな PR から始めるのがおすすめです。
- ドキュメント(README・公式サイト・チュートリアル)の typo 修正、表記揺れ統一
- 古いバージョンの依存ライブラリのアップデート PR
- TypeScript の型定義の追加・改善(特に既存 JS ライブラリの型定義不足を埋める)
- 軽微なバグ修正(
good first issueラベルが付いた Issue が狙い目)
GitHub の検索で is:issue is:open label:"good first issue" language:TypeScript のように絞り込むと、初心者向けの Issue が見つかります。最初の PR がマージされた経験は、心理的な大きな自信になります。
技術発信が案件獲得につながる理由
Zenn・Qiita・個人ブログでの技術発信は、ポートフォリオの一部として強く機能します。理由は次の通りです。
- 言語化能力の証明: 実装の判断を文章で説明できるかどうかは、チーム内コミュニケーション能力の指標になる
- 学習履歴のタイムスタンプ: 「いつ何を学んだか」が時系列で残るため、成長スピードを示せる
- エージェント・発注者からの発見経路: 技術記事経由でスカウトが来ることがある(特に Zenn は技術者の閲覧率が高い)
発信プラットフォームは Zenn を第一選択にするのが現実的です。エンジニア層の閲覧率が高く、Markdown ベースで書きやすいためです。記事のテーマは「学習中に詰まったポイントとその解決」が王道で、検索流入も狙えます。
副業から月20〜30万円の複業スタイルへステップアップする戦略

最初の案件を獲得した後、月数万円から月20〜30万円規模の継続的な複業スタイルへ移行するためには、稼働日数とスキルレベルを連動させた段階的なステップアップが必要です。「最初の案件が取れたら終わり」ではなく、その後の伸ばし方を最初から描いておくことが、持続可能な副業の条件になります。
月数万円から月20万円への稼働×単価ステップアップ表
実際の移行パスは、次のような段階を踏むことが多いです。
ステージ | 稼働 | 時給 | 月収目安 | 案件タイプ | 求められる追加要素 |
|---|---|---|---|---|---|
Step 1 | 週0.5日(土日数時間) | 3,000円 | 4〜5万円 | SPA改修・LP対応 | 最初の実績を作る。スピードより信頼性を優先 |
Step 2 | 週1日 | 3,500〜4,000円 | 14〜16万円 | SPA改修・小規模新規 | 1つ目の案件で得た実績を別案件で再活用 |
Step 3 | 週2日 | 4,000〜5,000円 | 28〜40万円 | 新規開発・継続改修 | Next.js または状態管理ライブラリでの設計経験 |
Step 4 | 週2日 + スポット | 5,000〜7,000円 | 40〜55万円 | 新規開発リード・技術顧問 | アーキテクチャ設計・他メンバーへの技術指導経験 |
時給単価の根拠は2026年時点の各エージェント公開データ(【2026年】TypeScript案件の年収レポート等)に基づきます。詳細な月収シミュレーションはReact・TypeScript複業案件の単価相場と週稼働別の月収シミュレーション【2026年版】を参照してください。
重要なのは、Step 1 から Step 2 への移行(最初の案件 → 2件目)が最大の山であることです。最初の案件で「クライアントに迷惑をかけずに継続できた」という実績ができれば、その後のステップは技術スキルと稼働調整で進められます。
月20万円超を狙うために必要な追加スキル
Step 2 から Step 3 への移行には、技術スキルそのもの以上に「上流工程に絡める力」が問われます。具体的には以下です。
- 要件定義・仕様調整: 発注側の曖昧な要望をヒアリングして仕様に落とし込む力。実装に着手する前に「何を作るべきか」を整理できる
- アーキテクチャ設計: ディレクトリ構成・状態管理戦略・API 連携設計を初期に決められる。後から変更しづらい部分の判断ができる
- コードレビュー力: 他メンバーの PR をレビューし、設計意図を尊重しながら改善提案できる。これは Step 4 の技術顧問への伏線になる
- 見積もり力: 「この機能はいくらでいつまでにできるか」を提示できる。受け身ではなく主体的に動ける副業エンジニアは単価が上がりやすい
これらは座学で身につくものではなく、実案件で経験を積みながら身につけていくのが基本です。Step 2 で案件を進めながら、上記の要素を1つずつ意識的に経験していく姿勢が、Step 3 への移行を早めます。
本業との両立・税務・契約面で押さえるべき基本
副業の継続性を保つには、税務・契約の基本を押さえておくことも欠かせません。本業との両立で最初に確認すべきは、勤務先の副業規定です。副業可否、報告義務の有無、競業避止のスコープを契約書や就業規則で確認してください。許可制の場合は事前申請を済ませてから案件応募に進みます。
税務面では、副業の年間所得が20万円を超えると確定申告が必要です。報酬の振込時に源泉徴収されているケース・されていないケースがあるため、案件契約時に報酬体系を確認してください。経費計上できる支出(書籍・学習教材・PC周辺機器・自宅作業環境費の一部)も合わせて記録しておくと、確定申告時に対応しやすくなります。
契約面では、業務委託契約書を必ず締結し、報酬額・支払いサイト・著作権の帰属・秘密保持義務・成果物の納品基準を明文化してください。エージェント経由の案件であればエージェントが契約書テンプレートを提供することが多いので、初回は内容を熟読して不明点をエージェント担当者に確認しましょう。詳しい税務・契約の運用は専門家の情報源を別途確認することをおすすめします。
まとめ:今日から動くための最初の3ステップ
ここまでの内容を踏まえ、読み終えた直後の今日から動ける具体的な3ステップを示して、本記事を締めくくります。
ステップ1: 現在地のセルフ診断を今日中に終える
本記事の序盤で示したセルフ診断リスト(GitHub の公開リポジトリ・TypeScript の型エラー解消・useEffect 依存配列・PR 経験・テスト経験・デプロイ経験の6項目)を、いま実際にチェックしてみてください。チェック数によって、次に取り組むべきフェーズが決まります。
ステップ2: 今週のタスクを1つだけ決める
ロードマップ全体を眺めると圧倒されますが、必要なのは「今週の1タスク」だけです。フェーズ1のチェックが埋まっていなければ TypeScript の型システムの章を読み返し、サンプルコードを1つ写経する。フェーズ2に入っていれば Next.js の App Router で1ページ作る。フェーズ3に入っていればポートフォリオサイトの自己紹介セクションを書く。範囲を狭めれば手は動きます。
ステップ3: GitHub リポジトリを1つ整備し始める
どのフェーズにいても、GitHub リポジトリの整備は今日から始められます。既存のリポジトリ1つを選び、README を書き直す、ファーストコミットから振り返って雑なコミットを reset せずに、これからのコミットだけでも Conventional Commits 形式で書く、テストを最低1つ書く——これらは技術スキルとは別軸の「作法」であり、すぐに着手できて評価につながります。
副業エージェント・フリーランスプラットフォームへの登録は、これら3ステップを進めた先で「準備が整ったタイミング」に行うのが効果的です。Workee のような複業向けプラットフォームは、本業を続けながら稼働日数を選んで案件参画できるため、フェーズ3に到達した時点で選択肢の1つとして検討してみてください。準備のない状態で登録だけ済ませても面談で評価につながりにくいので、まずはポートフォリオと診断結果を整えることを優先するのが現実的です。
学習中の不安は、漠然とした「全体像が見えない感覚」から来ています。それを「今週のタスク1つ」に変換できれば、3〜6ヶ月後には最初の案件応募ができる位置に立てます。本記事が、その第一歩の判断基準になれば幸いです。



