BEAM✲とは？『アジャイルデータモデリング』の7W・モデルストーミング・JEDUFを手順で解説

BEAM✲（Business Event Analysis & Modeling）は、分析したい業務の出来事を7つの質問（7W）で表に書き起こし、業務側の担当者と一緒にスタースキーマの要件を固めるデータモデリングの手法です。ローレンス・コル（Lawrence Corr）とジム・スタグニット（Jim Stagnitto）の『Agile Data Warehouse Design』（2011年）で提唱され、2024年12月に邦訳『アジャイルデータモデリング』が講談社から出ました。この記事では、例データの聞き方、モデルストーミングの4手順、列に付ける短縮コード、JEDUFの考え方を、DuckDB 1.5.6で実行したSQLとあわせて説明します。なお、バッチとストリームを同じコードで書く分散処理基盤は同名の別物で、そちらはApache Beamの解説で扱っています。

まとめ：BEAM✲で押さえる要点

• 目的：BIやレポートに必要なデータ要件を、業務側の担当者と一緒に具体例で集める。成果物はデータウェアハウスに載せるスタースキーマ（名前の✲はスターの意味）。
• 7W：Who・What・When・Where・How many・Why・How。How many が数値（ファクト）、残りが分析軸（ディメンション）になる。
• イベントの3分類：離散型・反復型・発展型。順にトランザクション・定期スナップショット・累積スナップショットのファクトテーブルに対応する。
• 進め方：ビジネスイベントのモデリング→ディメンションのモデリング→イベントマトリックスへの追加→バックログへの追加。
• 短縮コード：HV・CV・SA・GDなどの2文字コードを列に足すと、例データの表がそのまま技術仕様になる。
• JEDUFとJIT：初期のイテレーションでは全体像を必要十分なだけ設計し（JEDUF）、細部は実装の直前に詰める（JIT）。

以下、手法の位置づけと7Wから順に、実際の設計手順、向かない場面までを見ていきます。

BEAM✲の定義と『アジャイルデータモデリング』の位置づけ

BEAM✲は「Business Event Analysis & Modeling」の頭文字で、末尾の✲（six point open centre asterisk）は、成果物のスタースキーマと、中心のイベントの周りに7Wを配置するディメンショナルな位置関係を表しています。

土台はラルフ・キンボールのディメンショナルモデリングです。Kimball Group はFour-Step Dimensional Design Processで設計の判断を「ビジネスプロセスの選択」「粒度の宣言」「ディメンションの特定」「ファクトの特定」の4ステップにまとめ、その答えは業務側との協働セッションで決めると書いています。BEAM✲はこの協働セッションの進め方を具体化したもので、キンボール流を置き換える手法ではありません。

原著『Agile Data Warehouse Design』と邦訳の書誌

邦訳480ページの章立てと読む順番

講談社サイエンティフィクの書誌にある目次によると（発行は2024年12月24日）、第1部「モデルストーミング」が第1章〜第5章、第2部「ディメンショナルデザインパターン」が第6章〜第9章で、第2部は7Wごとに章が分かれています。付録Bが「BEAM✲記法とショートコード」で、巻末に日本語版だけの事例集が付きます。事例はランサーズ、エイベックス、クラシコム、商船三井、ビズリーチ、NE、北陸大学、東京大学、リクルート、福岡地所、住友化学、風音屋の12件です。

読む順番は、第1部を先に通読し、第2部は困った場面で引くのが効率的です。Holisticsの書評も、最初の5章は2回に分ければ読み切れる分量で、後半のデザインパターンは参照用に回してよいと評しています。実装を担当するなら、スキーマ設計の第5章と、ファクトテーブルの種類と粒度を扱う第8章を先に読みます。正誤表は書誌ページの「ダウンロード・リンク」にあります。

7Wの質問とモデル上の行き先

BEAM✲の中心は7Wです。各質問への答えがそのまま列になり、どの列がファクトでどの列がディメンションになるかが質問の段階で決まります。著者が公開しているBEAM✲ Canvasの日本語版には、質問ごとに聞く内容が並んでいます。

