データアナリストのSQL実技テスト対策、面接官の減点ポイント

「正解のデータは出せたはずなのに、面接後のフィードバックが芳しくなかった」——データアナリスト職の選考でSQL実技テストを受けた候補者から、こういう相談を受けることが増えています。

IT・Web業界を中心に800名以上の転職支援に携わってきましたが、SQL実技テストの合否を分けているのは、正答率そのものよりもクエリの書き方と、それをどう説明したかであるケースが実は少なくありません。今回は、出題形式別の準備の仕方と、面接官が実際に減点しているポイントを、現場で聞いてきた話を交えてお伝えします。

目次

1. データアナリスト選考のSQL実技テスト対策、まず押さえておきたい実態
2. 出題形式は主に3パターン、対策の仕方がまるで違う
3. オンラインジャッジ型の準備
4. 画面共有でのライブ実装型の準備
5. 口頭でのSQL設計説明型の準備
6. 面接官はクエリの正誤だけを見ていない、減点される典型パターン
7. 頻出するSQL問題の傾向と、実行計画への意識
8. GROUP BY・JOIN・サブクエリ・ウィンドウ関数、どこまで書ければ十分か
9. 「書けた」で終わらせない、説明の仕方が評価を左右する
10. SQLとPython、どちらが重視されるか
11. 未経験からデータアナリストを目指す場合、SQLはどこまで準備すればいいか
12. まとめ、SQL実技テストは「解けるか」より「どう解いたか」が見られている

データアナリスト選考のSQL実技テスト対策、まず押さえておきたい実態

データアナリスト・データサイエンティストの選考でSQLの実技試験を課す企業は、この数年ではっきり増えました。書類選考の段階で「SQL実務経験3年以上」とだけ書かれていた求人が、選考が進むにつれて「HackerRankでの実技テスト」「画面共有でのライブ実装」という具体的な関門に変わる、という流れを何社分も見てきています。

背景にあるのは、SQLが「あると望ましいスキル」から「実務の前提条件」に格上げされたことです。一般社団法人データサイエンティスト協会が定めるスキルチェックリストでも、データエンジニアリング力の中にSQLの操作が明確に含まれており(参考：DS検定®とは｜一般社団法人データサイエンティスト協会)、業界団体の公式な基準としてもSQLは分析業務の土台に位置づけられています。企業側からすれば、職務経歴書の「SQL使用経験あり」という一文だけでは実務レベルを判断しきれないため、実技テストで直接確認したい、という発想は自然な流れです。

ただ、ここで見落とされがちなのが実技テストは「解けたら合格」の場ではないという点です。私がこれまで面接官側から聞いてきたフィードバックを振り返ると、正答が出ているのに評価が伸びなかったケースの方が、不正解で見送られたケースよりもむしろ多いくらいです。次の章から、出題形式ごとに何が見られているのかを具体的に見ていきます。

出題形式は主に3パターン、対策の仕方がまるで違う

データアナリスト職のSQL実技テストは、大きく分けて3つの形式に分類できます。同じ「SQLテスト」という名前でも、評価の重心が形式ごとに違うため、どれを受けるか分からないまま漠然と勉強を始めると、本番で的を外した準備になりがちです。

オンラインジャッジ型の準備

HackerRankやPaizaに代表される自動採点型は、制限時間内に決められた出力を返すクエリを提出する形式です。テストケースを通過すれば機械的に正解と判定されるため、一見すると対策しやすいように思えますが、実は時間配分の失敗が最大の落とし穴になっています。

2021年度のDS検定模擬問題では、売上テーブルに対して複数条件で抽出するSQL問題が出題されており、BETWEEN構文とIN構文のどちらで書き換えるかという解説がされています(参考：2021年度 DS検定 模擬問題②(データエンジニアリング力)の解説｜Zenn。個人のエンジニアによる二次解説記事です)。この手の問題は書き方自体は難しくない一方、制限時間内に複数問を解き切る必要があるため、1問目で条件分岐に悩んで時間を溶かすと、後半の集計・結合問題にしわ寄せが来ます。

