金融​データアナリスト​面接の​基礎｜SQL・​統計・​可視化を​実務問題で​整理

結論：SQLが​書けるだけでは​通過しない、​3層で​評価される​面接

金融業界の「データアナリスト」採用面接は、運用会社のデータ部門・銀行や証券会社のデータ分析部署・事業会社の経営管理部門・フィンテック企業のいずれであっても、おおむね同じ3つの層で評価が組み立てられています。1つ目はSQLを中心とした実装力（テーブルから欲しい数字を正しく取り出せるか）、2つ目は統計・確率に対する思考力（数字の意味を正しく解釈できるか）、3つ目は可視化・レポーティング力（相手に応じて伝え方を変えられるか）です。どれか1つが強くても、残り2つが弱ければ「実務で使える人」とは評価されにくい構成になっています。

この3層それぞれについて、実際に面接で出やすい問題のパターンを「以下は説明用の仮設例です」と明示した設例で示し、式・クエリ→数値代入→結果→意味の順に検算しながら解説します。数理モデルの構築力そのものを問うクオンツ職の​採用プロセスとは評価軸が異なる点、また同じ「面接で手を動かす」系統でもExcel​モデル​監査を​問う​面接とは求められる力の種類が異なる点も、次の見出しで整理します。

金融業界の​「データアナリスト」とは​何を​指すのか

「データアナリスト」という職種名は組織によって指す範囲が広く、求人票を読んだだけでは業務内容が分かりにくい肩書きの1つです。本記事のスコープでは、おおむね次の4つの現場を想定しています。

共通するのは、既にある取引・顧客・KPIデータをSQLやBIツールで集計・検証し、意思決定者が判断できる形に落とし込む役割だという点です。これは、価格モデルやリスクモデルの数理的な構築・検証そのものを主業務とするクオンツ職とは目的が異なります。クオンツ職の面接では確率過程やモデルの実装力が主戦場になりますが、データアナリスト職の面接では「既存データから正しく数字を出し、意思決定に使える形で見せられるか」が主戦場になります。同様に、事業会社の経営企画・FP&A部門でのKPI集計業務との重なりも大きく、組織設計や役割の違いはFP&Aの​役割解説記事に譲ります。

入社後に実際に作るものは、ワンショットの分析レポートだけではありません。毎週・毎月同じ形式で回す集計クエリやダッシュボード、部門間で数字の定義がずれないためのKPI定義書、そして「なぜこの数字が動いたのか」を説明するアドホック分析が中心になります。面接では、この「再現性のある集計を書けるか」「異常値や欠損に気づけるか」「結論を一言で言えるか」が繰り返し形を変えて問われます。

頻出の​SQL​問題​パターン

ここからは、面接やデータテストで実際に出やすい4つのSQLパターンを、財務データを題材にした仮設例で示します。テーブル定義・設問・クエリ・結果・意味の順に並べているので、必ず自分の手元でも同じ結果になるか検算してみてください。SQLの基本文法（SELECT・WHERE・JOINの基礎など）は別記事に譲り、ここでは面接で差がつきやすい応用パターンに絞ります。

パターン1：JOINと​集計で​「前月比」を​出す

顧客セグメント別の月次取引額と前月比を求める問題です。以下は説明用の仮設例です。

取引テーブル（transactions）は customer_id・txn_month・amount（万円）を持ち、C1〜C4それぞれについて2026年1月・2月の取引額が入っているとします（C1:100→120、C2:80→90、C3:500→450、C4:300→320）。「セグメント別の月次合計と、前月からの増減額」を1本のクエリで求めます。

SELECT
  c.segment,
  t.txn_month,
  SUM(t.amount) AS total_amount,
  SUM(t.amount) - LAG(SUM(t.amount)) OVER (
    PARTITION BY c.segment ORDER BY t.txn_month
  ) AS mom_change
FROM transactions t
JOIN customers c ON c.customer_id = t.customer_id
GROUP BY c.segment, t.txn_month
ORDER BY c.segment, t.txn_month;

