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

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

Avatar for GO Inc. dev GO Inc. dev
May 15, 2026
41

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

Avatar for GO Inc. dev

GO Inc. dev

May 15, 2026

More Decks by GO Inc. dev

Transcript

  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 境界を意識する 担当範囲のコンテキストを深く理解し、設計する。 ドメイン知識は敵じゃない 整理すれば味⽅になる