はじめに
「AIがコーディングをしてくれるこれからの時代、エンジニアにはドメイン知識がより重要になる」と言われることが増えました。
一方で、「ドメイン知識とは何か？」と聞かれると、意外と説明が難しい気がしています。
会計知識、労務知識、業界特有の業務フロー、自社独自の運用ルールなど、どれもドメイン知識と呼ばれます。しかし、その範囲が広いため、何を学ぶべきなのか整理しづらいことがあります。
そこでシステム開発におけるドメイン知識を「そのルールを誰が決めているのか」という観点で整理してみました。
1. 世界のルール
法律や制度など、外部によって定義されるルールです。
例:
- 法律
- 税制
- 会計基準
- 業界規制
- 公的制度
特徴:
- システムの外部に正解が存在する
- 自社の都合で変更できない
- 比較的安定している
例えば、会計ソフトを開発するなら会計基準を、人事労務システムを開発するなら労働関連法規を理解する必要があります。
2. 業界のルール
業界内で共有されている概念・用語・業務フローです。
例:
- EC: カート、注文、出荷、返品、SKU、在庫引当
- 飲食: 席、来店、予約台帳、コース予約、席回転
- 人事労務: 入社、退社、雇用契約、勤怠、打刻
特徴:
- 法律ほど厳密ではない
- 業界参加者の共通認識として存在する
- 時代とともに変化する
「その業界でシステムを作るなら当然知っている前提の知識」と考えるとわかりやすいです。
3. 企業のルール
企業独自のビジネスモデルや業務運用によって定義されるルールです。
例:
- 商品や顧客の定義
- 承認フロー
- 料金体系
- ポイント付与ルール
- 各種例外運用
特徴:
- 自社で決定・変更できる
- 他社との差別化要因になりやすい
- システム固有の複雑さを生みやすい
ドメイン知識は何から学ぶべきか
まず世界のルールがあり、その上に業界のルールがあり、さらにその上に企業固有のルールが存在します。
そのため、ドメインを理解する順序としては、
- 世界のルール
- 業界のルール
- 企業のルール
が自然に思えます
例えば会計システムであれば、会計基準を知らずに業界慣習を理解することは難しいですし、業界慣習を知らずに個社特有の運用を理解することも難しいでしょう。
システムの複雑さはどこから生まれるのか
一方で、システム開発における複雑さの源泉は別の場所にあるように思います。
法律や制度には外部に正解があります。業界慣習にもある程度の共通認識があります。
しかし企業固有のルールには外部の正解がありません。
事業の成長や運用上の事情によって変化し続けますし、例外も増えていきます。そのためシステムの複雑さは、企業固有のルールから生まれることが多いように感じます。
つまり、
- 学ぶ順序は「世界 → 業界 → 企業」
- 複雑さの源泉は「企業 → 業界 → 世界」
と言えるかもしれません。
おわりに
ドメイン知識と言うと、法律や業界知識をイメージすることが多いかもしれません。
しかし実際の開発現場で向き合うのは、それらを前提とした企業固有のルールであることも少なくありません。
AIがコードを書く時代になったとしても、「そのシステムは何を解決するのか」「その会社はなぜそのルールを持っているのか」を理解することの価値はむしろ高まるのではないかと思います。
ドメイン知識について考える際は、「世界のルール」「業界のルール」「企業のルール」のどこに属する話なのかを意識すると、少し整理しやすくなるかもしれません。
