ドメイン知識とは？発注者がエンジニアに伝える3つの方法
「御社のドメイン知識を整理してください」——要件定義会議でそう言われ、何のことか分からず戸惑った経験はないでしょうか。あるいは、時間をかけて開発したシステムが完成後に「現場で使えない」と判明し、手戻りと追加費用が発生したという経験をお持ちの方もいるかもしれません。
こうした問題の多くは、「ドメイン知識」の共有が不十分なことに起因しています。しかし「ドメイン知識」という言葉がエンジニア向けの概念として語られることが多いため、発注者側の担当者が「自分には関係ない」と感じてしまうケースが少なくありません。
実は、システム開発を成功させるために「ドメイン知識の整理と共有」を担うのは、エンジニアではなく発注者側です。エンジニアは技術の専門家ですが、あなたの業務の専門家ではないからです。
本記事では、「ドメイン知識」とは何かをIT文脈でわかりやすく解説した上で、発注者がエンジニアに業務知識を効果的に伝えるための3つの具体的な方法を紹介します。次の要件定義会議を成功させるための実践的な準備方法として、ぜひ参考にしてください。
目次
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
こんな方におすすめです
ドメイン知識とは？IT文脈での意味をわかりやすく解説
「ドメイン」とは何か——業務領域・事業分野のこと
「ドメイン（domain）」という言葉は、日本語では「領域」や「分野」を意味します。IT文脈における「ドメイン」は、Webサイトのアドレス（ドメイン名）のことではなく、「そのシステムが対象とする業務領域や事業分野」を指します。
たとえば、次のような関係です。
- 医療分野のシステム → ドメインは「医療」（診療記録・保険請求・薬剤管理など）
- 物流会社のシステム → ドメインは「物流・配送」（在庫・配送ルート・運賃計算など）
- 小売業のシステム → ドメインは「小売販売」（商品管理・売上・返品・顧客管理など）
「ドメイン知識」とは、こうした各業務領域に固有の専門知識のことです。
エンジニアが使う「ドメイン知識」の定義
システム開発の文脈では、「ドメイン知識」とは次のような知識を指します。
- 業務手順と例外処理（「通常はこうするが、このケースでは別の対応をする」）
- 業界固有の用語・概念（自社や業界内だけで使われる専門用語）
- 関連する法規制・業界ルール（コンプライアンス・商習慣）
- 評価指標やKPI（その業務が何をもって「成功」とするか）
- 業務上の優先順位（どの条件が最重要で、どこにトレードオフがあるか）
エンジニアは技術の専門家ですが、あなたの業務については「素人」です。会計の仕組み、製造ラインの工程、物流の制約——こうした業務固有の知識を持っているのは、その業務に携わってきた発注者側の人間です。この業務知識を「ドメイン知識」と呼び、システム開発においてエンジニアに正確に伝えることが発注者の重要な役割です。
業務知識との違い・関係
「ドメイン知識」と「業務知識」はほぼ同じ意味で使われることが多いですが、使われる文脈に違いがあります。
「業務知識」は一般的な文脈で使われる言葉で、「その仕事に必要な知識全般」を指します。一方、「ドメイン知識」はIT・ソフトウェア開発の文脈で使われる専門用語で、「開発するシステムが扱う業務領域に関する知識」という特定の意味を持ちます。
エンジニアが「ドメイン知識を整理してください」と言った場合、「あなたの業務についての知識をシステム開発に使えるよう整理・共有してください」という意味です。
ドメイン知識不足がシステム開発を失敗させる3つの理由
なぜ「ドメイン知識の共有不足」がシステム開発の失敗に直結するのでしょうか。3つの典型的なパターンを見ていきます。
理由①要件定義で「言葉の意味」がズレる
システム開発の失敗の多くは要件定義の段階で起きています。その主な原因の一つが、「同じ言葉で異なることを指している」という認識のズレです。
たとえば、発注者が「受注データ」と言ったとき、エンジニアはデータベース上の1つのテーブルをイメージするかもしれません。しかし発注者の業務では「受注データ」には注文ヘッダー・明細・顧客情報・納品先・決済情報が複合的に含まれており、業務によってはその組み合わせが異なるケースもあります。
こうしたズレは、事前にドメイン用語を定義・共有しておくことで大幅に防ぐことができます。
理由②エンジニアが誤った前提で設計してしまう
ドメイン知識が共有されていないと、エンジニアは「一般的な業務のあり方」や「自分の経験則」を前提に設計を進めてしまいます。
しかし、各企業の業務には固有のルールや例外が必ずあります。「通常は1件の発注に対して1件の納品だが、分割納品が発生することもある」「月末は処理量が3倍になる」——こうした業務固有の制約を伝えておかないと、通常ケースしか想定しない設計になってしまいます。
結果として、開発後に「想定していた業務フローに対応できない」という問題が発覚するのです。
理由③「現場で使えない」と判明するのは開発後
最も深刻なのが、システムが完成してから「現場の実務に合わない」と判明するケースです。この時点での修正は、要件定義・設計からのやり直しを意味することもあり、大きな追加費用と時間が発生します。
このケースの多くは、「現場担当者の視点」がシステム開発に反映されていないことが原因です。実際にシステムを使うのは現場の担当者ですが、要件定義に経営者や管理職のみが参加し、現場の業務の細かなニュアンス（例外処理・操作のテンポ・表示情報の優先順位）が伝わっていない場合があります。
発注者側が持っているドメイン知識——特に現場担当者の業務上の知恵——をエンジニアに正確に伝えることが、開発後の「使えない」を防ぐための最も重要な対策です。
発注者がエンジニアにドメイン知識を伝える3つの方法
ドメイン知識を効果的に伝えるための実践的な方法を3つ紹介します。難易度の低いものから順に試してみてください。
方法①業務フロー図で「見える化」する
最も基本的かつ効果的な方法が「業務フロー図」の作成です。業務フロー図とは、業務の流れを図で表したもので、「誰が・何を・どの順番で・どの条件で行うか」を可視化します。
発注者が作成する際の3つのポイント:
-
実際に業務を行っている担当者と一緒に作成する: 経営者や管理職が一人で作ると、現場の実態と乖離したフロー図になりがちです。実際に操作する担当者と対話しながら作成することが重要です。
-
例外処理・エラーケースを漏らさない: 「通常はこうするが、こんな場合はどうする」という例外ケースこそが最も重要なドメイン知識です。「問題ない場合のフロー」だけでなく、「何か問題が起きたときのフロー」も必ず記載してください。
-
現場の言葉で書く: 標準的な業界用語ではなく、自社内で実際に使っている言葉で記載します。エンジニアが理解できない用語は後で定義すれば問題ありません。
業務フロー図のツールは、最初はExcelやシステム開発の用語集でも十分です。まず「見える化」することが第一歩です。
方法②ドメイン用語集を作成する
「受注」「発注」「仕入れ」——これらの言葉は会社によって意味が異なります。自社固有の用語や、業界内で当たり前のように使われている専門用語をエンジニアに伝えるために「ドメイン用語集（用語集）」を作成します。
ドメイン用語集に記載すべき内容:
項目 |
内容例 |
|---|---|
用語名 |
「受注」 |
自社での定義 |
「顧客から注文を受け付け、受注番号が発行された状態」 |
含まれる情報 |
顧客情報・商品コード・数量・希望納品日・特記事項 |
関連する業務 |
在庫確認→出荷指示→請求書発行 |
例外・注意事項 |
「仮受注（見積もり段階）は別管理。正式受注のみ本システム対象」 |
用語集は完璧である必要はありません。まず10〜20の主要な用語を定義するだけで、要件定義会議での認識ズレを大幅に減らすことができます。
方法③ドメインストーリーテリングで具体的な業務シナリオを伝える
「業務ストーリーを物語として語る」という手法がドメインストーリーテリングです。Stefan HoferとHenning Schwentnerが体系化したこの手法は、システム開発における要件定義の手戻りを防ぐ効果があるとして、近年注目を集めています。
ドメインストーリーテリングでは、業務を次のような構造で語ります:
「[誰が] [何を/誰に対して] [どのように] [何をする]」
具体例（物流会社の場合）:
- 「担当者がシステムに発注内容を入力する」
- 「システムが倉庫に在庫確認依頼を送る」
- 「倉庫担当者が在庫の有無を確認して返答する」
- 「在庫があれば担当者が出荷指示を出す。在庫がなければ発注者に連絡し入荷予定日を確認する」
このように「人物が登場するシナリオ形式」で業務を語ることで、エンジニアは業務の流れを直感的に理解できます。業務フロー図との組み合わせが特に効果的です。
ドメインストーリーテリングはホワイトボードや付箋を使ったワークショップ形式で実施することも多く、エンジニアと発注者が同じ場で業務を「共に語る」ことで、認識のズレをリアルタイムで発見・修正できます。
要件定義でドメイン知識を活かす実践ポイント
業務フロー図・用語集・ドメインストーリーテリングで整理したドメイン知識を、要件定義の場で効果的に活かすための実践ポイントを紹介します。詳しい要件定義の進め方については要件定義の進め方【発注者向け完全ガイド】もあわせてご覧ください。
要件定義前に準備する3つのこと
要件定義会議を実りあるものにするために、事前に以下の3つを準備しておきましょう。
-
業務フロー図（現状のAs-Is）の作成: 現在の業務の流れを図示します。理想の姿（To-Be）は後でいいので、まず現状を正確に把握・可視化することが先決です。
-
主要なドメイン用語の定義（10〜20語）: 要件定義でよく使いそうな業務用語を事前に定義します。エンジニアから「この言葉の意味を教えてください」と質問される前に、用語集として共有しておくことで会議の効率が大幅に上がります。
-
例外ケースのリスト化: 「通常業務以外に、こんなケースが発生する」という例外をあらかじめリストアップしておきます。「月末集中処理」「取引先によって処理が異なる」「年1回だけ発生する特殊業務」など、漏れやすい業務を事前に整理しておくことが重要です。
エンジニアとの定例ミーティングで確認すること
要件定義会議では、エンジニアが使う技術的な言葉に圧倒されがちです。しかし、発注者側が確認すべきことは明確です。
-
「〇〇とはどういう意味ですか？」と積極的に聞く: 分からない用語が出てきたら、恥ずかしがらずにその場で確認する。理解しないまま進めると、後で認識ズレが発覚します。
-
「この業務のケースでは対応できますか？」と具体例で確認する: エンジニアが設計した仕組みが、実際の業務ケース（特に例外ケース）に対応できるかを確認します。
-
「この場合、画面ではどのように表示されますか？」と視覚的に確認する: 実際の操作イメージを早い段階で共有することで、「完成してから想定と違った」を防げます。
共通言語が生まれたかを確認するチェックリスト
要件定義が終わった時点で、以下を確認してみてください。チェックが多いほど、ドメイン知識の共有がうまくいっているサインです。
- エンジニアが業務フロー図を見ながらシステムの動きを説明できるようになっているか
- 自社の用語をエンジニアが正しい意味で使えているか（認識ズレがないか）
- エンジニアから「この業務ではこういうケースは想定しますか？」という質問が来ているか（業務への理解が深まっているサイン）
- システムの仕様書に、自社の業務固有の条件が具体的に記載されているか
これらが確認できたなら、ドメイン知識の共有は順調に進んでいると言えます。エンジニアとの外注コミュニケーション全般については、開発会社への外注コミュニケーション方法も参考にしてください。
まとめ：発注者が「ドメインエキスパート」として開発に関わる
「ドメイン知識」とは、あなたの業務領域に関する専門的な知識のことです。そしてその知識を最も深く持っているのは、発注者であるあなた自身です。
エンジニアは技術の専門家ですが、あなたの業務の専門家ではありません。「技術のことはエンジニアに任せ、業務のことはこちらが伝える」という役割分担の意識を持つことが、システム開発成功の鍵です。
本記事で紹介した3つの方法（業務フロー図・用語集・ドメインストーリーテリング）を、まず1つから試してみてください。最も取りかかりやすいのは「用語集の作成」です。10語の定義から始めるだけでも、次の要件定義会議が大きく変わるはずです。
発注者が「ドメインエキスパート」として開発に積極的に関わることで、「作ったけど使えない」システムを防ぎ、本当に現場で価値を生むシステムを実現できます。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