質問の順番にも意味があります。最初に「誰が何をするか」を聞いて「顧客は製品を注文する」のような主語・動詞・目的語の文を作り、次の「いつ」の質問で、そのイベントが一瞬で終わるのか、定期的に起きるのか、時間をかけて進むのかを見極めます。ファクトテーブルの型はここで決まります。

7Wと5W1H・5W2Hの目的と回答形式の違い

見た目は5W1Hに「How many」を足しただけですが、役割が違います。5W1Hは文章や報告に抜けがないかを確かめる観点で、答えは文になります。7Wは答えを表の列にするための質問で、How many だけが集計できる数値として扱われます。Canvasの英語版では How many の問いを「How many/much is involved? How long does it take?」としており、5W2Hの「How much」も含めて数量・金額・所要時間をまとめてここで聞きます。

3つのイベントタイプとファクトテーブルの対応

BEAM✲は「いつ」の答え方でビジネスイベントを3つに分けます。公式のBEAM✲ Reference Card（RC 2.0）は、イベントのコードと物理テーブルのコードを次のように対応させています。

発展型の累積スナップショットについて、Kimball Group は「開始点・標準的な中間ステップ・終了点がはっきりしたパイプラインやワークフローの処理」を対象とし、節目ごとに日付の外部キーを持たせ、処理が進むたびに同じ行を更新すると説明しています。ロード方式が違うので、イベントタイプの判定を誤るとETLを作り直すことになります。

業務システムの記録形式と分析用イベントタイプの区別

業務システムに残っている記録の形と、分析に必要なイベントタイプが一致するとは限りません。邦訳を紹介したスライド「30分でわかる『アジャイルデータモデリング』」（Speaker Deck）は、発表者自身の応用例として、有料会員の決済履歴（離散型）にアップグレード時の差額決済が混ざる場合に、月ごとの「会員ステータス」（反復型）に持ち替えたほうが分析が簡単になると説明しています。広告の閲覧ログとクリックログ（どちらも離散型）を毎回結合する代わりに、「配信→クリック」と状態が進む発展型として1行にまとめる例もあります。元データの形に引きずられず、分析で欲しい単位を先に決めてください。

モデルストーミングの4手順

モデルストーミングは、データモデリングとブレインストーミングを合わせた造語で、業務側の担当者とモデラーが同じ場で要件を集めるワークショップを指します。原著の公開サンプル（PDF）は、具体例を書き込むBEAM✲テーブルのほかに、イベントマトリックス、階層チャート（hierarchy chart）、タイムライン（timeline）、短縮コードを書き足したスタースキーマを道具として挙げています。前述のスライドは、進め方を次の4手順に整理しています。

1. ビジネスイベントのモデリング：7Wで1つのイベントをBEAM✲テーブルに書き起こす。
2. ディメンションのモデリング：テーブルに出てきた顧客や製品の粒度・列・階層・履歴の要否を聞く。
3. イベントマトリックスへの追加：イベントとディメンションの対応を行列にまとめる。
4. バックログへの追加：重要度を付けて、ディメンション→イベント→レポートの順に実装タスクへ落とす。

手順1：例データの6テーマによるBEAM✲テーブルの記入

BEAM✲テーブルの特徴は、列の定義より先に具体例のデータを書くことです。Reference Card は、聞き出す例を Typical・Different・Missing・Repeat・Group・Range の6テーマに分けています。注文イベントに当てはめると次のようになります（値は架空の例です）。

ばらつきの大きい Range と Missing から要件が出ます。「10年前の注文まで遡るか」「廃番品の名前はどう出すか」「返品はマイナス数量で記録するか」で履歴の保持期間と欠損の扱いが決まり、Repeat の行が許されるかを聞くと、注文番号なしではこの行を区別できないことが判明して粒度が定まります。Group は、セット商品を1行で持つか明細に割るかの判断材料です。

手順2：ディメンションの階層と履歴（HV・CV）の確認

