2026年9月8日 第2回 データ整備を前向きに考える会 データを使う側視点の データ整備 しんゆう / データ分析とインテリジェンス 

今日話すこと データアナリストとして使う側にもいる経験から、「こう整 備されていると使いやすい」という感覚がある。今はその感 覚をもとにデータ整備をしている。 そこで、今日はデータ整備の4つの仕事からそれぞれ1つずつ 代表的な事例を取り上げて、よく見る光景・使う人が困るこ と・こうしている・こう考えているの流れでどう整備をして いるかを話す。 

自己紹介 しんゆう @data_analyst_ 「データを使いやすくする人」 たまに「データを分析してインテリジェ ンスを提供する人」 データ分析とインテリジェンス note.com/shinu analytics-and-intelligence.net 

データ整備の4つの仕事 最初に「データ整備」の範囲を確認 抽出 整理 必要なデータを取り出す 使える形に整える 品質管理 記録 基準を決めて監視する メタデータを残す 

1. 抽出 見る人ごとに 必要なものだけを渡す 

よく見る光景 「このダッシュボードにデータがあると聞いたが…」 あらゆるグラフや表が大量に並んでいる 粒度が最小で、各自で集約が必要 「追加してみました」が増えていく たくさんの人が使う前提で作ると、こうなりやすい。 

使う人が困ること 必要なものを探すのに認知負荷がかかる 全員が不要なグラフを取捨選択する手間を負う パネルが多いほど重くなりがち 

こうしている：見る人ごとに分ける 汎用ダッシュボード 経営者向け → 全員がここから探す 売上推移 進捗 担当者向け 担当詳細 KPI 必要なものだけ 経営者には数字と進捗だけ。担当者には担当範囲の詳細デー タ。元データは同じでも出し方を変える。 

こう考えながらやっている そのダッシュボードを見る人にとって何が必要か。これが最 重要かつ唯一の観点 「便利だろう」と追加してもまず使われないのでやめておく 見る人が必要としていないものは、親切ではなくノイズ。作 る前に見る人に聞く 

2. 整理 まずはよく使うものに絞る 

よく見る光景 「様々な種類のデータを1つにまとめたテーブル」 広告・自社サービス・クライアントなど、異なる種類のデー タを集約 結果として数十から、ときには数百カラム 大半はNULLでデータがスカスカ 汎用的に使えるようにと1つのテーブルに全部入れた結果。 

使う人が困ること カラムが多すぎて似た名前のカラムが大量にあり、どれがど れか分からない いくらメタデータを書いても分かりづらくて間違える AIも誤読のリスクが高まる 

こうしている：よく使うものだけに絞る よく使うものだけに絞ると、ほとんど残らない。 あとは個別に見るか、よく使うものを追加していけばいい。 とあるサービスの700カラムも、10カラム程度でほぼ解決し た。 

こう考えながらやっている 増やすのは簡単なので、「作っておけば使うかもしれない」は 本当に使いたい作業の邪魔になる 最初から全部入れておく必要はない 必要になったら足す方が、使う側には親切 

3. 品質管理 勝手に変えない 

よく見る光景 「使う側が知らないところで行われること」 テーブルやカラムの削除・リネーム 更新時間の変更 定義の変更 合計に影響が出るレコードの追加 ある日突然、昨日まで動いていたクエリやダッシュボードが 壊れる。 

使う人が困ること データ基盤側 変更を実施 ✕ 共有なし エラーになって業務が止まる ← まだまし 数字が正しくなくなる エラーにならない変更が一番怖い おかしいと気づいたときには、 すでに報告・意思決定に使った後 ← 一番怖い 

こうしている：事前の共有・確認 何が変わり、影響がどうかを、理由を添えてまず共有する その後、いつ行うかの合意を取る 処理がどう変わるか詳しい話は補足程度でよい 一方的に通達するのではなく、合意を取る。 

こう考えながらやっている この共有がされずに変更が続くと、使う側は常にデータを疑 う必要が生じる データへの信頼がなくなると、誰もデータを使わなくなる 共有と合意は手間だが、信頼を維持するコストと考える 

4. 記録 使う人向けの文言を 別に書く 

よく見る光景 「とあるテーブルのメタデータ」 「sales_daily は orders および order_items を日次でバッチ集計した集計テーブルである。集計粒度は「日付 × 店舗 × 商品カテゴリ」。集計ジョブは毎日 AM 4:00（JST）に前日分を処理し、処理完了後に該当日付のパーティションを置換す る。orders 側の後日修正（キャンセル・返品）は翌日のバッチで再集計されるため、直近7日間の値は確定値ではない。 金額は税抜。通貨は JPY 固定。店舗コードは stores テーブルのマスタに準拠するが、閉店店舗は集計対象外。パーティシ ョンキーは sales_date。クラスタリングキーは store_code。データ保持期間は3年。 技術者向けの説明としては正しい。 

使う人が困ること 使うために必要な最低限のことを探すのに手間取る 技術的な詳細を聞いても使うときにはあまり役立たない 読み込まないと分からないメタデータは認知負荷になる 使うのに必要なことがまずぱっと分かればいい 

こうしている：使う人向けの文言を別に書く 使う人向け（追加） 日別・店舗別・カテゴリ別の売上（税 抜）。 直近1週間は数字が動く。 store_code で絞ると速い。 技術者向け（残す） sales_daily は orders および order_items を日次でバッチ集計し た集計テーブルである。集計粒度は「日付 × 店舗 × 商品カテゴ リ」。集計ジョブは毎日 AM 4:00（JST）に前日分を処理し、処理 完了後に該当日付のパーティションを置換する。orders 側の後日 修正（キャンセル・返品）は翌日のバッチで再集計されるため、 直近7日間の値は確定値ではない。金額は税抜。通貨は JPY 固 定。店舗コードは stores テーブルのマスタに準拠するが、閉店店 舗は集計対象外。パーティションキーは sales_date。クラスタリ ングキーは store_code。データ保持期間は3年。 

こう考えながらやっている 書けばいいというわけではなく、読みやすいことが重要 どのような書き方が読みやすいかは人と目的による なので大きく分けて使う人向けと作る人向けの2つが必要 

データ整備で最も重要な考え データの唯一の存在意義は 意思決定のための分析に寄与すること。 そのために、使う人の認知負荷を下げて 分析をしやすくすること。 一番いいのは当人にちゃんと聞く。