Kubernetesエンジニアのフリーランス案件の選び方｜契約前に確かめたいこと

フリーランスのKubernetesエンジニアが案件を選ぶときは、報酬や稼働日数に加えて、役割の実態、基盤の版とサポート期限、変更の経路と本番の権限、障害時の呼び出しの体制、チームの分担、契約の形と責任、稼働の振れ幅と契約期間の7点を契約前に確かめておくことが大切です。Kubernetesの案件は、募集の文面が同じでも、この7点の違いで負担と責任が大きく変わります。

特に見落としやすいのは、障害や版上げの責任と、本番に対して持てる権限が釣り合っているかです。責任だけが重く、変更や戻しの権限がない案件では、問題が起きても自分の手で状況を動かせません。この記事では、Kubernetes案件に固有の確認点を整理します。契約書全般の確認点は業務委託契約書のチェックポイントで解説しています。

Kubernetes案件の選び方で差が出る理由

Kubernetesの案件票は、「Kubernetes環境の構築・運用」「コンテナ基盤の改善」のように書かれることが多く、参画してから想定との違いに気づくことが少なくありません。

よくあるずれは次のようなものです。

• 設計の案件と聞いていたのに、実際は開発チームからの依頼対応が中心だった
• 版がサポート期限の近くまで古く、参画直後から急ぎの版上げを求められた
• 本番への変更はすべて別のチームの承認が必要で、自分では何も反映できなかった
• 障害時の呼び出しに入る前提になっていて、夜間の対応が続いた

こうしたずれは、面談と条件の確認の段階で、聞き方を工夫すれば多くを防げます。

契約前に確かめたい7つの点

1. 役割の実態は運用の担い手か、設計か、移行か

最初に確かめたいのは、自分が担う役割の実態です。同じ募集でも、日々の依頼と保守を回す役割、構成や運用ルールを決める役割、版上げや移行を期限までに進める役割では、毎日の仕事がまったく違います。仕事の種類ごとの中身はKubernetesエンジニアの仕事内容で整理しています。

面談では、「着任後の最初の1か月で、最も期待されている成果は何か」を聞くと、役割の実態が見えやすくなります。答えが「依頼をこなしてほしい」なら運用寄り、「構成の見直し案をまとめてほしい」なら設計の役割です。

2. 基盤の版と、サポート期限までの余裕

Kubernetesは各版のパッチ提供が約1年で終わり（2026年10月時点、Kubernetesの公式サイトによる）、マネージドサービスにもそれぞれのサポート期限があります。次の点を確かめておくと、参画後の負担が読めます。

• 今の版と、サポート期限までの余裕
• 直近で予定している版上げや移行と、その期限
• 廃止されるAPIや、更新が止まっている部品を使っていないか

古い版の案件を避ける必要はありません。版上げの経験は評価にもつながります。ただ、状態を知ったうえで受けることが大切です。期限が迫っているなら、調査と検証にかけられる期間を合わせて確かめておきます。

3. 変更の経路と、本番の権限

本番のクラスターにどう変更を届け、自分がどこまで操作できるかを確かめます。

• 変更はGitのリポジトリから自動で反映されるか、手作業の操作があるか
• 本番への反映に、誰の承認が必要か
• 自分に付く権限は、名前空間の単位か、クラスター全体か
• 障害時に、戻しの操作を自分で行えるか

権限が強すぎる場合も注意が必要です。クラスター全体の管理者の権限を一人で持つ形は、誤操作のときの責任が自分に集中します。権限の範囲と、操作の記録が残る仕組みがあるかを合わせて確かめておきましょう。

4. 障害時の呼び出しの体制

障害時の呼び出し（オンコール）に入るかどうかは、働き方と負担を大きく左右します。

• 呼び出しの当番に自分が入るか、入る場合は頻度と時間帯
• 一次対応と二次対応の分担、自分はどちらを担うか
• 呼び出しで対応した時間を、稼働としてどう扱うか

呼び出しの条件は案件票に書かれていないことが多いため、面談か条件の確認の段階で聞いておきます。

5. チームの分担と、自分の位置

体制図を見せてもらえる場合は、自分がどこに位置するかを確かめます。

• 基盤チームの人数と、その中での自分の担当
• SREやクラウドの担当、セキュリティの担当がいるか。いない場合、その仕事も自分が担うか
• 開発チームとの線引き（マニフェストを誰が書き、誰がレビューするか）

