LWP | データアーキテクチャの基本形

LWP TECHNICAL ARTICLE | 225

記事要約

データアーキテクチャを理解するには、まず、何がどこにあり、何と何が関係しているかを見ます。そのうえで、どのような操作ができ、機能を通してデータがどう変わり、どのような業務目的に結び付くかを考えます。

本記事では、データモデル、データスキーム、ビジネスロジックの三層を使って説明します。データモデルの中には、データストラクチャー、データオペレーション、データフローという三つの観点があります。データストラクチャーは、データとその静的な関連を表す全体概要図です。データフローは、機能とデータの入出力を表すデータフローダイアグラム（DFD）です。同じデータを扱っていても、両者で説明することは違います。

本記事の対象とゴール

CSV、Excel、Power Query、VBAなどを使って業務データを扱い、自分の仕組みを説明・設計したい人を対象とします。読み終えたときのゴールは、データの所在と関連、変換機能と入出力、処理のまとまり、業務上の目的を、それぞれ適切な階層で説明できることです。

ここで示す三層と用語の範囲は、本記事の説明のための整理です。具体例には、売上CSVと商品マスターから月次売上レポートを作る仕組みを使います。

目次

• 第1章　データアーキテクチャの全体像

• 1.1　三層の利用関係をつかむ

• 1.2　月次売上レポートを共通の例にする

• 第2章　データモデル

• 2.1　データストラクチャー――所在と静的な関連を表す

• 2.2　データオペレーション――操作と要素技術を捉える

• 2.3　データフロー――機能と入出力をDFDで表す

• 第3章　データスキーム

• 3.1　入力・目的・出力で処理をまとめる

• 3.2　利用できる条件まで含めて定義する

• 第4章　ビジネスロジック

• 4.1　業務目的と判断に従ってスキームを使う

• 4.2　月次売上の結果を確かめる

• 4.3　同じ仕組みを三層で読み直す

第1章　データアーキテクチャの全体像

1.1　三層の利用関係をつかむ

データアーキテクチャは、データを扱う基礎から業務目的までをつなぐ全体構造です。本記事では、その中にデータモデル、データスキーム、ビジネスロジックを置きます。

データモデルは、データの所在と関連、データに対する操作、機能に伴うデータの流れを表す基礎です。データスキームは、そのモデルを利用して組み立てる「意味のある一連のデータ処理」です。ビジネスロジックは、複数のスキームを業務上の目的・ルール・判断に従って利用します。

図の上下の矢印は「利用する」という関係です。ビジネスロジックがスキームを利用し、スキームがモデルを利用します。データがこの順番で移動する、という意味ではありません。

データモデルの中にある三要素は、互いに独立した章と同じ階層へ並べるものではありません。モデルを説明する三つの観点です。そのため本記事でも、第2章の下に2.1ストラクチャー、2.2オペレーション、2.3フローを置きます。

1.2　月次売上レポートを共通の例にする

例として、売上CSV、商品マスター、加工用テーブル、月次集計結果がある仕組みを考えます。売上CSVを受け取った明細をInput、商品名と金額を付けた明細をTransform、月次商品別の集計結果をOutputと呼びます。商品コードと商品名の対応はMasterに置き、取込先や対象月の設定はControlに置きます。

これらは、単に異なる名前の箱ではありません。TransformはInputの明細とMasterの商品情報を使って成立します。OutputはTransformの明細を集約した結果です。Controlの設定が変われば、読む対象や集計対象も変わります。この関連まで含めて把握することが出発点です。

本記事の金額は円単位で、税の計算は加えません。返品は負の数量として記録し、返品日が属する月に差し引く例とします。単価には売上明細に記録された取引単価を使います。これらは説明用の業務ルールであり、他の業務へそのまま適用する前提ではありません。

第2章　データモデル

データモデルは「何があるか」だけでなく、「どう関係し、何ができ、機能を介してどう変わるか」を捉える基礎です。同じ月次売上の仕組みを、次の三つの観点で説明します。

まず2.1では配置・接続・依存を見る全体概要図、2.2では変換などの操作とその実現手段、2.3では機能の入出力を追うDFDを扱います。三者を結び付けることで、データの置き場所の説明と、処理の説明がかみ合います。

2.1　データストラクチャー――所在と静的な関連を表す

2.1.1　データとリレーションを一緒に描く

データストラクチャーは、データがどこに、どのようなまとまりで存在し、それぞれがどのように関連しているかを表す構造です。CSV、シート、テーブル、配列などを列挙しただけでは、ストラクチャーの説明として足りません。データとデータの間にあるリレーションシップまで描きます。

