本業のオンコール明けの朝、副業の依頼文に「障害対応を含む」の一文を見つけて、画面を閉じかけました。本業の当番と重なって、どちらも回らなくなるのではないか。そう身構えながら添付の課題一覧を開くと、並んでいたのは「アラートが多すぎて誰も見ていない」「復旧の手順書が古い」「障害の振り返りが書かれていない」の3つです。SREの副業は、障害の最中ではなく、障害の前と後を受けます。

1. 本業と重なる場面、重ならない場面

障害の時間軸で仕事を分ける

SREの仕事は、障害を軸にすると前・最中・後の3つに分けて考えられます。この分け方は資料に書かれたものではなく、書き手の見立てです。副業で受ける仕事を選ぶための整理として使います。

前は、障害が起きていない間に進める仕事です。アラートの見直し、手順書の整備、手順の自動化がここに入ります。いつ着手していつ納めるかを、発注側と相談して決められます。

最中は、初動とオンコールです。障害は予定を聞いてから起きてくれないので、始まる時刻を選べません。時刻に縛られるのは、三つの局面のうちここだけです。

後は、真因分析と再発防止の振り返りです。障害が収まってから、日程を組んで進めます。報告書や振り返りの記入様式のように、成果物の形で区切りやすい仕事が中心です。

図の作成：Remogu編集部。書き手の見立てを整理したもので、統計データではありません

本業のオンコールとぶつかるのは最中

本業で当番を持つ人が副業で困るのは、最中が重なったときです。本業の当番中に副業先からも呼ばれれば、どちらかの対応を諦めることになります。不安の正体は、この一点にあります。

一方、前と後の仕事は、本業の当番がない日の夜や週末に進める形も組めます。成果物と納期を先に決めておけば、障害の発生時刻に左右されません。ただし、納期が本業の大きな障害の直後に重なれば、遅れる可能性は残ります。

そのため、依頼文の「障害対応を含む」の一文は、それだけで判断せずに中身を確かめます。最中まで含むのか、前と後だけなのかで、本業との重なり方がまったく違うからです。確かめる項目は、この記事の後半で整理します。

では、障害の対応はどんな局面に分けて考えられているのでしょうか。金融庁が示した例を見てみます。

2. 障害対応の局面の分け方

金融庁が示した机上演習の進め方の例

金融庁は「金融分野におけるITレジリエンスに関する分析レポート」（2026年7月）で、パブリッククラウドに起因する障害を想定した机上演習のシナリオづくりについて触れています。例として、フェーズを「初動」「業務継続確保」「復旧」「真因分析・再発防止」に分けることが考えられるとしています¹。

これは演習シナリオをつくるときの例です。障害対応の決まった型でも、守るべき基準でもありません。想定しているのも、パブリッククラウドに起因する障害という限られた場面です。

SREの現場全体が、この4つの局面で動いているという意味でもありません。この記事では、障害の対応を時間の順に分けて考えるときの手がかりとして、この例を借ります。

局面ごとの中身と副業との相性

初動・業務継続確保・復旧の3つは、障害が起きている間に進む局面です。その場で動ける人が要るため、時刻を選べません。真因分析・再発防止は、障害が収まったあとに進む局面で、日程を決めて取り組めます。相性の列は書き手の見立てで、資料の記述ではありません。

局面	中身	副業との相性（見立て）
初動	障害が起きた直後の対応	その場に居る人が要る
業務継続確保	業務を止めないための対応	その場に居る人が要る
復旧	サービスを使える状態へ戻す対応	その場に居る人が要る
真因分析・再発防止	原因を突き止め、同じことを繰り返さない手を考える	あとから時間を決めて進められる

障害の前は4つの局面に入っていない

この4つの局面は、障害が起きてからの流れです。監視の見直しや手順書の整備のような、障害の前の仕事は入っていません。副業で受けやすいと見ている前の仕事は、次の節以降の課題点や事例から拾います。

局面を分けて見ると、副業で受けやすいのは後ろの1つと、演習の外にある前の仕事だと分かります。最中の3つを持たない形で、どんな仕事が頼まれているのかを次に確かめます。

