DevOpsエンジニアの週2〜3日・副業案件|探し方と受けるときの注意点
公開 2026-11-04 監修:株式会社エージェントベスト
DevOpsエンジニアの週2〜3日・副業の案件は、週5日の案件より少ないものの、あります。成り立ちやすいのは、範囲を区切ったCI/CDの改善、IaCへの取り込み、パイプラインの点検と助言、新しいサービス向けの雛形づくりなど、成果物で区切れて、毎日の即応が要らない仕事です。
反対に、基盤チームの中心として日々の依頼に応える役割や、障害対応の当番に入る役割は、週2〜3日では成り立ちにくくなります。この記事では、週2〜3日・副業のDevOps案件の傾向、探し方、受けるときの注意点を整理します。週3日の働き方全般は週3日の業務委託案件の記事で解説しています。
週2〜3日のDevOps案件が週5日より少ない理由
DevOpsの仕事は、コードを書く時間が長く、リモートで進めやすい面があります。それでも週5日が中心になるのは、次のような事情があるためです。
- 開発チームの待ち時間に直結する:パイプラインが止まると開発者の作業が止まるため、すぐに直せる人が求められやすい
- 依頼が毎日のように届く:権限の追加、ビルドの失敗の調査、ツールの更新など、細かな依頼が続く
- 本番の変更に立ち会う:切り替えや大きな変更の日は、その場で判断できる人がいる必要がある
そのため、週2〜3日の案件は、日々の窓口を社内の人が持ち、外部の人は区切った範囲を担う形で募集されることがほとんどです。
週2〜3日・副業で見つかりやすいDevOps案件
| 案件の型 | 主な仕事 | 週2〜3日で成り立つ理由 |
|---|---|---|
| 範囲を区切ったCI/CDの改善 | 特定のサービスのビルドの高速化、テストの分割、承認の段階の追加 | 対象と期限がはっきりし、作業を稼働日にまとめやすい |
| IaCへの取り込み | 管理画面で作られた環境の一部をコード化し、変更の流れを決める | 環境ごとに区切って進められる |
| パイプラインの点検と助言 | 権限、秘密情報、外部の部品の扱いを点検し、改善案を出す | 点検と報告が中心で、日々の運用を担わない |
| 雛形と手引きづくり | 新しいサービスの立ち上げ用の雛形、使い方の手引き | 成果物で区切れ、利用者の声を集める日を決めやすい |
| 小さな組織の技術顧問に近い支援 | 少人数の開発チームの構成の相談、優先順位の助言 | 定例の相談が中心で、作業は社内の人が担う |
点検と助言の案件は、スタートアップや社内に専門の人がいない会社で出てきやすい型です。外部の人が構成を見て改善の順番を示し、実際の変更は社内の開発者が行う形になります。作業を担う案件か、助言を担う案件かで責任の重さが変わるため、参画前に確かめておきましょう。
週2〜3日のDevOps案件の探し方
1. 区切れる仕事を先に決める
週2〜3日で受けるなら、どの仕事を担い、どの仕事を担わないかを言葉にしておきます。たとえば「パイプラインの改善と雛形づくりは担うが、日々の権限の依頼と障害の当番は担わない」のように決めておくと、案件との照らし合わせが早くなります。
2. リモートで進められる条件を確かめる
稼働日が少ないほど、移動の時間を減らせるリモートの案件が向いています。ただし、閉じたネットワークの中で作業する案件や、作業用の端末を借りる案件では、出社や端末の受け渡しが必要になることがあります。条件の確かめ方はDevOpsエンジニアのリモート案件の記事をご覧ください。
3. 週5日の案件の一部を切り出してもらう
週5日で募集されている案件でも、移行の一部や特定のサービスの改善だけを切り出せば、週2〜3日で受けられる場合があります。ただ、発注側の体制によっては難しいこともあるため、条件を押しつけず、切り出し方の案を示して相談する形が現実的です。
4. 使ってきた構成に近い案件を選ぶ
稼働日が少ないほど、立ち上がりの早さが求められます。クラウド、CIツール、IaCのツールが自分の経験に近い案件を選ぶと、構成を読む時間が短く済み、短い稼働でも成果を出しやすくなります。
短い稼働で信頼を得る進め方
- 変更は稼働日に入れて、稼働日に見届ける:本番に影響する変更を、自分がいない日に適用されるようにしない
- 戻し方を先に書いておく:変更ごとに切り戻しの手順を残し、不在の日に問題が出ても社内の人が戻せるようにする
- 不在の日の窓口を決める:パイプラインが止まったときに誰が判断するかを、発注側の担当者と先に合意しておく
- 週の始めと終わりに短く報告する:今週やること、終わったこと、気になる点を文章で残す
- 手引きを残す:自分がいなくても使い続けられるよう、作った仕組みの使い方と直し方を書いておく
こうした進め方を面談で具体的に話せると、短い稼働でも任せられるかを発注側が判断しやすくなります。
受けるときの注意点
責任の範囲と稼働日数をそろえる
週2〜3日の案件で起きやすいのは、稼働日数は減ったのに、作った仕組みの面倒は毎日見ることになる状態です。パイプラインの失敗や権限の依頼が稼働日以外にも届き、結果として作業が増えていきます。担う範囲と、不在の日の対応を誰がするかを確かめておきましょう。稼働日以外に対応した時間の扱いは、精算の条件とあわせて確かめます。精算の仕組みは精算幅の記事、範囲が広がったときの考え方は作業範囲が広がったときの契約の扱いをご覧ください。
権限の渡し方と返し方を確かめる
DevOpsの仕事では、クラウドやリポジトリに強い権限を受け取ることがあります。週2〜3日の案件でも必要な範囲は同じになりやすいため、どの権限を受け取るか、契約が終わったときにどう返すかを最初に決めておくと、双方が安心できます。
会社員の副業でDevOps案件を受けるとき
会社員が副業で受ける場合は、上の注意点に加えて次の点を確かめます。
- 勤務先の就業規則:副業が禁止か、許可制か、届出制か。業務委託が対象に含まれるか
- 本業との競合と秘密:本業の取引先や競合に関わる案件、本業で作った仕組みと同じものを作る案件は、秘密の扱いで問題になりやすい
- 時間帯:開発チームとの打ち合わせや本番の変更が平日の日中に入るか
厚生労働省は「副業・兼業の促進に関するガイドライン」を公表しており、2026年10月時点の案内では、令和4年7月に改定されたものが掲載されています。モデル就業規則にも副業・兼業の規定が設けられていますが、実際の扱いは勤務先の就業規則によります。
本業で使っている社内のツールや設定、コードを副業の案件に持ち込まないよう、意識して切り分けましょう。就業規則の読み方や確定申告は会社員の副業で業務委託案件を受けるときの注意点と副業禁止の会社で業務委託を受けるリスク、申告が必要になる目安は副業の20万円ルールの記事、平日の日中に動けない場合は週末・夜だけの業務委託案件の記事で解説しています。判断に迷う場合は、勤務先の担当部署や税理士・専門家にご相談ください。
よくある質問
週2〜3日の案件でも、DevOpsの経験として評価されますか?
担った範囲と変えた内容を具体的に書けば、経験として評価されます。スキルシートには稼働日数と担当した範囲を正確に書き、基盤全体の責任者と誤解されない書き方にしておきましょう。
夜間や週末だけでDevOpsの案件は受けられますか?
打ち合わせが平日の日中に入ることが多いため、夜や週末だけの案件は限られます。点検と報告、雛形や手引きづくりのように、成果物で区切れて打ち合わせの少ない仕事なら成り立つことがあります。本番の変更を夜間に一人で入れる形は、発注側と手順を十分に合意してからにしましょう。
週3日で始めて、あとから稼働を増やせますか?
発注側の体制や予算によっては増やせることがあります。ただし案件ごとに事情が違うため、増やせる前提で受けるのは避けたほうが無難です。希望がある場合は参画前に伝えておくと、話がしやすくなります。
参考にした公的情報・資料
記事の内容は公開日時点の情報にもとづきます。制度や税率は変わることがあるため、手続きの前に必ず各機関の最新情報をご確認ください。