全体概要図では、売上CSVからInput、InputからTransform、TransformからOutputへ至る大きな道筋を示します。同時に、MasterがTransformへ商品情報を供給する関連を描きます。MasterはInputとOutputの間に直列に並ぶデータではなく、主経路に情報を与える別の参照元です。

実線は、どのデータを元にどのデータが成立するかという経路や参照を示します。波線は、取込先や対象月など、処理を方向付ける制御の関係を示します。図2のControlからOutputへの波線は、設定された対象月に従ってOutputが作られる、という依存を表しています。

この線種は本記事の全体概要図の凡例です。実線があるから自動的に更新される、波線があるから必ずその順序で実行される、とまでは読みません。関係の存在と、実際の実行条件は分けて説明します。

2.1.2　「静的」は、データが変化しないという意味ではない

ここで静的というのは、処理を一回実行したときの途中経過ではなく、仕組みに備わっている配置・接続・依存を見るという意味です。毎日CSVの中身が変わっても、「このCSVをInputへ取り込む」「TransformがMasterを参照する」という関係は説明できます。

したがって、全体概要図に矢印があっても、それだけでDFDになるわけではありません。図2で示しているのは、トップレベルのデータの道筋と関係です。どの条件で抽出し、どの入力を合わせ、何を計算して次のデータを作るかは、後のDFDで機能とともに説明します。

CSVからOutputまでの四つの箱を描いて終えると、MasterやControlへの依存が抜け落ちます。すると、マスターを変えたときにどこへ影響するのか、設定がなければ何が決まらないのかを判断できません。ストラクチャーで関連を明示する理由は、ここにあります。

2.1.3　画面に線が見えない関連も取り出す

関連は、画面上の矢印として存在するとは限りません。InputとMasterに同じ商品コードがあり、コードをキーとして対応付けるなら、その対応はデータモデルの一部です。名前定義、式による別シート参照、クエリ参照、配列や共有変数を経由する依存も、必要な範囲で全体概要図へ戻します。

売上明細の一行は、一件の売上または返品を表します。商品マスターの一行は、一つの商品を表します。両者は「同じ行番号だから」対応するのではありません。商品コードが対応を決めます。

今回の売上明細は次の四行です。Inputは、この内容を列と型が分かる状態で受け取ります。

商品マスターは、次の二行です。

P01の商品一件に対して、明細はS001、S003、R001の三件が関連します。この例ではMasterの商品コードを一意とし、明細側では同じ商品コードが複数回現れることを許します。この関係が分かって初めて、どのような照合が妥当かを考えられます。

同じ商品コードのMasterが二行あれば、結合後に一件の明細が複数行になる可能性があります。つまり、キーや一対多の関係は、図の飾りではなく結果の正しさを左右する条件です。

2.2　データオペレーション――操作と要素技術を捉える

2.2.1　何をするかと、何を使うか

データオペレーションは、データに対して行う操作と、その操作を実現するための要素技術を捉える観点です。読み込む、抽出する、検索する、結合する、型を変換する、計算する、集約する、書き出す、といった機能を考えます。

商品コードから商品名を付けるなら、必要なのは、キーを照合して対応する名称を取り出す機能です。その機能を、Power Queryの結合、Excelの検索数式、VBAなどのどの手段で実現するかは、次に考えます。

例えば、Power Queryはデータ加工の仕組みを提供し、その処理を表すM言語には、型変換、行の選択、テーブルの結合などの機能があります。Excel数式にも検索や集計の操作があります。技術名を一つ言っただけでは、どのデータに何を行うのかは定まりません。

2.2.2　操作には入力と結果を対応させる

「結合する」と書いたら、何と何をどのキーで合わせるかを説明します。「計算する」と書いたら、数量と取引単価から明細金額を作る、と説明します。「集約する」と書いたら、商品コードごとに数量と金額を合計する、と説明します。

これらはDFDの接続部分に現れる変換機能になります。一つの機能をVBAの一関数で実装するとは限らず、複数の式やクエリのステップで実現することもあります。設計での機能のまとまりと、コードの実装単位を自動的に同じものとみなさないことが大切です。

2.3　データフロー――機能と入出力をDFDで表す

2.3.1　全体概要図の関係を、変換機能へ展開する

本記事のデータフローは、データフローダイアグラム、すなわちDFDです。データを受け取り、機能によって変換し、その結果を次の機能へ渡す関係を表します。全体概要図で「InputとMasterからTransformが成立する」と捉えた部分を、入力、変換機能、中間データ、出力へ展開します。