3. 計画と振り返りが置き去りになる課題

金融庁が金融機関で認めた課題点

金融庁は同じレポートで、金融機関のサイバーインシデント対応の課題点を挙げています。重要なシステムが更改されているのにインシデント対応計画等を更新していないなど、実効性を欠く事例が認められたとしています¹。

同じ課題点には、もう1つの事例も挙がっています。国内外の拠点やサードパーティでサイバーインシデントが起きているのに、原因分析と再発防止策の検討・実施が十分でない事例です¹。

ここで話しているのは、金融機関のサイバーインシデント対応です。システム障害一般の話ではなく、どれだけの金融機関に当てはまるのかも、この記事で使う箇所には書かれていません。

課題点を前と後の仕事に置き直す

この2つの課題点を、前節の時間軸に置き直します。更新されていない計画や手順は障害の前の仕事、十分でない原因分析と再発防止は障害の後の仕事にあたります。この対応づけは書き手の見立てです。

出典：金融庁「金融分野におけるITレジリエンスに関する分析レポート」（2026年7月）をもとに作成。右側は書き手の見立てです

障害の前と後の仕事は、手が回らず後回しになりやすい、と見ています。障害が起きていない間は急ぎに見えず、起きたあとは復旧が優先されるためです。金融庁が理由まで述べているわけではないので、ここも書き手の見立てです。

後回しになりやすい仕事は、外から手を借りやすい仕事でもあります。計画の更新なら更新した手順書、原因分析なら報告書のように、成果物の形で区切れるからです。副業として受ける場合も、この区切りやすさが条件を決める助けになります。

では、障害の前に何を整えておけたのでしょうか。金融庁の事例集に、2件の事例があります。

4. 事例集の2件から見る、障害の前の備え

APIサーバーの再起動の事例

金融庁の事例集には、金融機関でAPIサーバーの再起動の手順に漏れがあり、出金サービスが使えなくなった事例があります。原因の1つとして、サーバーの再起動手順の不備が挙げられています¹。

同じ事例の対策には、作業手順書の作成段階のチェック体制の強化や、再起動時の対応手順の自動化などが挙げられています¹。手順書は書いて終わりではなく、作る段階で確かめる体制が対策に入っています。

これは1件の事例です。原因も対策もここで挙げたのは一部で、ほかにも資料には書かれています。手順を自動化していれば障害を防げた、と読むのは資料の範囲を超えます。

ネットワーク機器の間欠障害の事例

もう1件は、金融機関でネットワーク機器の間欠障害により決済業務が不可となった事例です。原因として挙がったことのうちに、予兆監視を十分に実施していなかったことと、ネットワーク障害時の復旧手順書を整備していなかったことがあります¹。

対策の1つとして、ネットワーク機器を予兆監視の対象に加えることが挙げられています¹。監視する対象の見直しが、そのまま対策の一部になっています。

この事例にも、ほかの原因と対策が資料にあります。ここで取り上げたのは、障害の前に整えられる部分だけです。予兆監視を入れていれば防げたと言い切ることは、できません。

事例の原因と、受けられる仕事の形

2件の事例を並べると、原因として挙がったことの一部が、手順書と監視という障害の前の仕事に当たります。表の左の3列は資料に書かれた内容、右端の列は書き手の見立てです。見立ての列は、副業でその仕事を受けるとしたらどんな成果物になるかを考えた例で、資料が副業を勧めているわけではありません。

事例	原因として挙がったこと	資料にある対策	受けられる仕事の形（見立て）
APIサーバーの再起動で出金サービスが使えなくなった	サーバーの再起動手順の不備	作業手順書の作成段階のチェック体制の強化、再起動時の対応手順の自動化など	手順書の見直し、手順の自動化
ネットワーク機器の間欠障害で決済業務が不可となった	予兆監視を十分に実施していなかったこと、ネットワーク障害時の復旧手順書を整備していなかったこと	ネットワーク機器を予兆監視の対象に加えること（対策の1つ）	監視の対象の見直し、復旧手順書の整備

