Kubernetesエンジニアのフリーランス面談でよく聞かれる質問と答え方

フリーランスのKubernetesエンジニアの面談でよく聞かれるのは、どんなクラスターをどの役割で扱ったか、障害のときに何をどの順番で調べたか、版上げをどこから担ったか、変更をどう本番に届けていたかの4つです。面談官は、知っているツールの数より「この人に本番のクラスターを預けたら、壊さずに変えられるか、壊れたときに戻せるか」を確かめようとしています。

答えるときは、模範解答を覚えるより、自分の経験から「本番で判断した場面」を3〜4つ選び、どの質問にもそこから答えられるように準備しておくのが近道です。面談全般の答え方の型は業務委託の面談でよく聞かれる質問と答え方で解説しているので、この記事ではKubernetesの面談に固有の質問に絞ります。

Kubernetesの面談で面談官が見ていること

Kubernetes案件の面談に出てくるのは、発注元の基盤チームのリーダーやSRE、インフラの責任者であることが多く、本人もクラスターを運用しています。そのため、用語の説明より、話の中に出てくる調べる順番と、変更の安全の確かめ方を聞いています。

面談官が知りたいのは、おおむね次の3点です。

1. 任せられる範囲：マネージドか自前か、何個のクラスターを、どこまでの権限で扱ってきたか
2. 崩れたときの動き方：障害や版上げの失敗のときに、何を見て、どう戻したか
3. 現場のやり方との相性：レビューや記録の習慣、開発チームとの接し方が自社に合うか

以下の質問は、この3点のどれかを確かめるためのものです。質問の意図が分かれば、答えの中心に何を置くかも決まります。

よく聞かれる質問と答え方の考え方

ここで示す答えの例は、組み立て方を伝えるための架空の例です。そのまま使うのではなく、ご自身の経験に置き換えて準備してください。

1. 「直近の現場のクラスターの構成と、あなたの役割を教えてください」

確かめたいのは、任せられる範囲です。マネージドサービスか自前の構築か、クラスターの数と分け方（本番・検証、チームごとなど）、載っているアプリの数、自分が設計・構築・運用のどこを担ったかを短く伝えます。チームで担っていた場合は、自分が決めたことと、ほかの人が決めたことを分けて話すと、後の質問との食い違いが起きません。

架空の例：「マネージドサービスのクラスターを本番と検証で2つ、基盤チーム3名で運用していました。私は版上げと配布の仕組みの担当で、権限の設計はリーダーが決めていました」

2. 「Podが起動しないとき、何から調べますか」

最もよく聞かれる質問の一つです。正解の手順を暗唱するより、自分の調べる順番と、その順番にしている理由を話します。たとえば、Podの状態とイベントを見て、スケジュールされていないのか、イメージが取れないのか、起動後に落ちているのかを分け、それぞれで次に見るものを決める、といった流れです。実際に起きた障害を一つ添えると、話に重みが出ます。

3. 「本番で起きた障害で、印象に残っているものを教えてください」

答えは次の順番で組み立てると伝わりやすくなります。

• 何から異常に気づいたか（アラート、問い合わせ、指標の変化など）
• 影響の範囲をどう見積もったか
• 原因をどう絞ったか（アプリ、クラスター、クラウドのどこか）
• まず何をして影響を止め、その後どう直したか
• 再発を防ぐために何を変えたか

「再起動したら直りました」で終わると、判断の中身が見えません。影響を止める手と、原因を直す手を分けて話せると、運用を任せられる人だと伝わります。

4. 「版上げはどのように進めましたか」

版上げは、計画、影響調査、検証、切り替え、振り返りのどこから担ったかで経験の重さが変わります。廃止されるAPIをどう洗い出したか、アドオンの対応をどう確かめたか、戻し方をどう用意したかを具体的に話します。手順書に沿って実施しただけの場合も、正直にそう伝えたうえで、気づいたことを添えれば十分な材料になります。

5. 「変更は、どうやって本番に届けていましたか」

GitOpsのツールやCI/CDの名前を挙げるだけでなく、誰のレビューを通り、どこで自動に反映され、問題が出たらどう戻すかを一続きで説明します。手作業でkubectlを使う場面があった場合は、どんなときに、どんな手続きで行っていたかも話せるようにしておきます。

