フリーランスエンジニアの運用保守案件｜単価相場と契約形態

深夜2時にアラートが鳴り、ノートPCを開いて一次対応を終えたのが3時半。翌朝は通常どおり9時から稼働。月額固定の準委任契約なので、この3時間半に対する報酬は1円も増えません。こうした月が何度か続いたあと、電卓を叩いて実質時給を出してみたら独立前の会社員時代を下回っていた——運用保守案件で働くフリーランスエンジニアから、こうした話は珍しくありません。

検索すると「運用保守はやめとけ」という記事が並びます。ただ、その多くは正社員の転職を前提に書かれていて、「スキルが身につかない」「年収が上がらない」といった一般論で終わっています。フリーランスの当事者が本当に知りたいのは、そこではありません。自分の単価が相場のどこにあるのか、契約書のどの条項が抜けているから夜間対応が無償になっているのか、そして次の更新で何を材料に交渉すればよいのか、です。

運用保守案件の単価が伸びにくいのは事実です。ただし、その原因を「職種の天井」だと考えてしまうと、打つ手がなくなります。実際に手取りを削っているのは相場そのものではなく、契約書に書かれていない時間外・待機対応が無償化される構造と、成果が数値で語れないために交渉材料をつくれない業務構造の2つです。この2つは、どちらも契約条件と実績の可視化で作り替えられます。

本記事では、公開されている単価データで運用保守案件の相場を確定させたうえで、準委任と請負の切り分け方、契約書で必ず詰めるべき5項目、運用の成果を単価交渉に使える数値へ翻訳する手順、そして運用保守を土台にしたキャリア設計までを順に解説します。読み終えたときに、手元の契約書のどこに修正依頼を出すかと、次の更新で何を提示するかが具体的に決まっている状態を目指します。

フリーランスエンジニアの運用保守案件とは｜業務範囲と開発案件との違い

契約や単価の話に入る前に、運用保守案件で自分が何を引き受けているのかを業務単位に分解しておきます。ここが曖昧なままだと、「契約範囲の外にある作業」を指摘すること自体ができなくなるためです。

運用保守エンジニアの主な業務範囲（監視・一次対応・恒久対応・改修）

運用保守エンジニアの案件は、一般に次の4層で構成されます。

注意したいのは、日本語の「運用保守」がこの4層を一語でまとめてしまう点です。英語で言えば、上2層はオペレーション（運用）、下2層はメンテナンス（保守）にあたり、契約上は性質がまったく異なります。上2層は「決められた時間、決められた手順で業務にあたること」が価値であるのに対し、下2層は「問題が解消された状態」が価値になります。

この違いが、後述する準委任と請負の切り分けにそのまま対応します。求人票や契約書に「運用保守業務」としか書かれていない場合、実際にはこの4層すべてが含まれていて、しかも責任の重さが層ごとに違う、という状態が発生します。

開発案件との違い｜成果物がない働き方の特性

運用保守案件と開発案件の違いは、次の3軸で整理すると分かりやすくなります。

1つ目は成果物の有無です。開発案件では「この機能をリリースした」という形で成果が残ります。運用保守では、何事も起きなかった月がもっとも良い月であり、成果が「起きなかったこと」として現れます。これが、あとで単価交渉の材料づくりに直結する構造的な弱点になります。

2つ目は稼働の読みやすさです。開発案件はリリース前に稼働が跳ね上がる一方、運用保守は定常業務の比率が高く、月ごとの稼働が読みやすい傾向があります。長期契約になりやすく、案件が途切れにくいのは運用保守の大きな利点です。ただし「読みやすい」のは定常業務の部分だけで、障害対応は完全に突発です。この突発部分をどう扱うかが契約上の最大の論点になります。

3つ目は責任の終わり方です。開発案件は納品と検収で責任が区切られます。運用保守は契約期間中ずっと責任が続き、しかも「どこまでやれば責任を果たしたことになるのか」が曖昧になりがちです。復旧まで対応するのか、一次切り分けまでなのか。この線引きが書かれていない契約書は、実務上かなり多く見られます。

