SREがフリーランスになるには|必要な経験と独立までの進め方
公開 2026-10-29 監修:株式会社エージェントベスト
SREとしてフリーランスになるには、サービスの信頼性を数字で定義し、障害から学んだことを開発チームと一緒に仕組みへ反映した経験が必要です。インフラを運用してきたことだけでは、SREの案件で求められる役割と合わないことがあります。
一方で、「SRE」という名前の案件でも中身はさまざまです。独立の準備は、自分の経験がどの型の案件に近いかを見きわめ、足りない実績を在職中に補うところから始めると進めやすくなります。
SREの案件は名前が同じでも中身が違う
SREの業務委託案件は、発注側がどんな課題を抱えているかで、仕事の中身が大きく変わります。
| 案件の型 | 発注側の課題 | 主な仕事 |
|---|---|---|
| 信頼性の改善 | 障害が多い、原因が分からない | SLOの設定、監視の見直し、障害の振り返りの仕組みづくり |
| 可観測性の整備 | ログやメトリクスが散らばっている | 収集の設計、ダッシュボード、アラートの整理 |
| プラットフォーム整備 | 開発チームごとにデプロイの方法が違う | コンテナ基盤、CI/CD、共通の仕組みづくり |
| SREチームの立ち上げ | 運用を担う体制がない | 役割の定義、オンコール体制、運用ルールの整備 |
| 運用寄りのSRE | 既存の基盤を安定して回したい | 監視、障害対応、定型作業の自動化 |
面談の前に、案件の説明から「どの課題を解決するために人を探しているのか」を読み取っておくと、自分の経験のどこを話すべきかが見えてきます。
SREの案件で問われる経験
GoogleがまとめたSREの書籍『Site Reliability Engineering』では、サービスレベル目標(SLO)、トイル(繰り返しの手作業)の削減、オンコール、障害から学ぶポストモーテムの文化などが章として取り上げられています。案件の面談でも、これらを実務でどう扱ったかが問われます。
SLOを決めて運用した経験
「可用性を高めた」ではなく、何を指標にし、目標をどう決め、目標を割り込みそうなときに誰とどう判断したかを話せることが大切です。エラーバジェット(目標に対して許される失敗の幅)を使って、機能開発と信頼性の作業の優先順位を開発チームと話し合った経験は、SREらしい実績として評価されます。
トイルを減らした経験
手作業で繰り返していた運用を、どう見つけ、どう自動化し、どれだけ手間が減ったかを説明できるようにしておきます。数字は守秘義務の範囲で、「週に何回の作業がなくなった」程度の伝え方でも十分です。
障害の振り返りを仕組みにした経験
個人を責めない形で障害の記録を書き、再発防止策を追いかけて完了させた経験は、どの型の案件でも話題になります。振り返りの書式や会議の進め方を整えた経験があれば、立ち上げ型の案件でも生かせます。
基盤の技術
Kubernetesなどのコンテナ基盤、IaC、CI/CD、監視の道具の経験は多くの案件で求められます。Kubernetesの知識を示す資格としては、Linux FoundationとCNCFが作成したCKA(Certified Kubernetes Administrator)があり、オンラインで実技形式の試験を受け、認定の有効期間は2年とされています(2026年10月時点の公式サイトによる)。
インフラ運用やバックエンドからSREを目指すとき
SREの案件に参画する人は、インフラ運用の出身者と、バックエンド開発の出身者が多い傾向があります。出身によって、強みと補うべき点が違います。
| 出身 | 強み | 在職中に補いたいこと |
|---|---|---|
| インフラ運用 | 障害対応、ネットワークやOSの知識、監視 | コードでの自動化、開発チームとの合意づくり、SLOの考え方 |
| バックエンド開発 | アプリケーションの理解、コードを書く力 | 本番運用、オンコール、インフラとネットワークの基礎 |
| クラウドの構築 | IaC、構成の設計 | 運用後の改善、指標の設計、障害の振り返り |
在職中にできることとして、所属チームでSLOを試しに決めてみる、障害の振り返りの書き手を引き受ける、繰り返しの作業をひとつ自動化する、といった小さな取り組みがあります。小さくても「自分で始めて、続けた」経験は、独立後の説明材料になります。
外から参画するSREが気をつけること
SREの仕事は、組織の習慣や開発の進め方を変えることを含みます。業務委託として外から入る場合、社内の人よりも次の点に気を配る必要があります。
- 決める権限は発注側にある:SLOやリリースの方針は、発注側の責任者が決める。提案と合意の材料づくりに徹する
- 権限は段階的に広がる:最初は閲覧だけで、本番の変更は依頼する形のこともある
- 残るものを意識する:手順書、ダッシュボード、SLOの文書など、契約が終わっても発注側が使い続けられる形で残す
- 一人に依存させない:自分がいないと回らない仕組みは、発注側にとってリスクになる
契約の終わりを見すえて引き継げる形で仕事を残す人は、次の案件の紹介や契約の更新につながりやすくなります。
オンコールと契約の確認
SREの案件では、障害時の呼び出し(オンコール)を含むことがあります。オンコールは稼働時間や生活への影響が大きいため、参画の前に次の点を確かめておきましょう。
- オンコールの有無と、当番の頻度・時間帯
- 待機している時間と、実際に対応した時間を稼働時間にどう含めるか
- 精算幅を超えたときの扱い
- 対応できないときの代わりの体制
精算の仕組みは精算幅の記事で解説しています。2024年11月に施行されたフリーランス法では、発注側は業務の内容・報酬の額・支払期日などを書面やメールなどで直ちに明示することが求められています。また、6か月以上の委託を途中で解除するときなどには、原則として少なくとも30日前の予告が必要とされています。受け取るべき条件はフリーランス新法の取引条件の明示にまとめています。
面談で聞かれやすいこと
| 質問の例 | 見られていること |
|---|---|
| どのサービスで、何を指標にSLOを決めましたか | 信頼性を数字で扱った経験があるか |
| 目標を割り込みそうなとき、どう判断しましたか | 開発チームや責任者と合意を作れるか |
| 減らしたトイルの例を教えてください | 繰り返しの作業を見つけて自動化できるか |
| 印象に残っている障害と、その振り返りを教えてください | 原因の分析と再発防止を最後まで追えたか |
| 監視やアラートをどう見直しましたか | 鳴りすぎ・見逃しを減らす工夫ができるか |
答えは、課題、取り組み、結果の順で話すと伝わりやすくなります。守秘義務で具体的な数字を出せない場合も、「何を測り、何を変えたか」は一般化して話せます。
独立までの進め方
- 経験を型ごとに整理する:上の表のどの型の案件に近いかを決め、関わったサービスごとに、指標・改善・障害対応の経験を書き出す
- スキルシートを用意する:道具の名前より、課題・取り組み・結果の順で書く。書き方はSREのスキルシートの記事で解説している
- 条件を決める:稼働日数、リモートの希望、オンコールを受けるかどうか、報酬の下限。報酬の考え方はSREの報酬の記事を参照
- 手続きとお金を準備する:退職前後の手続きは会社員からフリーランスになる手順、開業届は開業届の出し方を参照
- 案件を探す:探し方はフリーランスエージェントの使い方を参照
クラウドの構築から入る道筋はAWSエンジニアがフリーランスになるにはも参考になります。
よくある質問
SREの肩書きで働いた経験がなくても案件に応募できますか?
応募はできます。案件側が見るのは肩書きより、SLOの考え方、自動化、障害の振り返りなどを実務でどう扱ったかです。インフラ運用やバックエンド開発の中で、SREに近い取り組みをしていれば、その内容を具体的に整理して伝えましょう。
Kubernetesの経験は必須ですか?
案件によります。コンテナ基盤の整備が中心の案件では求められることが多い一方、可観測性や障害対応の仕組みづくりが中心の案件では、必須ではないこともあります。案件の型を見て、必要な経験を判断してください。
オンコールのない案件はありますか?
あります。可観測性の整備やプラットフォームづくりなど、改善が中心の案件では、オンコールを含まないこともあります。オンコールを受けたくない場合は、最初に条件として伝えておくと、合わない案件に時間を使わずに済みます。
参考にした公的情報・資料
- Site Reliability Engineering 目次(Google)
- Certified Kubernetes Administrator(The Linux Foundation)
- フリーランス法特設サイト(公正取引委員会)
記事の内容は公開日時点の情報にもとづきます。制度や税率は変わることがあるため、手続きの前に必ず各機関の最新情報をご確認ください。