まずはコードより業務と向き合う：テーブル解体のためにPdMを呼んだ話

CodMon Tech Talk #7
https://codmon.connpass.com/event/405781/

コドモンのDB負荷対策チーム、こんなかんじでやってます！

長年運用されてきた巨大な汎用テーブルの解体、レスポンスの悪い機能の改善…「手をつけるべきだ」と分かっていつつも、影響範囲の広さやリスクの高さから、なかなか一歩を踏み出せずに悩んでいるチームも多いのではないでしょうか。

コドモンの汎用テーブル解体ではコードやテーブルを置き換えるだけでなく、PdMも交えてユースケースを洗い出し、必要なデータの単位を見極めたり、各所に散らばっていたデータアクセスをリポジトリ層に集約したりと、あるべき姿を目指して試行錯誤しながら進めています。

汎用テーブル解体も3周目。そのドメイン理解フェーズの事例をご紹介します。

テーブル解体の具体的な流れやつまづきポイントについては以下のブログやスライドをご参照ください。

・汎用テーブルの解体を安全に進めるために
・汎用テーブルがもたらす副作用とその対処
・システム成長を止めない！本番無停止テーブル移行の全貌

Transcript

1. Tech Talk #7 コドモンのDB負荷対策チーム、こんなかんじでやってます！ まずはコードより業務と向き合う テーブル解体のためにPdMを呼んだ話 株式会社コドモン プロダクト開発部 さかうぇ 2026年10月13日
2. 今日は話さないこと • テーブル解体の具体的な流れは、こちらの記事やスライドをご覧ください！ 最後にQRコードを載せておきます CoDMON Product Team Blog 汎用テーブルの解体を安全に進めるために by. テックリード中田さん PHPカンファレンス2025 システム成長を止めない！ 本番無停止テーブル移行の全貌 by. さかうぇ 2
3. 今日、お話しすること • テーブル解体の実装フェーズの前の話 Step1. 事前調査（ドメイン理解の取り組み）・テスト拡充 事前調査・テスト拡充 Step2. 二重書き込み 約６か月間 Step3. データ移行 Step4. 参照切り替え Step5. 旧テーブルのデータ削除 ←イマココ 3
4. 目次 • 前提 • テーブル定義を決めるために • ドメインモデリング • 新テーブル定義 • そして実装フェーズへ • まとめ 4
5. 前提: テーブルの概要 • commentsテーブル 種別A. 職員の承認コメント 種別B. 保護者からの連絡 種別C. 連絡帳 種別D. 健康チェック 種別E. 食事チェック 種別F. ...... 何でも入っている、まさに「汎用テーブル」 5
6. 前提: テーブルの概要 • commentsテーブル 種別A. 職員の承認コメント 種別B. 保護者からの連絡 種別C. 連絡帳 種別D. 健康チェック 種別E. 食事チェック 種別F. ...... 健康チェック・食事チェックを分離すれば 現行テーブルのデータ量は６割程度になる 6
7. 前提: チームメンバーの理解度 • そこまで詳しくない… • • テックリード 2名 エンジニア 3名 打刻や請求系、保護者アプリは詳しいが、 健康チェックと食事チェックはそれほど詳しくない… • わかっていたこと • • • 健康チェック：排便記録、検温記録、午睡記録 の3種類ある 食事チェック：給食やおやつをどのくらい食べたか記録する いずれも日ごと・園児ごとに記録される 7
8. ◯：必要カラム △：判断できなかったカラム ✕：不要なカラム 前提: comments テーブルとは id PK PK PK PK PK 種別 健康チェック 食事チェック 連絡帳 保護者からの連絡 承認者コメント 紐づくID 子どもの ID 子どもの ID 子どものID 子どものID お知らせのID 日付 ◯ ◯ ◯ ◯ ◯ 本文(json形式) ◯ ◯ ◯ ◯ ◯ 公開ステータス △ △ ◯ ◯ ✕ 公開日時 △ △ ◯ ✕ ◯ 既読フラグ △ △ ◯ ✕ ✕ メールステータス △ △ ◯ ✕ ✕ 通知ステータス △ △ ◯ ✕ ✕ 画像パス △ △ ◯ ✕ ✕ 作成日時・更新日時 ◯ ◯ ◯ ◯ ◯ 削除フラグ △ △ ◯ ◯ ◯ 8
9. 目次 • 前提 • テーブル定義を決めるために • ドメインモデリング • 新テーブル定義 • そして実装フェーズへ • まとめ 9
10. テーブル定義を決めるために • 新テーブル定義の課題 • 必要なカラムに絞りたい → 不要な項目の判断が難しい 🤔 • 現行は重複データを許容 → ユニーク制約を追加したい 🛡 • 食事チェックは給食・献立管理との連携がある → 給食管理がとにかく複雑で、コードから全てを把握するのは困難 • そもそも、健康チェック・食事チェックのドメイン理解が浅い？ 10
11. テーブル定義を決めるために • 新テーブル定義の課題 • 必要なカラムに絞りたい → 不要な項目の判断が難しい テーブル制約は • まず業務を知って ビジネスルールに → ユニーク制約を追加したい 現行は重複データを許容 • 食事チェックは給食・献立管理との連携がある 理解するべきでは？ → 給食管理がとにかく複雑で、コードから全てを把握するのは困難 • action そもそも、健康チェック・食事チェックのドメイン理解が浅い？ 直結するものである 必要な機能を プロダクトマネージャーを呼んで 健康チェック・食事チェックの ドメインモデリングをする 11
12. ドメインモデリングと新テーブル 事前準備〜当日 • エンジニアだけで画面操作を確認しておいた • PdMと一緒に「誰が、いつ、どう使うか」を確認しながら ドメインモデル図を作成 12
13. 目次 • 前提 • テーブル定義を決めるために • ドメインモデリング • 新テーブル定義 • そして実装フェーズへ • まとめ 13
14. ドメインモデリング: 画面操作を確認して準備 14
15. ドメインモデリング: 健康チェックのわかったこと • 午睡チェックの重要性 • • • 乳幼児の午睡時間中の事故を防ぐのが目的 公的なガイドラインに5~10分ごとに1回、 子どもの様子を確認・記録する必要があると記載あり うつ伏せの場合は仰向けに直してそれも記録する ➡ 午睡の時間帯は頻繁に記録が行われる特性がある • 検温・排便記録の形式 • • 時間ごとの記録のみ、開所中は比較的満遍なく更新される 午睡データと同じカラムに JSON形式 で記録される 15
16. ドメインモデリング: 食事チェックのわかったこと • 主に給食の喫食量を記録する機能 • • • 日中のおやつ の 食べた/食べなかった 延長保育時の軽食 の 食べた/食べなかった ミルクの量 ➡ これも同じカラムに JSON形式 で保存される • 給食管理機能との連携 • 給食管理機能 から 写真などを 食事チェック に一括登録 • 献立更新時に 登録済みの食事チェックを上書き・リセットする ➡ 機能をまたいで食事チェックデータを更新される複雑さ 16
17. ドメインモデリング • ドメイン名は「デイリーチェック」 • 主な目的は、子どもたちの安全と 健康、成長のためのチェックと記録 • 当日のお子さまの様子を保護者に伝える、 連絡帳の元になるデータでもある • 健康チェック・食事チェックを 日々の記録としてまとめる方向で PdM とも合意できました 17
18. 目次 • 前提 • テーブル定義を決めるために • ドメインモデリング • 新テーブル定義 • そして実装フェーズへ • まとめ 18
19. 新テーブル定義 id PK PK 種別 健康チェック 食事チェック 関連種別 子ども 子ども 関連種別ID 子どものID 子どものID 日付 ◯ ◯ 本文(json形式) json json 公開ステータス △ △ 公開日時 △ △ 既読フラグ △ △ メールステータス △ △ 通知ステータス △ △ 画像パス △ △ 作成日時・更新日時 ◯ ◯ 削除フラグ ◯ ◯ • 新テーブル定義 UK • • • • • id 子どものID 日付 本文(json形式) 作成・更新日時 19
20. 目次 • 前提 • テーブル定義を決めるために • ドメインモデリング • 新テーブル定義 • そして実装フェーズへ • まとめ 20
21. そして実装フェーズへ あれから半年… • 汎用APIから、健康チェック・食事チェックの 専用APIを切り出し • リポジトリをまたいで散らばっていた データアクセスを１箇所に集約 • フィーチャートグルを活用して 小さくリリース ➡今週、現行テーブルの書き込み・参照共に完全に停止予定 👏👏👏 CoDMON Product Team Blog 「汎用テーブルの解体を安全に進めるために」 21
22. まとめ 22
23. コドモンのテーブル解体とは 単に汎用テーブルからデータを分離する作業 ではなく 「何が本当に必要なデータなのか」を突き止め、 「本来あるべき姿に近づける」作業 である CONFIDENTIAL - © 2022 CoDMON Inc. 23 23