ポイントは、集計関数SUM()の結果に対して、さらにウィンドウ関数LAG()を重ねている点です。GROUP BYによる集計はSELECT句の中で先に計算されるため、その結果をウィンドウ関数の引数として使うことができます。実行結果は次のようになります。

corporateは800万円→770万円で30万円減少、retailは180万円→210万円で30万円増加しています。ここで面接官が見ているのは、SELECT句とGROUP BY句の実行順序（FROM/JOIN→WHERE→GROUP BY→HAVING→ウィンドウ関数→SELECT→ORDER BYの順に処理される）を理解した上で書けているか、という点です。

パターン2：RANK・​DENSE_RANK・​ROW_NUMBERの​使い分け

同点（タイ）がある場合の順位付けの違いを問う定番パターンです。以下は説明用の仮設例です。3本のファンドの四半期リターンが、2026年Q1でF1=8.0%・F3=8.0%（同点）・F2=5.0%、2026年Q2でF2=6.0%・F3=4.0%・F1=3.0%だったとします。

SELECT
  quarter,
  fund_id,
  return_pct,
  ROW_NUMBER() OVER (PARTITION BY quarter ORDER BY return_pct DESC, fund_id) AS rn,
  RANK()       OVER (PARTITION BY quarter ORDER BY return_pct DESC) AS rk,
  DENSE_RANK() OVER (PARTITION BY quarter ORDER BY return_pct DESC) AS drk
FROM fund_returns
ORDER BY quarter, return_pct DESC, fund_id;

2026年Q1のF1とF3は同じ8.0%です。RANK()は同点の2件をどちらも1位とし、次点のF2は2位を飛ばして3位になります。DENSE_RANK()は飛ばさず、F2は2位になります。ROW_NUMBER()は同点でも必ず1件ずつ連番を振るため、ここではORDER BYにfund_idを補って並び順を固定しています（このタイブレークがないと、同点行のどちらが1位になるかはデータベースの内部処理に依存し、実行のたびに変わり得ます）。「ランキング上位◯社を抽出したい」という要件で、同点の扱いを何も考えずにROW_NUMBERを使うと、同着のはずの1社が抜け落ちる、という事故につながる点が実務でもよく話題になります。

パターン3：CTEで​ウィンドウ​関数の​結果を​絞り込む

パターン1の続きとして、「前月比の変化率が10%以上のセグメントだけを抽出してほしい」という追加要望を想定します。ウィンドウ関数の結果はWHERE句で直接は使えないため、CTE（共通テーブル式）で段階を分けて書く必要がある、という点が実務・面接の両方でよく問われます。

WITH seg_monthly AS (
  SELECT
    c.segment,
    t.txn_month,
    SUM(t.amount) AS total_amount
  FROM transactions t
  JOIN customers c ON c.customer_id = t.customer_id
  GROUP BY c.segment, t.txn_month
),
seg_mom AS (
  SELECT
    segment,
    txn_month,
    total_amount,
    LAG(total_amount) OVER (
      PARTITION BY segment ORDER BY txn_month
    ) AS prev_amount
  FROM seg_monthly
)
SELECT
  segment,
  txn_month,
  total_amount,
  prev_amount,
  ROUND((total_amount - prev_amount) * 100.0 / prev_amount, 1) AS mom_pct
FROM seg_mom
WHERE prev_amount IS NOT NULL
  AND ABS(total_amount - prev_amount) * 1.0 / prev_amount >= 0.1
ORDER BY segment, txn_month;

1段目のCTE（seg_monthly）でセグメント×月の合計を作り、2段目（seg_mom）で前月の値をLAG()で取り出し、最後のSELECTで変化率を計算してから10%以上のものだけに絞り込みます。パターン1の結果を使うと、corporateの変化率は(770-800)÷800=-3.75%で条件を満たさず、retailの変化率は(210-180)÷180=約16.7%で条件を満たすため、結果は次の1行だけになります。

面接では「なぜ1つのSELECTでLAG()の結果をそのままWHEREに書けないのか」を説明できるかが問われます。理由は処理順序にあり、WHERE句はウィンドウ関数よりも前の段階で評価されるため、ウィンドウ関数の計算結果をフィルタ条件に使うには、CTEやサブクエリで一度「外側」に出す必要があります。