常駐・リモート・フルリモートで変わる稼働の実態

運用保守案件は、働き方によって稼働の実態が大きく変わります。

常駐案件では、監視オペレーションの当番がシフト制で組まれ、夜勤や交代勤務が発生するケースがあります。この場合は拘束時間が明確な代わりに、拘束時間そのものが長くなりがちです。

一方、フルリモートの運用保守案件では、日中の稼働は柔軟である代わりに、オンコール（待機当番）という形で「呼ばれたら対応する」時間が発生します。拘束時間として見えにくいため、契約書に待機の定義がないまま運用され、実質的に24時間の心理的拘束が生まれることがあります。

つまり、常駐は「拘束が見えるが長い」、フルリモートは「拘束が見えにくいが分散する」という違いです。どちらが良いかは単価だけでは決まらず、待機の頻度と報酬条件をセットで見る必要があります。この点は、次に見る単価データの読み方にも関わってきます。

運用保守エンジニアの単価相場｜働き方・経験年数別のデータ

ここからは、公開されているデータで運用保守案件の相場を確定させます。自分の現在単価が相場のどこに位置するかが分かれば、交渉の出発点が定まります。

運用保守エンジニア案件の平均単価と単価レンジ

フリーランス向け案件検索サイトが公開している集計によると、運用保守エンジニア案件の平均単価は月額67万円、最高単価は140万円です（フリーランスジョブ「運用保守エンジニア案件の平均単価相場」、2026年9月時点）。

実務経験年数ごとの平均単価は同サイトでは「測定中」として公開されていないため、経験年数で単価がどう動くかを公開データから読むことはできません。これは裏を返せば、運用保守という職種では経験年数が単価に自動的に反映されにくい、という市場の実感とも整合します。年数ではなく、担当できる層（前述の4層のうちどこまで担えるか）が単価を決めていると考えたほうが実態に近いでしょう。

平均67万円に対して最高140万円というレンジの広さは重要です。倍以上の開きがあるということは、「運用保守だから単価が上がらない」という説明では説明できない差が市場に存在する、ということを意味します。

常駐・リモート・フルリモートの単価差をどう読むか

同じ集計では、働き方別の平均単価が次のように公開されています。

フルリモートと常駐の差は月額8万円、年間にすると96万円です。この差をどう解釈するかで、取れるアクションが変わります。

単純に「フルリモート案件のほうが高いから乗り換えるべき」と読むのは早計です。フルリモートの運用保守案件は、監視の自動化がある程度進んでいて、手順の実行より判断と改善が求められる現場である傾向があります。つまり単価差は、立地の差というより担当する層の差を反映している可能性が高いと考えられます。

そのうえで、この8万円は交渉可能な差でもあります。現在常駐で参画していて、担当業務のうちリモートで実施できる比率が高いのであれば、「単価を上げてください」ではなく「リモート比率を上げさせてください」という形で交渉すると、発注側にとっても検討しやすい提案になります。稼働場所の条件は単価より合意のハードルが低く、結果として実質時給（移動時間を含めた時間あたりの報酬）を押し上げます。

なお、フリーランス市場全体でもリモート案件のほうが単価が高い傾向は確認されています。エン・ジャパンの定点調査では、2025年12月度のフリーランスエンジニア全体でリモート案件の平均単価が80.2万円、常駐案件が76.6万円と報告されています（エン・ジャパン『フリーランススタート』定点調査レポート）。

開発・インフラ・PM職種との単価比較で見える立ち位置

運用保守の67万円が相対的にどの位置にあるのかを、同一ソースの職種別データで比較します。

（出典: フリーランスジョブ「フリーランスエンジニア案件の平均単価相場（一覧）」 および DevOpsエンジニア案件の平均単価相場、2026年9月時点）

