Data Architecture
韓国と日本をひとつのシステムで運営するための構造です。物件プロファイルがルールを持ち、料金は行として立ち、台帳の上に分析層が別に立ちます。
Principle
国ごとの違いは条件分岐ではなく物件プロファイルに持たせます。物件ごとに下の9つを指定すれば、ルールがついてきます。だから韓国と日本がひとつのシステム・ひとつの台帳で回ります。
| プロファイル | 韓国 | 日本 |
|---|---|---|
| 請求サイクル | 暦月 | サイクル — 入居日を基準に翌月同日の前日まで |
| 長期／短期の判定 | 契約月数 | サイクル6個以上で長期。最初の契約時に1回だけ判定し、更新しても再判定しません |
| 日割りの分母 | その月の実日数 | 長期＝実日数／短期の最終残余＝28日固定 |
| 請求のタイミング | 毎月の支払期限日 | 入居月＝当月日割＋翌月分を同時／以降は前月1日／3サイクル未満は一括 |
| 更新手数料 | なし（協議） | 更新後賃料の10%・長期のみ（免除交渉は可能） |
| 法定届出 | 賃貸借届出の対象 | 該当なし — 韓国の制度です。日本の契約にはこのステップが生まれません |
| 入居可能時点 | 整備リードタイム D+n | 退去+7日 |
| 新規募集の開始 | 満了 D-60 | 退去予定日の1ヶ月前 |
| 中途解約の違約金 | なし | 長期＝2サイクルの通知／それ以内の退去は2サイクル分（その期間の賃料は二重請求しません）・短期＝残期間全額 |
サイクルが最大の違いです。 暦月とは別の軸なので、画面ではなく計算エンジンが分かれます。物件プロファイルを見ずに実装すると、二国のうち必ずどちらかが間違います。
Hierarchy
「拠点」と呼んでいたものは物件のブランド名であり、その上に法人・エリア・投資家・建物の階層が抜けていました。
Tables
マスター・台帳・イベントを区別します。台帳は事実を積み、イベントはその事実がいつ・なぜ変わったかを残します。
v5
期間区分は物件ごとに異なり、数も違います — 韓国2区分・日本3区分。列にすると区分が増えるたびに列を追加することになり、物件ごとに異なる数を持てません。
| 区分 | 期間 | 敷金 | 支払 |
|---|---|---|---|
| 超短期 | 3ヶ月以下 | なし | 一括（全額前払い） |
| 短期 | 3ヶ月超〜6ヶ月未満 | なし | 3ヶ月分前払い後に月払い |
| 長期 | 6ヶ月以上 | 賃料1ヶ月分 | 敷金＋賃料前払い後に月払い |
日本基準の例です。区分の境界は「最小以上〜最大未満」ひとつに固定しています — 含むかどうかを区分ごとに決めさせると、「6ヶ月」がどこに属するのか誰も確信できなくなります。
⚠ 号室テーブルに料金の列をつくらないでください。 つくると物件が増えるたびにマイグレーションが必要になります。 日本は価格が2段なのに支払方式が3段で、列方式では3つ目の境界を置く場所がありませんでした。
Ledger
PostgreSQLのマイグレーション29件で立っています。運営システムが使うテーブルと分析が読むテーブルが、同じ台帳を見ます。
Policies
スキーマだけでは台帳になりません。以下はコードではなくポリシー文書として固定されています。
OBSERVED（実測）とDERIVED_FROM_CONTRACT（契約由来）を区別します。稼働率は契約ではなく実際の稼働日から出ます。通貨は法人から継承されます。 物件と取引がそれぞれ決めると必ず食い違います。画面の合計も
¥55,196,240 · 79,909万ウォンのように分けて出します — 換算してひとつの行にすると、その為替レートがそのまま根拠のない数字になります。
Analytics
指標を画面で計算しません。系譜があり、各段階にデータテストが掛かります。
データテスト8種 — 稼働率の範囲検証・ブロック号室の稼働禁止・平均賃料の順序・タイムゾーンの妥当性ほか。