テーブルに出てきた「製品」「顧客」ごとに、カテゴリ→サブカテゴリ→製品のような階層と、過去の値を分析で使うかを聞きます。販売当時のカテゴリで集計したいなら HV（Historic Value・SCDタイプ2）、常に現在のカテゴリで見るなら CV（Current Value・SCDタイプ1）です。Reference Card は前者を「as was」、後者を「as is」の集計を支えるものと説明しています。この確認を後回しにすると、ディメンションを作り直して過去分を再ロードする手戻りになります。

手順3：イベントマトリックスによる共通ディメンションの洗い出し

イベントマトリックスは、縦にビジネスイベント、横にディメンションを並べ、どのイベントがどのディメンションを使うかに印を付けた行列です。複数のイベントで使われる製品や顧客は共通（コンフォームド）ディメンションとして先に作る価値があり、1つのイベントでしか使わないものは後回しにできる、という優先順位がこの表から読み取れます。Kimball Group のEnterprise Data Warehouse Bus Matrixも、行がビジネスプロセス、列がディメンションの同じ形で、「実装は行列の1行ずつ」と説明しています。

手順4：バックログへの実装範囲と完了条件の登録

前述のスライドでは、「製品」「顧客」ディメンション、それらを結合した「顧客の注文」イベント、そのイベントを集計したレポートの順に着手する例が示されています。各タスクには、対象イベント、ファクト1行の粒度、必要なディメンション、業務側が期待する集計結果を書いておきます。「月別・チャネル種別の数量と金額が、業務側の手元の集計と一致すること」を完了条件にすれば、後述のSQLの出力をそのまま受け入れ確認に使えます。

著者が公開している無料テンプレート4点

道具は自作しなくて済みます。modelstorming.comのテンプレートページで、次の4点が公開されています。

• BEAM✲ Canvas：7Wの問いを1枚にしたPDF。英語版のほか日本語版とオランダ語版があり、ポスター印刷やMiro・Muralの背景に使える。ライセンスは CC BY-SA 4.0。
• BEAM✲ Table（Excel）：短縮コードからSQL DDLとテーブル図を生成する。OracleとSQL ServerのDDL例が同梱。
• Event Matrix（Excel）：複数のイベントを要約し、共通する名詞を見つける。
• BEAM✲ Reference Card：記法と短縮コードの早見表。スマートフォン用とA4・USレター印刷用がある。

初回のワークショップは Canvas と BEAM✲ Table の2点で足ります。

短縮コードで例データの表を技術仕様にする方法

短縮コードは、データの性質を表す主に2文字の略号で、BEAM✲テーブルの列名の下に書き足します。原著のサンプルは、これによって履歴の扱いや集計規則を記録でき、スタースキーマの生成にも使えると説明しています。Reference Card から実装に直結するものを抜き出すと次のとおりです。

原著のサンプルは、技術的な関心が薄い参加者の前では短縮コードを隠すか無視できると書いています。ワークショップの場では書かず、終了後にモデラーが足す運用で十分です。dbtで実装するなら、ND（重複不可）は unique、FK は relationships のデータテストに写せます。

BEAM✲テーブルからスタースキーマへのSQL実行例

次のSQLは1本のスクリプトとして DuckDB 1.5.6 で実行し、結果を確かめたものです。データは架空で、列名は英語にしています。

離散型：注文明細のトランザクションファクト

How many の数量と金額がファクト、Who・What・When・Where がディメンションになります。製品は次節で使うので HV 用の有効期間を持たせています。