パターン4：累積比率で​集中度を​測る

リスク管理・コンプライアンス寄りのデータ分析でよく出るのが、保有銘柄の集中度を測る問題です。以下は説明用の仮設例です。あるファンドの保有銘柄7銘柄の組入比率が、A=25%・B=20%・C=15%・D=15%・E=10%・F=8%・G=7%（合計100%）だったとします。

SELECT
  security_id,
  weight_pct,
  SUM(weight_pct) OVER (
    ORDER BY weight_pct DESC, security_id
    ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
  ) AS cum_pct
FROM holdings
ORDER BY weight_pct DESC, security_id;

ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROWは「並び替えた先頭行から現在行まで」を毎行ごとに合計し直す指定です。この結果から、上位3銘柄で60%、上位5銘柄で85%を占めていることが分かります。「単一銘柄で組入比率何%を超えたら警告する」といった集中リスクの社内ルールを、SQLの累積和で機械的にチェックできる形にする、という発想を示せるかが評価ポイントです。

統計・確率の​基礎質問

金融データアナリストの面接では、SQLで正しい数字を出せることに加えて、「その数字をどう解釈するか」を確かめる統計・確率の質問がよく続きます。ここでは各質問がどんな意図で聞かれているかを整理し、手法そのものの解説は専用記事に委ねます。

• 「年収データの代表値には平均でなく中央値を使うべき理由を説明してください」というタイプの質問は、外れ値の影響や分布の形を理解しているかを確認するものです。相加平均・幾何平均・中央値・分散・標準偏差の使い分けは記述統計の​入門記事で扱っています。
• 「2つのKPIの相関係数が高いとき、それは何を意味しないか説明してください」というタイプの質問は、相関と因果を混同していないかを確認するものです。疑似相関・第三因子・逆因果の見分け方は相関と​因果の​違いを​扱う​記事に譲ります。
• 「月次データのサンプル数が少ないとき、平均値の信頼区間はどう変わりますか」というタイプの質問は、点推定だけに頼ることの危うさを理解しているかを確認するものです。標準誤差と信頼区間の考え方は標準誤差・​信頼区間の​記事で扱っています。
• 「施策の前後でKPIに差が出たとき、それが偶然でないとどう言えますか」というタイプの質問は、t検定・p値・多重検定の理解を確認するものです。この深掘りはt検定と​p値の​記事に譲ります。

これら4本に共通するのは、面接官が知りたいのは公式の暗記ではなく「なぜその手法をここで使うのか」「その結論を過信していないか」を言葉で説明できるかという点です。数式を正確に再現できても、「サンプル数が少ないので信頼区間は広くなり、断定的な結論は避けるべきです」といった一言が出てこないと、実務で数字を扱う人物として評価されにくくなります。

可視化・​レポーティングで​評価される​観点

可視化課題では、グラフの見た目の巧拙よりも「誰に何を伝えるためのアウトプットか」を意識できているかが評価の中心になります。経営会議向けの資料と、現場担当者向けの週次モニタリング資料では、同じデータでも見せ方が変わるべきです。

実務でこの「誰向けにどう見せるか」を体系的に扱うのがビジネスインテリジェンス​（BI）の考え方であり、経営会議用の資料と現場用の資料を分けて設計する発想は経営管理​ダッシュボードの設計論とも重なります。ダッシュボードの一番上に置く要約部分の作り方はサマリー・​ダッシュボードタブで、目標対比のKPIを1本の棒でシンプルに見せたい場面ではブレットチャートのような技法が使われます。面接では「なぜこのグラフの種類を選んだのか」「軸を省略していないか」を自分の言葉で説明できるかが問われ、装飾的な円グラフを多用するより、比較したい数字を素直に並べる方が評価されやすい傾向があります。