この並びを見ると、運用保守エンジニアの67万円は、バックエンドやインフラよりむしろ高く、DevOps や PM より低い、という位置にあります。「運用保守は最下層」という印象は、少なくとも案件単価の集計上は当てはまりません。

一方、フリーランスエンジニア全体の平均単価は2025年12月度で78.3万円と報告されており、運用保守はここから約11万円下にあります。同じ調査で SRE の平均単価は93.5万円です。

つまり構図はこうです。運用保守そのものが安いのではなく、運用の仕事のうち「判断・自動化・改善」に寄った領域（DevOps・SRE）だけが明確に高く評価されている、ということです。単価を上げる方向は「運用保守から逃げる」ではなく「運用保守の中で高く評価される層に業務の重心を移す」であり、これは後半のキャリア設計の節で具体化します。

職種横断の単価水準をより広く確認したい場合は、フリーランスエンジニア単価を職種別に比較もあわせて参照してください。

「運用保守はやめとけ」の正体｜単価が伸びない構造を分解する

前節のデータからは、「運用保守だから単価が低い」という単純な説明は成り立たないことが分かりました。では、実際に多くの人が感じている閉塞感はどこから来ているのでしょうか。

「やめとけ」と言われる理由を会社員論とフリーランス論に分ける

「運用保守はやめとけ」と書かれた記事で挙げられる理由は、おおむね次の5つに集約されます。

1. スキルが身につかない（定型作業の繰り返し）
2. 夜勤・シフトで生活が不規則になる
3. 年収が上がりにくい
4. 障害対応の精神的負荷が高い
5. 成果が評価されにくい

このうち3の「年収が上がりにくい」は、正社員の給与テーブルを前提とした議論です。会社員であれば、評価制度の中で運用部門が低く格付けされていれば昇給は制度的に制約されます。しかしフリーランスは案件単位で単価が決まるため、この制約はそのまま当てはまりません。

同様に2の「夜勤・シフト」も、常駐の監視オペレーション案件を前提にした話であり、フルリモート・オンコール型の案件では前提が変わります。

一方で、1・4・5はフリーランスにもそのまま残ります。そして、フリーランス特有の問題として、これらに加えて契約に起因する2つの構造が乗ります。これが本質です。

実質時給を削る要因｜契約外のオンコール・夜間対応

1つ目は、契約に書かれていない対応が無償化される構造です。

ここで押さえておきたい前提があります。フリーランスは業務委託契約の当事者であり、労働基準法上の労働者ではありません。したがって、労働基準法が定める時間外・深夜・休日の割増賃金の規定は適用されません。つまり、深夜に3時間対応しても、契約書に時間外の報酬条件が書かれていなければ、追加報酬は発生しないのが原則です。

これは発注側が意地悪をしているというより、月額固定の準委任契約で「業務内容: システムの運用保守」とだけ書かれている場合、時間外対応も「運用保守」に含まれると読めてしまう、という契約設計上の問題です。

実質時給への影響を具体的に見てみます。

さらに、待機（オンコール）そのものは稼働時間に計上されないことが多いにもかかわらず、当番の日は飲酒や遠出ができず、実質的には拘束されています。この「見えない拘束」を時間換算に入れると、実質時給の低下はさらに大きくなります。

重要なのは、この低下が相場の問題ではなく契約の問題であるという点です。月額65万円という金額自体は平均67万円と大きく変わりません。削られているのは分母のほうです。

単価が据え置かれる要因｜成果が数値で語れない業務構造

2つ目は、成果が数値化されないために交渉材料がつくれない構造です。

開発案件であれば、更新交渉の場で「この機能を設計から実装まで担当し、リリースしました」と説明できます。運用保守では、同じ調子で話すと「毎日監視を行い、障害時には対応しました」となり、契約時に期待されていた内容をそのまま述べているだけになります。発注側から見れば、単価を上げる理由がどこにも提示されていません。

