データモデリングは、業務を理解するためにもある——THから考えるPdMの仕事

私は、事業部門や現場の要望を聞き、プロダクトの目的やスコープを整理し、PRDや画面・帳票の要件へ落とし込む仕事をしている。PRDは、何を、誰のために、なぜ作るのかをチームで共有する文書だ。一方で、データベースの構造や実装方式を決めるのは、主にエンジニアの役割だと考えてきた。

その分担を変えたいわけではない。ただ、要件として「顧客情報を表示する」「残高を連携する」と書いたとき、その意味をどこまで説明できていたのかは、改めて考える余地がある。

ここでいう顧客は、申込者なのか、契約者なのか、実際の利用者なのか。残高は、いつの時点で、何が反映された数字なのか。画面に必要な項目を並べただけでは、こうした問いは残ってしまう。

THデータモデルの考え方に触れて、私の中で変わったのはこの点だった。データモデリングは、保存する形を決める前に、業務で何を同じものとして扱うかを考える仕事でもある。 そう考えると、PdMが関われるところは思っていたより広い。

この記事では、一般的なデータモデリングの中でTHが何を重視しているのかを整理し、要件整理やヒアリング、システム間連携へつなげて考えてみたい。金融サービスを題材にするが、例は説明のために単純化した架空のもので、個別企業の実装や制度上の要件を示すものではない。

また、図はすべて理解を助けるためのMermaid図である。THの着眼点を説明する図も、正式なTH記法を再現したものではない。関係、処理、時間を混同しないよう、それぞれの図が答える問いを添えていく。

1. 一般的なデータモデリングの中に、THを置き直す

「一般的な方法対TH」という二択ではない

最初に整理したいのは、比較するものの大きさだ。「一般的なデータモデリング」は幅の広い活動であり、THはその中で使える具体的なモデル化の方法である。同じ大きさの二つの製品を比較するようには扱えない。

データモデリングには、業務上の対象や意味を考える概念モデル、識別や属性・関係を詳しく定める論理モデル、実際のデータベースにどう保存するかを決める物理モデル、といった見方がある。呼び方や境界は組織によって違っても、「意味を決めること」と「保存方法を決めること」を分ける意義は共通している。

ERモデルは、その中でエンティティと関係を表現する代表的な方法だ。エンティティとは、顧客、口座、注文など、区別して管理したい対象である。ER図をテーブル設計図として見る機会は多いが、ERの発想自体が物理設計だけに限られているわけではない。Chenの原論文も、現実世界の意味を捉えることを出発点にしている。

したがって、「一般的なモデルは構造しか扱えず、THなら業務の意味まで扱える」とは言えない。業務の意味、履歴、役割、集計の根拠を丁寧に扱う実践は、TH以外にもある。

私が注目したい違いは、表現できるかどうかというより、何に注意を向けるための型が用意されているか、という点だ。

観点	一般的なデータモデリングで考えること	THで特に整理されている着眼点
出発点	業務目的、対象、要求、既存データなどから意味を捉える	対象を類型化し、画面・帳票などの現物と突き合わせて意味を確かめる
一件の識別	識別子、一意になる範囲、業務上の単位を定める	KEYとRKEYを通じ、識別と参照の構造を明示的に読む
共通性と違い	継承、分類、関連、属性の所属などを検討する	種類による分類と、同じ対象の局面による分担を区別する
対象の役割	マスター、取引、履歴、集計などを目的に応じて整理する	リソース系・イベント系・情報系という類型で捉える
時間と粒度	発生、履歴、有効期間、集計単位を設計する	類型と配置の規則を使い、先行・後続や粗い・細かい単位を読みやすくする
加工の説明	変換、集計、データの由来を別の図や仕様で表す	加工データの区別と、補助的なSPFチャートを組み合わせる
作業の進め方	採用する方法論やチームの運用によって異なる	周辺の方法論で、現物の確認、部分図、統合、定義をつなぐ

右側は、左側にできないことの一覧ではない。広い実践の中から、確認したい観点をまとめて持ちやすくしたもの、と読むのが私にはしっくりくる。

モデルの記法と、仕事の進め方を分ける

THは、日本のデータ総研が研究と実務の中で発展させてきた概念データモデルの技法だ。周辺には、分析・整理の方法論であるPLAN-DBや、データの加工を記述するSPFチャートがある。公式の説明でも、モデルの技法だけでなく、手順や成果物を含む体系として整理されている。データ総研の技法紹介

ここは、私の理解でも分けておきたい。THという記号を使っただけで、関係者への確認が済むわけではない。逆に、THの記号を採用しなくても、現物から疑問を見つけ、意味を確認して定義へ戻す進め方は取り入れられる。

次の図は、厳密な学説の分類ではなく、この記事での使い分けを示したものだ。矢印は、活動とそこで使う方法・道具の対応を表している。

THを使うことと、既存のデータベースを置き換えることも同義ではない。概念として何を区別するかと、その区別を何個のテーブルで実現するかは、別の判断である。

また、この図を上流から下流への一方通行と考えるつもりもない。既存システムの制約や性能検証から、業務上の選択を見直すことはある。往復するときにも、何を守り、どこを変更したのかが分かるようにしたい。

2. 同じ業務を、違う着眼点で見てみる

まずは、一件の単位をそろえる

