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

DevOpsエンジニアのフリーランス面談でよく聞かれるのは、CI/CDやIaCをどこまで自分で設計したか、パイプラインの権限と秘密情報をどう扱ったか、改善の効果をどう測ったか、作った仕組みを開発チームにどう使ってもらったかの4つです。面談官はツールの名前より、「この人に本番を変えられる仕組みを任せて大丈夫か」を確かめています。

準備は、模範回答を覚えるより、自分の経験から「設計を決めた場面」を3〜4つ選び、どの質問にもそこから答えられるようにしておくのが近道です。面談全般の型は業務委託の面談でよく聞かれる質問と答え方にまとめているので、ここではDevOpsの面談に固有の点に絞ります。

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

面談に出てくるのは、開発組織の責任者、基盤チームのリーダー、SREなど、自分でもパイプラインやインフラに触れてきた人が多くなります。そのため、言葉の上手さより、話の中の判断の理由と、安全への配慮を聞いています。

確かめたいのは、おおむね次の3点です。

1. 任せられる範囲：既存の設定を直す人か、流れを一から設計できる人か
2. 壊さない動き方：本番に影響する変更を、どんな手順と権限で入れてきたか
3. チームとの相性：開発者の声を聞き、使われる仕組みにできるか

以下の質問は、このどれかを確かめるためのものです。答えの例は組み立て方を示す架空の例なので、ご自身の経験に置き換えてください。

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

1. 「直近の案件で、CI/CDのどこを担当しましたか」

確かめたいのは任せられる範囲です。対象のサービスの数、使っていたツール、自分が作った部分と既存を直した部分を分けて話します。「CI/CD構築」とひとまとめにすると、掘り下げで食い違いが出やすくなります。

架空の例：「3つのサービスのパイプラインのうち、1つは一から設計し、残り2つは既存の定義にテストの分割と承認の段階を足しました」

2. 「パイプラインが遅い、よく落ちるという課題にどう取り組みましたか」

最もよく掘り下げられる質問です。次の順で組み立てると伝わります。

• 何を測って問題を見つけたか（どのジョブに何分かかっていたか、どの失敗が多かったか）
• 原因をどう見立てたか
• どんな手を並べ、なぜその手を選んだか
• 変えた後に何がどう変わったか

「キャッシュを入れて速くしました」だけだと、測ったかどうかが見えません。DORAが示す変更のリードタイムや変更の失敗率のような指標（2026年10月時点の公式ガイドによる）を使っていた場合は、どの指標で効果を説明したかを添えると、改善の考え方が伝わります。

3. 「本番への認証情報や秘密情報をどこに置いていましたか」

DevOpsの面談に特有の質問です。CI/CDは本番を変えられる強い権限を持つため、面談官は攻撃の入り口にしない設計をしてきたかを見ています。GitHubの公式ドキュメントでも、外部のアクションはコミットのハッシュ値で固定すること、ワークフローのトークンの権限は既定を読み取りだけにして必要なジョブだけに広げること、秘密情報が漏れたらログを消して入れ替えることなどが勧められています（2026年10月時点）。

答えるときは、使った仕組みの名前より、なぜその置き方にしたか、漏れたらどうする手順だったかを話します。経験がない部分は、検証環境で試したことと分けて話しましょう。

4. 「IaCで、既存の環境をどうコードの管理下に移しましたか」

管理画面で作られた環境の取り込みは、多くの現場の課題です。範囲の区切り方、差分をなくすまでの進め方、コードと実物がずれたときにどちらに合わせたか、stateをどう分けたかを順に話します。止めずに移せたか、移した後に誰がどう変更する流れにしたかまで話せると、任せられる範囲が伝わります。

5. 「本番で失敗したデプロイと、そのときの対応を教えてください」

失敗の話は避けずに準備しておきます。面談官は、失敗の大きさより、戻す手順を持っていたか、原因をどう仕組みで防いだかを見ています。他人のミスとして語ると評価が下がりやすいため、自分の設計の中で何を変えたかに焦点を当てます。

6. 「作った仕組みを、開発チームにどう使ってもらいましたか」

共通の雛形や基盤を作った経験を確かめる質問です。利用者に話を聞いた方法、使われなかった理由とその後の改善、古い版からの移行の進め方を話します。何チームに使われたかを数字で言えると、規模が伝わります。

7. 「このプロジェクトでは、最初に何から手を付けますか」

案件の資料を読んだうえで聞かれることがあります。面談の時点では分からないことが多いので、断定的な計画より、何を確かめてから決めるかを順に示すほうが信頼されます。今のパイプラインと構成を読む、開発者に困りごとを聞く、測る対象を決める、といった自分の型を話しましょう。

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

長く続けられるか、どんな局面で力を出したいかを確かめる質問でもあります。働き方の希望に加え、得意な出発点（新規の整備か、移行か、標準づくりか）を添えると、案件との合い方が伝わります。

準備は「設計を決めた場面」を3〜4つに絞る

1. 場面を選ぶ：パイプラインの改善、IaCの取り込み、権限の見直し、本番の失敗など、性質の違う場面を選ぶ
2. 場面ごとにメモをつくる：状況、測ったもの、並べた選択肢、選んだ理由、結果、学び
3. 規模の数字をそろえる：サービスの数、チームの数、環境の数を、どの場面でも同じ数字で言えるようにする
4. 構成図を口で説明できるようにする：オンライン面談で画面を共有できない場合に備え、言葉だけで流れを説明する練習をしておく
5. スキルシートと照らし合わせる：シートの記述と話の内容がずれていないかを確かめる

面談官はシートを見ながら質問するため、話とシートのずれは信頼を下げます。書き方はDevOpsエンジニアのスキルシートの記事、技術的な質問や課題が出る場合の備えは技術テストの記事をご覧ください。

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

複数の人が同席する面談では、最初に誰が何を見たいかを聞いておくと、限られた時間で話の配分を決めやすくなります。

DevOpsならではの逆質問

逆質問は、印象づくりより参画後のずれを防ぐ確認に使います。

• 今のパイプラインとインフラの状態と、最初に期待されている成果
• 本番の環境に対して、自分に与えられる権限の範囲と承認の流れ
• 開発チームの数と、窓口になる人
• 作った仕組みの運用や問い合わせ対応を、誰が担う想定か
• 切り替え作業や障害対応で、夜間や休日の対応があるか

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

よくある質問

使ったことのないCIツールやクラウドの案件でも、面談で通りますか？

通ることはあります。ツールが違っても、テストの分け方、成果物の昇格、権限の絞り方などの考え方は共通です。使っていない部分は正直に伝え、似た仕組みでどう考えたかを話すほうが、知っているふりをするより評価されやすくなります。

面談でライブコーディングや設定ファイルの作成を求められることはありますか？

案件によっては、その場で設定ファイルを読んで問題点を挙げる、簡単なパイプラインを書くといった課題が出ることがあります。事前に形式を聞いておき、普段使っている書き方で落ち着いて説明できるよう準備しておきましょう。

資格は面談で聞かれますか？

聞かれることはありますが、比重は実務の話より小さいのが一般的です。聞かれた場合は、取った理由と、実務で生かした場面を1つ話せれば十分です。評価のされ方はDevOpsエンジニアの資格の記事で解説しています。