TypeScriptエンジニアの週2〜3日・副業案件|探し方と受けるときの注意点
公開 2026-11-04 監修:株式会社エージェントベスト
週2〜3日や副業で受けられるTypeScriptエンジニアの案件は、週5日の案件より少ないものの、あります。TypeScriptの仕事はプルリクエストとチャットで進むため、作業を稼働日にまとめやすく、リモートとも相性がよいからです。見つかりやすいのは、画面の改修や小さな機能の追加、範囲の決まったAPIの開発、JavaScriptからの移行、型チェックやCIの整備のように、範囲を切り出しやすい仕事です。
探すときは、「週3日で何でも」ではなく、稼働日数で担える範囲を先に決めて、その範囲に合う案件を選ぶことが大切です。この記事では、TypeScriptの週2〜3日・副業案件の傾向、探し方、受けるときの注意点を整理します。週3日の働き方全般は週3日の業務委託案件の記事で解説しています。
週2〜3日のTypeScript案件が週5日より少ない理由
TypeScriptの案件で週5日が多いのは、仕事の進め方によるものです。
- レビューの往復が多い:プルリクエストへの指摘と修正が毎日回るため、不在の日が多いと待ちが生まれる
- 型の定義がチーム全体に効く:画面とサーバーで共有する型を変えると、ほかの人の作業にすぐ影響が出る
- スプリントの会議に出る必要がある:計画や振り返りの会議に出られないと、作業の割り当てがずれやすい
そのため、チームの一員として機能開発の中心を担う役割は、週5日で募集されることが多くなります。週2〜3日の案件は、範囲と期限がはっきりした仕事として募集されることがほとんどです。
週2〜3日・副業で見つかりやすいTypeScript案件
| 案件の型 | 主な仕事 | 週2〜3日で成り立つ理由 |
|---|---|---|
| 画面の改修・小さな機能の追加 | 既存の画面の修正、管理画面の追加 | 1つの作業が小さく、稼働日にまとめやすい |
| 範囲の決まったAPIの開発 | 社内向けのAPI、外部サービスとの連携の処理 | 仕様が先に決まり、ほかの作業と切り離しやすい |
| JavaScriptからの移行 | ファイルやディレクトリ単位での型の追加 | まとまりごとに区切って進められる |
| 型チェック・CIの整備 | 設定の見直し、型エラーの解消、自動チェックの追加 | 機能開発と並べて進めやすい |
| 技術の相談役 | 設計のレビュー、型の決まりづくりの助言 | 定期的な確認が中心で、日々の実装は担わない |
移行や型チェックの整備は、TypeScriptならではの週2〜3日向きの仕事です。社内の開発者がふだんの機能開発を続けながら、外部の人に型の追加や設定の見直しを任せる形がとられることがあります。TypeScript 7.0の公開で設定の見直しを考える現場もあるため、版上げの準備を区切って任されることも考えられます。変化の中身はTypeScriptの将来性の記事で扱っています。
技術の相談役は、TypeScriptの経験が長い人に向いた形です。設計や型の決まりを外から見て助言する役割で、回数や時間を区切って関わることが多くなります。
週2〜3日のTypeScript案件の探し方
1. 担える範囲を先に決める
週2〜3日で受けるなら、どの仕事を担い、どの仕事は担わないかを先に決めておきます。たとえば「画面の改修と型の追加は担うが、リリースの立ち会いや障害の一次対応は担わない」のように言葉にしておくと、案件との照らし合わせが早くなります。
2. 稼働する曜日と、返信の時間帯を決める
TypeScriptの案件はリモートが多い一方、朝会やスプリントの会議の曜日は決まっています。稼働する曜日を固定できるか、稼働日以外にチャットやレビューへどこまで応じられるかを決めておきましょう。会議の曜日に合わせられる人ほど選択肢が広がります。
3. 層を絞って、経験の近い案件を選ぶ
稼働日数が少ないほど、立ち上がりの早さが求められます。画面ならふだん使っているフレームワーク、サーバーなら慣れた実行環境やデータベースの案件を選ぶと、短い稼働でも成果を出しやすくなります。フレームワークごとの事情はReactの週2〜3日案件の記事、Node.jsの週2〜3日案件の記事も参考になります。
4. リモートの条件と端末の扱いを確かめる
週2〜3日の案件はリモートが前提のことが多いものの、貸与の端末や仮想デスクトップでの開発が条件になる場合もあります。端末の受け取りや接続の手順は、稼働日が少ないほど負担になりやすいため、早めに確かめましょう。リモートの事情はTypeScriptのリモート案件の記事で解説しています。
短い稼働で信頼を得る進め方
週2〜3日のTypeScriptエンジニアは、不在の日があることを前提に仕事の進め方を組み立てる必要があります。
- プルリクエストを小さく分ける:稼働日のうちにレビューに出せる大きさに区切り、不在の間に止まらないようにする
- 型の変更は影響を書いて出す:共有している型を変えるときは、誰の作業に影響するかを説明に書く
- 稼働日の始めと終わりに短く報告する:始めに今日の予定、終わりに進んだことと残ったこと、質問を残す
- 判断の理由を残す:anyを残した理由や設定を変えた理由を、コメントやメモに書いておく
こうした進め方を面談で具体的に話せると、短い稼働でも任せられるかを発注元が判断しやすくなります。
受けるときの注意点
責任の範囲と稼働日数をそろえる
週2〜3日の案件で起きやすいのは、稼働日数は少ないのに、チームの中心の機能やリリースの責任まで任される状態です。不在の日にもレビューや不具合の対応を求められ、結果として稼働日以外の作業が増えていきます。参画前に、担う範囲と、不在の日に急ぎの対応が出たときに誰が受けるかを確かめておきましょう。
稼働時間の記録と精算を確かめる
レビューへの返信や型エラーの相談など、稼働日以外に少しずつ時間を使うことがあります。稼働日以外に対応した時間をどう扱うかを、精算の条件とあわせて確かめておきます。精算の仕組みは精算幅の記事、参画後に範囲が広がったときの扱いは作業範囲が広がったときの契約の扱いで解説しています。
移行や整備の案件は「完了の形」を決める
移行や型チェックの整備は、どこまでやれば終わりかがあいまいになりがちです。対象のディレクトリ、型チェックの設定、残してよい型の無視の扱いなど、完了の形を最初に決めておくと、稼働が延び続けることを防げます。
会社員の副業でTypeScript案件を受けるとき
会社員が副業でTypeScriptの案件を受ける場合は、上の注意点に加えて次の点を確かめます。
- 勤務先の就業規則:副業が禁止か、許可制か、届出制か。業務委託が対象に含まれるか
- 本業との競合:本業と同じ分野のサービスや、本業の取引先に関わる案件は、競業や秘密の扱いで問題になりやすい
- コードと知識の切り分け:本業で書いたコードや社内の共通部品を、副業の案件に持ち込まない
- 時間帯:朝会やスプリントの会議が平日の日中に入る場合、本業の時間と重ならないか
厚生労働省は副業・兼業についてガイドラインやモデル就業規則を公表しています(2026年10月時点)。TypeScriptのエンジニアは、本業と副業で似たコードを書くことが多いため、コードの持ち込みには特に注意が必要です。就業規則の読み方や確定申告は会社員の副業で業務委託案件を受けるときの注意点、所得の申告の考え方は副業の確定申告と所得20万円のルール、副業が禁止の会社の場合は副業禁止の会社で業務委託を受けるリスクで解説しています。判断に迷う場合は、勤務先の担当部署や税理士などの専門家にご相談ください。
よくある質問
平日の夜や週末だけでもTypeScriptの案件は受けられますか?
チームの会議に出なくてよい範囲の仕事なら、成り立つことがあります。範囲の決まった機能の追加や、移行の作業、レビューの相談などです。ただ、平日の日中の会議を前提にする案件が多いため、選べる案件は限られます。探し方は週末・夜だけの業務委託案件の記事で解説しています。
週2〜3日の案件の経験は、スキルシートでどう書けばよいですか?
稼働日数と担った範囲を正確に書き、何を防いだか、何が楽になったかを1行で添えます。チームの中心の機能を一人で担ったように読める書き方は避け、範囲を明確にしておくと面談で説明しやすくなります。
週3日で始めて、あとから週5日に増やすことはできますか?
発注元の体制や予算によっては増やせることがあります。ただし案件ごとに事情が違うため、増やせる前提で受けるのは避けたほうが無難です。将来の希望がある場合は、参画前に伝えておくと話がしやすくなります。
参考にした公的情報・資料
記事の内容は公開日時点の情報にもとづきます。制度や税率は変わることがあるため、手続きの前に必ず各機関の最新情報をご確認ください。