Upgrade to Pro — share decks privately, control downloads, hide ads and more …

エンジニアはドメイン知識とどう向き合うべきか?

GO Inc. dev
May 15, 2026
830

 エンジニアはドメイン知識とどう向き合うべきか?

GO Inc. dev

May 15, 2026

Transcript

12 slides
  1. © GO Inc. 2度の転職で直面した「ドメイン知識の壁」 2 毎回ぶつかる、逃れられないつらみ ビジネス⽤語の迷宮 専⾨⽤語が⾶び交い、 会話についていけない ドメイン知識が難解

    業界特有のルールが複雑で 理解が追いつかない 仕様が複雑すぎる 関連する要素が多く、 全体像が⾒えない 「なんとなく」の実装 本質を理解せず、表⾯的なコード を書いてしまう
  2. © GO Inc. 「勉強」の罠にハマり、実装が⽌まる やったこと 業界本を読み漁る 社内資料を全部読む ⽤語集を作る 結果 量が多すぎて終わらない

    実装が進まない とにかく「つらい」 ドメイン知識 = 暗記すべきもの という誤解 アンチパターン①:全部覚えようとする
  3. © GO Inc. 対策①:最低限の「地図」だけを持つ 全部を覚えず、業務の前提を理解する 基礎知識は得るが、深⼊りしない ⾦融ならFP/証券外務員資格、⼩売なら店舗運営の概要など、 議論の⼟台となる共通認識を優先する。 現場の「空気感」を知る ニトリの店舗研修のように、ユーザーがどのような環境で

    システムを使うかを知る。 「地図」があれば迷わない 詳細はその都度調べればいい。 今どこにいるか、どこへ向かうかだけ把握する。 「全部覚える」は不可能。 「地図を持つ」は戦略。 https://xtech.nikkei.com/atcl/nxt/column/18/02286/012600009/
  4. © GO Inc. 対策②:用語を徹底的に揃える 同じ概念には同じ名前を使う。これが設計の命。 ⽤語のズレは、 モデルと実装のズレ ビジネスと⾔葉を 1ミリもズラさない 曖昧な⾔葉を

    徹底的に排除する ⾦融ドメインの例 ⼀般的考え⽅ 注⽂ = 取引成⽴ VS 実際のドメイン 注⽂ (Order) 約定 (Execution) ⽤語の整理 = モデルの整理
  5. © GO Inc. 対策③:業務の「構造」をモデルに落とす 業務の流れ = コードの構造 業務には「構造」がある 単なるデータの集まりではなく、 そこには不可逆な流れや依存関係が存在する。

    構造をそのままコードにする 業務プロセスを観察し、その関係性を クラスやDBの関連として忠実に再現する。 変更に強い設計へ 業務ルールが変わった際、コードのどこを 直すべきかが明⽩になり、負債化を防げる。 ⾦融ドメインのモデル例 Order Execution Position Balance Execution
  6. © GO Inc. まとめ:ドメイン知識を味方につける 01 覚えようとしない 最低限の「地図」だけを持ち、詳細はその都度整理する。 02 ⽤語を揃える 概念の違いを明確にし、⾔葉の定義を妥協しない。

    03 モデル化する 業務の構造をそのままコードの構造に落とし込む。 04 境界を意識する 担当範囲のコンテキストを深く理解し、設計する。 ドメイン知識は敵じゃない 整理すれば味⽅になる

More Decks by GO Inc. dev