SREのフリーランスはリモートで働ける?案件の傾向と探し方
公開 2026-10-29 監修:株式会社エージェントベスト
SREは、監視やログの仕組みの整備、SLOの導入、リリースの自動化などで、リモートで働けるフリーランス案件があります。扱う対象がクラウドやコードの上にあり、チームとのやり取りもチャットや画面の共有で回せる仕事が多いためです。
ただし、SREの案件でリモートの条件を大きく左右するのは、出社の有無よりもオンコール(障害の連絡を受けて対応する当番)です。在宅で働けても、待機中は決められた時間内に対応を始められる場所にいなければならない、という条件が付くことがあります。この記事では、SREに固有の「時間と場所の縛り」を中心に整理します。
リモートで進めやすいSRE案件の型
SREの案件は、改善の仕組みをつくる仕事と、日々の運用を担う仕事で、時間の縛りが大きく変わります。
| 案件の型 | 主な仕事 | 時間と場所の縛り |
|---|---|---|
| 可観測性の整備 | メトリクス・ログ・トレースの収集、ダッシュボードとアラートの見直し | 少ない。日中の作業が中心 |
| SLOの導入支援 | 指標の選び方の整理、エラーバジェットの運用づくり | 少ない。開発チームとの打ち合わせが中心 |
| リリースの仕組み | CI/CDの整備、段階的な公開、戻し方の自動化 | 少ない。本番の反映の時間帯だけ決まりがある |
| 障害対応の仕組みづくり | 対応手順の整備、振り返りの進め方の定着 | 少ない。障害が起きたときの参加の有無による |
| オンコールを含む運用 | アラートの一次対応、障害時の復旧、定常作業 | 大きい。待機の時間帯と応答の速さが決まる |
案件で見られる技術はSREの案件で求められるスキルで、SLOや振り返りの経験をどう積むかはSREがフリーランスになるにはで解説しています。
出社や待機が求められやすい場面
SREの案件で、在宅だけでは済まない条件が付くのは次のような場面です。
- 大きな障害のときに関係者が集まる:影響の大きい障害では、指揮をとる人と担当者が同じ部屋に集まる進め方をとる会社がある
- 本番の権限が社内の端末に限られる:在宅では読み取りだけ、本番の変更は社内の端末から、という決まり
- 監視の部屋に詰める体制:画面を常に見ている当番を置き、交代で詰める
- オンコールの待機:自宅にいてもよいが、決められた時間内にパソコンを開いて対応できる状態でいる
- 大型のリリースや移行の当日:関係者がそろって見守る日を設ける
このうち、オンコールの待機は「出社なし」の案件にも付くことがあります。リモートかどうかだけで判断せず、待機の条件を分けて確かめることが大切です。
オンコールで確かめたい4つの点
Googleが公開しているSREの書籍の「Being On-Call」の章では、オンコールの持ち方について、次のような考え方が示されています。案件の条件を確かめるときの物差しとして使えます。
応答までの時間
同書では、利用者に直接影響するサービスでは5分程度、そうでないサービスでは30分程度で対応を始めることを目安として挙げ、応答の速さはサービスの可用性の目標から決まると説明しています。応答の目安が5分なのか30分なのかで、待機中に外出できる範囲がまったく変わります。案件の目安を聞き、自分の生活で守れるかを考えておきましょう。
当番の人数と頻度
同書は、1拠点のチームで24時間の主担当と副担当の当番を回すには少なくとも8人、2拠点なら6人が要るとしています。少人数で回している現場では、当番が回ってくる頻度が高くなります。当番表の人数と、自分が入る頻度を確かめておきましょう。
1回の当番で起きる障害の数
同書では、障害1件の対応には、原因の分析や再発防止、振り返りの文書まで含めて平均で約6時間かかるとし、12時間の当番で扱えるのは最大2件としています。毎日のように鳴るアラートは、それ自体が見直すべき問題だという考え方です。アラートの件数や、誤報の多さを面談で聞いておくと、待機の重さを想像しやすくなります。
時間外の対応の扱い
同書では、時間外の対応には休みや金銭で報いること、その量に上限を設けることにも触れています。業務委託では、待機の時間と、実際に対応した時間をそれぞれどう扱うかを、契約の段階で決めておくことが大切です。決めないまま参画すると、稼働の時間が想定より増えることがあります。稼働の考え方は稼働率の記事で解説しています。
(上の数字は同書の2026年10月時点の公開版によるものです。各社の運用はこれと同じとは限りません。)
リモートでの障害対応の進め方
役割と連絡の場所を先に決める
在宅のメンバーが集まる障害対応では、誰が指揮をとり、誰が手を動かし、誰が関係者へ報告するかを、最初の数分で決めることが大切です。障害ごとに専用のチャットの場所を作る、音声の通話をつなぎっぱなしにする、といった決まりがある現場も多く、参画したら最初に確かめておきます。
時刻と作業をその場で記録する
離れていると、誰が何をしたかが見えにくくなります。打った命令、見たグラフ、判断の理由を、時刻とともにチャットに残しておくと、後の振り返りの材料になり、途中から加わった人もすぐ状況をつかめます。
振り返りは文書で非同期に進める
障害の振り返りは、文書の下書きを先に共有し、各自がコメントを書いてから短い打ち合わせで決める形にすると、時間帯がそろわないチームでも進めやすくなります。
端末・接続・情報管理で確かめること
- 呼び出しの受け方:呼び出しのアプリを私物のスマートフォンに入れてよいか、貸与の端末を持つか
- 待機中の端末:外出先でも対応できるよう、ノートパソコンと通信の手段を持ち歩く必要があるか
- 本番の権限:障害時だけ権限を上げる運用か、承認者に夜間も連絡が取れるか
- ログの中身:ログに利用者の個人情報が含まれる場合、手元への保存や外部のツールへの貼り付けを認めているか
- 接続の条件:在宅の回線や、外出先の共用のネットワークからの接続を認めているか
総務省の「テレワークセキュリティガイドライン」(第5版、2021年5月公表)は、テレワークでの端末や通信の管理の考え方を整理しています。待機中に外出先から接続する場面が想定されるなら、その条件を参画前に確かめておくことをおすすめします。
リモート案件の探し方
オンコールの経験は「仕組み」とあわせて書く
スキルシートには、オンコールに入った経験だけでなく、アラートを減らした、手順を整えて誰でも対応できるようにした、といった改善の経験をあわせて書くと、リモートでも任せやすい人だと伝わります。書き方はSREのスキルシートの書き方をご覧ください。
オンコールなしの案件も視野に入れる
可観測性の整備やSLOの導入支援など、オンコールを含まない案件もあります。生活の都合で待機が難しい場合は、こうした型の案件を中心に探すと選択肢を絞りやすくなります。クラウドごとの事情はAWSエンジニアのリモート案件の記事やGCPエンジニアのリモート案件の記事を、作業場所などの取引条件の確かめ方はフリーランス法の取引条件の明示の記事をご覧ください。
よくある質問
フルリモートのSRE案件でも夜間の対応はありますか?
あります。出社がなくても、オンコールの当番として夜間や休日の連絡を受ける条件が付くことがあります。リモートかどうかとは別に、待機の時間帯と応答の目安を確かめておきましょう。
オンコールの待機中は自宅にいなければなりませんか?
案件によります。応答の目安が短い案件では、すぐにパソコンを開ける場所にいる必要があります。目安が長めの案件では、ノートパソコンと通信の手段を持ち歩けば外出できることもあります。待機中に何が求められるかを参画前に確かめておくことをおすすめします。
オンコールのないSREの案件はありますか?
あります。監視の仕組みの見直し、SLOの導入支援、リリースの自動化など、仕組みをつくる仕事が中心の案件では、オンコールを含まないことがあります。障害対応への参加の有無を、面談で確かめておきましょう。
参考にした公的情報・資料
記事の内容は公開日時点の情報にもとづきます。制度や税率は変わることがあるため、手続きの前に必ず各機関の最新情報をご確認ください。