データを名詞で置き、データ間の接続部分には変換する機能を置きます。機能には「商品を照合する」「金額を計算する」のような動詞を使い、何が変わるかを明らかにします。一つの機能へ、明細とマスターという複数の入力が集まる場合もあります。

図5では、角丸枠が変換機能、実線の矢印が機能へ入るデータ・機能から出るデータを表します。データの保管先と機能を描き分けるので、Masterからの情報が「商品を照合する」機能のどこへ入るかまで分かります。

一般的なDFDでも、プロセス、データストア、外部との境界、データの流れを区別します。機能はプロセス記号に、流れるデータ名は矢印に置く表記が使われます。本記事もその区別を用い、変換機能をデータ間の流路上に配置しています。Visual Paradigm「How to Draw Data Flow Diagram?」

2.3.2　必要な機能と中間データまで細かくする

「TransformからOutputへ」という全体概要図の関連だけでは、どの月を、何単位で、どう集計するかは伝わりません。そこでDFDでは、対象月の明細を選び、商品別に数量と金額を集約する機能へ分けます。

全体概要図のControlからOutputへの波線を、図6では「対象月という値を、抽出機能へ入力する」というデータの受け渡しとして具体化しています。ここでは対象月も機能が受け取るデータなので、実線を使います。制御に関する情報が、詳細化するとパラメーターというデータ入力になることを区別して読みます。

図5と図6をつなぐTransformは、加工済み明細を保持する接点です。Outputは一行が一か月・一商品になり、元明細より粗い単位になります。DFDでは、どの機能で行の単位が変わるのかも確認できます。

中間データは、すべてを新しいシートとして保存する必要はありません。クエリの途中の値やメモリ上のテーブルでも、説明上の入力・出力として区別できます。永続的な保存先なのか、機能間で受け渡す途中のデータなのかを明記します。

2.3.3　静的な関連と動的な変換は、観点が違う

データストラクチャーで問うのは「何がどこにあり、何と関係するか」です。DFDで問うのは「どの機能が、何を受け取り、どう変えて、何を出すか」です。前者は全体の配置と依存、後者は機能に伴うデータの変化を見る観点です。

DFDを動的な観点と呼ぶのは、機能による入出力の変化を扱うためです。ただし、DFDだけで厳密な実行時刻、待ち時間、全処理の実行順序を表すわけではありません。実行を許可する条件、エラー時の停止や再実行などは、必要に応じて別に記述します。

また、DFDにも大きな粒度と細かい粒度があります。「図が細かければDFD、粗ければストラクチャー」という区別ではありません。本記事では、全体概要図でつかんだ関連を、DFDで必要な機能とデータの入出力へ展開しています。

第3章　データスキーム

3.1　入力・目的・出力で処理をまとめる

データスキームは、データモデルを利用して組み立てる、意味のある一連のデータ処理です。ストラクチャー・オペレーション・DFDで捉えた仕組みに、「どの入力から、何をするために、どの結果を返すか」というまとまりを与えます。

CSV取込であれば、CSVを受け取り、形式を解釈し、列と型を確認して、Inputへ明細を渡すまでが一つのまとまりになります。マスター照合なら、明細とマスターから、商品名を付加した明細を返すまとまりです。月次集計なら、加工済み明細と対象月から、月次商品別結果を返します。

DFDとスキームは、どちらか一方だけを選ぶ関係ではありません。あるスキームの内部をDFDで説明できます。DFDは機能とデータの流れを表す観点であり、スキームはその一連の処理を何のための単位として使うかというまとまりです。

例えば「一件検索」というスキームは、キーを受け取り、検索し、必要な項目を取り出して返します。その内部には、検索や項目抽出というオペレーションと、マスター、入力キー、結果の関連があります。一つの関数で実装する場合も、複数の機能で構成する場合もあります。

3.2　利用できる条件まで含めて定義する

処理名だけでなく、入力の形式、キー、出力の単位、見つからない場合の扱いを決めます。マスター照合なら、商品コードの重複と未一致をどう扱うかが重要です。未一致を無条件に捨てると、元の売上明細が減る可能性があります。

CSV取込にも前提があります。引用符で囲まれた値には、カンマや改行を含めるCSV形式があります。そのため、文字列をカンマで分割するだけでは正しく読めない場合があります。対応する読込機能を使い、必要な列と型を確認します。RFC 4180

Power Queryの左外部結合は、左側の全行を保持して右側の一致情報を取り込みます。未一致の結果を確認できるため、売上明細を残しながら照合結果を点検する用途に使えます。ただし、右側の重複キーによる行数増加まで防ぐ機能ではありません。Microsoft Learn「左外部結合」