-- ディメンション
CREATE TABLE dim_customer (customer_key INTEGER PRIMARY KEY, customer_code VARCHAR, customer_name VARCHAR, segment VARCHAR);
CREATE TABLE dim_channel  (channel_key  INTEGER PRIMARY KEY, channel_name VARCHAR, channel_type VARCHAR);
CREATE TABLE dim_date     (date_key     INTEGER PRIMARY KEY, full_date DATE, year_month VARCHAR);
CREATE TABLE dim_product (
  product_key INTEGER PRIMARY KEY, product_code VARCHAR, product_name VARCHAR,
  category VARCHAR, valid_from DATE, valid_to DATE, is_current BOOLEAN
);
-- トランザクションファクト：1行 = 注文の1明細
CREATE TABLE fact_order (
  order_no VARCHAR,                 -- DD（退化ディメンション）
  date_key INTEGER, customer_key INTEGER, product_key INTEGER, channel_key INTEGER,
  quantity INTEGER, amount INTEGER  -- FA（完全加算）
);
INSERT INTO dim_customer VALUES (1,'C001','一郎','個人'),(2,'C002','二郎','個人'),(3,'C003','三商事','法人');
INSERT INTO dim_channel  VALUES (1,'表参道店','実店舗'),(2,'自社EC','EC'),(3,'外部モール','EC');
INSERT INTO dim_date     VALUES (20260901,DATE '2026-09-01','2026-09'),(20260915,DATE '2026-09-15','2026-09'),(20261001,DATE '2026-10-01','2026-10');
-- P10 のカテゴリが10月に PC から法人向けPC へ変わった想定（HV）
INSERT INTO dim_product VALUES
 (1,'P10','ノートPC','PC',       DATE '2020-01-01',DATE '2026-09-30',false),
 (2,'P10','ノートPC','法人向けPC',DATE '2026-10-01',DATE '9999-12-31',true),
 (3,'P20','モニター','周辺機器',  DATE '2020-01-01',DATE '9999-12-31',true);
INSERT INTO fact_order VALUES
 ('O-1',20260901,1,1,1,1,180000),
 ('O-2',20260901,2,3,2,2, 60000),
 ('O-3',20260915,3,1,3,5,850000),
 ('O-4',20261001,1,2,2,1,170000);

SELECT d.year_month, c.channel_type, SUM(f.quantity) AS qty, SUM(f.amount) AS amount
FROM fact_order f
JOIN dim_date d    ON f.date_key = d.date_key
JOIN dim_channel c ON f.channel_key = c.channel_key
GROUP BY ALL ORDER BY 1, 2;

HVとCV：当時のカテゴリと現在のカテゴリの集計差

この例ではSCDタイプ2の履歴を保持し、当時の製品行と現在行を結合して両方のカテゴリを表示します。手順2のCV（SCDタイプ1の上書き）とは異なる実装です。

SELECT p.category AS category_as_was, cur.category AS category_as_is, SUM(f.amount) AS amount
FROM fact_order f
JOIN dim_product p   ON f.product_key = p.product_key
JOIN dim_product cur ON p.product_code = cur.product_code AND cur.is_current
GROUP BY ALL ORDER BY 1;

当時の値なら PC が103万円、現在の値なら法人向けPCが120万円です。どちらの数字を見たいかは手順2で業務側に決めてもらう事項で、技術側が推測で決めると月次の数字が合わなくなります。

反復型：在庫の定期スナップショットと準加算の落とし穴

この例の在庫数量は、同じ単位で数えた製品を同一日時点で合計できます。ただし、日付をまたいで足しても、その時点の在庫数量にはなりません。短縮コードでは on_hand_qty が SA、日付が NA です。

-- 定期スナップショット：1行 = 1日×1製品の在庫
CREATE TABLE fact_inventory_daily (
  snapshot_date DATE, product_code VARCHAR,
  on_hand_qty INTEGER               -- SA（日付が NA ディメンション）
);
INSERT INTO fact_inventory_daily VALUES
 (DATE '2026-09-28','P10',40),(DATE '2026-09-29','P10',38),(DATE '2026-09-30','P10',35),
 (DATE '2026-09-28','P20',20),(DATE '2026-09-29','P20',20),(DATE '2026-09-30','P20',18);

SELECT SUM(on_hand_qty) AS wrong_sum_over_days,
       SUM(on_hand_qty) FILTER (WHERE snapshot_date = DATE '2026-09-30') AS month_end_on_hand,
       ROUND(SUM(on_hand_qty) * 1.0 / COUNT(DISTINCT snapshot_date), 1) AS avg_daily_on_hand