架空の証券サービスで、一人の顧客が口座を持ち、ある商品に注文し、一つの注文が複数回に分かれて約定する場面を考える。約定とは、売買が成立した出来事である。さらに、ある時点の口座・商品別の保有数量を記録することにする。

この例では、一口座の名義人は一人、一注文の対象商品は一つ、一つの約定が属する注文も一つと仮定する。まだ注文していない口座や、一度も約定していない注文は存在できる。共同名義、複数商品を組み合わせた注文、移管などは、この最初の図には含めない。

先に条件を書くのは、図の見た目だけでは、その線がどこまでの業務に有効なのか分からないからだ。

対象	この例での「一件」	一件を区別する手掛かり
顧客	このサービスが顧客として管理する一主体	顧客ID
口座	顧客に帰属する一つの口座	口座ID
商品	売買対象として識別する一商品	商品ID
注文	ある口座から出された一つの注文	注文ID
約定	その注文に対応する一回の売買成立	約定ID
保有断面	ある時点の、一口座・一商品の保有状態	口座ID、商品ID、基準時点の組

「口座と商品が分かれば保有数量が分かる」とだけ考えると、いつの数量かが抜ける。逆に、時点ごとの保有をすべて記録する必要があるかは、利用目的から判断する。細かく残せばよい、という話でもない。

ER図で、対応関係を見る

以下のER図は、顧客をCUSTOMER、口座をACCOUNT、商品をPRODUCT、注文をORDER、約定をEXECUTION、保有断面をPOSITION_SNAPSHOTとしている。属性は省略し、対応件数に絞った。二本の短い縦棒は「ちょうど一件」、丸と三つ又の記号は「ゼロ件以上」を表す。

このER図では、実線は参照先のIDを自分の識別の一部に使う関係、点線はそうでない関係を表す。保有断面は口座・商品・基準時点の組で識別し、注文や約定などは独自のIDで識別する想定だ。後に使う説明図では線の意味が異なるため、それぞれの凡例に従って読む。

この図から、一口座に複数の注文があり、一注文には約定がない場合も複数ある場合もある、と読める。ただし、線だけで注文取消の条件や、保有数量の計算方法まで決まるわけではない。それらを定義書や別の図で補うのは、一般的なモデリングでも必要な作業だ。

THの類型を使って、同じ対象の役割を見る

次は、同じ六つの対象を、THのリソース系・イベント系・情報系という着眼点で並べ直してみる。リソースは出来事に登場する対象、イベントは指図や発生した出来事、情報系は集計や状態量、ある時点の観測などを扱う。

実線は先ほどと同じ対応関係、点線は保有断面を作る際の材料という意味である。正式なTHの配置や矢線規則を再現した図ではなく、視点の違いを示す説明図として読んでほしい。

二つの図で、対象と基本的な対応関係は同じだ。後者では、対象の役割とデータの由来という着眼点を重ねている。なお、保有数量は約定だけで決まるとは限らない。期首残高や移管などが必要な業務なら、それらを追加しない限り計算は完成しない。

私にとって、この類型化が効くのは、質問を作る場面だ。「このテーブルは何ですか」ではなく、「これは実際に起きたことですか、これから実行したい指図ですか、それらを集計した結果ですか」と聞けるようになる。

注文数量100と約定数量70が違っていても、それだけでは不整合ではない。注文は意図、約定は成立した事実だからだ。残る30が未成立なのか、取消済みなのかまで確認して、初めて状態を説明できる。

THでは、対象の置き方にも意味を持たせる。代表的には、リソースと関与するイベント、親と明細、先行と後続を、一定の上下・左右関係で並べる。表現できる情報が増えるというより、複数の図を同じ順序で読み、粒度や関係の抜けを見つけやすくする工夫だ。

ただし、位置と矢印は別に読む。正式なTHの関係線はKEY側からRKEY側へ向かい、処理の実行順を表す線ではない。例えば、集計結果は後から作られても、詳細より粗い単位として上に配置される。「右側だから後続」「矢印があるから実行可能」と機械的に読まないことも大切になる。

KEYとRKEYは、値ではなく役割を分ける

口座データの口座IDがA001で、注文データにもA001が入っている。このとき、口座自身を識別する側がKEY、注文からその口座を参照する側がRKEYになる。

二つのA001は、同じ値でよい。違うのは役割だ。一方は「私はこの口座」、もう一方は「この注文は、その口座のもの」と言っている。一般的なモデルでも、識別子と参照によって表現できる考え方である。

さらに、受付担当者と承認担当者が同じ社員だったとしても、二つの役割を一つの「担当者」にまとめてよいとは限らない。たまたま同じ人が担当したことと、制度上いつでも同じ担当でよいことは別だからだ。

確認したいこと	値だけを見ると起きる誤解	業務として確認する問い
識別	同じ番号なら同じ対象だと思う	その番号は全社で一意か、システム内だけか
役割	同じ人なら一項目にまとめる	受付と承認は別の人になり得るか
変更	番号が変わったら別の対象だと思う	改番しても同じ契約・同じ口座として追うか
参照	存在するIDなら正しいと思う	対象は合っていても、参照する役割や時点は合っているか

概念上の参照を説明できることと、データベースの外部キー制約を実装することも同じではない。外部キー制約は参照先の存在などを守る手段になるが、その口座をその取引で使ってよいか、操作した人に権限があるかまで、一つの制約が説明してくれるわけではない。