障害の前の仕事は、手順書・監視・自動化という具体的な成果物に落とせます。では、副業ではどんな形でその成果物を受けられるのでしょうか。次の節で仕事の形ごとに整理します。

5. 副業で受けやすい仕事の形

成果物で区切れる4つの形

前節の事例で障害の前に整えられる部分として見えたのは、手順書と監視と自動化でした。ここから先は資料の話ではなく、書き手の見立てです。その仕事を副業として受けるなら、どんな形と成果物が考えられるかを4つに整理します。

1つ目は、監視の見直しです。いまあるアラートを一覧にして、鳴りすぎているものと見られていないものを仕分け、見直し案にまとめます。冒頭の課題一覧にあった「アラートが多すぎて誰も見ていない」に当たる仕事です。

2つ目は、手順書の自動化です。古くなった復旧の手順書を現状に合わせて更新し、繰り返す手順はスクリプトにします。成果物は、動くスクリプトと更新した手順書の2点です。

3つ目は、振り返りの型づくりです。障害が起きたあとに何を書き、誰が何を決めるかを、記入様式と進め方にまとめます。「障害の振り返りが書かれていない」状態に対して、書ける仕組みを置く仕事です。

4つ目は、SLOの下書きです。サービスの信頼性を測る指標と目標の案を作ります。ただし、どの水準を目標にするかを決めるのは発注側です。決め方は、SREの信頼性の目標を誰が決めるかで整理しています。

図の作成：Remogu編集部。書き手の見立てを整理したもので、統計データではありません

区切りやすさが条件を決める

4つに共通するのは、納めるものが先に決まる点です。アラートの一覧も更新した手順書も記入様式も、完成の形を依頼の段階で言葉にできます。完成の形が決まれば、いつ作業するかは本業の予定に合わせて組めます。

一方、依頼文に「障害対応を含む」とだけあって成果物が書かれていない場合は、最中を含んでいる可能性があります。そのときは、前と後の仕事だけに絞れないか相談します。絞れるなら受けやすくなり、絞れないなら見送る判断も残ります。

とはいえ、前と後の仕事なら誰でも同じ条件で受けられるわけではありません。本番環境にどこまで触るかで、必要な権限も、連絡の取り方も変わります。受ける前に何を決めておくかを、次の節でまとめます。

6. 受ける前に決めておくこと

障害時に呼ばれるかどうか

最初に決めたいのは、障害が起きたときに呼ばれるかどうかです。呼ばれない前提で受けたのに、障害の最中に連絡が来る。この食い違いが、冒頭の不安の中身でした。

「呼ばれない」は、口約束にしません。契約書や依頼の文書に、障害対応はこの委託の範囲に含まない、と書いて残すのが確実です。ここは資料にある話ではなく、書き手の見立てです。

もし最中を含む依頼なら、当番の体制を先に確かめます。誰が当番を持ち、副業のメンバーはどの順番で呼ばれるのか。確かめ方は案件の障害の当番は誰が持つのかにまとめています。

権限・成果物・連絡・期間・秘密保持

障害の前と後の仕事でも、決めておきたいことは残ります。次の表は、書き手の見立てとして6つの項目を並べたものです。例は考え方を示すためのもので、実際の条件は案件ごとに異なります。法律上の義務の中身は、この表では扱いません。

決めること	例	残し方（見立て）
障害時に呼ばれるか	障害の最中の対応は委託の範囲に含めない	契約書か依頼の文書に書く
本番環境の権限	読み取りだけにするか、変更も行うか	権限の範囲を一覧にして共有する
成果物の形と区切り	アラートの一覧、更新した手順書、記入様式	完成の形と納める日を先に書く
連絡の時間帯	平日の夜や休日に返信が要るか	返信の目安の時間を決める
契約の期間と更新	期間の終わりと、更新するときの進め方	期間と更新の扱いを文書にする
秘密保持の範囲	見てよい資料と、持ち出さない情報	対象の情報を具体的に書く

6つのうち、本業と重なりやすいのは連絡の時間帯です。本業の当番の日に副業先から返信を求められると、同じ不安がまた起きます。返信の目安を「翌営業日の夕方まで」のように時間で決めておくと、本業の当番と分けて動けます。

