やったこと
- ST環境に最新コード反映、動作確認
- モノレポリリースフローの設計変更（ローカル→ST→本番の段階的切り替え）
- 本番は別パスで先行リリース → 安定確認後にDNS切り替えの方針
- ローカルDB構築完了、データ投入確認済み
- 英語勉強会: static/dynamic languages, classification vs category
学んだこと・ナレッジ
ビジネスモデルキャンバス（BMC）の基本
事業の全体像を9ブロックで整理するフレームワーク。「誰に・何を・どう届けて・どう稼ぐか」を1枚で可視化する。
- 埋める順番は右（顧客）から左（自社）へが定石
- 「この人が困っている→だからこれを作る」の順番。技術起点で考えると誰も欲しがらないものができる
- うちのプロダクトのフォームはレイアウト順（左上から）になっている → 改善余地あり
BMCの9ブロックをDB分割するメリット
現状: 全ブロックを1つのJSONカラムに格納。分割した場合:
- 変遷が追える: ブロックごとにHistoryテーブルを持てば、顧客セグメントの変更履歴（個人→法人など）が記録できる。JSONだと全体丸ごと保存で差分が取れない
- AIが矛盾を指摘できる: 顧客セグメントが「法人」なのにチャネルが「Instagram広告」→ AIが整合性チェック
- ダッシュボードで成長が見える: ブロック別の成熟度やピボット記録を可視化
ドメイン知識なしにテーブルは設計できない
BMCの構造も使われ方も知らずにDB設計をしていた。9ブロックにはそれぞれ意味があり、ユーザーは右から左へ埋め、時間とともに変わっていく。「どう使われるか」を知らなければ、JSONで十分かテーブルを分けるべきか判断できない。