SREのフリーランス案件｜報酬の決まり方と単価を上げる考え方

SREのフリーランス案件の報酬は、信頼性の改善を任されるのか運用を回すことが中心なのか、機能開発と信頼性の作業の優先度を決める場に加われるか、オンコールの待機と対応をどう扱うか、基盤技術の経験、自分がいなくても回る仕組みを残せるかで決まります。SREの単価について公的な統計はなく、案件ごとに大きく変わります。

SREの案件は、名前が同じでも中身の差が大きい職種です。単価を上げるには、障害に強い人であることより、障害が起きにくく、起きても早く戻せる仕組みを作り、その効果を説明できる人であることを示すのが近道です。

SREの報酬は「改善の裁量」で差がつく

SREの案件は、おおむね次の3つに分かれます。

報酬を大きく分けるのは、技術の難しさより、改善のために使える時間と裁量があるかです。運用の対応に追われて改善に手が回らない案件では、経験を積んでも説明できる成果が残りにくくなります。応募の前に、日々の時間のうち改善に使える割合や、開発チームとの関係を確かめておくと、案件の中身が見えてきます。案件の型ごとに求められる経験はSREがフリーランスになるにはで整理しています。

報酬を左右する主な要素

1. 優先度を決める場に加われるか

SLOとエラーバジェットを使って、「今は機能開発より信頼性の作業を優先する」と開発チームと合意する役割は、SREらしい仕事の中心です。この判断の場に加われる案件は、責任も大きく、報酬にも表れやすくなります。反対に、決まった作業を依頼されて実行するだけの立場では、裁量が小さくなります。

2. オンコールの負担と扱い

障害時の呼び出しを含むかどうかは、報酬と働き方の両方に大きく影響します。扱いの考え方は次の章で詳しく説明します。

3. 基盤技術の幅

Kubernetes、IaC、CI/CD、監視やトレースの仕組みなど、SREの案件で使う技術は幅広くあります。どれか一つを深く、他を一通り扱える人は、参画できる案件が広がります。技術ごとに求められる水準はSREの案件で求められるスキルにまとめています。

4. 仕組みを残して手放せるか

フリーランスのSREは、いずれ現場を離れることを前提に関わります。そのため、自分の作業を減らすだけでなく、社員のチームが続けられる形で仕組みと文書を残せる人は、発注側にとって価値が高くなります。「自分がいないと回らない」状態は、短期的には頼られても、長い目で見ると評価につながりにくいことがあります。

5. どのクラウド・どの規模か

基盤のクラウドや、サービスの利用者の規模によっても、求められる経験は変わります。クラウドごとの報酬の考え方はAWSエンジニアの報酬の記事やGCPエンジニアの報酬の記事も参考になります。

オンコールの扱いが報酬の実質を決める

Googleがまとめた書籍『Site Reliability Engineering』のオンコールの章では、SREの時間の少なくとも50%をエンジニアリングに充て、残りのうちオンコールに使うのは25%までとする考え方が紹介されています。また、業務時間外の対応には十分な補償を考えるべきだとし、Googleでは代休か金銭で補償し、その補償に上限を設けていること、その上限が実質的に一人が引き受けるオンコールの量の上限になっていることが書かれています。

これは会社員のSREについての考え方ですが、フリーランスにとっても、オンコールは量を区切り、報酬との関係を決めておくものだという点で参考になります。オンコールを含む案件では、次の時間をどう扱うかを分けて確かめましょう。

待機は、実際に作業をしていなくても、外出や予定が制限されます。待機をまったく報酬に反映しない契約では、呼び出しが少ない月でも負担だけが残ります。反対に、待機に報酬がある代わりに、対応の時間は月額に含める決め方もあります。どれがよいかは、呼び出しの頻度と、当番を交代する人数によって変わります。

精算の仕組みは精算幅の記事で解説しています。

面談で確かめておきたいこと

SREの案件は、募集の文面だけでは中身が分かりにくいため、面談で次の点を聞いておくと、提示額の理由を読み取りやすくなります。

1. 参画後に最初に期待されている成果は何か（導入か、改善か、運用の安定か）
2. SLOや監視の指標は決まっているか。決まっていないなら、決める役割を担うのか
3. 開発チームとの定例や、優先度を決める場に参加するか
4. 一日の時間のうち、運用の対応と改善の作業がおおよそどのくらいの割合か
5. オンコールの当番の人数と頻度、待機と対応の扱い

これらの答えによって、同じ月額でも、積める経験と負担の大きさが変わります。

報酬が伸びにくいパターン

• アラートの対応に一日の大半を使っている：改善の成果が残らない
• SLOや優先度の話し合いに呼ばれない：裁量が小さく、SREとしての経験を説明しにくい
• 作業が自分にしか分からない：属人化し、引き継ぎができない
• オンコールの負担が契約に反映されていない：月額が同じでも実質の報酬が下がっている

単価を上げるための考え方

改善の成果を数字で残す

通知の件数、復旧までの時間、手作業にかかっていた時間、リリースの失敗の割合など、改善の前後で比べられる指標を記録しておきます。守秘義務の範囲で、割合や傾向として説明できる形にしておくと、次の案件でも更新の相談でも使えます。

運用の担い手から改善の担い手へ

運用が中心の案件に入っている場合でも、繰り返し起きる作業を自動化する、通知の条件を見直すといった小さな改善から始めると、次の案件で示せる経験が増えます。

オンコールの設計そのものを担う

当番の組み方、通知の段階、手順書の整備など、オンコールの仕組みを作る側に回ると、障害対応の経験が組織づくりの経験に変わります。

更新の前に条件を相談する

担当が改善や導入に広がったときや、オンコールの負担が参画時の想定と変わったときは、条件の見直しを相談する材料になります。呼び出しの回数や対応の時間を記録しておくと説明しやすくなります。伝え方は単価交渉の記事にまとめています。

よくある質問

SREの単価の相場はいくらですか？

SREの単価について公的な統計はなく、案件の型、裁量の大きさ、オンコールの有無と扱い、基盤技術の経験、稼働日数、商流によって大きく変わります。相場の数字より、ご自身の経験が導入・改善・運用のどれに近いかを整理し、オンコールの扱いまでそろえて比べるほうが判断の材料になります。

オンコールのない案件は報酬が低くなりますか？

オンコールの有無だけで決まるわけではありません。導入や改善が中心で、日中の作業だけの案件もあります。ただ、オンコールを含む案件では、その負担が報酬に反映されることがあるため、比べるときは負担と報酬の関係を分けて考えましょう。

インフラ運用の経験からSREの案件に移ると、報酬は上がりますか？

肩書きが変わるだけでは上がるとは限りません。運用の中で改善や自動化に取り組み、その成果を説明できるようになると、改善を任される案件に進みやすくなります。示し方はSREのスキルシートの記事で解説しています。