私が候補者に勧めているのは、本番前にHackerRankの「SQL(Basic)」「SQL(Intermediate)」の練習問題を時間を計って通しで解いておくことです。正答できるかどうかより、1問あたり何分で書き終えられるかの感覚を体に入れておく方が本番で効きます。

画面共有でのライブ実装型の準備

面接官が見ている画面で、その場でクエリを書きながら会話を進める形式です。オンラインジャッジ型と違って自動採点がないため、完成したクエリの正誤だけでなく、書いている最中の思考プロセスがそのまま評価対象になります。

この形式で失敗しやすいのは、黙り込んで一気に完成形を書こうとするパターンです。実装が止まった数十秒の沈黙は、面接官からすると「行き詰まって焦っている」ようにしか見えません。私が勧めているのは、テーブル構造を確認する→抽出条件を声に出す→GROUP BYの単位を宣言する→書き終えたら実行結果を自分で読み上げる、という手順をあらかじめ型として決めておくことです。書きながら「まずユーザーテーブルと注文テーブルを結合してから、月ごとに集計します」と一言添えるだけで、面接官は今どこにいるかを把握でき、途中で軌道修正のヒントを出しやすくなります。

口頭でのSQL設計説明型の準備

コードを実際には書かず、「このデータからこの数値を出すには、どんなクエリを書きますか」と口頭だけで説明させる形式です。データアナリストの選考では、時間の制約からこの形式を選ぶ企業も一定数あります。書かない分、構文の細部よりも設計の筋道を追えているかが評価の中心になります。

口頭説明型で評価が下がりやすいのは、「JOINしてGROUP BYします」のような抽象度の高い説明で止まってしまうケースです。どのキーで結合するか、集計の粒度は何か、欠損値やダブルカウントの可能性にどう対応するかまで言葉にできて、はじめて実務でクエリを書ける人だと判断されます。私は面接前の練習として、実際に手元でクエリを書いた後、そのクエリを見ずに口頭だけで再現できるかを試してもらうことがあります。書けることと、書かずに説明できることの間には想像以上に差があり、この練習だけで面接での説明の滑らかさが変わった候補者を何人も見てきました。

面接官はクエリの正誤だけを見ていない、減点される典型パターン

出題形式が何であれ、面接官が共通して見ているのは「欲しい結果が出せるか」だけではありません。私がこれまで企業の採用担当・面接官から直接聞いてきたフィードバックを整理すると、正答なのに評価が伸びない理由にはいくつかの型があります。

このうち特に企業側の担当者からよく聞くのが、NULLと重複行の扱いです。あるデータ基盤チームのリーダーは、「INNER JOINを使った結果、本来カウントすべきレコードが結合条件に合わず消えていることに、候補者自身が最後まで気づかなかった」というフィードバックを話していました。出力された数字が一見それらしく見えてしまうため、本人は正解したつもりで終わっているのですが、実務ではこの手の見落としがそのままレポートの誤りに直結します。「このJOINで行が減る・増える可能性はないか」と自分に問い返す癖があるかどうかは、コードの見た目以上に評価を左右しています。

命名や可読性への言及も、地味ながら繰り返し聞く指摘です。分析基盤が育っている企業ほど、書いたクエリは自分だけでなくチームメンバーが後から読み直す前提で運用されています。そのため「変数名が適当」「一時的に使っただけのサブクエリに説明がない」という書き方は、たとえ結果が正しくても「実務に持ち込んだら周りが困る書き方」と受け取られることがあります。時間制限のあるテストの中でここまで気を配るのは簡単ではありませんが、せめて主要なテーブルにはmonthly_salesのように意味の通るエイリアスをつける、複雑な条件には一言コメントを添える、といった最低限の配慮は、時間内でも十分にできる工夫です。

実際にあった相談を一つ紹介します。ECサイトを運営する事業会社でマーケティング分析をExcel中心に担当していた30代後半の方が、自社開発のSaaS企業のデータアナリスト求人に応募しました。オンラインジャッジ型のSQLテストは制限時間内に全問正答していたのですが、続く二次面接で面接官から「このサブクエリ、なぜここで切ったんですか」と聞かれた瞬間に言葉に詰まってしまいました。正解にたどり着くこと自体には慣れていたものの、なぜその書き方を選んだかを自分の言葉で説明する練習をしてこなかったことが、そのとき初めて浮き彫りになったそうです。

