Kubernetesエンジニアがフリーランスになるには|必要な経験と独立までの進め方
公開 2026-10-29 監修:株式会社エージェントベスト
Kubernetesエンジニアとしてフリーランスになるには、本番のクラスターを運用した経験、障害のときに原因を自分で切り分けた経験、版上げを計画から実施まで一通り担った経験の3つが目安になります。チュートリアルどおりにクラスターを作れることより、動いている本番を壊さずに変えた経験が先に見られます。
業務委託では、参画した翌週から既存のクラスターを任されることが珍しくありません。この記事では、案件の型ごとに必要な経験、在職中に積んでおきたい実績、独立前の準備を順に整理します。報酬の決まり方はKubernetesエンジニアの報酬の記事で扱っています。
独立の目安は「本番を壊さずに変えた」経験
会社員としてKubernetesに関わっていても、関わり方によって独立のしやすさは変わります。
| 関わり方 | 独立の目安としての見え方 |
|---|---|
| 用意されたクラスターにアプリをデプロイしていた | 利用者としての経験。基盤側の案件ではもう一歩必要 |
| 決まった手順で設定変更や運用をしていた | 運用の案件には入りやすい。原因の切り分けを話せるかが鍵 |
| 障害の原因を調べ、設定や構成を直した | 運用・改善の案件で評価されやすい |
| 版上げや構成の変更を計画し、実施した | 改善・移行の案件に入りやすい |
| クラスターの分け方や権限、配布の仕組みを決めた | 設計・新規構築の案件の候補になる |
表の下に行くほど、自分で判断し、その結果に責任を持った経験になります。少なくとも「障害の原因を調べて直した」段階の経験を、具体的に話せる状態にしておくと、最初の案件を探しやすくなります。
案件の型ごとに必要な経験
運用・保守の案件
デプロイの対応、アラートの一次対応、定型の設定変更が中心です。Podが起動しない、通信がつながらないといった場面で、イベントやログを見て原因を絞り込めることが求められます。手順書を読むだけでなく、手順の外で起きたことに対応した経験が話せると有利です。
改善・移行の案件
手作業の運用をGitでの管理に移す、仮想マシンで動いていたアプリをコンテナに移す、といった案件です。既存の構成を読み解き、止めずに切り替える計画を立てる力が見られます。切り替えに失敗したときにどう戻すかを事前に決めた経験があると、話に説得力が出ます。
設計・新規構築の案件
クラスターの構成、ネットワーク、権限、配布の仕組み、監視の方針を決める案件です。複数の選択肢を比べて決めた経験と、その判断が後でどうだったかを振り返れることが求められます。最初の案件からこの型を狙うより、改善や移行の案件で判断の経験を積んでから広げるほうが現実的です。
案件で問われる技術の中身はKubernetesの案件で求められるスキルで、分野と段階ごとに整理しています。
在職中に積んでおきたい実績
版上げを一度、計画から担う
Kubernetesの公式ページでは、1.19以降のマイナー版のパッチ提供は約1年とされています。どの現場でも版上げは繰り返し発生するため、一度でも計画から担った経験は、多くの案件で話せる材料になります。公式の「Deprecated API Migration Guide」では、廃止予定のAPIを無効にした環境で試す、使っている箇所を探す、新しいAPIに移す、という流れが示されています。こうした事前の確認を自分で組み立てた経験は、手順どおりに上げた経験と区別して書けます。
障害の振り返りを書く
自分が対応した障害について、何が起き、何を見て原因を絞り込み、何を直したかを文書にしておきます。社内の文書は持ち出せませんが、書いた経験そのものが面談で話す練習になります。
手作業の変更を一つ、Gitでの管理に移す
kubectlで直接変更していた設定を、マニフェストとしてリポジトリに置き、レビューを通して反映する形に変えた経験は、改善の案件でそのまま評価されます。
クラウドの権限やネットワークに踏み込む
マネージドサービスの案件では、Kubernetesの中だけでなく、クラウドのネットワークや権限との組み合わせが問われます。クラスターの外側の設定にも関わっておくと、参画できる案件が広がります。クラウド側の準備はAWSエンジニアがフリーランスになるにはも参考になります。
個人の検証環境と費用の管理
在職中の業務だけでは触れない分野は、手元の検証環境で補えます。小さなクラスターを作り、わざと設定を壊して原因を探す練習は、障害の切り分けの力をつけるのに向いています。資格の準備と兼ねるなら、実技の試験であるCKAの範囲が参考になります。評価される場面はCKAの記事で整理しています。
クラウドのマネージドサービスで検証する場合は、使い終わったクラスターやロードバランサーを消し忘れると費用がかさみます。予算の通知を設定し、検証のたびに後片付けまで手順に入れておきましょう。
独立の手続きとお金の準備
会社を辞めて独立する場合は、健康保険・年金・住民税の切り替えと、開業届の提出が必要です。国税庁の案内では、個人事業の開業・廃業等届出書の提出期限は、事業の開始等の事実があった日の属する年分の確定申告期限までとされています(2026年10月時点)。青色申告の承認申請の期限など詳しい手順は開業届の出し方、退職前後の流れは会社員からフリーランスになる手順をご覧ください。
本番のクラスターを扱う案件では、操作の誤りでサービスが止まる可能性もあります。契約書の損害賠償の条項を確かめ、フリーランスの賠償責任保険で備え方も見ておくと安心です。
面談で問われること
独立して最初の面談では、次のような質問がよく出ます。経歴を書く前に、それぞれに答えられるかを確かめておくと、準備の抜けが見つかります。
- 担当していたクラスターは、マネージドサービスか自前の構築か。何を自分たちで管理していたか
- 最近対応した障害で、最初に何を見て、どう原因を絞り込んだか
- 版上げで、事前に何を確かめたか。うまくいかなかったときの戻し方は決めていたか
- 変更はどの経路で本番に届いていたか。直接変更が必要な場面はあったか
- 自分が決めたことと、決まったことに従ったことの境目はどこか
最後の問いは、任せられる範囲を判断するために聞かれます。チームで決めたことを自分の判断のように話すと、深く聞かれたときに答えがぶれます。関わり方をそのまま話すほうが、評価は安定します。
最初の案件で確かめておくこと
- 本番への変更の経路:Git経由で反映するのか、kubectlで直接変更する場面があるのか
- 権限の範囲:参画初日にどのクラスター・どの名前空間を操作できるのか
- 障害対応の範囲:夜間・休日の当番があるか、アプリの不具合の調査まで含むか
- 版上げの予定:参画期間中に版上げが予定されているか、誰が判断するのか
- 引き継ぎの資料:構成図や手順書、過去の障害の記録がどこまで残っているか
フリーランス法では、発注側は業務の内容・報酬の額・支払期日などを、書面やメールなどで明示することが求められています。取引条件の確かめ方はフリーランス新法の取引条件の明示にまとめています。案件の探し方はフリーランスエージェントの使い方も参考になります。
よくある質問
アプリの開発者としてKubernetesを使ってきた経験だけで独立できますか?
アプリをデプロイする側の経験は土台になりますが、基盤の案件では、クラスターの設定や障害の切り分けの経験が先に確かめられます。まずは所属先で基盤側の作業に関わる、検証環境で構築と障害対応を練習するなど、運用側の経験を足してから応募するほうが進めやすくなります。
オンプレミスのクラスターしか経験がありません。
自前のクラスターを運用した経験は、マネージドサービスの裏側の理解として評価されることがあります。一方で、案件の多くはマネージドサービスを使っているため、クラウドのネットワークや権限の仕組みを検証環境で一通り触っておくと、参画できる案件が広がります。
SREとKubernetesエンジニアは、どちらの肩書きで探すべきですか?
クラスターの設計や運用そのものが得意ならKubernetesエンジニア、信頼性の目標づくりや障害対応の仕組みが得意ならSREの案件が合いやすくなります。SREとして独立する進め方はSREがフリーランスになるにはをご覧ください。
参考にした公的情報・資料
- Releases(Kubernetes)
- Deprecated API Migration Guide(Kubernetes)
- No.2090 新たに事業を始めたときの届出など(国税庁)
- フリーランス法特設サイト(公正取引委員会)
記事の内容は公開日時点の情報にもとづきます。制度や税率は変わることがあるため、手続きの前に必ず各機関の最新情報をご確認ください。