週2〜3日・副業のAWSエンジニア案件はある？傾向と探し方、受けるときの注意点

週2〜3日や副業で受けられるAWSエンジニアの案件は、数は限られますが、あります。AWSの案件は、構築の期間や運用の体制に入ることを前提に週5日で募集されるものが中心です。そのなかで週2〜3日でも成り立ちやすいのは、構成のレビューや改善の助言、手作業の環境のIaC化、費用の見直し、小規模なサービスのインフラ担当など、範囲と成果物を区切れる仕事です。

探すときは「週3日なら何でも」ではなく、稼働日数に合う役割を選び、障害対応の扱いを先に決めることが大切です。この記事では、週2〜3日・副業のAWS案件の傾向、探し方、受けるときの注意点を整理します。週3日の働き方全般は週3日の業務委託案件の記事で解説しています。

週2〜3日のAWS案件が少ない理由

AWSの案件で週5日が多いのは、仕事の性質によるものです。

• 構築には連続した作業時間が要る：設計から構築、検証までを短い期間で進める案件では、毎日手を動かす前提で計画が組まれる
• 開発チームが待っている：環境の用意が遅れると、アプリの開発やテストが止まる
• 障害の窓口になる：運用の案件では、日中のアラートや問い合わせにすぐ応じることが期待される

そのため、環境全体の責任を1人で負う役割を週2〜3日で募集することは多くありません。週2〜3日の案件は、担う範囲を絞った役割として募集されることがほとんどです。

週2〜3日・副業で見つかりやすいAWS案件

構成のレビューや助言は、社内にAWSを使うエンジニアはいるものの、設計を相談できる相手がいない会社で出てくる案件です。週次の定例で設計を見たり、変更のプルリクエストをレビューしたりする形が多くなります。

IaC化は、短い稼働に向いた仕事です。対象の範囲を決めれば、コードと手順書という成果物で区切れるため、稼働日数が少なくても進み具合を示しやすくなります。

費用の見直しは、請求の内訳を読み、使われていない資源やサイズの大きすぎる資源を洗い出し、削減の案を示す仕事です。案を実行する作業は社内の担当者が行い、フリーランスは分析と提案に回る形もあります。反対に、新しい環境を短い期間で立ち上げる構築の案件や、日中の監視を担う運用の案件は、週2〜3日では成り立ちにくい傾向があります。

週2〜3日の案件で評価されやすい経験

稼働日数が少ない案件では、参画してすぐに一人で判断できるかが見られます。評価されやすいのは次のような経験です。

• 他人が作った環境を短期間で読み解いた経験：構成図やコードが不十分な環境でも、全体を把握して改善点を挙げられる
• 範囲を区切って納めた経験：IaC化や移行の一部など、決められた範囲を成果物にまとめて引き渡した
• 文章での報告に慣れていること：会議に出られない日も、チャットやチケットで状況と判断の材料を残せる

スキルシートでは、週5日の案件と同じように担当工程を書いたうえで、「短期間で引き継いだ」「範囲を区切って納めた」といった点を添えると、短い稼働での働き方を想像してもらいやすくなります。

週2〜3日のAWS案件の探し方

1. 担える範囲と成果物を先に決める

「既存環境のIaC化と、その手順書まで」「月2回の設計レビューと改善案の提出」のように、範囲と成果物を言葉にしておくと、案件との照らし合わせが早くなります。

2. 稼働する曜日と、稼働外の連絡の扱いを決める

定例の曜日と稼働日が合うかが大切です。稼働日以外にチャットへどこまで応じられるか、急ぎの判断が出たら誰が代わるかも決めておきましょう。

3. リモートで入れる案件から選ぶ

短い稼働では、移動の時間が負担になります。アカウントへの入り方や端末の条件など、リモートで作業できるかを早めに確かめましょう。AWS案件のリモートの事情はAWSのリモート案件の記事で解説しています。

4. 経験の近い構成から選ぶ

