誰が何を担うか：データ関連ロールと責任の空白

Stage 1 — 第2章 | データマネジメント入門 推定学習時間：35〜45分 | 難易度：★★☆☆☆

この章で学ぶこと

前章では、さくら商事で「売上」の数字が揃わない症状を見ました。 そのとき現場でよく起きるのが、「誰かが直せばいい」では終わらない ということです。

データエンジニア（Data Engineer）だけが直す問題でも、経理だけが決める問題でもありません。 役割ごとに担うべき責任 が違うからです。

この章では、データマネジメントに関わる主要ロールを整理し、さくら商事で 責任の空白地帯 がどこに生まれるかを見ます。

この章を終えると、こんなことができるようになります：

• データエンジニア、アナリティクスエンジニア（Analytics Engineer）、アナリスト、データスチュワード（Data Steward）などの 役割の違い を説明できる
• 「この問題、誰に聞けばいいか」をロールから判断できる
• 指標やマスターデータ（Master Data）に オーナー（Owner） がいないと何が起きるか説明できる
• 小さな組織で兼任が起きるとき、最低限決めておくべき責任を挙げられる

1. 前章の続き：責任者がいない会議

さくら商事の経営会議で「6 月売上」の不一致が話題になったあと、次のやり取りが Slack に残りました。

#data-help（社内チャンネル）

経理・佐藤:「Looker の売上、経理数字と 500 万円差があります。SQL 直してください。」

基盤・鈴木:「どの定義が正ですか？ 返品反映前後どちらを SSOT（Single Source of Truth）にしますか？」

マーケ・田中:「うちの CV ベース売上は正しいです。広告効果測定用です。」

経営・木村:「じゃあ“公式売上”を一つ決めて。誰の仕事？」

…既読スルーが 3 人。

ここで足りないのは、SQL の速度でも BI の見た目でもありません。 「公式売上を決め、維持し、変更を管理する責任者」 です。

2. データマネジメントに関わる主要ロール

肩書きは会社ごとにバラバラです。 だから 機能（何を担うか） で覚えると、現場で迷いにくくなります。

2.1 ロールは「部署」ではなく「責任の種類」

さくら商事では、鈴木さん一人が DE + AE + 基盤運用 を兼任しています。 田中さんは マーケ担当 + ダッシュボード作成 です。

兼任自体は悪ではありません。 問題は、どの帽子を被っている状態で判断しているか が見えないことです。

現場メモ

「SQL 書いて」は DE/AE の仕事に見えて、実は 定義未決のまま実装を求めている ケースが多いです。 さくら商事の佐藤さんの「SQL 直して」も、本来は先に どの売上が公式か の判断が必要でした。

3. さくら商事の「6 月売上」をロールで分解する

前章の 3 つの数字を、ロールの観点で見直します。

ここで必要なのは、次の 3 点を 明示的に割り当てる ことです。

1. ビジネスオーナー — 「公式売上はこれ」と決める人（例: 経営企画 or 経理責任者）
2. スチュワード — 定義を文章化し、変更を記録する人（例: 基盤 + 経理の兼任でも可）
3. 提供責任 — SSOT として配布する表や指標を運用する人（例: AE/DE + 基盤）

【さくら商事・公式売上（仮の整理案）】
          指標名: 月次公式売上（経営会議用）
          定義: status = 'completed'、税込、返品反映後、テスト注文除外
          期間: order_date ベース
          SSOT: mart_finance_monthly_sales（DWH 上のテーブル名・仮）
          ビジネスオーナー: 経理部長
          スチュワード: 鈴木（基盤）+ 佐藤（経理）
          

このメモが 1 枚あるだけで、Slack の「誰の仕事？」はかなり減ります。

4. 責任の空白地帯：よくある 4 パターン

4.1 「みんなのデータ」問題

症状: 顧客マスタ、商品マスタ、売上定義が「どこかにあるはず」で、更新責任が不明。

さくら商事では、商品カテゴリ名が EC 管理画面 / 分析用 CSV / 経理コード で微妙に違い、マーケの田中さんが手作業で置換していました。

埋め方: マスターデータごとに オーナー + スチュワード を 1 行で決める。

4.2 「作った人がいなくなった」問題

症状: ダッシュボードや SQL の作者が退職・異動し、定義が説明できない。

山田さんが引き継いだ Looker ダッシュボードは、作者のメモがなく、フィルタ条件の意味が分かりませんでした。

埋め方: 指標・マート単位で オーナー、更新頻度、定義リンク を残す（後の Stage でメタデータとして詳述）。

4.3 「ツールは入れた」問題

症状: DWH や BI は導入したが、誰が何を標準として使うか決まっていない。

さくら商事は BigQuery 上に DWH がありました。 しかしマーケは Looker、経理は Excel、CS は別 SaaS のエクスポートを見ていました。

