1 集計定義書の概要
1.1 定義と目的
1.1.1 再現性の確保
集計定義書は、同じデータ範囲と同じ計算仕様に基づいて、誰がいつ集計しても同一の結果が得られる状態を目指す文書である。特に、集計対象の選び方、粒度、指標の算式、除外条件、欠損値や異常値の扱いが明文化されていることが再現性を左右する。これにより、後日発生する検証依頼や、担当変更・組織変更が起きた場合でも、結論の説明責任を果たしやすくなる。
1.1.2 品質基準（正確性・一貫性・追跡可能性）
品質の評価軸として、まず正確性がある。定義書に含まれる前提がデータモデルや業務ルールと整合していれば、算出値の意味がぶれにくい。次に一貫性は、複数のレポートやダッシュボードで同一指標が同じ式・同じ条件で計算されることを指す。さらに追跡可能性は、集計結果がどのデータソース・どのバージョン・どの処理手順に依存しているかを辿れることを意味する。結果として、問い合わせ対応や原因特定が迅速化する。
1.2 対象となる業務・用途
1.2.1 レポーティング
日次・週次・月次の定例レポートでは、指標の算出方法が変更されると過去比較が成り立たなくなる。そのため、集計定義書は、集計期間、対象外の条件、集計単位を含めて統一し、報告の前提を固定する役割を担う。定義書があることで、数値の増減がデータ変動なのか、計算仕様の変更なのかを切り分けやすくなる。
1.2.2 分析と指標設計
探索的な分析の段階では、指標候補の検討や分母分子の再設計が頻繁に起こる。集計定義書は、採用した仕様を文書として残し、後から同じ分析を再現できるようにする。さらに、指標の意図と計算式が紐づくため、分析の解釈が曖昧になるリスクを抑えられる。
1.2.3 ダッシュボード運用
ダッシュボードは継続運用されるため、仕様変更がユーザー体験に直結する。集計定義書は、表示指標の計算ロジックと更新のタイミングを明確化し、表示差異の問い合わせを減らす。加えて、バージョン切替や後方互換の扱いを定めることで、画面に反映される値の信頼性を維持しやすい。
2 作成の基本要素
2.1 集計対象の特定
2.1.1 対象データソース
集計の入力となるデータソース（例：イベントログ、会計データ、顧客マスタ、在庫データなど）を列挙し、それぞれの用途を明記する。データソース名だけでなく、参照するテーブルやファイル、取得経路、必要に応じて結合キーも示すことで、他者が同じ手順で再構築できる。データ品質を担保するため、参照可能範囲（利用可能な期間、粒度制約、欠損の性質）も合わせて記載すると実務で役立つ。
1.2.1.1 対象期間・更新頻度
集計する期間の定義（開始・終了、時間帯、締め日、カレンダーの種類）と更新頻度（リアルタイム、日次バッチ、週次集計など）を決める。期間指定は、分析目的との整合性が重要であり、例えば「注文日基準」か「確定日基準」かで結果が変わり得る。更新頻度は、データ鮮度と遅延の影響を見積もるための前提となるため、いつ時点のデータで計算するかを明確化する。
2.1.1.1 データの鮮度とタイムラグ
タイムラグは、入力データが遅れて到着したり、訂正が行われたりすることで発生する。定義書には、典型的な遅延時間、遅延がある場合に採用するカットオフ（例：確定済みのみを対象にする、一定時間経過後に確定データとして扱う等）を記載する。これにより、再計算時に値が変動する理由が説明可能になる。
2.2 集計粒度（グレイン）
2.2.1 時間粒度
時間粒度は、集計単位を決める最重要要素の一つである。日次、週次、月次、四半期、あるいは時刻までの粒度などを指定し、集計の境界（タイムゾーン、週の開始曜日、月の扱い）も明確にする。粒度が曖昧なまま進めると、同じ名称の指標でも他部署のレポートで値が一致しない。
2.2.2 地域・組織粒度
地域や組織は階層を持つ場合が多い（国・都道府県・店舗など、部門・チームなど）。定義書ではどの階層を採用するか、集計キーのレベル、境界が変更された場合の扱い（再分類するのか、当時所属で固定するのか）を規定する。組織改編がある現場では、この部分を省くと過去データ比較に歪みが生じやすい。
2.2.3 属性・ユーザー粒度
属性やユーザー粒度では、同一人物・同一アカウントの識別方法（IDの正規化、重複IDの統合）や、匿名化の条件などが関わる。例えば「アクティブユーザー」を定義する場合、ユーザーをカウントする判定条件と判定時点を明記する必要がある。粒度の指定は、個人情報の取り扱い方針とも整合していることが望ましい。
2.3 指標（KPI/メトリクス）の定義
2.3.1 指標の名称と意図
指標名と意図（何を測って意思決定に使うのか）をセットで記載する。名称だけでは計算方法が推測されやすく、解釈の食い違いが起こる。意図を文章で明確にすることで、後の改訂や派生指標の設計時にブレを抑えられる。
2.3.2 分子・分母の設計
比率指標では分子と分母の定義が結果の意味を決定する。分母に含める条件（対象外の除外、母集団の範囲、重複の扱い）と、分子に含めるイベントの条件をそれぞれ示す。さらに、分母がゼロになるケースの扱い（ゼロ除算の回避、NULLの扱い、表示ルール）も規定しておくと実務での例外処理が安定する。
2.3.3 集計関数と単位
合計、平均、中央値、重み付き平均、ユニーク件数など、採用する集計関数を明記する。あわせて単位（通貨、件数、時間、割合の基準、通貨換算が必要な場合のレート）も記載する。単位の混在は誤解につながるため、指標ごとに統制することが重要である。
3 計算ルールとデータ処理
3.1 フィルタ条件と除外条件
3.1.1 レコード選別基準
集計に用いるレコードの選別基準を定義する。具体的には、ステータス（有効・無効）、種別（対象イベントのみ）、金額の符号（返金を控除するのか等）、サブスク状態など、業務上の要件を論理条件として書き起こす。加えて、条件の優先順位がある場合は順序も示すと解釈が揃う。
3.1.2 例外ケースの扱い
例外は「想定外」ではなく「想定して定義する」対象として扱う。例えば、重複登録、部分キャンセル、複数にまたがる注文、暫定データ、テストデータなどが該当する。例外の扱い（除外する、別カテゴリに集計する、フラグで保持して後処理する）を具体化し、判断基準を明記することで運用時の恣意性が減る。
3.2 欠損・重複・異常値
3.2.1 欠損時の方針
欠損には種類がある（データが存在しない、取得漏れ、計算に必要な入力がないなど）。定義書には、欠損が発生した場合に指標値をどう扱うかを決める。例えば、除外するか、ゼロで埋めるか、NULLとして扱うか、補完するかを指標ごとに指定する。補完を行う場合は方法と前提を残し、説明可能性を確保する。
3.2.2 重複の特定と解消
重複は、同一イベントが複数回取り込まれる場合や、ユーザーIDの統合前後で発生する場合がある。重複の特定には、識別子（イベントID、トランザクションID等）や時系列の整合性を使う。解消の方針として、最新を採用、最小値を採用、重複分を控除、あるいはユニークカウントに切り替えるなど、指標の性質に応じた方法を選ぶ必要がある。
3.2.3 異常値の検出と処理
異常値は、誤入力や計測エラー、極端な利用行動によって生じる。検出方法として、範囲チェック（上限下限）、統計的手法（外れ値検出）、ルールベース（不自然な組み合わせ）などがある。処理としては、除外、キャップ（上限で丸める）、別フラグで保持しレポートからは切り離すといった手段が考えられる。処理方針は意思決定への影響を踏まえて決める。
3.3 データ変換と派生項目
3.3.1 正規化・カテゴリ化
生データの粒度が混在している場合、正規化によって整合性を取る。カテゴリ化では、入力値の体系（例：商品カテゴリのコード体系、地域コードの変換表）を基に、集計に適したラベルへ変換する。カテゴリ化が将来変更される可能性があるため、参照テーブルやバージョンを明記すると追跡が容易になる。
3.3.2 タイムスタンプ整形
タイムスタンプ整形は、集計境界の誤りを防ぐために重要である。タイムゾーン変換、フォーマット統一、ミリ秒以下の丸め、欠落時刻の扱いなどを規定する。加えて、複数の時刻属性（作成時・更新時・確定時）がある場合は、どの時刻を集計基準にするかを明記する。
3.3.3 集計キーの設計
集計キーは、どの単位で結果を出すかを決める。時間キーに加えて、地域・組織・属性などのキーを組み合わせる。キー設計では、結合の粒度がぶれると集計重複が増えるため、キーの定義と生成手順を示す。さらに、キーに含まれる値の欠損時の扱いも規定しておくと、後工程の不整合が減る。
4 運用とガバナンス
4.1 バージョン管理
4.1.1 変更履歴の管理
集計定義書の改訂は、指標値の変化や過去比較への影響を伴う。そこで、変更点の要約、理由、影響範囲、適用開始日を変更履歴として残す。特に、計算式や除外条件、母集団定義を変更した場合は、どの指標に波及するかを明示することで影響調査が容易になる。
4.1.2 参照可能な過去定義
再計算や監査の場面では、当時の定義が必要になる。定義書は版ごとに参照できる状態にし、同一の指標名称でも版により計算が異なる可能性を許容する形で管理する。過去に生成された集計結果と、対応する定義書バージョンの紐づけを作っておくと整合性が保たれる。
4.2 役割分担と承認フロー
4.2.1 作成者・レビューア・承認者
作成者は仕様を具体化し、レビューアは論理の欠落や整合性を点検する。承認者は業務要件や品質基準に照らして最終判断を行う。役割を分離することで、単独者の見落としを減らし、説明責任を明確にする。加えて、レビュー観点（計算の正しさ、用語の定義、データ範囲、例外処理）をチェックリスト化すると運用が安定する。
4.2.2 誤りの是正手順
誤りが見つかった場合の手順を事前に定める。発見経路（問い合わせ、テスト不合格、監査指摘など）を記録し、再現手順、影響指標の特定、修正案の作成、再計算の要否を整理する。修正により値が変わる場合は、ユーザーへの告知や過去分の扱い（再公表か、注記のみか）までをルールとして明記すると混乱が少ない。
4.3 検証と品質保証
4.3.1 クロスチェック
クロスチェックでは、独立した観点から同じ結論が得られるかを確認する。例えば、SQLの結果と別ツールの集計、集計値の合計整合（売上が明細合算と一致する等）、レコード数の検証などがある。定義書の論理とデータの実体が整合しているかを確かめる工程として位置づける。
4.3.2 テストデータと再計算
テストデータは、境界条件や例外を含むように設計する。ゼロ除算、欠損、重複、極端値などを含めて期待値が得られるかを確認する。加えて、再計算可能性として、必要なデータが取得できるか、再計算が可能な期間がどこまでかを確認する。再現できない状況がある場合は、定義書側で制約として記載する。
4.3.3 レポート反映ルール
反映のタイミングや優先順位を定める。例えば、定義書の改訂がリリースされた場合に、当日版を差し替えるのか、次回更新で反映するのかを決める。さらに、ダッシュボードや定例レポートに反映する際の互換性（旧定義との併記、遡及集計の有無、注記の書式）を統一することで、ユーザー側の混乱を抑えられる。
5 付録・テンプレート項目
5.1 用語集と略語
定義書内で使用する専門用語や略語の意味をまとめる。表記ゆれがある場合は正規の表記も併記し、読み手が同じ概念として理解できるようにする。用語集は改訂時に更新し、参照性を維持する。
5.2 集計仕様サマリー
主要要素を短く要約して一覧化する。対象データソース、期間定義、粒度、主要指標の算式、除外条件、欠損・異常値処理の概要などを一箇所に集約する。要約は詳細理解の入口として機能し、レビューや引き継ぎの効率を高める。
5.3 参照資料（データ仕様・コード・SQLなど）
参照すべきデータ仕様書、コード、SQL、変換定義（マッピング表）、外部レポートとの対応表などの所在を記載する。リンクやファイル名に加え、更新主体と更新頻度も書ける範囲で添えると、情報の鮮度が保たれる。実装との照合を促す構成にすることで、定義書と運用が乖離しにくい。
5.4 よくある質問（FAQ）と注意事項
FAQには、運用で頻出する疑問や誤解を集める。例として「なぜ値が前回と一致しないのか」「欠損はゼロかNULLか」「同名指標でも版で違うのはなぜか」などを扱う。注意事項では、データ鮮度の制約、例外処理の適用条件、再計算に必要な前提を明記し、実装者や利用者の判断ミスを減らす。