6. 「権限やネットワークの制限をどう決めましたか」

名前空間の分け方、RBACの付け方、ネットワークポリシーで通信を絞った経験を聞く質問です。設定の細部より、どこまで許し、どこから許さないかの線を、誰とどう合意したかが見られています。

7. 「リソースの要求と上限は、どう決めていましたか」

値を決めた根拠を確かめる質問です。実際の使用量を測ってから決めたか、見直しの時期を決めていたか、メモリ不足による強制終了が続いたときに何を調べたかを話します。

8. 「なぜフリーランスでKubernetesの仕事をしているのですか」

長く続けられるか、どんな仕事で力を出したいかを確かめる質問でもあります。働き方の希望だけでなく、運用の改善、移行、基盤づくりなど、関わりたい仕事の種類を添えると、案件との合い方が伝わります。仕事の種類の違いはKubernetesエンジニアの仕事内容で整理しています。

準備は「本番で判断した場面」を3〜4つに絞る

上の質問は数が多く見えますが、答えの材料は共通しています。準備は次の手順で進めると効率的です。

1. 場面を選ぶ：障害、版上げ、権限や通信の設計、配布の仕組みの変更など、性質の違う場面を3〜4つ選ぶ
2. 場面ごとにメモをつくる：状況、気づいたきっかけ、調べた順番、選んだ手、戻し方、結果、その後に変えたことを書き出す
3. 構成の数字をそろえる：クラスターの数、チームの人数、載っているアプリの数を、どの場面でも同じ数字で言えるようにする
4. 口頭で図を説明できるようにする：通信の経路や配布の流れを、画面共有がなくても言葉で説明できるようにしておく
5. スキルシートと照らし合わせる：シートに書いた役割と、話す内容が一致しているかを確かめる

スキルシートとの一致は特に大切です。面談官はシートを見ながら質問するため、話とシートがずれると、どちらも信用されにくくなります。シートの書き方はKubernetesエンジニアのスキルシートの記事、冒頭の自己紹介の組み立て方は面談の自己紹介の記事で解説しています。

面談の相手によって重心が変わる

技術の掘り下げが深い面談では、その場で構成図を描くように頼まれることもあります。オンラインの面談なら、画面共有で図を描ける準備をしておくと安心です。環境の整え方はオンライン面談で気をつけることをご覧ください。

Kubernetes案件ならではの逆質問

面談の終わりの逆質問は、印象づくりより参画後のずれを防ぐ確認に使います。Kubernetesの案件では、次の点を聞いておくと判断がしやすくなります。

• マネージドか自前か、クラスターの数と、今の版の状況
• 変更の届け方と、本番に直接操作する権限を持つ人の範囲
• 障害時の呼び出しの体制に、自分が入るかどうか
• 直近で予定している版上げや移行と、その期限
• 基盤チームと開発チームの役割の分担

一般的な逆質問の考え方は業務委託の面談で聞いておくべき逆質問にまとめています。逆質問で聞いた内容は、契約前の確認にもそのまま使えます。案件を選ぶときの確認点はKubernetes案件の選び方で整理しています。

よくある質問

検証環境でしか経験していない機能について聞かれたら、どう答えればよいですか？

本番での経験がないことを先に伝え、検証環境で何を試し、どこまで分かったかを話します。本番の経験のように話すと、掘り下げられたときに答えに詰まります。正直に範囲を示したほうが、任せる範囲を決めやすくなり、面談官の評価も安定します。

面談でその場でコマンドや設定を書くように言われることはありますか？

案件によっては、設定ファイルの読み方や、障害の場面を想定した調べ方を口頭やその場の作業で確かめることがあります。暗記より、何を確かめるためにそのコマンドを使うのかを説明できるようにしておくと落ち着いて答えられます。

面談で見送られたとき、何を見直せばよいですか？

役割の伝え方、障害の話の組み立て、スキルシートとの一致の3点から見直すのがおすすめです。ツールの経験が足りないのか、判断の中身が伝わらなかったのかで、次にやることが変わります。見送られやすい理由は面談で見送られる理由の記事で解説しています。