FROM fact_inventory_daily;

結果は wrong_sum_over_days が171、month_end_on_hand が53、avg_daily_on_hand が57.0でした。日付をまたいだ171は、特定時点の在庫数ではありません。この例では月末時点の在庫数が53、記録した9月28〜30日の3日間の日次平均が57です。月全体の平均を求めるには、対象期間の日次データをそろえます。BIツールの既定の集計が SUM のままだと、この171が画面に出ます。

発展型：注文処理の累積スナップショット

節目の日付を1行に持ち、処理が進むたびに同じ行を更新します。例を短くするため日付を直接持たせていますが、実務では節目ごとに日付ディメンションへの外部キーを置きます。

-- 累積スナップショット：1行 = 1注文の処理全体
CREATE TABLE fact_order_fulfillment (order_no VARCHAR, ordered_at DATE, shipped_at DATE, delivered_at DATE);
INSERT INTO fact_order_fulfillment VALUES
 ('O-1',DATE '2026-09-01',DATE '2026-09-02',DATE '2026-09-04'),
 ('O-2',DATE '2026-09-01',DATE '2026-09-03',NULL),
 ('O-3',DATE '2026-09-15',NULL,NULL);
-- 配達が起きたら同じ行を更新する
UPDATE fact_order_fulfillment SET delivered_at = DATE '2026-09-06' WHERE order_no = 'O-2';
SELECT order_no, shipped_at - ordered_at AS days_to_ship, delivered_at - shipped_at AS days_to_deliver
FROM fact_order_fulfillment ORDER BY 1;

UPDATE 前の O-2 は days_to_deliver が NULL で、UPDATE 後は3になりました。追記だけのロードでは作れないので、ETLの設計が離散型と変わります。dbtで組む場合は、こうした完成形のテーブルをdbtのmarts層に置くのが一般的な分担です。

JEDUFとJITによる事前設計と詳細設計の分担

JEDUF（Just Enough Design Upfront）は、初期のイテレーションで全体像を必要十分な範囲だけ設計する考え方です。原著のサンプル章は、これを各イテレーション内で直近の実装対象を詳細に詰めるJIT（Just-In-Time）設計と組み合わせ、BDUF（Big Design Up Front）＝ウォーターフォール型のDWH構築で全体モデルを先に固め切る進め方を避けると説明しています。同じ箇所で、1イテレーションで届けられる最小の単位を、スタースキーマ1つとそのETL、BIの設定の組とし、「最小の設計量はスター1つ」と書いています。

JEDUFは「設計しない」ことではありません。テーブル定義まで描き切らない代わりに、イベントマトリックスで「どのイベントがどのディメンションを共有するか」の地図だけは早い段階で作ります。この地図なしにイベント単位で作り進めると、顧客や製品のディメンションがチームごとに別定義になり、後で数字が合わなくなります。先に決めるのは共通ディメンションの定義と粒度、後回しにしてよいのは個々のファクトの細部、と線を引いてください。

データモデリング手法の比較：ER図・Kimball・Data Vault・イベントストーミング

「データモデリング」と呼ばれる手法は目的が異なります。混同しやすいものを並べます。

データベースの正規化とER図は役割が異なります。正規化はデータの冗長性と更新時の不整合を減らすための設計手順で、ER図はエンティティ・属性・関連を表す図です。正規化によってテーブルを分割すると、分析時に必要な結合が増える場合があります。スタースキーマはあえてディメンションを非正規化し、ファクトとディメンションの2種類のテーブルだけで業務側にも読める形にします。Data Vaultは業務キーのHub、キー間の関係のLink、変更行を追記するSatelliteに分ける正規化寄りのモデルで、業務側が直接読む形ではありません。名前が似たEventStormingは複雑な業務領域を協働で探索するワークショップで、成果物は分析用のテーブルではありません。「データ分析用の表を業務側と決めたい」ならBEAM✲、「システムの境界や振る舞いを決めたい」ならイベントストーミングです。

