このユニットの結論
経営分析の数字がおかしいとき、「どこで何が起きたか」を遡れなければ、直しようがありません。
項目ごとに、どこから来て（上流）、どう変わって（変換）、どこへ行くか（下流）を追えるようにしておく。これがデータの来歴（系譜）です。人が手で書いた来歴は古くなるので、連携の定義から自動で取れる部分を増やします。
1. 何の話か
このユニットは、データの項目がどこから来て、どう変わって、どこへ行くかを追えるようにする話です。
11-03 古い項目と新しい項目を対応させる で学んだ対応表は、移行のときの「古い → 新しい」の対応です。来歴は、稼働後も含めて、連携と処理のすべての段階で「どこから、どう変わって、どこへ」を追えるようにしたものです。世界で共有されている考え方では「データリネージ」と呼びます。
2. なぜ必要か
来歴が追えないと、
- 経営分析の原価の数字が合わないとき、連携のどの段階の問題かを特定するのに何日もかかる
- 項目の意味を変えるとき、下流で誰が影響を受けるかが分からず、変えてから壊れる
- 監査で「この数字はどこから来たか」を問われて答えられない
- 障害で一部のデータが欠けたとき、どこまで影響が広がったかを追えない
ということが起きます。約36本のシステム連携でデータが流れる構成では、来歴なしに原因を探すのは、地図なしで道を探すのと同じです。
3. このユニットで分かること
- 来歴の 3 つの要素（上流・変換・下流）
- 人が書く来歴と、自動で取る来歴
- 来歴を使う場面
4. 来歴の 3 つの要素
| 要素 | 書くこと | 例（一般的な例） |
|---|---|---|
| 上流 | どのシステムの、どの項目から、どの連携・処理で来るか | 勤怠・工数SaaS の「日次工数（時間）」から、工数連携で |
| 変換 | 途中でどう変わるか。単位、丸め、結合、集計、名寄せ。変換の規則の置き場所 | 時間を 8 で割って人日に。0.125 人日単位で丸め。規則は変換規則文書の第 12 項 |
| 下流 | どの項目、帳票、分析に使われるか | 新基幹の「案件原価」、FIN-CORE への原価の仕訳、BI の案件収支 |
来歴は、最重要データチェーン（顧客 → 契約 → 案件 → 要員 → 工数 → 原価 → 売上 → 請求 → 会計 → 経営分析）の項目から書き始めます。全項目を一度に書こうとすると終わらず、重要な項目の来歴も中途半端になります。
5. 自動で取る部分を増やす
来歴には、人が書く部分と、自動で取れる部分があります。
- 自動で取れる：連携の定義（どの項目をどこへ渡すか）、集計の処理の定義、BI の計算式。これらは定義そのものから機械的に来歴を取れます
- 人が書く：変換の意図（なぜ 8 で割るのか）、業務上の意味、例外の扱い
人が書いた来歴は、連携が変わった瞬間に古くなります。自動で取れる部分をできるだけ増やし、人が書く部分は「意図と意味」に絞ります。来歴の定義と、品質を止める仕組みは DAT-008 データ系譜・品質ゲート定義 にまとめ、移行時の対応は DAT-004 データ移行対応表 と結びつけます。
来歴を使う場面は、原因の調査（数字が合わないとき、どの段階から合わなくなったかを辿る）、影響の調査（項目を変えるとき、下流を列挙する）、説明（監査や経営層に、数字の出どころを示す）の 3 つです。
CASE FACTFROZEN正本に記載されたアステリア案件の事実
アステリア案件のデータの流れに関する記載
- 最重要データチェーン：顧客 → 契約 → 案件 → 要員 → 工数 → 原価 → 売上 → 請求 → 会計 → 経営分析
- データ正本：顧客・契約は営業管理システム、社員・組織は人事マスター、工数は勤怠・工数管理SaaS、案件・案件予算・案件原価・請求は新基幹、正式な会計残高・仕訳は FIN-CORE、経営分析は BI
- 連携：IF-04 工数連携（勤怠・工数SaaS → 連携基盤 → 新基幹）、IF-05 売上仕訳連携、IF-07 原価仕訳連携（新基幹 → 連携基盤 → FIN-CORE）、IF-08（新基幹 → BI）、IF-09（FIN-CORE → BI）
- 成果物に DAT-004 データ移行対応表、DAT-008 データ系譜・品質ゲート定義 がある
- P-009 橋本 奈緒 — データ移行リーダー
項目ごとの来歴がどう記録されたか、変換の規則がどこに置かれたかは、正本に記録がありません。記録なし
6. THINK — 「BI の原価と新基幹の原価が合わない」
稼働後、経営層から「BI の案件原価と、新基幹の画面の案件原価が合わない」と指摘がありました。担当者が次のように答えました。
「BI は新基幹から数字を取っているはずなので、どちらかが間違っています。BI の担当と新基幹の担当にそれぞれ聞いてみます。」
問題
この進め方で、原因にたどり着けるでしょうか。
判断例を開く
判断
「担当に聞く」は、来歴がないときの最後の手段です。来歴があれば、聞く前に段階を絞れます。
確認すること:
- BI の「案件原価」の来歴はどうなっているか。新基幹のどの項目を、どの連携で、いつ取り込んでいるか
- 新基幹の画面の「案件原価」は、同じ項目か。集計の時点（取り込みの時点と、画面を見た時点）が違わないか
- 途中に変換（丸め、集計の単位、対象の範囲）があるか。あるなら、その規則はどこに書かれているか
- 同じ上流で同じ時点なら、どの段階から値が変わっているかを、段階ごとの記録で辿れるか
- 来歴がないなら、まずこの 2 つの「案件原価」の来歴を書くことが最初の作業
「どちらが間違っているか」ではなく「どこで分かれたか」を問うのが、来歴の使い方です。分かれた場所が分かれば、直すのか、説明するのかを決められます。
7. よくある失敗
- 全項目の来歴を一度に書こうとして終わらない
- 人が書いた来歴が、連携の変更で古くなり、嘘の地図になる
- 変換の規則が処理の中にだけあり、文書になっていない
- 来歴を「監査のため」とだけ捉え、原因の調査に使わない
8. 成果物との接続
- DAT-008 データ系譜・品質ゲート定義：項目ごとの上流・変換・下流と、変換規則の参照。品質を止める仕組みも同じ文書に
- DAT-004 データ移行対応表：移行時の古い項目と新しい項目の対応。来歴の「上流」の出発点
9. AI WORKFLOW — 連携の定義から来歴の下書きを作らせる
AIは、連携の定義や変換の規則の文書から、項目ごとの上流・変換・下流を抜き出し、来歴の下書きを作るのに役立ちます。
指示例:
「次の連携の定義と変換規則の文書から、項目ごとに『上流のシステムと項目』『変換の内容』『下流のシステムと項目』を表にしてください。文書に書かれていない部分は空欄のまま示し、推測で埋めないでください。」
10. REVIEW — AIの下書きを確認する
- AIが抜き出した上流・下流が、連携の定義と一致しているか
- 空欄の部分を、連携の開発者と業務部門に確かめたか
- 連携の定義を AI に渡してよいか（相手の会社との守秘の扱い）を事前に確かめたか
11. 人間が判断すること
- どの項目から来歴を書くか
- 変換の意図と業務上の意味（人にしか書けない部分）
- 「合わない」数字について、来歴に基づいて説明するか、どちらかに合わせるか
12. 判断演習
「案件ごとの利益」という数字の来歴を考えてください。
上流（売上と原価はそれぞれどこから来るか）、変換（どう計算されるか、時点はいつか）、下流（誰がどの帳票や会議で使うか）を書いてください。そのうえで、「利益が合わない」と言われたとき、最初にどの段階を見るかを書いてください。
あなたの記録あなたの考え。事実ではありません
判断ノート
このユニットで覚えてほしいこと
数字は来歴で追う。上流・変換・下流を項目ごとに書き、自動で取れる部分を増やし、重要な項目から始める。「どちらが正しいか」ではなく「どこで分かれたか」を問う。