🧭 はじめに
ETL（Extract, Transform, Load）処理は、データ連携・分析基盤の要となる重要コンポーネントです。
しかし、命名規約やフォルダ構成がプロジェクトごとにバラバラだと、検索・保守・引き継ぎコストが急増します。
この記事では、
DataSpider・SSIS・Azure Data Factory などで共通的に使える
命名規約とフォルダ構成のベストプラクティスを紹介します。
🧩 課題
- 命名の不統一：チームごとに異なるルール。検索や比較が困難。
- 階層構造の混乱：業務別／処理別／日次・月次ジョブが混在。
- 属人化・引き継ぎ難：特定担当者に依存。改修が怖い状態。
⚙️ 解決アプローチ（設計思想）
「誰が見ても意味がわかる構造」を実現するために、以下の5原則を定義します。
| 原則 | 内容 |
|---|---|
| ① 一貫性 | 命名・階層ルールはツール・環境を問わず共通化 |
| ② 可読性 | 名前を見ただけで「何を・どこで・いつ」処理しているかがわかる |
| ③ 拡張性 | 新業務や新ツール追加時も再設計不要 |
| ④ 自動化適性 | JP1やGit CI/CDパイプラインで自動検出可能 |
| ⑤ 再利用性 | DataSpiderテンプレートやモジュール化を前提設計 |
🧱 命名規約：用途別テンプレート
用途ごとに命名規則を統一することで、検索・監査・差分抽出が容易になります。
| 種類 | 接頭辞 | 命名フォーマット例 | 良い例 | 悪い例 |
|---|---|---|---|---|
| 抽出（Extract） | EX_ |
EX_{System}_{Table}_{YYYYMMDD} |
EX_SAP_SALES_20251018 |
SALES_DATA_1 |
| 変換（Transform） | TR_ |
TR_{Source}_{Target}_{RuleName} |
TR_SALES_CSV_AGGREGATE |
CONVERT_SALES1 |
| ロード（Load） | LD_ |
LD_{TargetSystem}_{Table}_{Cycle} |
LD_DWH_SALES_DAILY |
LOAD1 |
| 検証（Validation） | VL_ |
VL_{Target}_{Type} |
VL_SALES_COUNT_CHECK |
VALIDATION_OLD |
| 共通ユーティリティ | UT_ |
UT_{Function} |
UT_ERROR_LOG_EXPORT |
UTIL |
💡 命名ルールのポイント
- 「処理タイプ_対象_目的_周期」の構造で意味を自明化
- すべて大文字＋アンダースコア区切りで統一
- 英単語略語はチーム標準リストで統一（例：SALES=販売、HR=人事）
📁 フォルダ階層設計：3段階構造（業務／処理／周期）
現場で最も混乱するのがフォルダ階層。
DataSpiderやADFでの実運用を想定し、**「業務領域」→「処理種別」→「実行周期」**の3階層構造を推奨します。
/ETL_Projects/
├── Sales/ # 業務領域
│ ├── Extract/ # 処理種別
│ │ ├── Daily/ # 実行周期
│ │ │ └── EX_SAP_SALES_YYYYMMDD
│ │ └── Monthly/
│ │ └── EX_SAP_SALES_MONTHLY
│ ├── Transform/
│ │ └── TR_SALES_AGGREGATE
│ └── Load/
│ └── LD_DWH_SALES_DAILY
├── HR/
│ ├── Extract/
│ └── Load/
└── Common/
└── UT/
└── UT_ERROR_LOG_EXPORT
💡 階層設計のポイント
- 業務名は部門・システム単位で固定
- 処理種別（Extract / Transform / Load）は全業務共通
- 実行周期（日次／月次／随時）でサブ階層を設ける
🧠 実運用でのトラブル回避Tips（DataSpider編）
| 問題例 | 原因 | 対策 |
|---|---|---|
| ジョブ名が長すぎて保存不可 | DataSpiderの内部制限（128文字） | 命名テンプレートで上限100文字以内に統一 |
| 同名ジョブが上書きされる | フォルダ構成不統一 | 業務フォルダごとに命名プレフィックスを設定 |
| 実行順依存（Extract完了前にLoad開始） | ジョブ制御不足 | JP1連携またはDataSpiderスケジュール連携で制御 |
| バージョン違いで挙動不一致 | 5.x ↔ 6.x間の仕様差 | バージョン管理をGitで運用（後述） |
| 履歴ジョブが肥大化 | 履歴保持ポリシーなし | ローテーション命名＋自動削除タスク導入 |
🧩 補足：命名上限と依存回避
DataSpiderはジョブ名・変数名に長さ制約があるため、
命名時点での文字数制御を標準化ドキュメントに明記することが望ましいです。
🔄 Git・JP1との連携とリリース運用
ETL環境では、命名規約を「運用ルール」としてCI/CDに組み込むと効果が最大化します。
🔹 Git連携（変更履歴管理）
- フォルダ構成をそのままGitリポジトリにマッピング
- 各ジョブをYAMLまたはXML形式でエクスポート
- 命名ルールをPRレビューで自動チェック（Git Hook）
例：リポジトリ構造
/ETL_Repo/
├── Sales/
│ ├── Extract/
│ └── Load/
├── HR/
└── Common/
🔹 JP1連携（実行管理）
- フォルダ階層をジョブネット単位に対応
-
JP1/AJS3で命名規約をトリガー判定条件として利用 - ジョブログ連携：命名規則により自動マッピング可能（
EX_→ Extractログなど）
💡 運用のポイント
-
Gitタグ＝リリース名に統一（例：
REL_20251018） - JP1ジョブ名＝ETLジョブ名を一致させ、トレース容易化
- 自動デプロイ時の命名検証（正規表現で強制）
💬 良い設計・悪い設計の対比
| 観点 | 良い設計例 | 悪い設計例 |
|---|---|---|
| 命名規則 | TR_SALES_CSV_AGGREGATE |
sales_conv_1 |
| フォルダ構成 | /Sales/Extract/Daily |
/ETL2023/backup/old |
| 再利用性 | 共通ロジックは/Common/UT/に配置 |
同一処理を各業務フォルダで重複作成 |
| Git連携 | 各ジョブが個別バージョン管理 | 一括エクスポート後に手動上書き |
| JP1ジョブ制御 | ETL階層＝ジョブネット構造で統一 | 個別トリガー管理で依存関係不明瞭 |
🔍 まとめ
| 効果 | 内容 |
|---|---|
| 保守性向上 | 命名規約・階層化で検索と影響範囲分析が容易 |
| 属人化防止 | Git＋JP1＋共通命名で誰でも追跡可能 |
| クラウド対応 | Azure Data Factory / Fabricへそのまま展開可能 |
| 移行容易性 | フォルダ構成と命名をテンプレート化して他案件へ流用可能 |
✅ 最終チェックポイント
- 命名ルール：
処理種別_対象_目的_周期- フォルダ構成：
業務/処理/周期の3階層- Git・JP1：リリース単位で連携・検証
- 文字数制限・バージョン依存を考慮済み
📚 参考資料
🌐 運営ブログのご紹介
📘 MyWay Going（マイウェイ・ゴーイング）
データ連携基盤・ETL・DB設計を専門とするフリーランスエンジニアのポートフォリオサイトです。
Qiitaでの技術発信を軸に、活動実績まとめ・案件進行で得た学び・キャリア構築ノウハウを掲載しています。
気になる方はぜひご覧ください🙌
▶️ 技術発信のハイライト・活動実績・フリーランスとしての取り組みを整理
👉 MyWay Going｜データエンジニア活動実績とキャリア戦略