そして「何も起きなかった」ことの価値は、放っておくと誰も数えません。アラートの誤検知を減らした、手順書を整備して属人性を解消した、繰り返し発生していた障害を恒久対応で止めた——こうした改善は確実に発注側の利益になっていますが、数値として記録されていなければ交渉の場には出てこないのです。

結論として、運用保守で単価が伸びない主因は「職種の天井」ではなく、(1) 契約範囲が曖昧で時間外が無償化される、(2) 成果が数値化されず交渉材料がない、という2点に絞り込めます。どちらも自分の側から動かせる要因です。次節以降で、それぞれへの具体的な打ち手を見ていきます。

運用保守案件の契約形態｜準委任・請負の違いと選び方

(1) の「契約範囲が曖昧」を解消するには、まず自分の契約が法的にどういう構造になっているかを理解する必要があります。

準委任契約と請負契約の違い｜責任範囲はどこで切れるか

システム開発・運用の業務委託で使われる契約類型は、主に請負契約と準委任契約の2つです。

（条文は民法（e-Gov 法令検索）を参照）

ポイントは「善管注意義務」の意味です。準委任契約で負うのは、善良な管理者の注意をもって業務にあたる義務であり、結果を出す義務ではありません。したがって、準委任契約の運用保守エンジニアは、適切な手順で適切に対応した以上、復旧しなかったこと自体の責任は負わないのが原則です。

にもかかわらず「準委任なのに復旧完了まで責任を負わされている」と感じるケースが多いのは、契約書の業務内容欄に「障害発生時はサービス復旧まで対応する」といった完成義務に近い文言が混ざっているか、あるいは業務内容が「運用保守一式」としか書かれておらず、現場の運用で結果責任が事実上追加されているかのどちらかです。

準委任と請負で報酬水準がどう変わるかについては、準委任と請負でエンジニア単価はどう変わる？で契約形態そのものの選び方を整理しています。本記事では、運用保守という業務特性に固有の論点に絞って続けます。

運用保守で準委任が選ばれる理由と、請負が混ざるケース

運用保守で準委任が選ばれるのには合理的な理由があります。監視や一次対応は、いつ何が起きるかを事前に定義できないため、「仕事の完成」を契約時に特定できません。特定できないものを請負にすると、範囲の解釈で必ず揉めます。だから業務遂行型の準委任が選ばれます。

問題は、そこに請負的な業務が混ざり込むときです。典型的には次のケースです。

• 恒久対応: 障害の根本原因を修正する作業。これは「修正されている状態」という成果があるため、本来は請負または成果完成型の準委任で切り出すのが自然です
• 機能改修・追加開発: 運用の延長で依頼される軽微改修。件数が増えると実質的な開発案件になりますが、月額固定の準委任に吸収されると無償の追加作業になります
• 移行・リプレイス作業: 期間と成果が明確な作業。運用保守契約に含めると、通常の運用業務が圧迫されます

これらが月額固定の準委任契約に無定義で入り込むと、「準委任なのに成果責任を負い、かつ作業量が増えても報酬は変わらない」という、もっとも不利な状態が生まれます。

対処の方向は2つです。1つは、契約書の業務内容欄で層ごとに業務を列挙し、恒久対応・改修は別途協議または別契約とすると明記すること。もう1つは、一定の工数を超える作業は追加精算の対象とする条項を入れることです。いずれも「請負にしてください」という話ではなく、「準委任の範囲を明確にしてください」という依頼として伝えられます。

フリーランス新法の書面明示義務で確認できること

2024年11月1日に施行された「特定受託事業者に係る取引の適正化等に関する法律」（フリーランス・事業者間取引適正化等法、いわゆるフリーランス新法）は、こうした曖昧さを是正するうえで使える根拠になります。

同法では、発注事業者がフリーランスに業務委託をした場合、書面または電磁的方法により、直ちに取引条件を明示することが義務づけられています。明示すべき事項には、給付の内容（業務の内容）、報酬の額、支払期日、業務委託をした日、給付を受領する日などが含まれます（公正取引委員会「フリーランスの取引適正化に向けた公正取引委員会の取組」）。

