Kubernetesエンジニアのスキルシートの書き方｜面談で評価される実績の見せ方

Kubernetesエンジニアのスキルシートは、ツールの名前を並べるより、「どんなクラスターを」「どの役割で」「どう変えたか」を書き分けるのが基本です。具体的には、マネージドサービスか自前の構築か、クラスターの数と分け方、担った工程、変更を本番に届ける方法、版上げの経験の5つをそろえると、案件側が任せられる範囲を判断しやすくなります。

この記事では、項目ごとの書き方と、架空の記入例を紹介します。スキルシート全体の基本の構成はフリーランスのスキルシートの書き方、案件で見られるスキルの中身はKubernetesの案件で求められるスキルで扱っています。

ツール名の羅列では伝わらないこと

「Kubernetes、EKS、Helm、Argo CD、Prometheus、Terraform」と並べただけでは、次のことが分かりません。

• 用意されたクラスターにアプリを載せたのか、クラスターそのものを作ったのか
• 本番を運用していたのか、検証環境だけなのか
• 構成を決めたのか、決まった構成を回していたのか
• ツールを導入したのか、既にあるものを使っていたのか

面談では、こうした点を一つずつ確かめられます。最初から書き分けておくと、面談の時間を、自分の判断や工夫の話に使えます。

冒頭に「クラスターの要約」を置く

プロジェクト欄の冒頭に、クラスターの環境を1〜2行でまとめます。

規模は、正確なノード数やPod数を書かなくても構いません。守秘義務の範囲で、「数台」「数十」のように幅を持たせて書けば足ります。スキルシートに書いてよい範囲はスキルシートに書いてよいこと・いけないことをご覧ください。

スキル一覧は分野ごとに「深さ」を添える

スキル一覧の欄では、ツールを分野ごとにまとめ、それぞれに関わりの深さを添えます。

「作成」「導入」「運用」「修正」「検証」のように、関わり方を一言添えるだけで、同じツール名でも経験の厚みが区別できます。触っただけのツールは書かないか、「検証」と明記して分けます。

担った工程と役割を書き分ける

Kubernetesの経歴は、同じ期間でも担った工程によって見え方が大きく変わります。工程ごとに、主担当か、レビューや支援だったかを書き分けます。

• 設計：クラスターの分け方、通信の入り口、権限の方針を決めた（主担当／レビュー参加）
• 構築：IaCでクラスターと周辺のクラウドのリソースを作った
• 移行：仮想マシンからコンテナへ、または別のクラスターへ載せ替えた
• 運用：デプロイ対応、障害対応、定型の変更
• 改善：手作業の変更のGit管理への移行、監視の見直し、版上げの仕組み化

主担当ではない工程も、関わり方をそのまま書くほうが、面談で深く聞かれたときに答えがぶれません。

変更の届け方を1行で書く

Kubernetesの案件では、変更をどう本番に届けていたかがよく聞かれます。次のように1行で書いておくと、運用の成熟度と、自分の関わり方が伝わります。

例：マニフェストはHelmで管理し、本番への反映はGitOpsのツールで自動化（導入から担当）
例：既存のGitOpsの運用に参加し、環境ごとの差分の整理を担当

「導入から担当」「既存の運用に参加」の違いは、改善の案件を狙うときに大きな差になります。

版上げの経験は「どこから担ったか」まで書く

Kubernetesの公式ページでは、1.19以降のマイナー版のパッチ提供は約1年とされています。版上げはどの現場でも繰り返し発生するため、経験として書いておく価値があります。書くときは、回数と、作業の始まりと終わりがどこだったかを1行に入れます。

例：版上げ2回を担当。廃止APIの影響調査から、ノードの入れ替えと反映後の確認まで
例：版上げ1回に参加。ノードの入れ替えの作業を担当（計画はリーダーが作成）

公式の「Deprecated API Migration Guide」では、版ごとに削除されたAPIと移行先がまとめられています。こうした資料をもとに影響を調べた経験があれば、「廃止APIの影響調査を担当」と書き添えると、事前の確認から担ったことが伝わります。

障害対応は「調べた順番」と「その後」を書く

障害対応の経験は、件数より、1件を具体的に書くほうが伝わります。何が起き、何を見て絞り込み、何を直し、再発を防ぐために何を変えたかを短くまとめます。オンコールの関わり方の書き方はSREのスキルシートの書き方で詳しく紹介しています。

プロジェクト欄の記入例

ここでは、マネージドサービスでの運用改善と、版上げの仕組み化を担当した場合を想定した記入例を示します。以下は書き方を示すための架空の例で、実在の案件や実績ではありません。業界や規模はぼかしています。

期間：20XX年X月〜20XX年X月（1年2か月）
案件概要：小売業向け 会員サービスの基盤の運用改善
クラスターの要約：マネージド（EKS）。本番・検証の2クラスター、チームごとに名前空間を分割。数十のサービスが稼働
規模・立場：基盤チーム3名（自分はメンバー。後半は版上げのとりまとめ）
担当工程：運用、改善（設計はレビューに参加）
使用技術：EKS、Helm、GitOpsのツール（導入から担当）、Terraform（既存の修正）、Prometheus
担当内容：kubectlでの直接変更が残っていた設定をリポジトリでの管理に移し、レビューを通して反映する形に変えた。版上げで、廃止されるAPIの洗い出しとアドオンの対応状況の確認を担当した
工夫・成果：版上げの前の確認を検証環境で自動で行う仕組みを作り、次の版上げでの手作業を減らした。直接変更が必要になったときの手順を決め、リポジトリとの食い違いが残らないようにした

もう一つ、自前の構築の経験がある場合の例です。こちらも架空の例です。

期間：20XX年X月〜20XX年X月（10か月）
案件概要：製造業向け 社内システムのコンテナ基盤の構築
クラスターの要約：自前の構築（オンプレミス）。本番1クラスター、検証1クラスター
規模・立場：インフラ5名（自分はKubernetesの構築担当）
担当工程：構築、運用（設計は方針の検討に参加）
担当内容：クラスターの構築手順をコード化し、証明書の更新とバックアップの手順を整えた
工夫・成果：障害時の切り分けの順番を手順書にまとめ、運用チームに引き継いだ

資格の書き方

CKAなどの資格は、正式名称、取得年月、有効期限を書き、期限が切れたものは取得歴として分けます。CKAの有効期間や、経歴とのつなげ方はCKAの記事で紹介しています。資格欄だけでなく、プロジェクト欄の環境の情報と組み合わせると、知識が実務のどこで生きたかが伝わります。

よくある質問

検証環境で作ったクラスターの経験は書いてよいですか？

書いて構いません。ただし、業務の経験とは分けて「個人の検証」と明記します。どんな構成を作り、何を確かめたかを書くと、学んでいる方向が伝わります。

アプリをデプロイする側としての経験は、どう書けばよいですか？

「利用者としてKubernetesにデプロイ」と書き、マニフェストの作成やリソースの値の決定など、自分が担った範囲を具体的に書きます。基盤側の案件を狙う場合は、障害の切り分けで基盤側まで調べた経験があれば、あわせて書くと伝わりやすくなります。

版の番号は書いたほうがよいですか？

「1.xxから1.yyへの版上げ」のように書くと、時期と経験の新しさが伝わります。ただし、番号より、どの段階から担ったかのほうが評価につながります。面談でよく聞かれる質問は業務委託の面談でよく聞かれる質問も参考になります。