稼働日数が少ないほど、立ち上がりの早さが求められます。使っているサービスやIaCのツール、アカウントの構成が自分の経験に近い案件を選ぶと、短い稼働でも成果を出しやすくなります。

短い稼働で信頼を得る進め方

• 変更は稼働日に完結させる：本番への変更を稼働日の途中で止めて翌週に持ち越さない。終わらないときは手前で区切る
• 不在の日の連絡先を決める：急ぎの判断や障害が出たときに誰が対応するかを、発注元の担当者と先に合意しておく
• 週の始めと終わりに短く報告する：稼働日の最初に予定、最後に結果と気になる点を文章で残す
• 作業の記録をコードとチケットに残す：不在の間も、関係者が変更の経緯を追えるようにする

こうした進め方を面談で具体的に話せると、短い稼働でも任せられるかを発注元が判断しやすくなります。

受けるときの注意点

障害対応の扱いを契約前に決める

週2〜3日のAWS案件で最も起きやすいのは、稼働日数は減ったのに、障害のときだけ週5日と同じ対応を求められる状態です。自分が作った環境ほど頼られやすく、稼働日以外にも呼び出されることがあります。障害の連絡体制に入るか、入るならどの時間帯か、そのときの精算をどうするかを確かめておきましょう。待機の扱いは待機の報酬の記事で解説しています。

稼働時間の記録と精算を確かめる

AWSの作業は、チャットの返信やレビューのように、稼働日以外にも細かく時間を使いがちです。稼働日以外に対応した時間の扱いを、精算の条件と合わせて確かめておきます。仕組みは精算幅の記事をご覧ください。

権限と費用の責任を確かめる

短い稼働でも、本番の権限を持つことは変わりません。誤った操作や作った資源の費用が問題になったときの扱いを、契約と運用の両方で確かめておきます。参画後に役割が広がった場合は作業範囲が広がったときの契約の扱いをご覧ください。

会社員の副業でAWS案件を受けるとき

会社員が副業でAWSの案件を受ける場合は、上の注意点に加えて、次の点を確かめます。

• 勤務先の就業規則：副業が禁止か、許可制か、届出制か。業務委託が対象に含まれるか。厚生労働省は「副業・兼業の促進に関するガイドライン」を公開しており、勤務先の規程を読む際の参考になります
• 本業との競合：本業の顧客や取引先と同じ業界の案件は、競業や秘密の扱いで問題になりやすい
• 時間帯：日中の定例や障害の対応が、本業の勤務時間と重ならないか
• 端末とアカウント：本業の端末や、本業で使うAWSのアカウントを副業の作業に使わない

AWSエンジニアは、本業でも副業でも環境の深いところに触れる立場です。設定や認証の情報を混ぜないよう、意識して切り分ける必要があります。就業規則の読み方や確定申告などは会社員の副業で業務委託案件を受けるときの注意点と副業禁止の会社で業務委託を受けるリスク、平日の日中に動けない場合は週末・夜だけの業務委託案件の記事で解説しています。判断に迷う場合は、勤務先の担当部署や専門家にご相談ください。

よくある質問

週2〜3日の案件でも、AWSの経験として評価されますか？

担った範囲と成果物を具体的に書けば、経験として評価されます。スキルシートには稼働日数と担った範囲を正確に書き、環境全体の責任者と誤解されない書き方にしておきましょう。

平日の夜や週末だけでもAWSの案件は受けられますか？

日中の定例や障害の対応がある案件では難しくなります。IaC化や構成の点検のように、成果物で区切れて日中の即応を求められない仕事なら成り立つことがあります。

週3日で始めて、あとから週5日に増やすことはできますか？

発注元の体制や予算によっては、稼働を増やせることがあります。ただし案件ごとに事情が違うため、増やせる前提で受けるのは避けたほうが無難です。将来の希望がある場合は、参画前に伝えておくと話がしやすくなります。