その回の選考は見送りとなりましたが、次の応募先に向けて、書いたクエリを一行ずつ「なぜこう書いたか」を声に出して説明する練習を重ね、二次面接では設計意図を聞かれても即座に答えられるようになり、内定を得ています。

頻出するSQL問題の傾向と、実行計画への意識

出題内容そのものについても触れておきます。データアナリスト職の実技テストで頻出するのは、実在の業務を想定した集計問題です。「月ごとの売上合計と前月比を求める」「顧客ごとの累計購入金額でランキングを出す」「特定期間にログインしたユーザーのうち、購入に至った割合を求める」といった、EC・SaaS系の企業でよく扱われるテーマがそのまま題材になることが多く、抽象的なアルゴリズム問題とは毛色が違います。

こうした題材が多いのは、企業側が「アルゴリズムを解ける人」ではなく「自社のデータで明日から使える人」を見極めたいからです。競技プログラミング的なSQL問題集ばかり解いていると、この実務寄りの言い回しに戸惑うことがあるので、練習の後半では自分の志望企業の事業内容に寄せた架空のお題(例えば自分で「月次のリピート率を出すには」といった課題を作る)で手を動かしておくと、本番での適応力が上がります。

実行計画への意識も、差がつきやすいポイントの一つです。件数の多いテーブルに対して毎回全件走査になるような書き方をしていないか、絞り込み条件を先に効かせているか、といった視点は、正答か不正解かには影響しませんが、実務経験の有無を判断する材料として面接官が意識的に確認してくることがあります。私が聞いた例では、「このクエリ、テーブルが1000万行あったらどうなりそうですか」と一言だけ添えて反応を見る面接官がいました。完璧な実行計画の知識までは求められていませんが、「インデックスが効く列で絞り込んでから結合する」という発想があるかどうかだけでも、印象はかなり変わります。

GROUP BY・JOIN・サブクエリ・ウィンドウ関数、どこまで書ければ十分か

「どこまでSQLを勉強すればデータアナリスト職の選考に通用するのか」という質問もよく受けます。私が見てきた範囲では、求められる構文の難易度自体はそこまで高くありません。むしろ基本構文を迷わず正確に使えるかどうかの方が重視されています。

ウィンドウ関数まで自在に書ける候補者は、正直なところ多くありません。だからこそ「前月比を求めるならLAG関数」「顧客ごとの購入順位ならRANK」といった典型パターンを2〜3個手が覚えているだけで、他の候補者との差が付きやすい領域でもあります。一方で、サブクエリを何段も重ねて無理に1つのクエリで完結させようとする書き方は、可読性の観点でむしろマイナス評価を受けることがあります。CTE(WITH句)を使って処理の段階を分けて書く方が、実務でも歓迎されやすい書き方です。

「書けた」で終わらせない、説明の仕方が評価を左右する

ここまで繰り返し触れてきましたが、SQL実技テストの合否を分ける最大の要素は、クエリを書き終えた後の説明にあると私は考えています。同じ正解にたどり着いた候補者でも、「このクエリで合っていると思います」で終わる人と、「まず対象期間で絞り込んでから、ユーザー単位に集約しています。重複購入がある場合は最新の注文だけを残すようにROW_NUMBERで絞っています」まで語れる人とでは、面接官の受け取り方がまったく違います。

説明の練習として私が勧めているのは、クエリを書いた直後に「なぜその関数・その結合方法を選んだか」を一文で言い切る癖をつけることです。「LEFT JOINにしたのは、注文がないユーザーも含めて全体の傾向を見たかったからです」のように理由をセットで語る練習を重ねておくと、面接本番でどんな深掘りの質問が来ても、根拠に立ち返って答えられるようになります。逆に、書き方を丸暗記しているだけだと、少し切り口を変えた質問(「もし注文がないユーザーを除きたい場合は、どう直しますか」など)で急に答えに詰まってしまいます。

