インフラ・SREの案件に参画すると、稼働時間の見積もりが定例業務のようにはいかない場面に出会うことがあります。監視は止まらず、障害はカレンダーの都合を待ってくれません。「稼働時間はどのくらいですか」と聞かれても、平常時の数字だけでは答えたことになりません。稼働が伸びる場面をあらかじめ具体的に思い浮かべておかないと、契約が始まってから想定外の負担だけが積み上がってしまいます。

この記事では、インフラ・SRE領域の案件で稼働時間が読みにくくなる場面を洗い出し、契約前に決めておきたい条件を整理します。単価の話に入る前に、まず「時間」の前提を詰める視点を大切にします。条件が言葉になっていれば、稼働が伸びたときも、慌てて交渉をやり直す必要はなくなります。

1. インフラの案件が「時間の契約」になりやすい理由

システム開発の多くは、要件から成果物を定義し、その完成をもって区切りがつきます。ところがインフラ・SREの領域では、システムは公開したあとも動き続けるため、成果物という区切りを置きにくくなります。結果として契約は、「何を作るか」ではなく「どれだけの時間、状態を保つか」という単位で組まれやすくなります。

社内に運用を任せられる人材が不足している

IPAの調査によると、日本企業の85.1%でDXを推進する人材が不足していると報告されています¹。新しい機能を作る人材だけでなく、すでに動いているシステムを保守し続ける人材も、社内では十分に確保できていない企業が少なくありません。だからこそ運用を外部のエンジニアに委ねる案件が生まれ、その契約は稼働できる時間そのものを軸に組まれることになります。

社内に運用の担い手が少ないほど、外部のエンジニアに委ねる稼働の幅は広くなりがちです。裏を返せば、案件を選ぶ側にとっては、運用を任せてもらえる領域が広い分だけ、稼働の輪郭を自分から確認しておく必要がある、ということでもあります。

パッチ適用の窓は、予定どおりにやってこない

IPAが公表した「情報セキュリティ10大脅威 2026」では、システムの脆弱性を悪用した攻撃が組織向けの脅威の第4位に挙げられています³。脆弱性の情報は公開されてから悪用されるまでの期間が読めず、パッチを適用する窓は業務都合のカレンダーとは無関係に開きます。平常時の稼働時間だけを前提に契約すると、この窓への対応がどちらの負担になるのか曖昧なまま案件が進んでしまいます。

パッチの適用そのものは短時間で終わることもありますが、適用前の検証、適用後の動作確認、問題が起きたときの切り戻しまで含めると、実際にかかる時間は当初の見立てより膨らみやすくなります。窓が開くタイミングを事前に知ることはできなくても、窓が開いたときに何をどこまで担うのかは、契約前に決めておける部分です。

稼働時間を「月に何時間」という数字だけで確認することよりも、稼働がどの場面で膨らむのかを尋ねることのほうが、実態に近づきます。まずは、稼働がどう動くのかを時間の流れで見てみましょう。

図の作成：Remogu編集部。稼働が膨らむタイミングを整理したもので、統計データではありません

平常時の山は低くても、リリースや障害の場面では稼働が跳ね上がります。この跳ね上がり方を具体的に見ていくと、稼働時間が読めなくなる場面は3つに整理できます。

2. 稼働時間が読めなくなる3つの場面

稼働が読めなくなる場面は、案件によってばらばらに起きるものではなく、共通して起きやすい3つに整理できます。場面ごとに何が起きるかを把握しておくと、契約前の質問がぐっと具体的になります。

【表1】稼働時間が読めなくなる3つの場面

以下は、インフラ・SREの案件で稼働時間が伸びやすい3つの場面について、実際に何が起きるか、そしてなぜ時間が読みにくくなるのかという要因まで分けて整理したものです。契約前にこの3つを思い浮かべておくと、稼働時間を尋ねる質問の解像度が上がります。上から順に、対応の緊急度が高い場面から並べました。

