SREのフリーランス案件で求められるスキルと経験

SREのフリーランス案件では、利用者の体験から指標を選び、SLOとエラーバジェットで「直すか、進めるか」を判断する力、障害の原因を追える可観測性の設計、壊れても戻せるリリースの仕組み、繰り返しの運用作業をコードで減らす力が見られます。KubernetesやIaCなどの道具の経験は前提として確認されますが、評価の分かれ目になるのは、信頼性を数字で語り、開発チームと合意を作れるかです。

SREの案件の型や、インフラ運用・バックエンドから目指すときの進め方、オンコールの契約上の注意はSREがフリーランスになるにはで扱っています。この記事では、スキルの中身と、その示し方を深掘りします。

SREの案件で見られるスキルの全体像

SREはインフラとソフトウェア開発の間にある仕事です。どちらの出身かによって得意な分野が違うため、自分の軸の分野と、補っている途中の分野を分けて説明すると、案件側も役割を想像しやすくなります。

SLIの選び方とエラーバジェットの使い方

GoogleのSREの書籍では、SLIはサービスの水準のある側面を定量的に測る指標、SLOはSLIで測る目標の値や範囲、SLAは目標を満たせなかったときの結果を含む利用者との約束と説明されています。また、100%の達成を求めるのは現実的でも望ましくもなく、目標を外してよい幅（エラーバジェット）を持ち、その残りを新しいリリースを出すかどうかの判断に使う考え方が示されています。

案件で問われるのは、この定義を知っていることではなく、実際のサービスで何をSLIにしたかです。

• サーバーのCPU使用率ではなく、利用者が受け取った応答の成功率や速さを測った
• 「トップページ」「決済」など、利用者にとって重みの違う機能ごとに指標を分けた
• 今の実績がそうだからという理由で目標を決めず、緩めの目標から始めて見直した
• エラーバジェットを使い切りそうなときに、機能の追加より安定化を優先する取り決めを作った

書籍でも、今の性能を満たしているというだけで目標を決めないこと、緩い目標から始めて締めていくこと、SLOの数は少なく定義は簡潔に保つことが勧められています。こうした判断を、開発チームや事業側とどう合意したかまで話せると、外部から入るSREとしての動き方が伝わります。

可観測性を設計する力

可観測性の案件では、監視の道具を入れることより、障害が起きたときに「どこで、なぜ」を短い時間でたどれる状態を作ることが求められます。

OpenTelemetryは、トレース・指標・ログの3種類のデータを生成・収集・送信するためのフレームワークで、CNCF（Cloud Native Computing Foundation）のプロジェクトです。公式の説明では、OpenTelemetry自体はデータを保存・表示する仕組みではなく、オープンソースや商用のさまざまな保存先と組み合わせて使うとされています。特定の監視サービスに縛られずにデータを集める方法として、導入を検討する現場が増えています。

案件で評価されやすい経験は次のようなものです。

• サービスをまたぐ処理にトレースを入れ、遅い箇所を特定できるようにした
• ログに処理の識別子を入れ、指標・ログ・トレースを行き来できるようにした
• 鳴りすぎていたアラートを、利用者への影響を基準に絞り込んだ
• 監視データの量と費用を見て、保存の期間や間引きの方針を決めた

アラートの見直しは、SREの案件で最初に任されることの多い仕事です。「このアラートが鳴ったら、誰が何をするのか」が決まっていないアラートを減らした経験は、具体的に話せる材料になります。

壊れても戻せるリリースの仕組み

障害の多くは変更をきっかけに起きます。そのため、SREの案件では、変更を安全に出す仕組みづくりがよく求められます。

• 一部の利用者にだけ新しい版を出し、指標を見てから広げる段階的な公開
• 指標が悪化したときに、自動で前の版に戻す仕組み
• 設定の変更も、コードと同じようにレビューと記録を通す運用
• データベースの変更を、前の版のアプリでも動く形に分けて出す手順

ここで差がつくのは、戻せない変更をどう扱ったかです。データの形を変える変更や、外部サービスとの契約に関わる変更など、切り戻しが難しいものを見分け、出し方を変えた経験は、設計の深さとして伝わります。

トイルを減らす力

SREの書籍では、トイル（労苦）を、手作業で、繰り返し発生し、自動化でき、その場しのぎで、終わっても価値が残らず、サービスの規模に比例して増える作業と説明しています。そのうえで、SREの時間のうち運用作業を半分未満に保つことを目標にしています。

案件で評価されるのは、作業を自動にしたことより、作業そのものが要らなくなるように設計を変えた経験です。たとえば、証明書の更新を手順書から自動の仕組みに変える、容量の追加を手作業から自動の拡張に変える、問い合わせのたびに行っていた調査を利用者が自分で見られる画面に変える、といったものです。自動化のコードを、ほかの人が保守できる形で残したかも確認されます。

障害対応を仕組みにする力

障害対応では、技術の力に加え、初動の進め方が確認されます。指揮をとる人、調査する人、関係者へ知らせる人の役割を分ける、記録を時系列で残す、復旧と原因の調査を分けて進める、といった動き方です。

振り返りでは、個人の責任を問わず、仕組みの改善につなげる書き方が求められます。再発防止の対策が、実際に実施されたかを追いかける仕組みまで作った経験は、組織の運用を変えた実績として評価されます。

認定資格の位置づけ

SREに直結する資格は多くありませんが、基盤の技術を示す材料として、Kubernetesの実技試験であるCKAがあります。概要はSREがフリーランスになるにはで紹介しています。

クラウドの資格では、Google CloudのProfessional Cloud DevOps Engineerが、SREのプラクティスの適用、CI/CDパイプラインの構築、オブザーバビリティの実装と問題のトラブルシューティング、パフォーマンスと費用の最適化などを評価するとされています。推奨される経験は、Google Cloudでの本番システムの設計・管理1年以上を含む業界経験3年以上です（2026年10月時点のGoogle Cloudの案内による）。

資格は知識の裏付けになりますが、SREの案件では、実際の運用で何を判断したかが中心に問われます。

スキルシートと面談での示し方

SREの経験は、使った道具より、何を測り、何を決め、何が変わったかを書くと伝わります。

• 応答の成功率をSLIにし、SLOの残りを見てリリースの判断をする運用を作った
• 主要な処理にトレースを入れ、障害の原因を特定するまでの時間を短くした
• 段階的な公開と自動の切り戻しを入れ、変更による障害の影響を小さくした
• 手作業の証明書更新をなくし、関連する問い合わせ対応をなくした

面談では、「最近の障害で何をしたか」「SLOをどう決めたか」がよく聞かれます。書き方の詳細はSREのスキルシートの書き方、報酬との関係はSREの報酬の記事をご覧ください。

よくある質問

SLOを運用した経験がないとSREの案件は難しいですか？

SLOの運用経験がなくても、監視の改善や自動化の経験で参画できる案件はあります。そのうえで、担当しているサービスで利用者から見た指標を一つ決め、測ってみるだけでも、面談で具体的に話せる材料になります。

プログラミングはどこまで求められますか？

運用のためのツールや自動化のコードを、ほかの人が保守できる形で書けることが求められます。GoやPythonなどで、テストを書き、レビューを通す開発の進め方に慣れておくと、参画できる案件が広がります。

OpenTelemetryの経験は必須ですか？

必須とされる案件ばかりではありません。ただ、特定の監視サービスに縛られない計測の方法として広がっているため、トレースの仕組みと、指標・ログとの関係を理解しておくと、可観測性の案件で説明しやすくなります。