実務上、ここで効いてくるのが「給付の内容」の明示です。業務の内容が特定されていなければ明示義務を満たしたとは言いにくく、「運用保守一式」のような記載に対して具体化を求める根拠になります。交渉の場で法律名を振りかざす必要はありませんが、「業務内容の明示について、対応範囲を具体化していただけますか」という依頼は、法の趣旨に沿った正当な要請です。

同法ではこのほか、報酬の支払期日を給付を受領した日から60日以内に設定する義務、募集情報の的確表示義務、6か月以上の継続的業務委託について中途解除・不更新の際に原則30日前までに予告する義務、育児・介護との両立への配慮義務、ハラスメント対策の体制整備義務などが定められています。運用保守案件は長期契約になりやすいため、6か月以上の継続的業務委託に関する規定は自分の案件に当てはまるケースが多いはずです。

契約書で必ず詰める5項目｜稼働時間・オンコール・SLA・時間外・引き継ぎ

ここからが実務の中核です。手元の契約書（または次回更新の契約書案）を開いて、以下の5項目が書かれているかを確認してください。書かれていない項目が、そのまま実質時給を削っているポイントになります。

稼働時間の精算幅（下限・上限）と超過分の単価

確認すること: 月間の精算幅（例: 140〜180時間）と、下限を下回った場合の控除単価、上限を超えた場合の超過単価が明記されているか。

書かれていない場合に起きること: 繁忙月に200時間稼働しても報酬は変わりません。逆に、閑散月に130時間しか稼働しなかった場合に報酬を減額される可能性も残ります。つまり、発注側にとってだけ有利な状態になります。

修正依頼の伝え方: 「稼働時間の精算幅を契約書に明記していただけますか。下限140時間・上限180時間、超過分は時間単価◯◯円での精算を想定しています」。超過単価は、月額 ÷ 精算幅の中央値で算出した時間単価を目安にすると説明しやすくなります。月額65万円・精算幅140〜180時間なら中央値160時間で約4,060円です。

夜間・休日対応とオンコール待機の報酬条件

ここは2つに分けて考える必要があります。実際に対応した時間の報酬と、待機していた時間そのものの報酬は別物です。

確認すること（対応時間）: 所定時間外（夜間・休日）に障害対応を行った場合の報酬が定められているか。通常の時間単価と同額か、割増率が設定されているか。

確認すること（待機）: オンコール当番の頻度に上限があるか（例: 月◯日まで）。待機自体に対する手当があるか。当番中に対応が発生しなかった場合の扱いはどうか。

書かれていない場合に起きること: 前節で見たとおり、フリーランスには労働基準法の割増賃金規定が適用されないため、契約に定めがなければ夜間対応も待機も無償です。しかも当番の頻度に上限がなければ、体制の都合で当番が増えても報酬は一定のままです。

修正依頼の伝え方: 「所定時間外の障害対応について、対応時間の精算条件を定めていただけますか。あわせて、オンコール当番の頻度上限と待機手当についても取り決めをお願いしたいです」。待機手当の相場は案件によって幅がありますが、一律の金額を求めるより「当番1日あたり◯◯円」または「当番日数に応じた月額加算」という形で提案すると合意に至りやすくなります。

金額での合意が難しい場合は、当番日数の上限設定と当番翌日の稼働免除（深夜対応が発生した場合、翌日の稼働時間から控除する）という形での交換条件も有効です。報酬総額を変えずに実質時給を改善できます。

SLA・復旧目標と責任範囲の線引き

確認すること: サービスレベル（復旧目標時間・応答時間など）が定められている場合、それが「努力目標」なのか「達成義務」なのか。未達時のペナルティ条項があるか。一次対応（切り分け・暫定復旧）と恒久対応（根本原因の修正）のどちらまでが受託範囲か。

書かれていない場合に起きること: 準委任契約であるにもかかわらず、現場の運用で復旧完了までの結果責任を負う状態が固定化します。また、恒久対応が受託範囲に含まれるかが曖昧なまま、実質的な開発作業が無償で積み上がります。

