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