「処理が終わった」だけでは成功の条件として不十分です。取込後に必須列がそろっている、照合後に意図しない行数増加がない、集計前後の金額が対応している、といった確認まで決めておくと、後続のスキームから安心して利用できます。

第4章　ビジネスロジック

4.1　業務目的と判断に従ってスキームを使う

ビジネスロジックは、複数のスキームを利用して、業務上の目的・判断・処理を実現します。月次売上レポートなら、目的は対象月の商品別売上を把握することです。そのために、CSV取込、マスター照合、月次集計、帳票用データ生成を組み合わせます。

対象月をどこで区切るか、返品をどの月に差し引くか、未照合の明細があったら出力を止めるか。このような判断が、スキームをどう利用するかを決めます。単に取込・照合・集計を順に並べただけでは、業務上の意味は決まりません。

今回の例では、2026年9月を対象にし、負の数量も合計へ含めます。未照合が残った場合は、確認を終えてから結果を確定します。商品名を付けるためにMasterを参照しますが、取引単価はInputの値を使います。現在の商品マスターの価格で過去の取引金額を置き換えることはしません。

例えば返品を別欄へ出すルールに変われば、分類や集計結果の列を見直します。同じルールのまま実装を数式からPower Queryへ変える場合は、主に要素技術と実装が変わります。この二つを分ければ、変更の理由と範囲を説明できます。

4.2　月次売上の結果を確かめる

例の四行について、数量と取引単価を掛けると、明細金額は2,000円、1,500円、3,000円、−1,000円です。商品コードごとに数量と金額を集約すると、Outputは次の二行になります。

P01は数量2＋3−1＝4、金額2,000＋3,000−1,000＝4,000円です。P02の1,500円を加えると、全体は5,500円です。対象月の元明細の金額合計と、商品別結果の合計が一致することを確認します。

Power Queryのグループ化では、一つ以上の列をキーとして合計などを求められます。この例では、対象月を絞ったうえで商品コードを集約キーにします。Microsoft Learn「行のグループ化または要約」

数値が一致していても、別の月を集計していたら目的を満たしません。未照合の行を捨てたり、マスターの重複によって行を増やしたりしていないことも点検します。業務としての完了は、対象・ルール・結果がそろって初めて判断できます。

4.3　同じ仕組みを三層で読み直す

月次売上レポートの全体を、ここまでの三層に戻して読みます。

データストラクチャーを見れば、CSV、Input、Master、Transform、Output、Controlの所在と関連が分かります。オペレーションを見れば、照合、計算、抽出、集約など、必要な操作と実現手段が分かります。DFDを見れば、その機能が受け取るデータと返すデータ、複数入力や途中の状態を追えます。

スキームを見れば、それらを取込、照合、月次集計などの意味のある処理単位として利用できます。ビジネスロジックを見れば、何の目的で、どの条件・判断に従って使うかが分かります。

自分の業務でも、最初に「何がどこにあり、何と関係しているか」を一枚へ描いてください。その関係を、必要な操作とDFDで具体化します。さらに目的と入出力の明確なスキームへまとめ、業務上の判断につなぎます。対象、関連、機能、目的の階層をそろえると、仕組み全体を説明しやすくなります。

出典メモ

著者提供の「261003_データアーキテクチャ通常版_基本形.md」と、2026年10月3日の著者による修正指示を基に再構成しました。三層とデータモデル内の三観点は、本記事の整理方法です。データストラクチャーは所在と静的な関連の全体概要図、データフローは機能とデータの入出力を表すDFDとして扱っています。

既存の著者記事008「マクロ中間データ設計論」、140「Excel VBAマクロ開発で最初に作る5種類の設計資料」、148「VBAマクロ業務整理を359認知モデルと5設計書でつなぐ」、154「複雑な業務マクロの実行ボタンをデータ変換単位で設計する」を参照し、全体概要図・データの所在と関連・変換機能・中間データの考え方を確認しました。記事221の過去の整理も確認したうえで、本記事では今回の三層の定義を用いています。

DFDのプロセスとデータの描き分けは、本文中のVisual Paradigm公式マニュアルとIBM「What is a data flow diagram?」で確認しました。実線と波線による全体概要図の凡例は本記事の表記であり、一般的なDFDへ制御線を追加する規則を意味しません。技術資料の確認日は2026年10月3日です。

CSVの基本形式、Power Queryの左外部結合とグループ化は、本文中の一次資料を参照しました。表のデータは説明用で、集計の算術と対応を検算しています。Excel・Power Queryで実行した実測結果ではありません。図版は本記事向けの概念図で、外部資料の図や画面は転載していません。

Copyright © LWP 山中 一弘 |