■ 1. 旧システムで直面した課題とDDD導入の背景
- 勤怠管理システムの複雑性: 勤怠システムは、法律や就業規則、企業ごとの勤務体系の違いなどにより、複雑なルールと例外が膨大に存在する。
- 旧システムの課題:
- 処理の不明確さ: 自作フレームワークをベースにしていたため、処理の所在が不明確であった。
- 深刻な属人化: 「この処理の正解は〇〇さんしか知らない」という状況が頻発し、知識が特定のベテランメンバーに偏っていた。
- 高い教育コスト: 新メンバーにとってコードと業務知識の紐付けが難しく、システム理解に大きなハードルがあった。
- DDD導入の目的: 「何をどこで処理しているのかが不明確」という最大の課題を解決するため、新システムのリニューアル時にDDD（ドメイン駆動設計）を採用した。
■ 2. DDD導入によるシステムの改善と属人化の解消
- ドメインの整理とモデル化: 「現実の勤怠の仕組みを、チーム全員が同じ言葉で説明できるようにする」というアプローチで、勤怠ドメインの整理とモデルへの落とし込みを行った。
- 代表的なモデルの例:
- 労働パターン: 勤務区分やカレンダーなど、勤怠計算に必要な設定を定義する。
- 打刻: 出退勤・休憩といった「事実」だけを表し、「遅刻」などの解釈は加えない。
- 勤務実績: 打刻や計算で計上された、その日の「働いた結果」を表現し、ユーザーへの表示に用いる。
- 休暇履歴: 有休の付与・取得・消滅をすべて履歴として積み上げることで、残日数を自動的に導けるようにし、値の正当性に関する懸念を解消する。
- 共通理解の促進:
- ユビキタス言語の活用: 「労働パターン」「打刻」「勤務実績」「休暇履歴」といったモデル名を指して会話できるようになり、以前の曖昧な表現を解消した。
- 属人化の解消: 知識がモデルに閉じ込められ、チーム全体で共有できるようになり、仕様確認やレビューがスムーズになった。
■ 3. 9年間の運用で実感したDDDの価値
- チーム知識の維持: DDDは「複雑な業務知識をチーム全体で維持し続ける仕組み」として機能した。
- 価値の具体例:
- 新メンバーの立ち上がり加速: 旧システムのように勤怠ドメインの理解に数カ月かかることはなくなり、「休暇履歴」などの用語ベースで理解できるようになった。
- 制度変更への柔軟な対応: 制度やルールの変更が発生した場合、該当モデルにルールを追加・修正するだけで対応できるようになった。
- 最終的な評価: 9年間の運用を経て、DDDは単なる設計手法ではなく、「複雑な勤怠ドメインをチームみんなで理解し続けるための心強い道具」であり、「あのときDDDを選んでよかった」と心から言える。