BEAM✲が向く組織・向かない場面

向いているのは、分析の要件を持っている人（営業企画や経営管理）とデータ基盤を作る人が別のチームで、要件の受け渡しで手戻りが起きている組織です。BEAM✲テーブルは業務側の担当者が自分で例を書き込めるので、「作ってみたら欲しい集計と違った」という食い違いを実装前に潰せます。基盤の設計から外部と進めるなら、データ分析基盤構築・MLOps構築支援をご検討ください。その場合は発注側と支援側でBEAM✲テーブルを共有し、粒度や集計条件を合意します。

次の場面では、持ち込まないと判断してかまいません。

• 業務側の担当者が時間を割けない：モデラーが1人で7Wを埋めると、従来の要件定義書を表形式で書いているのと変わりません。
• 分析ではなく業務システムを作る：受注や在庫の更新処理には、正規化したモデルとアプリケーションの要件定義が先です。
• 不足データを収集・補完する手段がない：店舗コードが未記録で補完もできなければ、店舗別分析は実装できません。実装の見積もりでは、ETLの段階で何が取れるかを並行して確認します。
• 明細を1つの大きな表で配るだけで足りる：分析者が数人で1つの業務プロセスしか見ないなら、スタースキーマまで設計する手間に見合いません。

よくある質問

BEAM✲は何の略ですか？Apache Beamとは関係がありますか？

Business Event Analysis & Modeling の略で、データウェアハウスの要件収集とモデリングの手法です。Apache Beamはバッチ処理とストリーム処理を同じコードで書くためのオープンソースの分散処理フレームワークで、関係はありません。検索ではどちらも「beam」で出てくるので、モデリングの情報を探すときは「BEAM✲」「モデルストーミング」「7W」を一緒に入れると絞り込めます。

JEDUFとは何の略ですか？

Just Enough Design Upfront の略で、「事前の設計は必要十分な量だけにする」という意味です。全体を先に設計し切る BDUF（Big Design Up Front）を避けるための考え方として、原著で説明されています。BEAM✲では、初期のイテレーションで共通ディメンションの地図（イベントマトリックス）を作り、個々のイベントの詳細は各イテレーションでJIT（Just-In-Time）に設計します。

7Wと5W1Hは何が違いますか？

7Wは5W1Hに How many を加えたものですが、目的が違います。5W1Hは情報の抜け漏れを確かめる観点で、7Wは答えをテーブルの列にするための質問です。How many の答えが集計する数値（ファクト）になり、残りの6つの答えがディメンションまたは退化ディメンションになります。

『アジャイルデータモデリング』はどんな本ですか？

Lawrence Corr と Jim Stagnitto の『Agile Data Warehouse Design』の邦訳で、株式会社風音屋が監訳し、2024年12月に講談社から刊行されました（480ページ・税込4,950円）。第1部がモデルストーミング、第2部が7Wごとのデザインパターンで、国内12件の事例集が加わっています。スタースキーマに不慣れなら、ファクトとディメンション、粒度の基本を押さえてから読むと理解が早くなります。

データモデリングの手法にはほかにどんなものがありますか？

業務システム向けには正規化を軸にしたリレーショナルなモデリング（図示にはER図を使用）、分析向けにはキンボールのディメンショナルモデリング、ソースの変更履歴を細かく残す中間層向けにはData Vaultがよく使われます。BEAM✲はディメンショナルモデリングを土台に、業務側と分析要件を整理する進め方です。

関連記事

• DWH（データウェアハウス）とは？仕組みとDBとの違い、主要製品の料金比較【2026年11月】
• データマートとは？DWHとの違い・種類・設計単位から作る判断まで解説
• dbtのmarts層とは？3層の分け方とMetricFlowで指標を定義する手順【dbt 1.12対応】
• データベース正規化とは？第1〜第3正規形の手順と非正規化の判断を解説
• ER図とは？書き方・エンティティやリレーション・カーディナリティを実装目線で解説