「分類」と「分担」を、テーブル分割から切り離す

個人顧客と法人顧客を分けるのは、対象の種類を分ける話だ。共通する顧客の情報を持ちつつ、個人だけに必要な情報、法人だけに必要な情報や関係を区別する。これはサブタイプ、つまり全体の中にある特定の種類として考えられる。

一方、一件の申込みについて、受付内容と現在の審査情報を分けるのは、同じ対象の情報を局面ごとに分担する話だ。THではサブストラクチャという見方がある。こちらは「別種類の申込み」を作ることではない。

この図の矢印は分類・分担の対応であり、処理順ではない。また、個人・法人で分類することが、そのまま二つの物理テーブルを作る指示になるわけでもない。共通テーブル、別テーブル、ビューなどへの落とし込みは、技術的な条件と合わせて決める。

ここで一つ、境界がある。再審査を繰り返すなら、「現在の審査情報」と「各回の審査履歴」は同じ粒度ではない。現在の一件を扱うのか、過去を含む複数の出来事を扱うのかで構造が変わる。同じ申込番号が付いているからといって、すべてを一対一の分担に押し込むことはできない。

また、申込みと口座を別の対象として扱う理由は、番号が違うからだけではない。口座が生まれずに申込みが終わることがあり、開設後の口座は申込みとは違う期間・目的で管理される。成立や終了の条件を確かめることが、分ける根拠になる。

用語にも注意が必要だ。THでいう「スーパータイプ」は、別々の識別体系を持つ集合を、元の区分と番号を残して束ねる用法がある。一般的な拡張ERでいう、子が共通属性を継承する親型と、そのまま同義ではない。例えば「顧客・0001」と「仕入先・0001」を一つの一覧へ集めても、同じ法人を一件に名寄せしたとは限らない。名前を覚えるより、何を一つにしたのかを確かめたい。

3. THの着眼点で、見落としやすい問いが増える

時間を扱うとは、日付の列を増やすことだけではない

データモデルに時間を入れる、と聞くと、作成日時や更新日時を加えることを考えやすい。けれど、業務で知りたい時間はそれだけではない。

例えば、同じ「住所」でも、現在の住所と、過去の通知を送った時点の住所は違う。どちらも同じ文字列になっている日には、その違いは見えない。引っ越したときに初めて、更新してよい値と、当時の事実として残す値が分かれる。

THの類型や配置は、継続して扱う対象、発生した出来事、ある時点の状態を区別する手掛かりになる。ただし、有効期間や遡及訂正まで自動で決まるわけではない。実務では、どの時間を区別する必要があるかを、もう一段言葉にすることになる。

時間の問い	意味	混同したときの問題
いつ起きたか	売買や変更など、出来事が発生した時点	遅れて届いた出来事を翌日の実績にしてしまう
いつから有効か	契約や条件が業務上適用される期間	将来の条件を過去取引へ適用してしまう
いつ知ったか	自分たちのシステムが記録・認識した時点	当時は知らなかった事実を判断に使ったことにしてしまう
いつを観測したか	残高や状態を切り取る基準時点	異なる時点の数字を同じ「現在」として比べる

業務上の有効な時間と、データベースに記録された時間を区別する考え方は、一般的な時間データの設計にもある。OracleのTemporal Validityの説明も、この違いを扱っている。THだけの特徴としてではなく、THから得た問いを実務へ展開するときの補助線として使いたい。

例えば、4月3日に「4月1日から有効だった条件」を訂正登録したとする。「4月1日に実際に適用されるべき条件」と「4月2日時点でシステムが知っていた条件」は、違う答えになり得る。障害や問い合わせを振り返るなら後者も必要かもしれない。一方、その要件がなければ、すべての項目に複雑な二重の時間管理を導入する必要はない。

状態と、状態を変えた出来事を分ける

注文に「受付済み」「一部約定」「取消済み」という状態を持たせると、現在の様子は分かる。しかし、最後の状態だけでは、そこへ至った過程は説明できない。

100口の注文に40口、30口と約定があり、残り30口を取り消した場合を考える。画面の「取消済み」を見て、100口すべてが取り消されたと解釈されると困る。成立した70口と、取り消した30口を区別しなければならない。

次の図は、この一例だけを表す状態変化のフローである。矢印は起きた出来事による遷移を示しており、網羅的な注文仕様ではない。

ここで、「取消を依頼した」と「取消が成立した」は別の事実だ。依頼の後に追加の約定が発生する可能性を認める業務なら、その場合の数量と通知順序も扱う必要がある。単に状態コードを一つ増やせば済むわけではない。

構造としては、注文、約定、取消依頼、取消結果を区別する案が考えられる。どこまで独立した記録にするかは、問い合わせ、再送、訂正、監査などの要求から判断する。THでイベント系として整理することは助けになるが、遷移の許可条件は状態図やルール表で補う。

なお、出来事をエンティティとして扱うことは、イベントソーシングを採用することとは違う。後者は、出来事の列を正本として状態を再構成する実装上のパターンだ。モデルで注文や約定を区別しただけで、そのアーキテクチャまで決めたことにはならない。MicrosoftのEvent Sourcingの説明

同じ数量でも、足してよいものといけないものがある

THの情報系では、要約、在庫、断面という区別が参考になる。要約は期間などでまとめた数字、在庫は増減する状態量、断面はある時点を切り取った記録、と捉えると分かりやすい。