修正依頼の伝え方: 「本契約は準委任であり、善管注意義務の範囲で業務を遂行するものと理解しています。復旧目標時間については達成義務ではなく努力目標として整理し、一次対応までを受託範囲、恒久対応は都度協議とする旨を明記していただけますか」。

なお、SLA が定められていること自体は悪いことではありません。むしろ、目標値が明示されていれば「目標を上回って運用している」という形で後述の実績数値化に使えます。問題は、目標が義務として扱われ、かつ未達時のリスクだけを受託側が負う構造です。

引き継ぎ・再委託・契約終了時の取り決め

確認すること: 契約終了時の引き継ぎ期間と、その期間の報酬が定められているか。引き継ぎ資料の作成範囲はどこまでか。再委託（他のフリーランスへの一部委託）が認められているか。

書かれていない場合に起きること: 契約終了時に「引き継ぎ資料を作ってから終わってください」と言われ、契約期間外の無償作業が発生します。運用保守は属人化しやすいため、この要求は現実によく発生します。

修正依頼の伝え方: 「契約終了時の引き継ぎについて、引き継ぎ期間と対象範囲を定めていただけますか。引き継ぎ期間も通常の稼働として精算対象に含める整理でお願いしたいです」。

また、6か月以上の継続的業務委託にあたる場合、発注側は中途解除・不更新の際に原則30日前までの予告が必要です。この予告義務はフリーランス新法に基づくものであり、契約書に書かれていなくても適用されます。次の案件を探す時間を確保できるという意味で、自分の側の権利として知っておく価値があります。

5項目チェックリスト

5項目すべてが埋まっている契約書は多くありません。すべてを一度に通そうとするより、実質時給への影響が大きい順（多くの場合は2・3・1）に優先順位をつけて交渉するほうが現実的です。

運用保守で単価を上げる交渉｜実績を数値に翻訳する

契約条件を整えたうえで、次は (2) の「成果が数値化されない」問題に取り組みます。

運用の成果を数値化する5つの指標

運用保守の成果は、次の5つの指標に翻訳できます。いずれも発注側のコストや事業リスクに直結するため、単価交渉の材料として説明しやすいものです。

1. インシデント件数の削減 参画時点と現在で、月あたりの障害件数を比較します。「月平均12件だったインシデントを、恒久対応と監視ルール見直しにより月平均4件まで削減」のように示します。

2. MTTR（平均復旧時間）の短縮 障害発生から復旧までの平均時間です。「MTTR を平均90分から35分に短縮」と言えれば、サービス停止時間の短縮という形で事業インパクトに換算できます。

3. 自動化による工数削減 手作業で実施していた定型作業をスクリプト化・自動化した場合、削減された月次工数を記録します。「月次のバッチ確認作業を自動化し、月8時間の工数を削減」。この数値は、そのまま発注側のコスト削減額に換算できます。

4. アラート精度の改善（誤検知の削減） 監視ルールを調整して誤検知を減らした成果です。「誤検知アラートを月120件から月18件へ削減」。夜間の無駄な起床が減るという意味で、自分自身の労働環境改善にも直結します。

5. 属人性の解消（ドキュメント整備） 手順書・構成図・障害対応フローの整備件数です。「未整備だった運用手順書を23本作成し、一次対応の他メンバー実施可能率を100%に」。発注側にとっては継続性リスクの低減にあたります。

これらを記録するために、特別な仕組みは必要ありません。月末に15分だけ時間を取り、その月のインシデント件数・対応時間・実施した改善を簡単な表に追記していくだけで、半年後には十分な交渉材料になります。重要なのは、参画直後にベースラインを取っておくことです。比較対象がなければ「削減した」と言えません。すでに参画中で記録がない場合は、今月を起点に記録を始めてください。

契約更新の交渉タイミングと提示の組み立て

