ドメイン知識

一言でいうと

製品が対象とする業界の業務の流れ、規則、商習慣についての理解です。

提唱者と登場年

特定の提唱者はいません。英語版Wikipediaはdomain knowledgeを、一般的な知識と対比される、特定の分野に固有の知識と定義しています。ソフトウェア開発では、対象システムが動く業務環境についての知識を指し、開発者ではなく、その業務に携わる利用者から学ぶ必要があると記述しています。

ソフトウェア開発でこの知識の扱い方を体系化した文書に、Eric Evansが2003年に刊行した書籍『Domain-Driven Design』があります。Martin Fowlerは、この手法を、業務の手順と規則を十分に理解したドメインモデルを開発の中心に置く方法と説明し、複雑な業務を扱うシステムに適していると述べています。

何を解決するか

業務を知らない開発者は、利用者の言葉をそのまま仕様にするか、自分の想像で補うしかありません。どちらの場合も、業界では当然の例外や規則が抜け落ち、導入後に手戻りが発生します。

ドメイン知識を持つ人が開発に加わると、要件を聞き取る段階で抜けている条件に気づけます。業界の言葉と製品の仕様を対応づけられるため、利用者と開発者のあいだの認識のずれが小さくなります。

一方で、ドメイン知識は業界の経験者を採用するだけで得られるとは限りません。業界出身者の知識を開発チームへ伝える仕組みがなければ、知識は1人に留まります。

実際の進み方

まず、製品に必要な業務の範囲を決めます。業界全体の知識ではなく、製品が扱う工程と、その工程に関わる規則や例外を特定します。

次に、知識の入手先を決めます。業界出身者を採用する方法、顧客の現場で業務を観察する方法、業界の専門家に助言を受ける方法があり、会社によって組み合わせが異なります。

そのうえで、得た知識を開発チームの共通の言葉にします。業務で使われる用語と製品の中で使う名前をそろえ、用語集や業務の流れ図として残します。

導入でよくある失敗

• 業界経験を必須条件にして、候補者の母数を小さくしすぎる。入社後に学べる範囲まで必須にすると、採用が進みません
• 業界出身者1人に業務の判断を集中させる。その人が不在になると、要件の確認が止まります
• 業界の慣習をそのまま製品に写す。業務の非効率まで再現してしまい、製品を導入する意味が薄れます

求人票にこの語がある場合に読み取れること

求人票に業界知識や業務知識が挙がっている場合、製品が特定の業界の業務を深く扱っていると読み取れます。ただし、必須とするか加点とするかは企業によって異なります。

面接では、候補者の持つ業界の知識が、自社の製品が扱う工程と重なっているかを確認してください。同じ業界でも、扱った工程が違えば知識の中身も違います。業界経験のない候補者については、業務を学ぶために何をしてきたか、複雑な業務要件をどう設計に落としたかを聞くと、入社後の立ち上がりを判断する材料になります。

隣接手法との違い