概要 データアナリスト面接では、曖昧な事業上の問いを信頼できる分析へ変える力が評価されます。優れた候補者はSQL、指標判断、データ品質、事業向けの明快な説明を組み合わせます。
面接官が評価すること
—
SQL:結合、絞り込み、集計、ウィンドウ関数、データ修正を正しく行えるか。
—
指標:数字を並べるだけでなく、事業を適切に表す尺度を定義できるか。
—
事業理解:結果を顧客、売上、リスク、業務へ結び付けられるか。
—
品質:欠損、重複、外れ値、計測不良、偏った標本を見つけられるか。
—
ダッシュボード:見栄えだけでなく、意思決定に役立つ報告を設計できるか。
—
説明力:仮定、確信度、限界、提案を明確に伝えられるか。
優れたアナリストはクエリに答えるだけではない
本当に知るべき問いを確認し、データで答えられるか検証し、仮定を明示し、どの意思決定を支える分析か説明します。精度と判断力の両方が必要です。
データアナリストの選考プロセス 一般的な選考には、初期面談、SQL、分析ケース、ダッシュボード・可視化、関係者への説明、行動面接が含まれます。
一般的な選考段階
1
採用担当者面談:職務との適合、使用ツール、業界、報酬、志望理由を確認します。
2
採用責任者面談:過去の分析、関係者、成果、説明方法を深掘りします。
3
SQL面接:結合、集計、絞り込み、ウィンドウ、日付、空値、デバッグを評価します。
4
分析ケース:指標変動を診断し、製品変更を評価し、対応を提案します。
5
ダッシュボード・可視化:指標、グラフ、絞り込み、報告頻度を評価します。
6
行動面接:当事者意識、曖昧さ、優先順位、関係者、不完全なデータへの対応を見ます。
SQL面接
分析ケース
中心となる問い
正しいデータを正確に取得・変換できるか。
データを根拠ある意思決定へ変えられるか。
良い評価材料
正しい結合と条件、適切な粒度、目的に合うウィンドウ関数
明確な仮定、分類、定義、限界、提案
よくある誤り
異なる粒度を結合して行数を増幅させる
品質やセグメントを確認せず結論を出す
有効な準備
現実的なスキーマ、コホート、継続率、ファネル、デバッグを練習する
診断、実験、ダッシュボード批評、経営向け要約を練習する
粒度が落とし穴になりやすい
利用者、注文、明細、セッション、イベントなど異なる粒度を結合すると、多くの誤りが生まれます。SQLを書く前に分析単位と各行が表すものを定義しましょう。
SQL面接の基礎 珍しい構文より、粒度、結合、条件、集計、日付、空値、検証を正しく考える力が重要です。
SQL問題を解くための確実な手順
1
書き始める前に事業上の問いと出力列を確認します。
2
1行が利用者、注文、明細、セッション、イベント、アカウント、日付のどれを表すか定義します。
3
必要な表を特定し、各結合のカーディナリティを確認します。
4
日付、状態、テスト、取消、返金、社内アカウントの条件を慎重に定義します。
5
粒度を定めてから集計し、必要ならCTEで事前集計してから結合します。
6
順位、累積、重複除去、前後イベントにはウィンドウ関数を使います。
7
件数、一意値、合計、空値、重複、事業ルールで結果を検証します。
重要な概念
粒度
各行が表す単位です。誤ると売上、利用者、注文、イベントが増幅されます。
LEFT JOIN
対応する行がなくても左側の全行を残します。活動のない利用者や日付を含める場合に使います。
ウィンドウ関数
関連行をまとめて消さず、順位、累積、LAG、LEAD、重複除去を計算します。
コホート
登録月、初回購入、獲得経路、プランなど、共通の開始点や属性を持つ集団です。
✓ 推奨
—
条件をWHEREとJOINのどちらへ置くべきか確認する
✗ 避けること
—
SELECT DISTINCTで重複の原因を隠す
—
LEFT JOINで残した空値を条件によって意図せず除外する
SQL面接の質問 利用者、注文、イベント、サブスクリプション、継続率、売上、ファネルに関する現実的な問いを練習します。
初級 · SQLと集計
過去30日間の総売上が最も多い顧客5人を取得するクエリを書いてください。
回答の組み立て — 絞り込み → 結合 → 集計 → 並べ替え → 件数制限
取消・返金済み注文を含めるか確認し、通常は完了注文だけを対象にします。注文を日付と状態で絞り、顧客別にまとめ、売上を合計し、降順で上位5件を取得します。
日付の基準と粒度が重要です。売上が明細表にあるなら事前集計し、結合による増幅を防ぎます。5位同率をすべて含めるならLIMITではなく順位関数を使います。最後に対象売上合計、件数、重複を検証します。
想定される追加質問
5位と同額の顧客をすべて含めるにはどうしますか?
売上が明細粒度なら何が変わりますか?
返金をどう除外しますか?
中級 · SQLとコホート
1月登録者の7日目継続率を計算してください。
回答の組み立て — コホート定義 → 再訪定義 → LEFT JOIN → 集計
まず継続を登録後ちょうど7日目の活動とするか、最初の7日間のいずれかとするか定義します。7日目なら、1月登録者のuser_idとsignup_dateをCTEにし、7日目の有効イベントをLEFT JOINします。
LEFT JOINなら戻らなかった人も残ります。分母は観測可能な対象利用者、分子はイベントのある一意利用者です。7日分をまだ観測できない利用者は分母から外します。獲得経路、端末、地域、登録週でも分けられます。
想定される追加質問
7日目継続と7日間の移動窓はどう違いますか?
観測期間が7日未満の利用者をどう扱いますか?
どのイベントを活動として数えますか?
中級 · SQLとウィンドウ関数
各利用者の2回目の購入日を求めてください。
回答の組み立て — 利用者ごとに購入へ連番を付ける
有効な完了購入だけに絞り、row_number() over (partition by user_id order by purchase_at, order_id)で番号を付け、2番の行を選びます。同じ時刻がある場合もorder_idで順序を一意にします。
全利用者を表示するなら、この結果を利用者表へLEFT JOINし、2回目がない人は空値にします。大きな表ではuser_idと購入日時の索引が有効です。
想定される追加質問
2回目の購入がない利用者もどう表示しますか?
同一時刻の購入をどう扱いますか?
1回目と2回目の間の日数をどう計算しますか?
中級 · SQLとファネル分析
登録、メール確認、オンボーディング完了、初回購入からなるファネルで、各段階の転換率をどう計算しますか?
回答の組み立て — 利用者ごとに各段階の最初の時刻を一つずつ持つ
条件付き集計で利用者ごとに1行を作り、各段階の最初の時刻を取得して繰り返しイベントを重複計上しません。順序が必須なら、確認は登録後、オンボーディングは確認後、購入はオンボーディング後であることを条件にします。
段階間と全体の転換率を計算し、各分子は次段階の一意利用者、分母は前段階の一意利用者とします。端末、獲得経路、地域、コホートで分けると離脱箇所が分かります。重複、段階飛ばし、タイムゾーン、試験アカウント、遅延イベントも確認します。
想定される追加質問
イベント順序をどう強制しますか?
オンボーディングの急落をどう調査しますか?
ファネルをどう可視化しますか?
指標と事業ケースの質問 適切な指標を定義し、変化を意味のある単位で分け、証拠に見合う確信度で対応を提案する力が評価されます。
中級 · 分析ケース
昨日、日次アクティブユーザーが12%減少しました。どう調査しますか?
回答の組み立て — 検証 → 分類 → ファネル → 外部要因 → 提案
まず計測変更、処理遅延、タイムゾーン、ボット除外、アプリ更新を確認し、生データとも比較します。次にプラットフォーム、バージョン、地域、獲得経路、利用歴、プラン、端末、流入元で分けます。
起動、ログイン、閲覧、中核操作のどこが落ちたかを確認します。起動が同じで活動が減ったなら製品内、起動自体が減ったなら通知、獲得、季節性、障害、外部要因が候補です。原因が更新後のエラーならロールバックします。データ遅延なら、誤った緊急性を作らず限界を伝えます。
想定される追加質問
最初にどの可視化を確認しますか?
季節性とプロダクトの後退をどう区別しますか?
DAUが減って売上が増えた場合、何を意味しますか?
中級 · 指標
新しい推薦機能の成功をどう定義しますか?
回答の組み立て — 目標 → 主要指標 → 推進指標 → ガードレール → セグメント
目標が発見、利用、購入、継続、客単価のどれかを確認します。主要指標はクリックだけでなく価値を表す必要があります。ECなら、アクティブ利用者当たりの推薦経由購入などです。
表示数、クリック率、カート追加、転換率、セッション売上、対象範囲、多様性を推進指標とし、返品、返金、無関係なクリック、遅延、苦情、共食いをガードレールにします。新規・既存、カテゴリ、端末、表示場所で分けます。短期はA/Bテスト、長期は継続と再購入で価値を確認します。
想定される追加質問
クリック率が上がり購入が増えない場合はどうしますか?
推薦品質をどう測定しますか?
既存購入の共食いをどう見つけますか?
中級 · 事業分析
売上が20%増加した一方、転換率が下がりました。どう説明できますか?
回答の組み立て — 売上を流入、転換、客単価、構成、価格、継続へ分解
流入増が転換率低下を上回った可能性があります。値上げ、セット販売、大口顧客、高価格商品の構成によって客単価が上がった場合もあります。訪問者が減っても価値の高い層へ変わった可能性や、計測定義の変更も考えられます。
獲得経路、商品、地域、新規・既存、顧客層、端末で分け、売上をセッション、転換、客単価、返金、再購入へ分解します。転換率の分母がセッション、利用者、訪問者のどれかも確認します。増収の質と持続性で評価します。
想定される追加質問
最初にどの分解を行いますか?
増収が値上げだけによる場合はどう考えますか?
持続可能性をどう検証しますか?
ダッシュボードと可視化 良いダッシュボードはグラフの寄せ集めではなく、明確な対象者のための意思決定ツールです。
中級 · ダッシュボード設計
サブスクリプション事業の状態を経営陣が把握するダッシュボードを設計してください。
回答の組み立て — 対象者 → 意思決定 → 指標 → セグメント → アラート
まず対象者と意思決定を確認します。経営陣には細かな運用指標すべてではなく、成長、継続、収益化、リスクの要約が必要です。
上部にMRR、純・総売上継続率、新規・拡張・縮小・解約MRR、有料顧客数、試用から有料への転換率、ARPU、必要ならCAC回収期間、実績対目標を置きます。顧客種別、獲得経路、プラン、地域、規模、営業支援とセルフサービスで分けられるようにします。
時系列、コホート、MRRブリッジ、解約理由、目標差分によって、成長しているか、なぜか、どこにリスクがあるか、何を調査すべきかへ答えます。定義、更新時刻、絞り込み、責任者、閾値も表示します。
想定される追加質問
最初の画面に何を表示しますか?
プロダクトマネージャー向けならどう変えますか?
誤解を招かないために何をしますか?
中級 · 関係者とのコミュニケーション
関係者が誤解を招くグラフを求めたらどうしますか?
回答の組み立て — 意思決定を確認 → リスクを説明 → より良い表示を提案
まず、そのグラフが支える意思決定を確認します。次に、累積売上が減速を隠す、カテゴリの多い円グラフが差を見えにくくする、区間を示さないと過度な確実性を与える、といったリスクを客観的に説明します。
同じ問いに答える時系列、コホート、ファネル、分布、積み上げ棒、要因分解を提案します。元の表示が必要なら限界を明示して併記できますが、自分の推奨としては扱いません。役立つことと分析の誠実さは両立します。
想定される追加質問
経営幹部から圧力を受けたらどうしますか?
誤用されやすいグラフは何ですか?
不確実性をどう表現しますか?
効果的なダッシュボードの原則
—
グラフの種類ではなく、意思決定と対象者から始める。
—
経営、製品、財務、運用の用途を一つの画面へ無理に詰め込まない。
Excelと表計算の質問 表計算を多用する職種では、数式、ピボットテーブル、データ整形、照合、検証可能なモデルが評価されます。
初級 · EXCELとデータ整形
分析前に乱れた表計算データをどう整えますか?
回答の組み立て — 把握 → 標準化 → 検証 → 文書化
まず行列、空値、重複、型、不可能な値、日付、外れ値を把握し、未変更の原本を残します。空白を除き、名称を統一し、日付を解析し、単位をそろえ、表記揺れを管理済みカテゴリへ対応付けます。重複除去前に事業上の一意キーを定義します。
合計と件数を信頼できる情報源と照合し、空値、一意値、範囲を確認します。変換内容を記録し、原本と整形済みデータを分け、見えない手作業を避けます。
想定される追加質問
重複行をどう扱いますか?
よく使う数式は何ですか?
ファイルを検証可能にするにはどうしますか?
初級 · EXCELと分析
ピボットテーブルと数式をどう使い分けますか?
回答の組み立て — 探索と、制御された計算の使い分け
ピボットテーブルは、ディメンション別に素早く探索、集計、要約するのに適しています。数式は、コホート、ブリッジ、加重スコア、例外、照合のような独自・多段階・監査可能な処理に向きます。
実務ではピボットで傾向を発見してから、制御されたモデルを作ります。定期レポートは、壊れやすい手作業の表へ依存せず、再現可能なSQLまたはBI処理へ移すべきです。
想定される追加質問
ピボットテーブルにはどのようなリスクがありますか?
VLOOKUPとINDEX/MATCHまたはXLOOKUPをどう比較しますか?
分析をExcelからSQLやBIへ移すのはいつですか?
重要な技能
XLOOKUP / INDEX MATCH
表間の値を対応付けます。キー、欠損、重複、完全一致・近似一致を確認する必要があります。
ピボットテーブル
データを素早く集計・分類します。元範囲、集計方法、条件を検証する必要があります。
照合
合計が財務、プロダクト分析、CRM、請求などの信頼できる情報源と一致するか確認します。
実験とA/Bテスト 実験を設計・分析・批判的に評価し、データから実際にどこまで結論を導けるか理解する力が評価されます。
中級 · 実験
新しい購入手続きのA/Bテストをどう分析しますか?
回答の組み立て — 仮説 → 無作為化 → 指標 → ガードレール → 決定
仮説は、新しい設計が摩擦を減らし、後続の悪影響なしに購入完了を増やすことです。無作為化単位、標本、期間、露出、対象条件、割当の固定を確認します。セッション単位だと同じ利用者に異なる版が表示される恐れがあります。
主要指標は購入手続き開始から購入への転換率です。決済エラー、所要時間、客単価、追加購入を副指標、返金、チャージバック、問い合わせ、遅延、エラー、苦情をガードレールにします。統計的有意性だけでなく実務上の大きさも見ます。有用な改善、健全なガードレール、信頼できる計測、安定した効果がそろう場合だけ展開を提案します。
想定される追加質問
転換率と返金がともに増えたらどうしますか?
結果を早く見すぎることをどう防ぎますか?
新規利用者だけに効果がある場合はどうしますか?
中級 · 実験
実験結果が統計的に有意でない場合、何を提案しますか?
回答の組み立て — 検出力を確認 → 方向を評価 → 費用を考慮 → 決定
有意でないことは効果がないことと同じではありません。標本数と期間が、意味のある差を検出できたか確認します。効果量と区間も見ます。利益と損失の両方を含む広い区間なら結論不能、ゼロ付近の狭い区間なら影響が小さいと考えられます。
保守費、リスク、戦略も考慮します。高コストで測定可能な利益のない機能は展開すべきではありません。戦略価値が高い、または低コストなら改善して再測定できます。設計、観測結果、確信度、限界、提案を分けて説明します。
想定される追加質問
「効果なし」と「結論不能」はどう違いますか?
技術に詳しくない人へどう説明しますか?
どのような場合に再実験しますか?
データ品質と分析判断 分析の信頼性は元データを超えません。誤った意思決定を生む前に問題を見つける力が評価されます。
中級 · データ品質
二つのダッシュボードで売上額が異なります。どうしますか?
回答の組み立て — 定義 → 情報源 → 条件 → 粒度 → 時点 → 照合
まず売上の定義を比較します。総額か返金・割引・税・チャージバック控除後か、注文日・決済日・発送日・請求日のどれかを確認します。次に情報源、条件、粒度を見ます。テスト、取消、社内アカウント、地域、明細結合、タイムゾーン、更新頻度も差の原因になります。
信頼できる情報源から始め、差分要因を一つずつ加減するブリッジを作って一致させます。どちらが誤りか示すだけでなく、共通定義、責任者、公式情報源、再発防止策を決めます。
想定される追加質問
公式な情報源をどう選びますか?
財務とプロダクトで異なる定義が必要ならどうしますか?
不一致をどう伝えますか?
初級 · データ品質
分析で欠損データをどう扱いますか?
回答の組み立て — 欠損を測る → 原因を特定 → 処理を選ぶ → 開示する
まず項目、割合、セグメント、期間、情報源、プラットフォーム別に欠損を定量化します。欠損は無作為とは限りません。任意項目、計測不良、遅延、連携、プライバシー、対象外のどれが原因か調べます。
原因に応じて行を除外し、根拠を持って補完し、不明カテゴリを設け、別の情報源で補い、または分析範囲を限定します。ゼロと不明は同じではありません。欠損が確信度へどう影響し、妥当な仮定を変えても結論が維持されるか説明します。
想定される追加質問
行を除外してよいのはどのような場合ですか?
欠損値の補完にはどのようなリスクがありますか?
計測不良をどう見つけますか?
計算例
発表前の品質確認
新しいオンボーディングがアクティベーションを改善したことを示したい状況です。
対象集団を確認
登録期間、プラットフォーム、国、対象条件を確認します。
指標を確認
アクティベーション定義、計測、重複、ボット、試験、遅延イベントを確認します。
比較を確認
比較可能な群を使うか、前後比較なら季節性と獲得構成を調整します。
結論を確認
主要セグメントでも主張が成り立つか、ガードレールが悪化していないか確認します。
結果
結果だけでなく、その結果を信頼できる理由も説明できるため、分析の説得力が高まります。
行動・関係者対応の質問 曖昧さ、圧力、説明、優先順位、データが期待した答えを支持しなかった状況への対応を扱います。
中級 · 行動面接
自分の分析が事業判断を変えた経験を教えてください。
回答の組み立て — 意思決定 → 分析 → 発見 → 提案 → 影響
公開、価格、マーケティング、製品、業務、優先順位の判断へ分析が影響した経験を選びます。使ったデータと指標、重要なセグメント、予想外の発見を、ツールの細部に埋もれず説明します。
次に提案と成果を示します。たとえば採算の悪い獲得経路を見つけて予算を移した、クリックを増やす一方で継続率を損ねる機能を停止した、などです。限界、不確実性、関係者との合意形成も含めます。
想定される追加質問
影響をどう測定しましたか?
誰が提案に反対しましたか?
今なら何を変えますか?
中級 · 関係者とのコミュニケーション
関係者は今すぐ答えを求めていますが、データが乱れています。どうしますか?
回答の組み立て — 緊急性を確認 → 方向性を示す → 限界を説明 → 検証計画
まず意思決定、期限、リスクを確認します。可逆で低リスクな判断なら暫定的な方向性で足りる場合がありますが、売上、顧客、規制、戦略に関わるなら品質基準を高くします。
今日答えられることと答えられないことを分け、必要なら確信度を明示した暫定推定を出します。同時に、整形、検証、照合の手順と信頼できる回答の期限を示します。速い誤答が事実として定着することを防ぎながら、関係者が動けるようにします。
想定される追加質問
非現実的な期限にどう異議を唱えますか?
方向性だけの回答で十分なのはいつですか?
確信度をどう伝えますか?
初級 · 行動面接
複数の分析依頼にどう優先順位を付けますか?
回答の組み立て — 影響 → 緊急性 → 工数 → 依存関係 → 整合
意思決定への影響、緊急性、工数、依存関係、可逆性で優先します。明日の公開判断に必要な分析は、任意のダッシュボード改善より通常優先されます。
各依頼について意思決定と責任者を確認し、繰り返す手作業レポートは自動化候補にします。競合する場合は、何をいつ届けられるか、どの判断が依存するか、なぜその順序を勧めるかを説明します。分析時間は依頼件数ではなく意思決定の質へ使います。
想定される追加質問
依頼をどう断りますか?
何を自動化しますか?
経営陣からの依頼をどう扱いますか?
データアナリスト面接の準備戦略 SQL、事業ケース、ダッシュボード批評、表計算、説明練習を組み合わせます。正確で明快、意思決定に役立つ回答を目指します。
4週間の準備プラン
1
第1週:SQL基礎。結合、GROUP BY、HAVING、日付、空値、CASE、正しい集計を練習します。
2
第2週:高度なSQL。ウィンドウ、コホート、継続率、ファネル、重複除去、順位、デバッグを練習します。
3
第3週:分析ケース。指標低下、実験、売上、ダッシュボード、提案を練習します。
4
第4週:説明と模擬面接。分析を明快に説明し、仮定を守り、プロジェクトを紹介します。
企業タイプ別の重点
—
プロダクト分析:ファネル、継続率、実験、イベント、セグメント、提案。
—
EC:売上、転換、客単価、再購入、在庫、マーケティング、返品。
—
金融:照合、リスク、不正、規制、コホート、財務上の正確性。
—
B2B SaaS:MRR、ARR、純・総売上継続率、商談、アクティベーション、拡張、解約。
—
業務分析:SLA、能力、生産性、費用、待ち行列、品質、根本原因。
クエリだけを暗記しない
面接官はスキーマ、定義、境界条件を変えます。粒度、カーディナリティ、対象集団、検証を理解し、新しいデータへSQLと分析を適応できるようにします。
要点
優れた回答は、正しいSQL、厳密な定義、事業判断、品質確認、明快な説明を組み合わせます。数字を増やすのではなく、信頼できる証拠でより良い意思決定を支えましょう。