場面	何が起きるか	時間が伸びる要因
障害対応	発生時刻を選べず、原因の切り分けに時間がかかる	影響範囲の確認と一次対応の完了までを見届ける必要がある
リリース・変更作業	検証環境と本番環境の差分で想定外の手順が発生する	切り戻しの判断まで含めると作業時間が延びやすい
移行・切替	旧環境と新環境を並行して見る期間が生じる	切替直後は監視から目を離せない時間が続く

たとえば障害対応では、一次切り分けの担当が決まっていても、原因が想定より深い場所にある場合、対応時間はどこまでも延びていきます。切り分けをどこで区切り、どこから先を引き継ぐのかという線引きがなければ、稼働時間は際限なく膨らんでしまいます。リリース・変更作業では、手順書どおりに進めば短時間で終わりますが、想定外の挙動が出た瞬間に切り戻しの判断が入り、確認の往復だけで時間が積み上がります。移行・切替も同様に、切替直後の監視期間をどこまでの稼働として数えるかが曖昧だと、落ち着いたはずの時間に気づかず稼働し続けることになります。

3つの場面に共通するのは、始まりの合図がこちらの都合で決まらないという点です。障害はカレンダーを選ばず、リリースの手順は検証環境と本番環境の差でずれ、移行の並行期間は計画より長引くことがあります。稼働時間を「何時間ですか」と数字だけで確認しても、こうした場面の扱いまでは分かりません。次は、この3つの場面を前提に、契約前に決めておきたい条件を具体的に見ていきます。

3. 契約前に決めておく条件

ここからが本題です。3つの場面で稼働が伸びること自体は避けられません。避けられるのは、伸びたときにどちらがどこまで動くのかが決まっていない状態です。次の5つの条件は、契約前に言葉にしておくと、あとで揉めにくくなります。

【表2】契約前に決めておきたい5つの条件

以下は、稼働時間が読めなくなる場面に備えて、契約前に確認しておきたい5つの条件を、確認しなかった場合に起きることと、実際にどう聞けばよいかという例まで並べて整理したものです。条件名を覚えることよりも、右側の聞き方をそのまま使ってみることのほうが、契約前の会話では役に立ちます。

決める条件	確認しないと起きること	実際の聞き方の例
対応時間帯と連絡手段	深夜や休日の連絡が稼働に含まれるのか曖昧になる	「緊急連絡は何時まで、どの手段で届きますか」
障害時の一次対応の範囲	切り分けまで担うのか、報告だけなのかがずれる	「一次対応はどこまでを担当範囲としますか」
作業の事前承認の経路	承認待ちの時間が稼働に含まれるかが不明なまま進む	「変更作業の承認は誰に、どのくらい前に相談しますか」
稼働上限を超えたときの扱い	超過分の扱いが決まらず、あとから交渉になる	「稼働上限を超えた場合の扱いは決まっていますか」
引き継ぎ・待機の位置づけ	待機している時間が稼働に数えられるか曖昧になる	「待機の時間は稼働に含まれますか」

5つの条件はどれも、契約書の条文というよりも、日々のやり取りのルールに近いものです。特に「稼働上限を超えたときの扱い」は、金額だけでなく、誰が超過を判断し、どのタイミングで知らせるかまで含めて確認しておくと、実際に上限へ近づいたときに慌てずに済みます。「引き継ぎ・待機の位置づけ」も見落とされがちな条件です。次の担当にすぐ引き継げる状態で待つ時間なのか、自分がいつでも一次対応に入れる状態で待つ時間なのかによって、負担の重さはまったく異なります。

5つの条件を眺めると、共通しているのは「誰の担当範囲か」という線引きであることに気づきます。この線引きを、参画する側とクライアントの側で分けて見てみましょう。

自分の範囲とクライアントの範囲を分けておく

一次切り分けやパッチ適用の実務は担っていても、体制の最終判断や契約条件の見直しはクライアント側に残る、という分け方が実務では多く見られます。ただし、この境界線は案件によって位置が動くため、契約前に一度言葉で確認しておく価値があります。