この違いは、ダッシュボードの仕様にも直結する。

表示したい数字	一件の単位	合計するときの注意
日別の約定数量	日付・口座・商品・売買区分	重複しない日を足せるが、単位や取消の扱いをそろえる
現時点の保有数量	口座・商品と、反映済みの範囲	何を反映済みとするかによって意味が変わる
月末の保有数量	月末時点・口座・商品	4月末と5月末を足しても、6月の保有数量にはならない

月初100口、月末100口という断面だけでは、その間に何もなかったのか、途中で大きな売買があったのかは分からない。状態と出来事は、互いに代わりになるとは限らない。

また、「保有数量」「売却可能数量」「受渡済み数量」が同じ値になる場面があっても、それぞれの定義が同じとは限らない。どの判断に使う数字かを先に置くと、同じ数量欄を流用してよいかを考えやすくなる。

SPFの考え方で、数字の作られ方を追う

データがどこにあるか分かっても、数字の意味が分かったことにはならない。どの記録を選び、何と結び、どの単位で集計したのかが必要だ。

THを補うSPFチャートは、こうした加工の入出力と操作を整理するために使われる。私はこれを、SQLの代わりというより、計算の前提を業務の言葉で確認するための道具として捉えている。概念上の加工と、プログラムの実行順序や本数は区別される。開発者によるPLAN-DBの論文

次の図は、SPFの「入力・加工・出力を追う」考え方を借りた簡略図で、正式なSPF記号ではない。矢印はデータの加工順を表す。

同じ日に、同じ口座から同じ商品に出した二つの買い注文を考える。注文O1は100口、O2は50口で、O1に40口と30口の二つの約定、O2に50口の一つの約定があったとする。

注文	注文数量	約定	約定数量
O1	100	E1	40
O1	100	E2	30
O2	50	E3	50

約定数量を足すと120口になる。一方、この表の注文数量をそのまま足すと250口になるが、元の注文数量は150口だ。注文と約定を結んだことで、O1の100口が二度現れたからである。

これは計算式の足し算が間違っているのではなく、足している一件の単位が変わった問題だ。後から同じ数字を削除すればよいわけでもない。別の注文が偶然同じ100口だった場合には、正しい記録まで消してしまう。

各段階で「今、この一行は何を表しているか」と聞く。この問いは、PdMでもできる。集計対象、時点、単位、未到着とゼロの違いまで確認すれば、「合計を表示してください」という要件を、検証できる要件に近づけられる。

得られるのは、魔法の表現力ではなく確認の足場

ここまでの着眼点は、一般的なデータモデリングでも扱える。THに価値を感じたのは、それらを類型や構造として学び、質問の順序を持ちやすくなることだった。

得たい効果	THから借りられる着眼点	それだけでは保証されないこと
認識のずれを見つける	一件の単位、KEY、参照する役割	関係者全員の合意
分け方の根拠を説明する	分類と分担、独立した対象の関係	適切なテーブル数やサービス境界
数字の意味を確かめる	イベント・在庫・断面・要約の区別	元データの品質や処理の即時性
変更の影響を追う	元の事実と加工結果の対応	自動的な変更追従
判断を引き継ぐ	現物、部分図、定義、疑問の対応	文書が継続して更新されること

つまり、効果を生むのは記号そのものではなく、その記号を使って、これまで暗黙だった条件を確認する活動なのだと思う。

4. PdMは、モデルの前提をどこまで明確にするのか

項目を渡すことから、意味を渡すことへ

私の仕事の中心は、何を実現したいかを決め、関係者の方向をそろえることだ。背景、目標、KPI、対象ユーザー、スコープとスコープ外を整理したうえで、必要な画面や帳票、業務上の条件を示す。

データモデルの考え方が入っても、この役割をエンジニアリングへ全面的に広げる必要はない。ただ、渡す要件の中身は少し変えられる。

例えば「口座一覧に状態を表示する」だけでは、状態の対象が曖昧だ。口座そのものの利用状態なのか、口座開設申込みの審査状態なのか、外部への登録処理の状態なのか。この三つを混ぜると、画面はできても利用者が次の行動を判断できなくなる。

「申込みの審査が終わったこと」と「取引できる状態になったこと」が違うなら、要件の段階で違いを伝える。何というテーブルに保存するかを決めなくても、業務として何を区別したいかは説明できる。

項目だけの要件	意味を含めた要件への書き換え
顧客名を表示する	現在の契約名義を表示する。過去の通知先名義とは区別する
注文状態を表示する	成立済み数量と未成立分の状態を、利用者が区別できるようにする
残高を連携する	基準時点と反映範囲を定義し、未確定部分があれば分かるようにする
担当者を記録する	受付、判断、承認の役割と、それぞれ誰が行ったかを区別する
エラーなら再実行する	同じ依頼の再送か、新たな依頼かを区別し、二重の業務処理を防ぐ

右側は、まだ完成した仕様ではない。それでも、エンジニアが判断するための前提は増えている。PdMがすべてのモデルを描く必要はなくても、「このモデルなら、業務で必要な違いを残せるか」を一緒に確かめることはできる。

ヒアリングは、名詞の収集で終わらせない

現場の説明を聞くと、顧客、申込み、契約、承認、通知といった言葉が出てくる。それをエンティティ候補として拾うのは出発点になるが、出てきた名詞をすべて箱にすればよいわけではない。

