ドメイン知識ってなんだろう。最近、ドメイン知識があるだのないだのという話を聞いて、ふとそんなことを思いました。何を「ドメイン知識」と呼んでいるのだろう？
ドメイン知識とは何か
調べてみると@shin_semiyaが情報を発信してくれています。
例えがいいですね。でも、まずは例えずに考えたい気分（ごめーんね）。みつけたのが「ドメイン分析，ドメインモデル，ドメイン知識」という記事。
用語，問題のとらえ方，システムの構造，システムの作り方などは，システム開発を効率化するためのドメイン知識(domain knowledge)です. ―― 「ドメイン分析，ドメインモデル，ドメイン知識」より
ふむふむ。
まず、「用語」。金融には独特の言い回しがあったりしますね。システムによって商品が何をさしているか異なっていたりするので、言葉をそろえるのは、とても大切なコミュニケーションの基盤になります。命名規則も大切。名前はいつも大切。
次に「問題のとらえ方」。これはシステムが作られる前提条件として、「要件」とか「RFP」とかで登場するものですかね。ある問題を解決するためのシステムを考える。どういう切り口で考えたのか？ とか。
そして、「システムの構造」は、システム図とか中身のことですかね。今の世の中、複数サーバがそれぞれの役割を持って活躍することがおおいので、それらの関係性を知ることも大切。
最後に、「システムの作り方」。どうやって作るか？ だとすると、設計になるんですかね。最近だとコード読んだほうがはやいので、プログラミングコード、とも言えるのかも。また、アジャイル開発やスクラムといったプロセスやフレームワークも作り方といえます。
仕様はドメイン知識？
僕が疑問に思ったのは、「仕様」についてです。これってドメイン知識になるのでしょうか？ 用語ではないですね。問題のとらえ方は？ ちょっと違う気がする。システムの構造でもないし、システムの作り方が仕様か？と言われるとむーん。そうだろうか？
問題のとらえ方 => 要件 => 仕様や言葉 => システムの構造 => システムの作り方
仕様って、問題のとらえ方の結果として生まれ、システムの作り方（設計）に必要な要素なので、部分的な情報に感じます。あくまでひとつの結果でしかない。
よって、仕様の行間に隠れている「この仕様の意義」とか「この仕様にいたった背景」とか、暗黙知的な要素が含まれていません。でも、こういうのって結構大切だったり。
だとすると、「仕様をよく知っている」からといって、「ドメイン知識がある」ではないと思うのです。
属人化して知識は共有すべきだ
最近、去年新卒でエンジニアになった若者とこんな話をしました。
属人化って悪いイメージがあるけど、『属人化していい』っていう人もいるんですよ。僕はこの意見に賛成で、仕様にすごく詳しくて、その人にきかないとわからない・・・っていう、生き字引的な属人化はあんまり価値がないと思っているんです。
だって、そういう知識って紙に書いた瞬間に価値が下がりますよね。だから、もっと価値が減りにくいものを身につけたほうがいいでしょう？
もっと別のところで属人化する。「本当に自分にしかできないこと」を属人化する。そういう属人化は、あってもいいんじゃないかと思うんですよね。
共有したくないとかは論外で、古くからこのシステムに関わっていることを価値とするのは、よく考えるとあんまり魅力的ではない。意外と「あの人、辞めちゃったけどなんとかなってるね」となることも経験上多かったりしますから。
そういうのはとっとと明文化してしまい、発信する力を身につけたほうがその人の価値は上がると思います。
だから、ドメイン知識にかぎらず、仕様にかぎらず。「情報は共有すべき」と思うんですよね。
旅と子育てとアジャイルコーチのブログ「世界」 