周辺の担当がいない現場では、CI/CDやクラウドの権限、監視の設定まで仕事が広がりやすくなります。広がった場合の扱いは作業範囲が広がったときの契約の扱いをご覧ください。

6. 契約の形と、負う責任の範囲

フリーランスのKubernetesエンジニアは、多くの場合、準委任契約で参画します。準委任では、基盤が止まらないことそのものではなく、業務を専門家として通常求められる注意を払って行うことが約束の中身になります。確かめたいのは、契約書や発注の書面の書き方が、この考え方と合っているかです。

• 「障害を発生させない」「稼働率を保証する」のように、結果を約束する書き方になっていないか
• 障害や誤操作による損害について、賠償の範囲や上限の定めがあるか
• 構築の案件で成果物の納品が求められる場合、その範囲は何か（設計書、IaCのコード、手順書など）

請負の形で構築を受ける場合は、完成に対する責任を負うことになります。契約の形の違いは準委任契約と請負契約の違い、損害の扱いは損害賠償責任の記事で解説しています。また、準委任なのに発注元の社員から細かな作業の指示や勤務時間の管理を受ける働き方は、偽装請負の問題につながるおそれがあります。詳しくは偽装請負の記事をご覧ください。

7. 稼働の振れ幅と、契約期間の区切り

Kubernetesの稼働は、切り替えの作業日や障害の対応で振れます。

• 切り替えの作業が夜間や休日に入るか、その頻度
• 精算幅を超えたときの扱いと、稼働が少ない月の扱い
• 契約の期間と、版上げや移行の予定が合っているか

たとえば、移行の切り替えの直前に契約の更新時期が来ると、更新されなかった場合に最も大事な局面を見届けられません。精算の仕組みは精算幅の記事をご覧ください。

フリーランス法では、6か月以上の業務委託で契約を解除したり更新しなかったりするときは、少なくとも30日前までに予告することが求められています（2026年10月時点、公正取引委員会の案内による）。詳しくは中途解除の30日前予告の記事で解説しています。

確かめた内容を書面と照らし合わせる

面談や事前の確認で聞いた内容は、契約の前に書面と照らし合わせます。フリーランス法では、発注する事業者は業務を委託したら直ちに、給付の内容、報酬の額、支払期日などの取引条件を、書面またはメールなどの電磁的方法で明示することとされています（2026年10月時点、公正取引委員会の案内による）。明示される事項はフリーランス法で明示される取引条件をご覧ください。

Kubernetesの案件では、特に次の点が書面に反映されているかを確かめます。

1. 業務の内容に、担う範囲（運用、版上げ、設計、構築など）が書かれているか
2. 障害時の呼び出しに入るか、入る場合の扱い
3. 結果を保証する書き方や、損害の責任を広く負う書き方になっていないか
4. 稼働の幅と、超えたときの精算方法
5. 契約期間と更新の時期

面談で聞いておくとよい質問はKubernetesエンジニアの面談でよく聞かれる質問と答え方の逆質問の項目でも紹介しています。一般的な逆質問の考え方は面談で聞いておくべき逆質問をご覧ください。

よくある質問

版の古いクラスターの案件は避けたほうがよいですか？

避ける必要はありません。版上げや移行の経験は、次の案件で評価されやすい経験です。ただし、サポート期限までの余裕、調査と検証にかけられる期間、切り替えの作業の時間帯と稼働の扱いを、参画前に確かめてから受けることをおすすめします。

障害時の呼び出しに入るかどうかは、面談で聞いてよいですか？

聞いて問題ありません。働き方と稼働の見込みを判断するために必要な確認です。「参画後の稼働の見込みを正しく立てたい」という目的を添えると、相手も答えやすくなります。呼び出しの条件の確かめ方はSREの案件の選び方でも触れています。

報酬の高い案件と、権限のはっきりした案件で迷ったらどうしますか？

一概には言えませんが、Kubernetesの案件では、権限が曖昧なまま障害の責任だけが重い状態が続くと、稼働が増えて時間あたりの報酬が下がることがあります。報酬の額だけでなく、稼働の見込みと権限の範囲を合わせて比べるとよいでしょう。報酬の決まり方はKubernetesエンジニアの報酬の記事で解説しています。