私なら、一つの言葉に対して次の順に質問を足す。

問い	申込みを例にした聞き方	明らかにしたいこと
一件とは何か	同じ人が出し直したら、同じ申込みですか	識別の単位
いつ成立するか	入力を始めた時点ですか、提出した時点ですか	下書きと業務上の受付の境界
何と結び付くか	一申込みから複数の口座ができることはありますか	関係の件数
何が繰り返されるか	差戻し後の審査は、過去の判断を残しますか	現在状態と履歴の違い
誰が意味を確定できるか	この受付日を決めている規程や担当はどこですか	根拠と確認先
何に使うか	この日付で、誰がどの締め処理を判断しますか	情報の利用目的

例えば物販の受注に置き換えると、「一受注の明細ごとの納期が同じだった」というサンプルを見ても、納期が受注全体の属性だとはまだ言い切れない。たまたま同じ値なのか、業務上別々に設定できないのかで違う。聞くべきなのは、今同じかではなく、別々に変わることがあるかだ。

画面や帳票も、同じ姿勢で見る。欄が近くにあるから同じ対象の情報とは限らないし、画面に出ていないから存在しないとも限らない。自動的に引き継がれる口座IDや、一覧全体に共通する営業日など、利用者には自明で表示されない条件もある。

実物は強い手掛かりになる。ただし、それをそのまま正しい業務の定義だとは考えない。古いシステムの制約が、画面の形に埋め込まれていることもあるからだ。

事実、要望、仮説を混ぜずに、少しずつ構造へ移す

専門用語が多い打ち合わせで、その場ですべてを理解し、確定するのは難しい。私自身、いったん記録を整理してから意味がつながることがある。そこを、知識が足りないから全部自分で抱えて持ち帰る、という形にはしたくない。

理解の途中でも残せるものはある。「現状そうしている」「今後そうしたい」「まだ分からない」を分けることだ。会議の発言をそのまま仕様にするのではなく、何として記録したかを明らかにする。

次の図は、私なら用意したい確認の流れである。矢印は作業の順序と見直しを表し、データの参照関係ではない。

「確認した」と「文書に反映した」は別の状態だ。 打ち合わせで答えが出ても、PRDや項目定義が古いままなら、エンジニアは古い条件で実装するかもしれない。

音声の文字起こしやAIによる整理を使う場合にも、この区別は残したい。話者の推測が確定事項へ変わっていないか、専門用語が別の語に置き換わっていないかを確認する。読みやすい議事録になったことと、要件として合意されたことは同じではない。

要件と根拠を、一段ずつたどれるようにする

資料とは、PRDだけではない。業務マニュアル、外部接続仕様、規程、契約、現行画面、問い合わせ記録、決定の議事録なども含まれる。外部サイトのリンクだけでなく、どの版のどの箇所を、どう解釈したかまで分かると、後で判断を見直しやすい。

ただし、すべてをPRDに複製すればよいわけでもない。転記を増やすほど、更新漏れが起きる。元資料へ戻れるリンクと、その資料から採用した条件、確認した人を対応付ける方が扱いやすい場合がある。

記録するもの	例	残す理由
要求	申込者が、次に何をすればよいか分かる	作る目的を失わないため
根拠	業務担当への確認、運用手順の該当箇所	誰の発言・どの条件に基づくかを追うため
意味の定義	差戻しは不承認ではなく、追加情報待ち	状態名だけの誤解を防ぐため
構造上の判断	現在状態と、各回の判断履歴を区別する	必要な情報が消えないか確かめるため
受入条件	再提出後も前回の差戻し理由を参照できる	動作として確認できるようにするため

次の図の線は、成果物の依存関係を示す。モデルはPRDの代用品でも、仕様の完成形でもない。根拠と実装の間にある、意味を確認するための表現だ。

受入テストを技術仕様からだけ作ると、仕様どおりには動くが、元の困りごとは解決しないということがある。図の最後に事業要求からの線も引いたのは、そのためだ。「正しく作ったか」と「必要なものを作ったか」の両方を確かめたい。

5. 業務ルールとシステム間連携を、構造の外へ放り出さない

関係を描くだけでは、してよいことは決まらない

顧客と口座がつながっていても、その口座で、今、その商品を取引してよいかは別の問いだ。利用契約、審査結果、商品ごとの条件、受付時間、利用停止の状態など、複数の情報が判断に関わることがある。

データモデルが材料を整理し、ルールがそれらを使って可否を決める。この二つを分けながら対応付けると、何の情報が不足しているのかが分かる。

架空の追加サービスの申込みなら、次のような確認表を作れる。これは法的な要件ではなく、モデルとルールをつなぐための設例だ。

確認する条件	参照する対象	条件を満たさない・分からない場合
基本契約が有効か	契約と有効期間	受付不可の理由を示す
このサービスの利用承認があるか	サービス別の利用承認	未承認と審査中を区別する
同じ申込みが進行中ではないか	申込みと現在状態	重複申込みとして扱う条件を確認する
判定に必要な情報がそろっているか	必要情報と確認結果	未確認を自動的に否決扱いしない

ここで、「承認」という単語だけでは足りないことも見える。承認された事実、現在の利用資格、今回の依頼を受け付けてよいという判定は、似ていても別のものだ。過去に承認されても、その後の失効で利用できない場合がある。