図の作成：Remogu編集部。責任範囲の分け方を整理したもので、統計データではありません

境界そのものは案件ごとに動きますが、境界の位置を事前に言葉にしておくかどうかは、参画する側で決められることです。表2の5条件を、この境界を確認する質問として使ってみてください。

境界の位置は、案件の規模や体制によっても変わります。少人数の体制ほど、自分が担う範囲が広がりやすい傾向があるため、体制の規模を尋ねることも、境界を把握する手がかりの一つになります。

境界と条件を言葉にできれば、あとはその条件がリモートの働き方の中でも成立するかどうかを確認する段階に進みます。

4. リモートで成立させるための前提

条件を決めても、それを実行する手段が整っていなければ、絵に描いた取り決めで終わります。リモートで運用を担うには、権限・通知・記録という3つの前提が整っている必要があります。

【表3】リモートで成立させるための3つの前提

以下は、リモートで運用を任せてもらう際に確認しておきたい3つの前提について、何を確認すればよいか、整っていない場合にどう代替できるかまで整理したものです。前提が完全に整っていない案件もありますが、代替の手段があるかどうかまで含めて確認すると、参画の判断がしやすくなります。

前提	確認すること	整っていない場合の代替
アクセス権の付与方法	必要な権限がいつ、誰の承認で付与されるか	一時的な権限昇格の手順で代替する
監視・通知の受け取り方	アラートがどの経路でどの範囲まで届くか	委任先を経由した通知の転送設定で補う
記録の残し方	対応の経緯をどこにどう残すか	作業後に自分の側でも記録を控えておく

IPAの「情報セキュリティ10大脅威 2026」では、リモートワーク等の環境や仕組みを狙った攻撃が、組織向けの脅威の第8位に挙げられています²。これは、リモートでの参画自体を避ける理由にはなりません。むしろ、だからこそアクセス権や監視の経路をあらかじめ細かく決めておく案件が増えている、と捉えるほうが実態に近い説明です。前提さえ整っていれば、リモートでの運用は十分に成立します。

監視の通知ひとつをとっても、一次受信者が誰になるか、深夜のアラートをどの経路で受け取るかによって、実際の負担は大きく変わります。仕組みが整っていない場合でも、委任先を経由した転送のように、当面をしのぐ代替が用意できるかどうかを確認しておくと安心です。記録の残し方も同様で、対応の経緯を残す場所が決まっていないと、あとから同じ問い合わせに何度も答えることになりかねません。

Remoguが扱う案件は、90%以上がフルリモート可能です⁵。ただし、前提がどこまで整っているかは案件によって差があるため、契約前に表3の3点を確認しておくと、参画してからの見え方のずれを防げます。前提が整い、稼働の範囲と条件が固まると、次に動くのは報酬の話です。

5. 条件を詰めると、報酬の前提も変わる

対応時間帯や稼働上限が曖昧なまま報酬の交渉に入ると、双方が思い描く前提がずれたまま金額だけが独り歩きします。稼働の幅が決まって初めて、報酬の話も具体的になります。

Remoguが実案件2,450件(2023年1月〜2024年2月・支払上限金額から算出)を分析した調査では、フリーランスエンジニア全体の平均月額報酬は約76.5万円で⁴、職種別ではCTO・VPoE・テックリードが約98.9万円で1位です⁴。これはインフラ・SRE単独の水準を示す数字ではなく、責任の範囲が明確な職種ほど高い基準線に位置するという、報酬全体の傾向を示すものです。

出典：Remogu「職種別・言語別の月額報酬ランキング」調査（2024年／実案件2,450件・支払上限金額から算出）をもとに作成

基準線が高い側に共通するのは、任される範囲が明確で、意思決定にまで関わっているという点です。稼働の境界を自分の言葉で説明できる状態は、単価交渉の場でも、担ってきた責任の範囲を裏付ける材料になります。

