「データが遅いんです」「いえ、それ多分データの話じゃないです」

データ構造の設計・診断は、次の4層に分けて考えると全体を一気通貫で語れます。1つの層だけを見て「テーブル設計が悪い」と決めつけると、的外れな提案（遅いのに正規化を追加する等）につながります。

ここで先に反論しておきます。「症状を見れば原因くらい分かるのでは」と思うかもしれません。ですが、「遅い」という同じ症状の裏に、正規化不足・インデックス不足・そもそもの概念設計の見落としという、まったく別の原因が潜んでいることは珍しくありません。症状名だけで対処すると、発熱の原因を確かめずに解熱剤だけ出すような対応になりがちです。

案件でデータ構造の相談を受けたら、まず「今どの層の問題か」を切り分けます。

「同じ情報が複数箇所にあって食い違う」

疑うべきは第2層（論理設計・正規化不足）

「検索・集計が遅い」

疑うべきは第3層（物理設計・インデックス/非正規化）

「新しい業務要件を既存DBに追加できない」

疑うべきは第1層（概念設計・ERの見直し）

「分析・BIで欲しい切り口が出せない」

疑うべきは第4層（分析活用・ディメンショナルモデリング不足）

相談を受けた際、症状を1行ずつ記録しながら層を切り分けるフォーマットです。

「GTMエンジニアリングの3層モデル」の自己診断が扱う4層分類（データが無い／繋がっていない／解釈できない／解釈できるが動けない）は、この4層モデルとは異なる軸です。データ構造の4層モデルは「どう構造化するか」、診断の4層分類は「部門横断でどこが機能不全か」を見ています。両者は直交する軸として併用できます。

例えば、「営業ダッシュボードの数字が部署によって食い違う」という相談を受けたとき、いきなりBIツールの設定を疑うのではなく、まず第2層（同じ顧客情報がSFAと請求システムに別々に存在していないか）を確認する、という順序で切り分けると手戻りが減ります。受託の提案力は、この4層を一気通貫で語れるかどうかで決まります。ER図やテーブル定義だけを見せても、クライアントには「業務がどう楽になるか」が伝わりません。

専門家を呼ぶ前に、自分たちで4層を順番にチェックする実務的な手順です。

この4ステップで「どの層が原因か」の当たりがつけば、対策の優先順位を間違えずに済みます。層をまたいで同時に手を付けようとすると、原因の切り分けができなくなるため避けてください。

正規化はどこまで進めればいいですか

実務上は第3正規形程度が目安とされています。正規化しすぎるとJOINが増えて読み取り性能が落ちるため、分析用途では意図的に非正規化する判断も必要です。「正規化＝常に正義」ではなく、更新異常を防ぐ目的と性能要件のバランスで決めます

業務系DBのER設計を、そのままBI・分析基盤に流用してよいですか

一般的には推奨されません。業務系は更新の整合性を優先した構造、分析基盤は集計のしやすさを優先した構造（スタースキーマ等）で、最適な形が異なります。業務系のテーブルをそのままBIに接続すると、欲しい切り口の集計が出せない事態が起きやすくなります

「検索が遅い」と言われたら、まず何を疑うべきですか

概念設計や論理設計の見直しから入るのは非効率です。まず第3層（物理設計）のインデックス設計・非正規化の余地を確認し、それでも解決しない場合に上位層（正規化・ER設計）を疑う、という順序が的外れな提案を避けるコツです

新しい業務要件が出るたびにテーブルを作り変える必要がありますか

多くの場合、原因は第1層（概念設計）の実体・関係の見落としにあります。業務フロー・帳票から名詞（実体候補）を洗い出す工程を最初に丁寧に行っておくと、後から要件が追加されてもテーブル構造の破壊的な作り変えを避けやすくなります

直近で「データの問題」として相談されたことを1つ思い出してください。それは本当にデータ構造の問題だったでしょうか。それとも、4層のどこか——概念設計・論理設計・物理設計・分析活用——のうち、まだ名前をつけて切り分けていないだけの症状だったでしょうか。