交渉を持ち出すタイミングは、契約更新の1〜2か月前が適切です。更新直前では発注側に予算調整の余地がなく、早すぎると実績の締まりが悪くなります。

提示の組み立ては、次の4ステップが有効です。

1. 実績の提示: 前節の5指標のうち、動かせた2〜3個を数値で示す
2. 役割の変化の提示: 参画時と比べて担当範囲がどう広がったかを述べる（一次対応のみ → 恒久対応・改善提案まで、など）
3. 相場の提示: 公開データに基づく相場感を示す（運用保守エンジニアの平均67万円、DevOps 領域は79万円、など）
4. 提案: 単価の希望額と、その根拠の要約

ここで押さえておきたいのは、3の相場提示だけで交渉しないことです。「相場が67万円なので上げてください」は、発注側にとって受け入れる理由になりません。1と2で「この案件においてあなたの価値が上がった」ことを示したうえで、3で「その価値は市場ではこの水準です」と接続する順序が重要です。

契約更新そのものを有利に進める考え方については、フリーランス案件の契約更新術で長期継続の観点から整理しています。

単価以外で取りに行く条件（待機手当・リモート比率・稼働下限）

単価の増額は、発注側の予算枠に直接影響するため、もっとも合意ハードルが高い項目です。交渉が難航した場合に備えて、単価以外のカードを用意しておくと結果的に実質時給を改善できます。

現実的な進め方は、単価増額を主目的として提示しつつ、難しい場合の代替案としてハードルの低いカードを用意しておくことです。「単価が難しい場合、当番日数の上限設定と翌日の稼働免除という形でご検討いただけますか」という二段構えにすると、交渉が決裂せずに何らかの改善を持ち帰れます。

運用保守案件を踏み台にするキャリア設計｜SRE・インフラ・上流への接続

最後に、中長期の視点を整理します。運用保守を「抜け出す対象」ではなく、継続的に案件を獲得しながらスキルを積み増す土台として設計する方法です。

運用保守で積み増せるスキルと単価への反映

前半で確認したとおり、運用保守エンジニアの平均単価は67万円、DevOps エンジニアは79万円、SRE は93.5万円でした。この階段は、担当する業務の性質が「手順の実行」から「判断と自動化」へ移るにつれて単価が上がる、という構造を表しています。

運用保守の現場にいながら積み増せるスキルは、この移行に直結します。

いずれも、現在の運用業務の延長線上で着手できます。しかも、これらの取り組みは前節の「実績の数値化」とそのまま重なります。つまり、単価交渉の材料をつくる行為と、次のキャリアに必要なスキルを積む行為が同じになるのが、運用保守という領域の利点です。

スキルが積み上がる現場かを見極める3つの基準

とはいえ、どの運用保守案件でもこれができるわけではありません。案件を選ぶ段階で、次の3点を確認してください。

1. 改善提案が通る余地があるか 監視ルールの変更や自動化の提案が、手続き上どう扱われるかを確認します。「提案は歓迎するが承認に3か月かかる」「運用設計は元請けの担当で受託側は実行のみ」という現場では、改善の実績をつくれません。面談時に「運用改善の提案はどのようなプロセスで進みますか」と聞くのが端的です。

2. 定型監視のみか、判断を求められる業務が含まれるか 手順書どおりの実行だけを求められる案件は、稼働は安定しますがスキルは積み上がりません。業務内容に恒久対応・設計変更・障害分析が含まれているかを確認します。

3. 技術スタックが更新されているか 運用対象のシステムが直近1〜2年で更新されているか、監視基盤やデプロイの仕組みが現代的かを確認します。10年前の構成をそのまま維持し続ける案件は、市場価値の観点では投資効率が低くなります。面談時に「監視基盤は何をお使いですか」「直近で構成に変更はありましたか」と聞けば、おおむね判断できます。

この3点のうち2つ以上が満たされない案件は、単価が相場並みであっても長期で参画する価値が下がります。逆に3点を満たす案件であれば、単価が相場をやや下回っていても、実績を積んで更新時に引き上げる戦略が取れます。