また、判定と行為も分けたい。「受付可能」と判定したことと、実際に「受け付けた」ことは違う。判定後、処理するまでに条件が変わるなら、どの時点の条件で実行を確定するかをエンジニアと確認する。ここから先には同時実行の制御が関わるが、業務として守りたい条件はPdM側から説明する必要がある。

同じ「成功」が、システムごとに違う

外部連携では、送信できたこと、相手が受信したこと、相手の業務で受理されたこと、最終的に処理が完了したことが違う。「成功」の一語にすると、利用者への案内を間違えやすい。

次のシーケンス図は、外部へ処理を依頼し、結果が遅れて届く場面だ。上から下へ時間が進み、横の矢印は通信を表す。重複通知があっても業務結果を二度反映しない、という条件を含めている。

この流れを描くと、必要なデータが増える理由が説明できる。利用者から受け付けた依頼、外部で付けられた業務番号、通知一件を識別する番号、現在の照会状態。それぞれが同じ番号で足りるとは限らない。

識別したいもの	確認すること
自社の業務依頼	同じ操作の再試行か、新しい依頼か
外部の業務対象	自社の一件と一対一か、分割・統合されるか
通信メッセージ	同一内容の再送か、訂正された内容か
外部の出来事	同じ約定や結果を二重に受け取っていないか

外部業務番号とメッセージ番号を同じものと思い込むと、再送と新規処理を区別できないことがある。複数メッセージが同じ業務結果を運ぶなら、受信した回数と業務上の発生回数は違う。

反対に、通知内容が訂正されたのに「同じ番号だから処理済み」と捨てるのも問題になる。外部仕様にある識別範囲、版、訂正の意味を確かめる必要がある。

こうした要求を実現する候補に、業務更新と送信予定を同じローカルなトランザクションで保存するTransactional Outboxがある。ただし、採用は技術判断だし、それだけで外部処理まで一括確定するわけでもない。配送の重複と、受信側での二重処理防止も考える必要がある。AWSのTransactional Outboxの説明

PdMとしてまず示したいのは方式名ではなく、「何をもって受付済みとするか」「結果不明をどう見せるか」「二重に起きてはいけない業務は何か」だ。その条件が、モデルと実装の双方へ伝わっていく。

商品の違いと、連携経路の違いを分ける

新しい商品を追加したとき、既存商品とは違うシステムへ接続することがある。このとき「接続先が違うから、商品も完全に別の管理にする」と急いで決めると、共通に扱いたい情報まで分かれるかもしれない。

商品が何か、どのサービスで扱うか、どこへ依頼を送るかは、分けて確認したい問いである。商品種類、投資対象の地域、通貨、リスク分類、販売チャネル、接続先は、必ずしも同じ分類軸ではない。

例えば「高い利回りを目指す」という運用上の特徴だけで、新しい商品エンティティを作るとは決められない。固有の属性や関係、契約・処理の違いがあるのか、それとも既存商品の属性として説明できるのかを調べる。正式な商品区分や制度上の位置付けは、その商品の資料と専門家への確認が必要だ。

次の図は、接続先が商品と有効期間によって変わり得る、と仮定した概念上の一案である。線は参照関係であり、通信の流れではない。

実際には、商品だけでなく、注文種別や顧客区分、時間帯などで経路が変わるかもしれない。必要な軸だけを追加し、同時に複数の設定が一致した場合の優先順位や、該当設定がない場合も定める。

設定の現在値だけで過去の経路を推測すると、設定変更後に説明が変わってしまう。過去の注文が実際にどこへ送られたかを残す必要があるなら、採用した設定の版や経路を追えるようにする。ここでも、「現在の規則」と「そのとき行ったこと」を分ける視点が役立つ。

6. 実務へ持ち込むなら、判断と変更までつなげたい

新しい種類を増やす前に、三つの案を比べる

将来の商品追加に耐えるモデル、と聞くと、何でも登録できる汎用構造を作りたくなる。しかし、すべてを「種別」と「値」で持てば、業務上の意味が消え、確認すべき条件がプログラムの奥へ移ることもある。

私はまず、属性で区別する、サブタイプとして固有情報を持つ、独立した対象として関連付ける、という三つを比べたい。分類を細かくするほど優れたモデルになるわけではない。

案	向いていると考えられる状況	確かめたい弱点
共通対象の属性で区別	ルールや情報構造がほぼ共通で、分類が主目的	固有の必須条件を見落とさないか
サブタイプを設ける	共通の対象だが、一部に固有の属性・関係がある	所属条件、複数所属、対象外を説明できるか
別の対象として結ぶ	成立・終了・識別・責任の単位が独立している	共通部分が重複し、対応管理が増えすぎないか

まだ存在しない将来を想像して、無条件に多対多へ広げる必要もない。現状の合意、具体的な追加予定、単なる可能性を分ける。将来の変更をゼロにするより、何を前提にしたモデルかを分かるようにする方が、現実的だと思う。

「同じものとしてまとめる」判断を、途中から見せる

完成図だけを見ると、分け方が自明だったように感じる。実務では、いくつかの案を比べ、業務担当と話し、制約との折り合いをつけて決めることが多いはずだ。

例えば、口座開設の審査について、「申込みに最新の審査結果だけを持つ案」と「審査ごとの記録を持つ案」を考える。差戻しがあるからというだけでは、後者が必要だと決まるわけではない。以前の判断を誰が何のために見るのかが必要になる。

