データクエリ

.factory/skills/data-querying/
├── SKILL.md
├── metrics.md (任意)
├── examples.sql (任意)
└── data-governance.md (任意)

---
name: data-querying
description: 明確に範囲設定された質問に答えるため内部データサービスをクエリし、共有しても安全で再実行しやすい結果と成果物を生成します。ステークホルダーが内部ウェアハウス、マート、レポートAPIからメトリクス、傾向、データスライスを必要とする場合に使用します。
---
# スキル: 内部データクエリ

## 目的

明確に範囲設定された質問に答えるため内部データサービスをクエリし、共有しても安全で再実行しやすい結果と成果物を生成します。

## このスキルを使うタイミング

- ステークホルダーが内部データに基づく**メトリクス、傾向、スライス**を求めている。
- 既存の**ウェアハウス、マート、レポートAPI**から答えを導出できる。
- アドホックな手動エクスポートではなく、**再現可能なクエリ**が必要。

## 入力

- **ビジネス上の質問**: 知りたいことを1〜2文で説明する。
- **期間とフィルター**: 日付範囲、顧客セグメント、環境など。
- **ソースシステム**: 使用するウェアハウス、スキーマ、APIの名前。
- **データ機密性メモ**: PII、財務データ、規制対象データが含まれるかどうか。

## 対象外

- 明示的に許可されていない本番OLTPデータベースへの直接クエリ。
- 新しいパイプラインや取り込みジョブの作成。
- 承認済みの場所の外部に生PIIやシークレットを共有すること。

## 規約

- 利用可能な場合は、生テーブルではなく**推奨クエリレイヤー**（例: dbtモデル、セマンティックレイヤー、分析API）を使用する。
- 保存済みクエリや分析ノートブックには、確立された**命名規約とフォルダー規約**に従う。
- 内部の**データ分類とアクセス制御**ポリシーを尊重する。

## 必須の動作

1. ビジネス上の質問を正確なクエリ仕様（メトリクス、ディメンション、フィルター）に変換する。
2. 適切なソースを選び、複数の選択肢がある場合はトレードオフを説明する。
3. 対象システムに対して高性能でコストを意識したクエリを書く。
4. **結果**と**再実行可能なクエリ成果物**（SQL、API呼び出し、ノートブック、ダッシュボードリンク）の両方を生成する。

## 必須の成果物

- 適切なリポジトリまたはフォルダーにチェックインされたクエリ本文（SQL、DSL、APIリクエスト）。
- 手法、前提、注意点をまとめた短い**分析サマリー**。
- 作成した**ダッシュボード、ノートブック、レポート**へのリンク。

## 実装チェックリスト

1. ビジネス上の質問、期間、フィルターを明確にする。
2. 鮮度、完全性、ガバナンスに基づいて最適なデータソースを特定する。
3. クエリを作成し、限定された期間またはサンプルで検証する。
4. 回答を歪める可能性がある結合、フィルター、集計を確認し、必要に応じて修正する。
5. 承認済みの場所に、内容が分かる名前でクエリを保存する。
6. 結果を取得し、主要な発見と制限を要約する。

## 検証

データスタックに存在する検証メカニズムを使用します。例:

- 関連プロジェクトで`dbt test`
- カスタムメトリクスまたは変換の単体テストや回帰テスト
- 既知のベンチマークまたは過去レポートとの手動スポットチェック

以下を満たしたらスキルは完了です:

- クエリが許容される時間とコストの範囲内で正常に実行される。
- 結果が期待値または既知の参照値と一致する（妥当な許容範囲内）。
- 別のエンジニアまたはアナリストが再利用できる程度に、クエリと結果が文書化されている。

## 安全性とエスカレーション

- クエリが**機密データまたは規制対象データ**に触れる場合、サンプル行を含める前に、送信先（PR、ドキュメント、チケット）が承認済みの場所であることを確認する。
- データ品質問題を特定した場合は、データ品質チケットを作成または更新し、分析サマリーで目立つように明記する。