案件ポートフォリオとしての運用保守の位置づけ

運用保守案件には、開発案件にはない明確な利点があります。長期契約になりやすく、稼働が読みやすく、案件が途切れにくいことです。フリーランスにとって収入の断絶はもっとも大きなリスクであり、この安定性には実質的な価値があります。

一方で、運用保守だけに依存すると、その案件が終了したときに提示できる実績が「運用していました」に偏ります。現実的な設計は、次のどちらかです。

パターンA: 運用保守を主軸にし、現場内で役割を拡張する 週5で運用保守案件に参画しつつ、監視設計・自動化・改善提案へ業務の重心を移していく形です。案件を変えずに単価と市場価値を上げられるため、負荷が低く、契約更新のたびに条件を積み上げられます。前節の3基準を満たす現場であれば、この戦略がもっとも効率的です。

パターンB: 運用保守を基盤にし、稼働の一部を開発・改善案件に充てる 週4で運用保守案件、週1で別の開発案件という組み合わせです。収入のベースを運用保守で確保しつつ、開発の実績も並行して積めます。契約上、副業・兼業が制限されていないか（専従義務の条項がないか）を事前に確認する必要があります。

いずれのパターンでも、前提になるのは契約条件の整備です。夜間対応とオンコールが無制限に降ってくる契約のままでは、役割を拡張する時間も、別案件に充てる稼働も確保できません。契約の整理が、キャリア設計の前提条件になります。

まとめ｜運用保守案件を「安定かつ伸びる案件」にする手順

本記事の内容を、実行順に整理します。

ステップ1: 相場における自分の位置を確認する 運用保守エンジニア案件の平均単価は月額67万円、最高140万円、働き方別ではフルリモート71万円・リモート可69万円・常駐63万円です。フリーランスエンジニア全体の平均は78.3万円、DevOps は79万円、SRE は93.5万円。自分の現在単価がこの分布のどこにあるかを把握します。

ステップ2: 契約書の5項目を点検する 稼働時間の精算幅、時間外対応の報酬条件、オンコール待機の頻度上限と手当、SLA と責任範囲の線引き、引き継ぎ・再委託の取り決め。この5つのうち書かれていない項目が、実質時給を削っている箇所です。

ステップ3: 実績の記録を今月から始める インシデント件数、MTTR、自動化による工数削減、アラート精度、ドキュメント整備件数。参画直後であればベースラインを、すでに参画中であれば今月を起点に記録を開始します。

ステップ4: 契約更新の1〜2か月前に交渉する 実績 → 役割の変化 → 相場 → 提案の順で組み立てます。単価が難しい場合の代替カード（当番上限・翌日稼働免除・リモート比率・稼働下限）も併せて用意します。

ステップ5: 次の案件選定基準を更新する 改善提案が通るか、判断を求められる業務が含まれるか、技術スタックが更新されているか。この3点で案件を選べば、運用保守を続けながら単価と市場価値を同時に上げられます。

明日から着手できる最初の一手は、ステップ2です。手元の契約書を開き、5項目チェックリストで空欄を数えてください。空欄がゼロなら、あなたの実質時給は相場どおりに守られています。空欄が3つ以上あるなら、単価の問題ではなく契約の問題を抱えている可能性が高い状態です。次の更新までに、どの空欄から埋めるかを決めるところから始めましょう。

運用保守は「やめとけ」と言われがちな領域ですが、その評価の多くは正社員の昇給構造を前提にしたものです。案件単位で条件を決められるフリーランスにとって、長期契約になりやすく稼働が読みやすい運用保守は、条件を整えさえすれば収入の安定と市場価値の向上を両立できる働き方になります。

関連情報

運用保守を含むフリーランス案件を探している方は、Workee（フリーランス向け）で案件の条件や契約形態を確認いただけます。契約条件を比較しながら案件を検討したい場合にご活用ください。