面接官がこの手の切り口を変えた質問を挟んでくるのは、意地悪をしたいわけではありません。実務では要件が途中で変わることが日常的にあるため、書いたクエリを別の条件に合わせて柔軟に組み替えられるかを確認したい、という意図がほとんどです。この観点は、技術面接やコーディングテストで落ちる人に共通する準備不足で取り上げた、エンジニア職の技術面接で「考えていることを言葉にできるか」が見られている構造と重なる部分が大きく、SQL実技テストだけに特有の話ではないと私は捉えています。

SQLとPython、どちらが重視されるか

データアナリスト志望の方からよく聞かれるのが、「SQLとPython、どちらを優先して勉強すべきか」という質問です。私が担当してきた求人を振り返ると、実技テストの主戦場はSQLであることが圧倒的に多いというのが実感です。Pythonが課される場合も、複雑なアルゴリズムを問うような内容ではなく、pandasでのデータ整形や簡単な可視化コードが中心で、難易度としてはSQL実技テストほど尖っていません。

これは業務の実態を反映しています。データアナリストの日々の業務は、社内のデータベースやデータウェアハウスから必要なデータを抽出・集計するところから始まることがほとんどで、Pythonでの分析はその後工程に位置します。抽出のところでつまずいていては分析まで辿り着けないため、企業側も入口の関門としてSQLを重視する傾向が強くなります。以前の記事(データエンジニアとデータアナリスト、求人票の違いの見分け方)でも触れましたが、求人票の書き方だけでは職務範囲が読み切れない分、選考の実技テストの中身が実際の業務比重を示す手がかりになっていることも多いです。

とはいえ、Pythonをまったく求められないわけではありません。特にBIツールの整備が進んでいない企業や、分析対象のデータ量が大きい企業では、pandasやSQLの実行速度改善の話題が面接で出てくることもあります。優先順位としては、まずSQLを実技テストで詰まらない水準まで仕上げ、余力があればPythonでの基本的なデータ整形に触れておく、という順番が現実的だと考えています。

未経験からデータアナリストを目指す場合、SQLはどこまで準備すればいいか

未経験からデータアナリスト職に挑戦する方の相談も増えていますが、この場合の準備の考え方は経験者と少し違います。実務経験がない分、面接官はより一層基礎構文の正確さと理解度を重視する傾向があるためです。応用的なウィンドウ関数を無理に覚えるより、GROUP BYとJOINを迷わず正しく書けることの方が、未経験選考では評価につながりやすいです。

未経験の方に特に伝えているのは、動くクエリを書けることと、実務で通用するクエリを書けることは別物だという点です。オンライン学習サービスの演習問題は、テーブル設計がきれいに整っていることが多く、実務データにありがちなNULLや表記ゆれ、重複行への配慮が抜け落ちたまま「解けた」気になりやすい構造になっています。この差を埋めるには、練習の段階から「このデータに欠損はないか」「このJOINで行は増減しないか」を自問する習慣をつけておくことが、面接本番での説明力に直結します。

ポイント： SQL実技テストは資格試験のように「一定点数を超えれば合格」という単純な仕組みではありません。同じ正解にたどり着いても、書き方と説明の仕方次第で評価は変わるという前提に立って準備するかどうかが、結果を大きく左右します。

まとめ、SQL実技テストは「解けるか」より「どう解いたか」が見られている

データアナリスト選考のSQL実技テスト対策というと、構文の難易度を上げることや、問題数をこなすことに意識が向きがちです。ですが実際に評価を左右しているのは、正答率そのものよりも、書き方の丁寧さと、なぜそう書いたかを言葉にできるかという一点だというのが、これまで数多くのフィードバックを聞いてきた私の実感です。

オンラインジャッジ型なら時間配分、画面共有のライブ実装型なら思考の言語化、口頭設計型なら結合キーと集計粒度の説明——形式ごとに準備の重心は変わりますが、どの形式にも共通しているのは、面接官が見ているのは正解にたどり着く力ではなく、実務でそのクエリを安心して任せられるかどうかだという点です。次に実技テストを控えている方は、正答を出す練習と同じだけ、自分の書いたクエリを声に出して説明する練習に時間を割いてみてください。