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

フリーランスのデータベースエンジニアの面談でよく聞かれるのは、どの製品と版を、どの規模で、どの工程まで担ったか、遅いSQLをどう調べたか、実際にデータを戻した経験があるか、本番の作業をどう安全に進めたかの4つです。面談官は製品の知識の量より、「この人に本番のデータベースを預けたら、問題が起きたときにどう動くか」を確かめようとしています。

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

データベースの面談で面談官が見ていること

データベース案件の面談に出てくるのは、発注元の基盤やインフラの責任者、アプリの開発リーダー、すでに参画している上位のデータベースエンジニアであることが多く、本人も技術に詳しい人です。そのため、用語を知っているかより、話の中に出てくる調べる順序と、本番への慎重さを聞いています。

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

1. 任せられる範囲：どの製品と版を、どのくらいの規模と停止の厳しさの環境で、設計・性能改善・移行・運用のどこまで担ってきたか
2. 崩れたときの動き方：遅い、止まった、データがおかしいといった場面で、何から確かめ、何を決めたか
3. 本番の扱い方：手順書、承認、戻し方、権限の扱いが、自社のやり方に合うか

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

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

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

1. 「直近の案件で扱ったデータベースの製品・版・規模を教えてください」

確かめたいのは任せられる範囲です。製品と版、データ量やテーブル数の目安、冗長化の構成、止まってよい時間の厳しさ、自分が担った工程を短く伝えます。複数の製品を扱った場合は、深く関わったものと触れた程度のものを分けて話すと、後の掘り下げで食い違いが起きません。

架空の例：「PostgreSQLの同期レプリケーション構成で、24時間止められない受注システムの運用と性能改善を担いました。設計は既にあり、私は変更作業と改善の提案、版上げの検証を担当しました」

2. 「遅いと言われたSQLを、どの順番で調べましたか」

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

• 遅いのは特定のSQLか、全体か、時間帯によるかをどう切り分けたか
• 実行計画や待機の情報から、何が想定と違っていたか
• 原因の候補をいくつ並べ、どれから試したか
• 直した後に、ほかの処理が遅くならないかをどう確かめたか

「インデックスを追加して速くなりました」だけで終わると、そこに至るまでが見えません。ほかの直し方を選ばなかった理由と、副作用の確認まで話せると、経験の深さが伝わります。

3. 「バックアップから実際にデータを戻したことはありますか」

バックアップを取る設定だけでなく、戻した経験があるかを確かめる質問です。本番の障害で戻した場面、復旧の訓練で戻した場面、検証環境で手順を確かめた場面を分けて話します。かかった時間、どの時点まで戻したか、手順書のどこを直したかを添えると具体的になります。経験が訓練だけの場合も、そのとおりに話せば十分です。

4. 「レプリケーションやクラスタで、切り替えが起きたときの動きを説明してください」

組んだことがあるかより、障害時にどう切り替わり、戻すときに何を確かめるかを理解しているかを見ています。同期と非同期のどちらにしたか、切り替えを自動にしたか人が判断したか、その選択で何を失うかを説明できると、設計の案件にもつながります。

5. 「版上げや移行で、切り替えに失敗したらどうする計画でしたか」

移行の案件で特に聞かれます。切り替えの手順より、中止を判断する基準と、戻す手順を持っていたかが問われます。リハーサルで何を測り、本番の停止時間に収まるかをどう確かめたかも話の材料になります。

6. 「本番のデータベースに変更を加えるとき、どう進めていましたか」

手順書を書く、レビューを受ける、承認を得る、検証環境で試す、戻し方を用意する、作業の記録を残す、という流れを持っているかを確かめる質問です。前の現場の決まりに従っていただけの場合も、その決まりがなぜあったかを理解していれば、それを話しましょう。

7. 「開発チームから無理な変更を頼まれたら、どうしますか」

本番直前のテーブル変更や、性能に影響する設計の依頼などの場面です。断るか受けるかではなく、影響を示し、代わりの案を出し、誰が決めるかをはっきりさせる手順を見ています。開発チームと対立した話より、どう合意したかを中心に話します。

8. 「使ったことのない製品の案件ですが、どう立ち上がりますか」

応募した案件の製品が、経験の中心と違う場合に聞かれます。設計や性能の考え方、復旧の原則は共通であることを示したうえで、管理の作法や実行計画の見方の違いを、検証環境でどこまで確かめてきたかを話します。資格の学習で知識を整理した場合は、ここで添えると説明しやすくなります。考え方はデータベースエンジニアに資格は必要かで扱っています。

準備は「調べた場面」と「戻した場面」に絞る

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

1. 場面を選ぶ：性能の調査、障害と復旧、移行や版上げ、本番の変更作業など、性質の違う場面を3〜4つ選ぶ
2. 場面ごとにメモをつくる：状況、最初に見たもの、原因の候補、選んだ直し方と理由、副作用の確認、結果、学びを書き出す
3. 環境の要約をそろえる：製品と版、構成、規模、停止の厳しさを、どの場面でも同じ言い方で言えるようにする
4. 2分版と5分版をつくる：最初は2分で話し、掘り下げられたら実行計画や待機の話まで詳しく話せるようにする
5. スキルシートと照らし合わせる：シートに書いた製品・版・工程と、話の内容が一致しているかを確かめる

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

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

データベースの面談は、相手によって聞かれる内容の重心が変わります。

元請けの会社と発注元の両方と面談することもあります。その場合、技術の掘り下げは技術者の面談で、報告や停止時間の調整の話は発注元の面談で重心を置くと、限られた時間を有効に使えます。

データベースエンジニアならではの逆質問

面談の終わりには、こちらから質問できる時間があります。逆質問は、印象づくりより参画後のずれを防ぐ確認に使います。データベースの案件では、次の点を聞いておくと判断しやすくなります。

• 対象の製品と版、構成、今後の版上げの予定
• 本番の操作を自分で行うか、手順書を渡して別の担当者が行うか
• 夜間・休日の作業や障害時の呼び出しの有無と頻度
• 検証環境の有無と、本番に近いデータで試せるか
• 作業の承認の流れと、権限の申請にかかる期間

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

よくある質問

面談でSQLを書く試験や、実行計画を読む問題が出ることはありますか？

案件によってはあります。画面を共有して実行計画を一緒に読んだり、簡単なSQLの書き方を口頭で聞かれたりすることがあります。どの製品の場合でも、実行計画のどこを見て判断するかを自分の言葉で説明できるようにしておくと落ち着いて対応できます。

大きな障害を起こしてしまった経験は話しても大丈夫ですか？

話して問題ありません。大切なのは、障害の大きさより、どう気づき、どう戻し、再発を防ぐために何を変えたかを説明できることです。他人のせいにする話し方は避け、自分の判断と、その後に手順をどう直したかに焦点を当てて話しましょう。

運用保守の経験が中心ですが、性能改善の案件の面談ではどう話せばよいですか？

運用の中で遅さや異常に気づき、原因を調べた場面があれば、その経緯を中心に話します。直したのが別の担当者でも、自分が何を調べて材料を渡したかを正確に伝えれば評価の材料になります。面談で見送られやすい理由は面談で見送られる理由の記事で解説しています。