架空のチームで、問い合わせ担当が過去の差戻し理由を参照し、再審査時には以前の判断と区別したい、と確認できたなら、次のように判断を残せる。

項目	記録の例
検討した問い	審査結果は最新の一件で足りるか
案A	申込みに最新結果と理由だけを持つ
案B	申込みと、各回の審査判断を区別する
確認できた必要性	問い合わせ時に、以前の差戻し理由と今回の判断を区別したい
採用する考え方	過去の判断を失わず、現在有効な判断を特定できるようにする
残る未決	訂正と再審査の違い、履歴の保存期間、閲覧権限
反映先	PRD、審査画面、問い合わせ画面、モデル、受入テスト

この結論は、単純な「履歴テーブルを作る」という指示より、設計意図を伝えやすい。現在値を別に保持するか、履歴から導くか、どう性能を確保するかは、エンジニアが比較できる。

概念上の関係を描くなら、例えば次のようになる。線は一件から対応する相手の件数を示す。ここでは、一申込みから開設される口座は高々一つという、この設例の条件を置いている。

APPLICATIONは申込み、REVIEW_DECISIONは一回の審査判断、REVIEWERは判断した担当者を表し、それぞれ独自のIDで識別する想定だ。丸と一本の縦棒は「ゼロ件または一件」を表す。この図でも、どの判断が現在有効か、過去の判断を訂正できるかまでは決まらない。関係図に条件を補い、具体例で確かめるところまでが必要になる。

レガシーの名前と、業務上の名前を無理に一度でそろえない

既存システムの項目名が分かりにくいからといって、すぐに全カラムを改名できるとは限らない。帳票、バッチ、外部連携が参照していれば、名前の変更だけでも影響が広い。

そこで、業務上の意味、保存上の名前、表示上の名前を分けて対応付けるという進め方が考えられる。以下の名称は架空の例だ。

業務上の定義	既存の物理項目名	画面・帳票の表示	注意すること
現在の契約名義	CUST_NM	口座名義	操作者名とは違う
通知作成時の送付先名義	PRINT_NM	宛名	現在の名義へ自動追従させてよいか確認する
外部側で業務受付が成立した日時	ENTRY_DT	外部受付日時	自社で結果を受信・確認した日時とは区別する

業務標準名を決めたからといって、画面に長い正式名称をそのまま出す必要はない。読みやすい表示名を使いながら、裏側の定義へ戻れるようにすればよい。

文字数の問題も、同じように分けて考える。業務上必要な名前の長さ、保存できる長さ、外部へ送れる長さ、紙面に表示できる長さは違う。帳票に入り切らないからといって、元の名前を短くして保存する必要があるとは限らない。

表示だけを省略する案でも、利用者が対象を取り違えないか、完全な値をどこで確認できるかを考える。表示制約と業務の同一性はつながっているが、同じ問題ではない。

また、空欄を一つの意味にしないことも重要だ。未入力、未審査、対象外、値はあるが非表示、連携待ち。これらを区別する必要があるなら、その違いを要件とモデルの双方へ渡す。画面上の見せ方だけで処理すると、集計や連携先で意味が復元できなくなる。

性能や障害対策は、最後まで待たずに条件として置く

データの意味を先に整理することは、性能や運用の問題を後回しにしてよいという意味ではない。復旧、データ損失、処理時間、情報の鮮度は、業務上の要求でもある。

ただし、PdMが最初からマルチクラウドや特定のデータベース製品を指定する必要はない。守りたい条件と、それを満たす方式を分けて話す方が、技術的な選択肢を比較しやすい。

PdMが関係者と明らかにしたい条件	エンジニアや専門担当と検討する内容
どの業務を、どれくらい止められるか	冗長化、切替、復旧手順と試験
どの記録を、どこまで失ってよいか	バックアップ、複製、復旧後の整合確認
いつまでに、どれだけ処理したいか	データ配置、索引、並列化、処理方式
表示の遅れをどこまで許せるか	キャッシュ、集計更新、同期・非同期の選択
訂正後、どこへ反映し直す必要があるか	再集計、通知、再送、履歴と版の管理

正規化も「速いか遅いか」だけで決まる話ではない。そもそも何に対して一つの値が決まるのかを整理し、重複更新による不整合を避ける意味がある。そのうえで、読み取りの多さや更新頻度、必要な整合性を踏まえ、集計済みデータやキャッシュなどを検討する。

バッチかリアルタイムかも、単独の二択ではない。同じサービスでも、注文受付は即時、報告用の集計は一定間隔という組み合わせがあり得る。複製や集計を足す場合には、元の事実はどれか、どれだけ遅れてよいか、作り直せるかを明らかにする。

データモデルは、その説明の土台にはなる。しかし、図があること自体が可用性、性能、法令遵守、本人性の証明になるわけではない。必要な専門判断と、実装・運用・検証を別に対応付ける。

変更に強いとは、影響がないことではなく、影響を追えること

ある項目の意味が変われば、その項目を使う画面だけでなく、集計、外部通知、問い合わせ対応にも影響が出る。例えば「受付日時」を入力開始から提出完了へ変えるなら、受付件数や処理時間のKPIも変わるかもしれない。

次の図の矢印は、定義変更によって確認が必要になる先を示す。すべてを自動で変更するという意味ではない。

