Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
エンジニアはドメイン知識とどう向き合うべきか?
Search
GO Inc. dev
May 15, 2026
41
1
Share
エンジニアはドメイン知識とどう向き合うべきか?
https://techblog.goinc.jp/entry/2026/05/15/150901
GO Inc. dev
May 15, 2026
More Decks by GO Inc. dev
See All by GO Inc. dev
ちょっとだけ踏み込んだ ダイナミックプライシング 〜オンデマンド交通への拡張〜
mot_techtalk
1
62
MySQL, PostgreSQLのオブザーバビリティをGrafanaで向上させた話
mot_techtalk
2
720
タクシー車両の位置状態情報を支えるシステムのインフラ構成
mot_techtalk
2
750
SREの視点で挑む Redis Stream 無停止移行
mot_techtalk
2
720
生成AIで社内データを整備しよう
mot_techtalk
1
270
GO Tech Talk #31 タクシーアプリ『GO』におけるNext.jsの活用
mot_techtalk
2
650
大規模基幹サーバーに gRPCを導入した過程での学び
mot_techtalk
2
79
大規模アプリのDIフレームワーク刷新戦略 ~過去最大規模の並行開発を止めずにアプリ全体に導入するまで~
mot_techtalk
1
640
GPT-5と寿司合戦を攻略する
mot_techtalk
1
190
Featured
See All Featured
A brief & incomplete history of UX Design for the World Wide Web: 1989–2019
jct
1
370
Believing is Seeing
oripsolob
1
120
Introduction to Domain-Driven Design and Collaborative software design
baasie
1
770
Art, The Web, and Tiny UX
lynnandtonic
304
21k
The #1 spot is gone: here's how to win anyway
tamaranovitovic
2
1k
svc-hook: hooking system calls on ARM64 by binary rewriting
retrage
2
240
Reflections from 52 weeks, 52 projects
jeffersonlam
356
21k
The untapped power of vector embeddings
frankvandijk
2
1.7k
The Straight Up "How To Draw Better" Workshop
denniskardys
239
140k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
32
2.9k
How to build a perfect <img>
jonoalderson
1
5.5k
YesSQL, Process and Tooling at Scale
rocio
174
15k
Transcript
© GO Inc. 登壇向け エンジニアは ドメイン知識と どう向き合うべきか? 2026.05.07 次世代事業本部 GX統括部
GXシステム開発部 / 武田 峻輔 GO株式会社
© GO Inc. 2度の転職で直面した「ドメイン知識の壁」 2 毎回ぶつかる、逃れられないつらみ ビジネス⽤語の迷宮 専⾨⽤語が⾶び交い、 会話についていけない ドメイン知識が難解
業界特有のルールが複雑で 理解が追いつかない 仕様が複雑すぎる 関連する要素が多く、 全体像が⾒えない 「なんとなく」の実装 本質を理解せず、表⾯的なコード を書いてしまう
© GO Inc. エンジニアの仕事における ドメイン知識の立ち位置 現実世界をコードに変換するための「材料」 現実世界 ドメイン知識 モデル コード
ドメイン知識は、抽象的な現実を具体的なロジックに変える架け橋
© GO Inc. 「勉強」の罠にハマり、実装が⽌まる やったこと 業界本を読み漁る 社内資料を全部読む ⽤語集を作る 結果 量が多すぎて終わらない
実装が進まない とにかく「つらい」 ドメイン知識 = 暗記すべきもの という誤解 アンチパターン①:全部覚えようとする
© GO Inc. アンチパターン②:実装優先で突き進む 「理解」を後回しにし、負債を積み上げる やってしまったこと 既存コードをコピペ 中⾝を理解せず「動けばいい」と考える なんとなく動くものを作る 仕様の曖昧さをコードで誤魔化す
後で直せばいいと考える その「後」は永遠に来ない THE RESULT モデルが崩壊する 後から理解不能になる 修正コストが爆発する もっとつらい
© GO Inc. 結論:ドメイン知識は「覚えるもの」ではない 覚えるもの ではなく 整理するもの エンジニアの本質は「翻訳者」 曖昧な現実を、厳密なコードへ 整理された知識は最強の設計指針
TRANSLATOR
© GO Inc. 対策①:最低限の「地図」だけを持つ 全部を覚えず、業務の前提を理解する 基礎知識は得るが、深⼊りしない ⾦融ならFP/証券外務員資格、⼩売なら店舗運営の概要など、 議論の⼟台となる共通認識を優先する。 現場の「空気感」を知る ニトリの店舗研修のように、ユーザーがどのような環境で
システムを使うかを知る。 「地図」があれば迷わない 詳細はその都度調べればいい。 今どこにいるか、どこへ向かうかだけ把握する。 「全部覚える」は不可能。 「地図を持つ」は戦略。 https://xtech.nikkei.com/atcl/nxt/column/18/02286/012600009/
© GO Inc. 対策②:用語を徹底的に揃える 同じ概念には同じ名前を使う。これが設計の命。 ⽤語のズレは、 モデルと実装のズレ ビジネスと⾔葉を 1ミリもズラさない 曖昧な⾔葉を
徹底的に排除する ⾦融ドメインの例 ⼀般的考え⽅ 注⽂ = 取引成⽴ VS 実際のドメイン 注⽂ (Order) 約定 (Execution) ⽤語の整理 = モデルの整理
© GO Inc. 対策③:業務の「構造」をモデルに落とす 業務の流れ = コードの構造 業務には「構造」がある 単なるデータの集まりではなく、 そこには不可逆な流れや依存関係が存在する。
構造をそのままコードにする 業務プロセスを観察し、その関係性を クラスやDBの関連として忠実に再現する。 変更に強い設計へ 業務ルールが変わった際、コードのどこを 直すべきかが明⽩になり、負債化を防げる。 ⾦融ドメインのモデル例 Order Execution Position Balance Execution
© GO Inc. 対策④:ドメインの「境界」を意識する 学習コストを削減し、担当範囲を深掘りする ドメインは広すぎる ビジネスの全容を⼀度に理解しようとするのは⾮効率。 まずは⾃分の「担当範囲」を定める。 コンテキストを絞る 決済担当なら「決済」を深く、⼝座管理は「概要」だけでOK。
境界を引く勇気を持つ。 境界が設計をシンプルにする 境界を意識することで、モデルの責務が明確になり、コード の結合度を下げることができる。 ⼝座管理 顧客管理 決済ドメイン DEEP DIVE
© GO Inc. まとめ:ドメイン知識を味方につける 01 覚えようとしない 最低限の「地図」だけを持ち、詳細はその都度整理する。 02 ⽤語を揃える 概念の違いを明確にし、⾔葉の定義を妥協しない。
03 モデル化する 業務の構造をそのままコードの構造に落とし込む。 04 境界を意識する 担当範囲のコンテキストを深く理解し、設計する。 ドメイン知識は敵じゃない 整理すれば味⽅になる
文章・画像等の内容の無断転載及び複製等の行為はご遠慮ください。 © GO Inc.