権限も、見落としたくない項目です。本番環境に変更を加えられる権限を持てば、障害の最中に頼られる立場になりやすくなります。読み取りだけで足りる仕事なら、その範囲に絞る相談ができます。

本業の取り決めを確かめる

もう1つ、本業側の取り決めも確かめます。副業を始められるかどうかや、届け出の要否は、本業の取り決めで決まります。この記事では本業の取り決めの中身には触れません。受ける前に、自分で読み直してください。

ここまで挙げた項目は、どれも依頼を受ける前に決められます。では、実際にどの順番で決めていけば、本業のオンコールと並べられるのでしょうか。最後に、受け方の順番を整理します。

7. 本業と並べるための受け方

決める順番を4つに分ける

ここまでの内容を順番に直すと、4つの手順になります。順番は書き手の見立てです。先に決めたことが、あとの項目の前提になるように並べています。

図の作成：Remogu編集部。書き手の見立てを整理したもので、統計データではありません

1つ目で障害の前か後かを選ぶと、2つ目で成果物を決めやすくなります。最中を持たない仕事に絞れば、納めるものは手順書や一覧のように形のあるものになるからです。成果物が決まれば、必要な権限も絞れます。

3つ目の連絡の時間帯は、本業の当番の予定と並べて決めます。4つ目の契約の期間は、最後に確かめます。期間の終わりと更新の扱いが書かれていれば、本業の状況が変わったときにも話し合いの出発点になります。

事例から借りるのは、前と後の仕事だけ

金融庁の資料から使えるのは、課題点と2件の事例の範囲です。計画や手順が更新されていない事例、原因分析と再発防止が十分でない事例、手順書の不備と予兆監視の不十分が原因に挙がった事例がありました¹。

これらはいずれも金融機関の話で、SRE全体の傾向を示すものではありません。副業で障害の前と後を受けられる、という整理も資料の結論ではなく、この記事の見立てです。その前提のうえで、冒頭の3つの課題は、いずれも成果物で区切れる仕事に見えます。

障害の前と後を受ける

本業のオンコール明けの朝に見た「障害対応を含む」の一文は、依頼文を読み進めて中身を確かめれば、不安の種にならない場合があります。確かめるのは、障害の最中を含むのか、前と後だけなのかです。含まないなら、手順書や監視の見直しのように、成果物で区切れる仕事が並んでいます。

Remogu（株式会社LASSIC運営）は、リモートワーク案件特化のエンジニアマッチングで、案件の90%以上がフルリモート可能です。本業の当番の合間に、場所を選ばず進められる案件を探せます。まず登録して、自分の経験に合う条件を確かめてみてください。

SREの副業は、障害の最中ではなく、障害の前と後を受けます。

8. よくある質問

インフラエンジニアでもSREの副業を受けられますか

受けられる仕事はあります。ただし、これは書き手の見立てで、資料に書かれた話ではありません。監視の見直しや手順書の自動化は、運用の経験がそのまま生きる仕事です。

案件によって求める経験は異なります。依頼文の成果物と、本番環境に触る範囲を読んで、自分の経験と合うかを見ます。

オンコールを含む案件を受けるなら何を確かめますか

当番の体制と、自分がどの順番で呼ばれるかを確かめます。あわせて、連絡の時間帯と、本業の当番と重なったときの扱いを文書に残します。これも書き手の見立てです。

体制の確かめ方は案件の障害の当番は誰が持つのかにまとめています。

土日だけで受けられる仕事はありますか

成果物で区切れる仕事なら、土日に進める形を組みやすくなります。アラートの見直しや手順書の整備は、完成の形を先に決められるためです。これも書き手の見立てで、案件ごとに条件は異なります。

一方、障害の最中の対応は、土日だけでは受けられません。依頼文に最中が含まれていないかを、先に確かめます。

※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

出典・参考情報

＊1 金融庁「金融分野におけるITレジリエンスに関する分析レポート」（2026年7月・2026年10月確認）