埋め方: 「会議で使う数字はここ」という 利用シーンごとの SSOT を先に 1 つ決める。

4.4 「現場判断でなんとか」問題

症状: 品質や権限の判断を、その都度アナリスト個人に委ねている。

返品データ 2 日分欠損があったとき、山田さんは 自分の判断で前日値を補完 し、ダッシュボードを更新しました。 後日、経営が「なぜ急に上がった？」と質問し、説明不能になりました。

埋め方: 「疑義が出たら誰に、いつ、何を報告するか」を インシデントの型 として決める（Stage 4 で詳述）。

5. 小さな組織での現実的な割り方

さくら商事のように データ基盤 1〜2 名 の組織では、全ロールを専任配置できません。 その場合でも、次の 最低限 3 点 は分けて考えます。

兼任のコツ:
          「今日は SQL を書く日（AE/DE）」と
          「今日は定義を決める日（スチュワード/オーナー）」を
          同じ会議で混ぜない。
          

現場メモ

定義会議に SQL の細かいチューニング話が入ると、2 時間経っても「公式売上」が決まりません。 さくら商事では、木村さんが「今日は定義だけ」と会議タイトルを変えたら、初めて 1 時間で合意できました。

6. 経営・現場・基盤の接点

データマネジメントは 経営の意思決定品質 と直結します。

CDO（Chief Data Officer）やデータ統括がいなくても、経営が「公式数字のオーナーを指名する」 だけで前進します。

体系コラム：カリキュラム上の位置づけ

コラム：さくら商事メモ — 公式売上オーナー指名の 1 時間

2026 年 6 月、木村さんは「定義会議」と題した 1 時間だけの枠を設けました。議題は SQL の最適化ではなく、公式売上のビジネスオーナー だけです。

佐藤さん（経理）は会計計上の定義を、田中さん（マーケ）は CV ベース売上との違いを、鈴木さん（基盤）は SSOT 候補テーブル名を提示しました。争点は「返品をいつ差し引くか」で、技術ではなく 経理ポリシー の話でした。

結果、ビジネスオーナーは経理部長、スチュワードは佐藤 + 鈴木、SSOT は mart_finance_monthly_sales（仮）と 1 枚のメモに落ちました。Slack の「SQL 直して」は「定義メモを見てから実装」に変わりました。

この 1 時間で決めたのは完璧な定義ではありません。しかし 誰に聞けばいいか が分かった時点で、Stage 1 の半分は終わっています。

まとめ

この章のキーメッセージ：

数字が揃わないとき、最初に疑うのは SQL の書き方だけではありません。 誰が定義を決め、誰が維持し、誰が公式として提供するか が決まっていない可能性があります。 さくら商事の次の一歩は、ツールではなく 「公式売上」のオーナー指名 です。

次に読む

• 前章: 信頼できるデータがないと起きること
• 次章: s1-p3-lifecycle-overview — データのライフサイクル（生成から廃棄まで）
• 関連: 指標定義: 売上、CVR、継続率をそろえる

確認問題

問題 1

さくら商事で「6 月公式売上」を SSOT として整備するとき、最初に指名すべき役割 として最も適切なのはどれですか。

A. BigQuery のクエリを最速に書けるデータエンジニア
B. ビジネス上「この定義で正しい」と認めるデータオーナー
C. Looker のグラフデザインに詳しいアナリスト
D. SaaS 連携ツールのベンダーサポート

正解: B

解説: SSOT は 技術配置 ではなく ビジネス合意 が先です。DE/AE は合意された定義を実装・配布しますが、「公式売上」の中身を決めるのはオーナーの責務です。

問題 2

商品カテゴリ名が EC / CSV / 経理コードでバラバラになり、マーケ担当が手作業で置換している。 この状態を 最も適切に説明 しているのはどれですか。

A. アナリストの Excel スキル不足
B. マスターデータのオーナーとスチュワードが決まっていない
C. DWH のストレージ容量不足
D. 統計検定の知識不足

正解: B

解説: カテゴリの揺れは マスターデータ管理 の問題です。誰が正を更新し、誰が変更を通知するかが決まっていないと、現場の手作業が恒久化します。

問題 3

返品データ欠損時、新人アナリストが独断で前日値を補完し、経営に説明できなくなった。 この事例で 不足していたもの として最も本質的なのはどれですか。

A. より高度な欠損値補完アルゴリズム
B. 品質疑義の報告先と公開前の判断ルール
C. ダッシュボードの色使い
D. 新しい BI ツールの導入

正解: B

解説: 欠損への対処は個人判断に委ねず、止める・報告する・オーナー判断を仰ぐ という運用が必要です。これはロールとガバナンスの設計問題です。

用語メモ（この章）