第4回：データベース連携を見据えた構造化
目次
実践編その3：将来を見据えたデータ管理
はじめに
これまで、データ入力の最適化（第2回）と使いやすいフォーム設計（第3回）について解説してきました。今回は、収集したデータをいかに構造化して管理し、将来的なデータベースへの移行に備えるかという、より戦略的なテーマを扱います。
「なぜExcelでデータベースのことを考える必要があるの？」と思われるかもしれません。しかし、不動産データが年々蓄積され、より高度な分析や複数拠点での共有が必要になったとき、適切に構造化されていないExcelデータは大きな負債となってしまうのです。
1. Excelテーブル機能の活用
なぜ「テーブル」機能が重要なのか
Excelの「テーブル」は、単なる見た目の装飾ではありません。データをデータベースのテーブルのように扱える、強力な機能です。
通常の範囲 vs テーブルの違い
【通常の範囲】
A1: 物件ID B1: 物件名 C1: 所在地
A2: P001 B2: 中央ビル C2: 東京都中央区
A3: P002 B3: 港ビル C3: 東京都港区
【テーブル化後】
同じデータが「tbl物件マスター」という名前の
構造化されたオブジェクトとして管理されるテーブル化の手順と効果
1. テーブルの作成
手順：
1. データ範囲を選択（見出し行を含む）
2. 挿入タブ → テーブル
3. 「先頭行をテーブルの見出しとして使用する」にチェック
4. テーブル名を設定（例：tbl物件マスター）2. テーブルがもたらす恩恵
① 自動拡張
新しい行を追加すると、自動的にテーブルに含まれる
→ 数式や書式も自動適用
② 構造化参照
=VLOOKUP([@物件ID], tbl点検履歴, 2, FALSE)
→ セル参照（A2など）より分かりやすい
③ 自動フィルター
各列に▼ボタンが表示され、簡単に絞り込み可能
④ 集計行
テーブルの最下部に合計、平均などを簡単追加不動産データでの実践例
物件マスターテーブルの構築
tbl物件マスター
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
物件ID | 物件名称 | 所在地 | 構造 | 階数 | 延床面積 | 建築年
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
P001 | 中央ビル | 東京都...| RC造 | 10 | 2500 | 1995
P002 | 港ビル | 東京都...| S造 | 8 | 1800 | 2000
P003 | 渋谷ビル | 東京都...| SRC造| 15 | 5000 | 2010
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━構造化参照の活用例
# 物件名称から延床面積を取得
=INDEX(tbl物件マスター[延床面積],
MATCH("中央ビル", tbl物件マスター[物件名称], 0))
# 2000年以降の物件の平均面積
=AVERAGEIF(tbl物件マスター[建築年], ">=2000",
tbl物件マスター[延床面積])2. データベース設計原則の適用
1行1レコード、1セル1データの原則
悪い例：
A列: 物件名
B列: 点検履歴（2023/4/1:適合、2023/10/1:適合、2024/4/1:要是正）
C列: 担当者（山田、田中、山田）良い例：
物件テーブル：
物件ID | 物件名
P001 | 中央ビル
点検テーブル：
点検ID | 物件ID | 点検日 | 結果 | 担当者
I001 | P001 | 2023/4/1 | 適合 | 山田
I002 | P001 | 2023/10/1 | 適合 | 田中
I003 | P001 | 2024/4/1 | 要是正 | 山田主キー概念の導入
主キーとは、各レコード（行）を一意に識別するための値です。
主キーの設計原則
良い主キー：
✓ 一意である（重複しない）
✓ 変更されない
✓ NULL（空）にならない
✓ できるだけ短い
実装例：
物件ID: P001, P002, P003...
点検ID: I20240001, I20240002...
契約ID: C2024-001, C2024-002...Excelでの主キー管理
# 自動採番の実装（A列が物件ID）
=IF(B2="", "", "P" & TEXT(COUNTA($B$2:B2), "000"))
# 重複チェックの入力規則
データ入力規則 → ユーザー設定
数式：=COUNTIF($A:$A, A2)<=1
エラーメッセージ：「このIDは既に使用されています」データの正規化
正規化とは、データの重複を排除し、整合性を保つための設計手法です。
第一正規形：繰り返し項目の排除
【Before：非正規形】
物件ID | 物件名 | 点検1日付 | 点検1結果 | 点検2日付 | 点検2結果
P001 | 中央ビル| 2024/4/1 | 適合 | 2024/10/1| 適合
【After：第一正規形】
物件テーブル：
物件ID | 物件名
P001 | 中央ビル
点検テーブル：
点検ID | 物件ID | 点検日付 | 点検結果
I001 | P001 | 2024/4/1 | 適合
I002 | P001 | 2024/10/1 | 適合第二正規形：部分関数従属の排除
【Before】
点検ID | 物件ID | 物件名 | 物件住所 | 点検日
I001 | P001 | 中央ビル | 東京都中央区... | 2024/4/1
【After】
物件マスター：
物件ID | 物件名 | 物件住所
P001 | 中央ビル | 東京都中央区...
点検記録：
点検ID | 物件ID | 点検日
I001 | P001 | 2024/4/13. テーブル間のリレーションシップ
外部キーによる関連付け
外部キーは、他のテーブルの主キーを参照するフィールドです。
【実装例：物件と点検の関連】
tbl物件マスター：
物件ID（主キー） | 物件名称 | 所在地
P001 | 中央ビル | 東京都中央区
P002 | 港ビル | 東京都港区
tbl点検記録：
点検ID（主キー） | 物件ID（外部キー） | 点検日 | 結果
I001 | P001 | 2024/4/1 | 適合
I002 | P001 | 2024/10/1| 要是正
I003 | P002 | 2024/4/1 | 適合VLOOKUPによるデータ結合
# 点検記録に物件名を表示
=VLOOKUP([@物件ID], tbl物件マスター, 2, FALSE)
# より柔軟なINDEX/MATCH
=INDEX(tbl物件マスター[物件名称],
MATCH([@物件ID], tbl物件マスター[物件ID], 0))多対多関係の実装
例：複数の所有者が複数の物件を所有するケース
tbl物件マスター：
物件ID | 物件名称
P001 | 中央ビル
P002 | 港ビル
tbl所有者マスター：
所有者ID | 所有者名 | 連絡先
O001 | 山田商事 | 03-1234-5678
O002 | 田中不動産| 03-9876-5432
tbl物件所有者（中間テーブル）：
物件ID | 所有者ID | 所有割合
P001 | O001 | 60%
P001 | O002 | 40%
P002 | O002 | 100%4. データベース移行への準備
データクレンジングの重要性
データベース移行前に、Excelデータを「きれい」にする必要があります。
1. 表記揺れの統一
# SUBSTITUTE関数で統一
=SUBSTITUTE(SUBSTITUTE(A2,"(株)","株式会社"),"㈱","株式会社")
# 住所の正規化
東京都港区赤坂１－２－３ → 東京都港区赤坂1-2-32. 空白データの処理
# 空白を統一的な値に変換
=IF(ISBLANK(A2), "未入力", A2)
# TRIMで余分な空白を削除
=TRIM(A2)3. データ型の統一
# 日付の統一（TEXT関数）
=TEXT(A2, "yyyy/mm/dd")
# 数値の統一（VALUE関数）
=VALUE(SUBSTITUTE(A2, ",", ""))データマッピングシートの作成
移行時の対応関係を明確にします：
データマッピング表
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Excel列名 | データ型 | DB列名 | DBデータ型 | 変換規則
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
物件ID | 文字列 | property_id | VARCHAR(10)| そのまま
物件名 | 文字列 | property_name| NVARCHAR(100)| トリム
建築年月 | 日付 | built_date | DATE | yyyy/mm/dd形式
延床面積 | 数値 | total_area | DECIMAL(10,2)| 小数点2桁
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━5. 実践的な構造化の例
ケーススタディ：法定点検管理システム
実際の不動産管理で必要な法定点検管理を例に、構造化を実践してみましょう。
要件：
- 複数の物件を管理
- 各物件で複数種類の法定点検を実施
- 点検履歴と次回予定を管理
- 点検業者情報も管理
テーブル設計：
1. tbl物件マスター
物件ID | 物件名称 | 所在地 | 管理会社ID | 築年数
2. tbl点検種別マスター
点検種別ID | 点検種別名 | 法定周期（月） | 根拠法令
3. tbl点検業者マスター
業者ID | 業者名 | 連絡先 | 資格情報
4. tbl点検実施記録
点検ID | 物件ID | 点検種別ID | 実施日 | 業者ID | 結果 | 次回予定日
5. tbl指摘事項
指摘ID | 点検ID | 指摘内容 | 重要度 | 対応状況 | 対応期限リレーションシップ図：
物件マスター ←─┐
├─→ 点検実施記録 ←─→ 指摘事項
点検種別 ←──────┤
│
点検業者 ←──────┘6. Power Queryを使った高度なデータ管理
ExcelのPower Query機能を使うと、より高度なデータ管理が可能です。
基本的な使い方：
1. データタブ → データの取得 → その他のデータソースから
2. 複数のテーブルを結合
3. データの変換・クレンジング
4. 更新可能なクエリとして保存実装例：月次点検レポートの自動生成
// Power Query M言語の例
let
// 点検記録を読み込み
点検データ = Excel.CurrentWorkbook(){[Name="tbl点検記録"]}[Content],
// 物件マスターと結合
物件結合 = Table.NestedJoin(点検データ, {"物件ID"},
tbl物件マスター, {"物件ID"},
"物件情報", JoinKind.Left),
// 当月のデータのみフィルター
当月フィルター = Table.SelectRows(物件結合,
each Date.Month([実施日]) = Date.Month(DateTime.LocalNow())),
// 必要な列を展開
結果 = Table.ExpandTableColumn(当月フィルター, "物件情報",
{"物件名称", "所在地"})
in
結果実装による効果測定
ある不動産管理会社での実装結果：
実装前の課題：
- データの重複入力：月間40時間
- 集計作業：月次レポート作成に8時間
- データ不整合によるトラブル：月3〜5件
実装内容：
- 全データをテーブル化
- 正規化による構造の最適化
- リレーションシップの確立
- Power Queryによる自動集計
実装後の成果：
- 重複入力：ほぼゼロ（95%削減）
- 集計作業：30分（94%削減）
- データ不整合：月0〜1件（80%削減）
- 追加効果：データ分析が容易になり、新たな改善点を発見
将来のデータベース移行シミュレーション
構造化されたExcelデータは、スムーズにデータベースへ移行できます：
移行前（構造化なし）：
- データクレンジング：80時間
- テーブル設計：40時間
- 移行作業：60時間
- 検証・修正：100時間
- 合計：280時間
移行前（構造化済み）：
- データクレンジング：10時間（既に実施済み）
- テーブル設計：5時間（Excel構造を流用）
- 移行作業：20時間
- 検証・修正：15時間
- 合計：50時間（82%削減）
まとめ：構造化がもたらす価値
データベースを見据えた構造化は、以下の価値をもたらします：
- 現在の業務効率化
- データの一元管理
- 重複入力の排除
- 高速な検索と集計
- データ品質の向上
- 整合性の確保
- エラーの削減
- 監査対応力の向上
- 将来への投資
- スムーズなシステム移行
- 拡張性の確保
- データ資産の価値向上
次回、最終回では「運用管理と継続的改善」について解説します。せっかく構築した仕組みを、どのように運用し、改善していくか。バージョン管理から効果測定まで、実践的なアプローチをご紹介します。