もう1つよく見落とされるのが、部門ごとにKPIの定義が微妙に違うために数字が合わない、という問題です。「解約率」1つとっても、分母を契約数にするか顧客数にするか、月末時点にするか月中平均にするかで数字は変わります。この定義のずれを防ぐ仕組みがKPI定義書であり、可視化課題で「この指標の定義を教えてください」と聞かれたときに即答できるかどうかは、実務経験の有無が最も出やすいポイントの1つです。

ビジネス​理解を​問う​ケース問題

ここまでのSQL・統計・可視化を組み合わせた総合問題として、「直近3か月で顧客の解約率が上昇している。原因を特定し、対応の方向性を提案してください」というケース問題を考えます。以下は説明用の仮設例に基づく進め方の整理であり、実在の企業事例ではありません。

まず最初にすべきなのは、指標の定義確認です。「解約率」の分母・分子・集計タイミングを確認しないまま分析を始めると、後で数字が合わなくなります。次に、全体の解約率をセグメント（契約期間・プラン・流入経路など）で分解し、どの切り口で悪化が集中しているかを特定します。この分解には、パターン1で示したJOINと集計、パターン2で示したランキングがそのまま使えます。

切り口を絞り込んだら、獲得月別に継続率を追うコホート分析で、特定の獲得月のコホートだけ継続率が悪いのか、全コホートに共通する悪化なのかを見ます。指標の計算式自体はチャーンレート・​NRRの考え方に沿って整理します。最後に、「この悪化は誤差の範囲ではなく本当に有意な変化か」を確認する場面では、前述のt検定・p値の考え方（詳細記事参照）が必要になります。1つのセグメントの解約率が前月から2ポイント上がっていたとしても、そのセグメントの母数が20件しかなければ、たまたま数件が重なっただけの可能性を排除できません。

この一連の流れを、面接の場で「まず定義を確認し、次にセグメントで分解し、コホートで時系列の癖を確認し、最後に統計的な有意性を確認してから経営層に一言で報告する」という順序で説明できるかどうかが、実務理解の有無を測る評価軸になります。

未経験からの​学習優先順位​（出身業界別）

金融データアナリスト職を目指す場合、出身業界によって強みと弱みの偏り方が異なります。以下は一般的な傾向の整理であり、個人の経験によって当てはまり方は変わります。

SQLの基本文法（SELECT・WHERE・JOINの基礎）を体系的に学び直したい場合はSQL​入門記事が入口になります。Excel・SQL・BI・Pythonをどう使い分けるかの全体像はデータ分析の​進め方の​記事で整理しています。公開データを使って自分の手でデータ取得から練習したい場合は、EDINET APIなどを扱うPythonでの​データ​取得記事も参考になります。どの出身背景であっても、「読んで分かる」状態と「自分で書いて検算できる」状態の間には大きな差があり、面接ではこの差がそのまま質問の深掘りで露呈します。

よく​ある​質問​（FAQ）

まとめ

金融業界のデータアナリスト面接は、SQLによる実装力、統計・確率に基づく解釈力、そして相手に応じた可視化・伝達力という3層で評価されます。SQLはJOIN・集計・ウィンドウ関数・CTEを使った応用パターンまで自力で書けて検算できることが目安になり、統計は暗記よりも手法選択の理由を説明できることが重視されます。可視化では見た目の巧拙よりも「誰に何を伝えるか」の設計が評価され、出身業界によって埋めるべき優先順位は異なります。いずれの層も、読んで理解した気になるだけでなく、自分の手を動かして検算する経験がそのまま面接での説明の説得力につながります。

出典・参考​（2026年9月確認）

• PostgreSQL公式ドキュメント「9.22. Window Functions」（ROW_NUMBER・RANK・DENSE_RANK・LAG・LEADの定義） postgresql.org
• PostgreSQL公式ドキュメント「7.8. WITH Queries (Common Table Expressions)」 postgresql.org
• PostgreSQL公式ドキュメント「2.7. Aggregate Functions」（GROUP BY・HAVINGの処理順序） postgresql.org

※本記事は教育目的の一般的な解説であり、法務・税務・投資助言ではありません。設例は理解のための仮設例です。年収・市場情報は執筆時点(2026年9月)の公開情報に基づく参考値です。