履歴を全部新しい定義で再計算するのか、ある日から切り替えて比較時に注記するのか。どちらもあり得るが、何も決めずに同じ名前でつなぐと、変化の理由が分からなくなる。

変更のたびに巨大な全体図を更新することだけが目的ではない。変更する意味から、影響する記録、処理、利用者へたどれること。そのつながりを保つために必要な範囲で、図と定義を更新したい。

7. 全社標準を変えなくても、取り入れられること

PdMが全部決めるのではなく、誰と決めるかを持つ

金融のように、業務、制度、外部機関、会計、セキュリティが絡む領域では、一人で全部の正解を持つことは難しい。これは、モデルを勉強すれば解消する種類の問題ではない。

PdMには、目的と範囲を整え、必要な問いが適切な人へ届き、その回答が要件へ反映されるようにする役割がある、と私は考えている。専門家の代わりに判断することとは違う。

論点	主に一緒に確認したい相手	PdMがつなぐこと
利用目的・優先順位	事業部門、利用者、業務担当	何を解決し、今回は何をしないか
制度・社内規則	コンプライアンス、法務、業務責任者	適用範囲、根拠、未確定の解釈
会計・報告	経理、報告業務の担当者	計上や締めの単位、必要な時点
外部システム	接続業務の担当者、エンジニア	相手の一件と自社の一件の対応
データ・処理設計	エンジニア、アーキテクトなど	業務条件と技術上の選択肢の対応
障害・リスク	運用、インフラ、リスク管理	止められる範囲と復旧後に守る整合性

職種名で担当が固定されるわけではない。EMが設計を主導するチームもあれば、テックリードや担当エンジニアが担うチームもある。大事なのは、説明する人、判断する人、実装する人、確認する人が曖昧にならないことだ。

外部機関そのものを今回変更しなくても、その仕様との依存関係は残る。「スコープ外」と「確認不要」を同じ意味にしない。外部へ何を渡し、何が返り、返らなかったときに誰が対応するかは、対象範囲の境界に書いておく必要がある。

まず一つの変更で、小さく試す

組織としてTHを正式採用するなら、記法、教育、成果物、保守責任などを検討することになる。独自の用語を増やすことで、かえって会話の負担が上がる場合もある。私個人の判断で、チーム全体の標準を変えようとは思わない。

それでも、取り入れられる問いはある。次の小さな仕様変更で、項目名の一覧に加えて、「何を一件とするか」「誰のどの役割か」「いつの情報か」を書いてみる。既存のER図や項目定義書があるなら、そこへ同じ観点を加えればよい。

私は、いきなり大きな図を作るより、代表的な一件と例外の一件を用意するところから始めたい。例えば正常な申込みと差戻しがある申込み。通常の約定と重複して届く通知。その二件を同じ定義で説明できるか、関係者と確かめる。

最初に残すもの	小さく始めるときの内容
一件の定義	対象、識別範囲、成立・終了の条件
小さな関係図	今回の判断に必要な対象だけ
通常例と境界例	未発生、分割、取消、再送などから関連するもの
用語と数字の説明	役割、粒度、時点、単位、空欄の意味
判断メモ	根拠、採用しなかった案、未決、確認者、反映先

これは文書を増やすための一覧ではない。既存のPRDや課題管理に置けるなら、別の資料を作らなくてもよい。同じ説明を複数箇所で手作業更新する仕組みは、できるだけ増やしたくない。

効果も、図の枚数で測るものではないだろう。仕様確定後に意味の取り違えが見つかる回数、同じ用語を何度も確認する負担、変更時に影響先を調べる時間などが、自分たちの課題として減っているかを見たい。ただし、改善したとすれば、それをモデリングだけの効果だと決めつけず、チームの運用も含めて振り返る必要がある。

共通言語とは、全員に同じ図を読ませることではない

業務担当には具体的な取引例が分かりやすく、PdMには目的と状態の対応が必要で、エンジニアには識別や制約の詳しさが必要になる。全員へ同じ図を配れば認識がそろうとは限らない。

共通にしたいのは、見せる資料の形ではなく、説明の中身だ。画面を見ても、関係図を見ても、定義書を見ても、同じ一件へ戻れる。何が起きたのか、今どの状態なのか、その数字は何から作られたのかについて、説明が食い違わない。その状態を目指したい。

THの体系に触れて得たのは、一般的なデータモデリングとは別の世界への入口ではなかった。もともとデータモデリングが扱っている意味の問題を、自分の仕事から考えるための、具体的な着眼点だった。

私は、データベースの設計をエンジニアから引き取る必要はない。一方で、データの意味まで曖昧なまま渡してよいわけでもない。実装の選択肢を残しながら、業務として守りたい違いと条件を伝える。その間に、自分が担える仕事がある。

データモデリングは、データベース設計者だけのものではない。プロダクトが何を約束し、業務が何を事実として扱い、人が何を判断するのか。それらを理解し直すための思考の道具でもある。

---

参考文献

• データ総研, 伊藤 洋一 『システム設計・データ活用のためのデータモデル入門 ビジネスを飛躍させる概念データモデルの理解 DATA UTILIZATION』翔泳社, 2025年
• 羽生 章洋『楽々ERDレッスン』翔泳社, 2006年
• ミック『達人に学ぶDB設計徹底指南書 第2版』翔泳社, 2024年