基準線の高さを見ることよりも、自分の案件がどちらの前提に近いかを確かめることのほうが、報酬の話を具体的にします。最後に、契約前に決める5条件のうち、どこまで決め終わっているかを確認しておきましょう。

契約前に決めた条件を、抜け漏れなく確認する

5つの条件は、一度にすべて決まるとは限りません。案件によっては、対応時間帯だけ決まっていて、稼働上限を超えたときの扱いは未確定のまま契約が始まることもあります。図4は、5条件がどこまで決まっているかを確認する例です。

図の作成：Remogu編集部。契約前に確認する5条件の状態を例として示したもので、統計データではありません

図4の例のように、5条件のうち2つしか決まっていない状態で契約に入るケースは珍しくありません。未確定の項目が多いほど、稼働が伸びたときに交渉からやり直すことになります。契約前の面談で、5条件のうちどこが決まっていて、どこが未確定かを一つずつ確認してみましょう。

6. まとめ

稼働時間は、契約が始まってから確認するものではなく、契約する前に言葉にしておくものです。単価の交渉よりも先に、稼働の境界を決める会話のほうが、結果として双方の納得につながります。5つの条件は、一度にすべてを詰めきる必要はありません。まずは表2の中から、いまの案件で最も曖昧になっている1つを選び、次の面談で確認してみましょう。次に案件の話を聞く機会があれば、まずどの条件が決まっていて、どこが未確定なのか、確認してみませんか。

7. よくある質問

Q1．運用の経験だけで参画できますか。

表1・表2で挙げた場面や条件は、開発の経験の有無よりも、運用を担った経験があれば具体的にイメージできる内容です。運用の経験を軸に、契約前の質問を用意しておくと、参画の判断がしやすくなります。開発と運用の両方を担ってきた経験があれば、それも条件を確認する際の材料として使えます。

Q2．障害対応は必ず含まれますか。

案件によって異なります。含まれる場合は、表2の「障害時の一次対応の範囲」をどこまで担当するか、契約前に確認しておくと、実際に障害が起きたときの認識のずれを防げます。一次対応のみなのか、原因の切り分けまで含むのかによって、想定しておく稼働の幅は変わります。

Q3．稼働上限を超えたらどうなりますか。

これも案件ごとに扱いが異なります。表2で挙げたとおり、超過分の扱いを契約前に確認しておかないと、対応したあとで交渉になりやすい項目です。稼働上限に近づいた時点で早めに相談する運用にしておくことも一つの方法です。誰が超過を判断するのかまで決めておくと、上限に近づいたときの連絡もスムーズになります。

Q4．アクセス権がなかなか下りない場合はどうすればよいですか。

表3で挙げた代替のとおり、一時的な権限昇格の手順や、委任先を経由した通知の転送で当面をしのぐ方法があります。恒久的な権限の付与には時間がかかることも珍しくないため、代替の運用をあらかじめ聞いておくと安心です。参画の初期段階で代替の手段まで確認しておけば、権限が下りるまでの間も稼働が止まらずに済みます。

Q5．IaCの経験は必須ですか。

必須かどうかは案件によって異なります。ただし、構成をコード化して管理してきた経験があると、権限設定や監視のルールを言葉で説明する場面がスムーズに進みやすくなります。表3の前提を確認する会話の中で、どこまでコード化されているかを尋ねてみるとよいでしょう。コード化が進んでいない案件では、記録の残し方そのものを一緒に整えていく関わり方も考えられます。

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

出典・参考情報

＊1 IPA「DX動向2025（AI時代のデジタル人材育成）」ディスカッション・ペーパー（2025年10月9日）
＊2 IPA「情報セキュリティ10大脅威 2026」組織向け脅威（2026年1月29日）
＊3 IPA「情報セキュリティ10大脅威 2026」組織向け脅威（2026年1月29日）
＊4 Remogu「職種別・言語別の月額報酬ランキング」調査（実案件2,450件・2023年1月〜2024年2月・支払上限金額から算出）（2024年）
＊5 Remoguサイト公開情報（フルリモート可能案件の割合）