「ドメイン知識」という言葉の解像度を上げてインプットに活かす
この記事はなにか
要約
- 「ドメイン知識」っていうけど、「解の質」を上げるための領域と「イシューの質」を上げるための領域があるのでは
- 「ドメイン知識を得よう！」と思っても領域によってインプットの仕方が異なる
- DSでもいわゆるコンサルタント的な部分でのドメイン知識が今後は大切
- ドメイン知識をインプットするときにどの領域なのか意識するとよい
背景
最近役職や会社のフェイズが変わったこともあり、今まで以上に自分で課題を見つけて自分で仕事を見つけてくることが求められるようになった。
これ系は、DSにおいていわゆる「DSはドメイン知識が大事！」みたいな話に繋がるところではあり、じゃあその「ドメイン知識」ってどう得たらいいのかなーと思い、他の人はどう考えているのだろうと調べたが、結構ふわっとした書き方や「それだけじゃなくね？🤔」と思ったことが多かったので書いた。
また、なんとなく「ドメイン知識」っぽいことをインプットしているものの、目的が曖昧で抽象度が高いのでドメイン知識」の解像度を上げる必要性も感じた。
ドメイン知識の要素分解
ドメイン知識という言葉は前述のように、結構大きな枠組みとして語られている気がする。そのため、何のためのドメイン知識かということをはっきりさせるために、典型的な分析案件のフローをもとに分解すると以下のようになる。
問題設定のためのドメイン知識
クライアントのビジネス目的を聞き出し、潜在ニーズを考え、クライアントが本当に求めていることは何かを知るために必要な、ステークホルダー周辺の知識。
具体的には、その業界の構造やビジネスフロー、業界で使われる用語、一般的に使われている分析内容や実施されていること、（サービスであれば）そのサービスはどういう内容なのか、など。
これは、クライアントの本当に解決したいことをヒアリングからあぶり出すための会話に必要。 つまり、クライアントとクライアントの土壌でビジネスのやり取りや議論をするための前提知識となる。
これがないと、クライアントとやり取りをしても議論をすることができないので、クライアントの言う通りのことをするだけになるが、クライアントが認識している課題と本当の課題(潜在的ニーズ）にずれがあったり、より優先順位が高いアプローチがあることが往々にしてある。
また、これはクライアントと会話をするためだけではなく、課題に対して仮説をたてアプローチを考える際にも必要となる。
仮説を立てる際は、一般的にはビジネスの背後でどういうことが起きていそうなのか、整理し、考え、仮説を立てることが必要になり、このビジネスの背後でどういうことが起きていそうなのかがまさにドメイン知識を指す。
このドメイン知識を得るためには、
- その作業/サービスを実際におこなっている(使っている）人にヒアリング
- その作業/サービスを実際に使ってみる
- その業界のビジネスに関する書籍やレポートを読む
などが考えられる。と、いっても何もわからない状態では何から着手すればいいかわからない場合も多いと思うので個人的には自社の既にドメイン知識がある人に色々と聞いたり、おすすめの書籍やサイト、資料を教えてもらうのが手っ取り早い。
「自社の既にドメイン知識がある人」は、例えば同業界の分析をしたことがあるデータサイエンティストが職種が同じなのでベストですが、知識そのものはコンサル部門や営業部門の人が最も詳しいことが多いので積極的に彼らに助力を得るのが近道となります。
なお、過去にドメイン知識について少し書いたときも同様のことを書いています。
分析のためのドメイン知識
主に
- 分析用データはどういう癖があるか
- モデルを作成するために、どういった背景がありそうか
の2点のために必要な知識。
前者は例えば、データに欠損がある場合はどういう事情で欠損しているか、どうやって取得されたデータか、カテゴリデータのラベルの意味はどうなのか、など使用するデータを理解し、場合によっては適切に補正するために必要となる。
このドメイン知識を得るためには、基本的にはデータの作成者にヒアリングしつつ、作成者がわからないところだけそれを知っていそうな人に聞く*1くらいだと思います。
つまり、事前にインプットは難しい。なお、このあたりを知るための取っ掛かりを得るのがEDAの役割のひとつ。
後者は、そもそも「モデリング」というものは現実で起きている事象をモデルに落とし込むことを指すので、良いモデルを作るためには現実をよく知る必要がある。そのために、例えば効果を測るにはコントロール変数としてどういったものを入れると良さそうか、交互作用はありそうか、など。分類予測であればラベルA,Bで明確に違いが起きそうな要因（特徴量）とはなにか、、、といったことを考えるための「事象の背景」に対する知識となる。
このドメイン知識を得るためには、「問題設定のためのドメイン知識」と重複しているが、
- その作業/サービスを実際におこなっている(使っている）人にヒアリング
- その作業/サービスを実際に使ってみる
の2点が主。
理由としては、「問題設定のためのドメイン知識」では仮説を考える際に「現実でどういうことが起きていそうか」を知る必要があり、「モデリング」では現実で起きていることを高解像度で知り、それをモデルに落とし込む必要があるので共通して「現実を知る」必要があります。よって、現実を知るために「その作業/サービス」を使うか使っている人に話を聞くことが必要となります。
活用のためのドメイン知識
主に、
- 分析結果をどう実行可能な施策に落とすか
- 施策をどうシステムに落とすか
ための知識となる。
例えば、どれだけ優れた分析をおこなっても、実行不可能な施策であれば誰も使えない。また、実行自体はできても現場の人が使いやすいシステムであったり、腹落ちをしていなかったらそれは使われない施策となってしまう。
そのために、分析結果を受けて実施する人が使いやすい施策およびシステムはどのような内容なのか？を考えるための知識が必要となる。
このドメイン知識を得るためには、
- 施策実施者(≠対面で分析プロジェクトとしてやりとりしているクライアント）の現場はどうなっているか
- 施策実施者の普段の業務はどうなっているか
- 施策実施者の「分析」に対しての気持ちはどうか
- （実施先の）システムがどうなっているか
を知る必要がある。
はじめの3つは、施策実施者にヒアリングしてみないとわからない。
例えば、「工場のAの改善のためにXをすればよい！」とわかり、対面で分析プロジェクトとしてやりとりしているクライアントが納得したとしても、それを実施する工場現場で働いている人に聞いてみると「Xをすることはできるけど、その場合作業Bが遅れてします」「Xをするのは面倒で多分忘れてしまう」「Xのためのモニター画面はあるけど、使いづらいシステムなので施策はおこないづらい」「分析の言っている意味がよくわからんからやり方がわからん」のようなことが原因で実質的に分析結果が使われなかったりする。
そのため、「どういう施策内容なら実施できそうか」を考えるためには実施者にヒアリングするしかない。
また、4つ目のシステムに関しても現状どういったシステムになっているかは既存システムがどうなっているか、新たなシステムを入れる場合はそれが可能かといったことはクライアントのシステム担当者の人にヒアリングをするしかない。
余談：クライアントを介さない自己学習が可能なこと
先程まで、ドメイン知識を「問題設定」「分析」「活用」と分けたが、インプットをする際に「自分一人である程度インプットできるもの」「クライアントあるいは実際に使う人へのヒアリングをしないといけないもの」の2種類があることがわかった。
「自分一人である程度インプットできるもの」はどのタイミングであろうと時間が許す限りおこなうことができるが、「クライアントあるいは実際に使う人へのヒアリングをしないといけないもの」はタイミングやそもそもそれが可能なのか、などインプットを突き詰めるのには限界がある。
つまり、自己学習が可能なことは「問題設定領域のドメイン知識」がメインということになる(「分析領域」も一部可能)。そのため、「XX業界の分析をすることになったので事前に色々知っておくぞ！」と思った場合は「問題設定」をするためにインプットをするという意識で情報を拾っていく意識が必要となる。
前提知識
ここまでは、各ドメイン知識領域がどの部分で必要となり、どうやって得ていくかを書いた。以降では前述の「ドメイン知識の要素分解図」をもとに、各ドメイン知識領域のデータサイエンティストとして使っていく際に知識を得ていく際の優先順位の話をおこなっていく。
今回考えるにあたりコンサル系の本やコンサル寄りのDS本を最近改めて読み直したので、本からの知見をもとに「(DSにおける）ドメイン知識」の観点でまとめた内容となっています。
そのため、まずは中心となる書籍で特に参考にさせていただいた箇所をざっくりと書く。
データサイエンティストの要諦
最近出た本。データサイエンティストのスキル定義でよくみる「ビジネス力」「エンジニアリング力」「統計力」のベン図*2でいう「ビジネス力」にフィーチャーした本は色々あるけれど、それ系の中でも特に良かった。
- モデリングしかできない"データサイエンティスト"は今後厳しい
- モデリングに加え、「分析をおこない、その結果からビジネスに意味のあるインサイトを得る」ことが"データサイエンティスト"に求められている
- 「分析をおこない、その結果からビジネスに意味のあるインサイトを得る」はいわゆるコンサルティング力なのでちゃんとコンサルティング力もつけようね
といったことを主題に深堀りがされている（+そのための教育やスキルアップはどうするかとか）。
イシューからはじめよ
有名な問題解決系のコンサル本。つまり、前述の「コンサルティング力」をどう上手くやっていくか、と考えてもよさげ。
バリューのある仕事とは？そのためにどうしたらいいの？という観点でタイトル通り「イシューからはじめる」ことを解いた本。
バリューの本質は下図のように「イシュー度」と「解の質」の2軸に分けられ、右上にいくほど「バリューのある仕事」としている。
「イシュー度」とは「自分の置かれた局面でこの問題に答えを出す必要性の高さ」 = 「問題に対して何を解くか」「課題設定」、
「解の質」とは「そのイシューに対してどこまで明確に答えを出せているかの度合い」 = 「どうやって解いていくか」「アプローチ方法」、
と定義されている。
一般的に、「解の質」がバリューを決めると考えられ、「イシュー度(課題の質)」は重要視されない。しかし、「解の質」が高くてもそもそもの「イシュー度(課題の質)」が良くないとクライアントにとっての価値が良くない。例えば、何かしらの相談に対して、物凄く詳細でわかりやすく調査レポートを出されても、そもそも調査自体が筋違いな方向性であれば何の意味がない。
そのため、仕事の仕方としてはまずは手当り次第思いついた課題を着手するよりも先に、「イシュー度」が高い問題はどれかじっくり検討をする。その後、その「イシュー度」が高い課題に対して、深堀りや分析を繰り返していくことで「解の質」を上げていくのが一番生産性(=成果/投資時間)が高い。
なお、よくやる「根性に逃げたやり方」は、とりあえず思い浮かんだ課題(検討しきってないので「イシュー度」は低いことが多い）に対してまず着手し、深堀りや分析を繰り返していくことで「解の質」が上がる。また、その繰り返しの中で色々なことが見えてくる（または取り組んでいる課題のよくなさに気づき、課題を変える）ので課題が徐々に変質していくことで「イシュー度」も上がっていく。といった進み方となる。いわゆる、走りながら考えるアプローチ。
そのため、右上の象限にたどりつくには、左回りルートは「一心不乱に大量の仕事を根性でおこうなうことで価値のある仕事にする」やり方なので生産性は低く、右回りルートの方が生産性が高い。
データサイエンスで考えると、例えば「施策Aの効果検証をしたい」という問題がある。その際に、「何を効果とするか」「効果検証手法はどうするか」など様々に考えられる。
左回りルートでは、とりあえずよくされているような効果の測り方、手法で分析をおこなう。その際に、よりよいアルゴリズムに改良したり、前処理の工夫などをおこなって「解の質」を上げる。併せて、分析結果のフィードバックを現場などから得つつちょっとずつ「イシュー度」を上げていくといったアプローチが考えられる。
このとき、アルゴリズムの改良であったり前処理をしたりといったことは非常に時間がかかる。また、分析後にフィードバックを得た結果、分析自体のやり直しが起きることもある。つまり、時間の無駄が多い。
一方で、右回りルートでは、分析をする前に「施策Aの効果検証をしたい」という問題について深堀りをおこなっていく。例えば、「何故施策Aの効果検証をしたいか」「効果を測ってその結果をどう使っていくか」「施策Aの効果をどう測るとビジネスに活かせるか」・・・など、問題そのものの設定をする段階で時間を使う。そして、ある程度その中で筋が良さそうなものに着手し分析を進めていき分析の質(「解の質」）を上げていく。
この例からわかるように、「解の質」を上げるのには分析が伴うため「イシュー度」を上げるより時間がかかるため、右回りルートの方が時間がかからず生産性が良い。
「ドメイン知識」がどう役に立つか
各書籍を併せて考えると、
といえる。
各ドメイン領域の性質
ドメイン知識の各領域に対して、それぞれが「イシュー度」と「解の質」どちらに該当するか考えると以下のようになる。
つまり、「バリューのある仕事をする」ために必要なドメイン知識は「問題設定領域」のドメイン知識となる。
一方で、「分析領域」「活用」のドメイン知識を増やしてもそれはあくまで「解の質」を上げるための知識となる。
また、各ドメイン領域が「コンサルティング」と「モデリング」に分けると以下のようになる
つまり、モデリング屋としてやっていくのであれば「分析領域」のドメイン知識を得ればいいし、コンサルティング力を上げたいのであれば「問題設定」「活用」のドメイン知識を得る必要がある。
まとめ
今までの内容をまとめると以下のようになる。
つまり、
- コンサルティング力のための知識で、「イシュー度」を高い問題設定をするために必要な知識を得たい → 「問題設定領域」のドメイン知識を得る
- コンサルティング力のための知識で、問題に対して「解の質」を高めるための知識を得たい → 「活用」のドメイン知識を得る
- モデリング力のための知識で、問題に対して「解の質」を高めるための知識を得たい → 「分析」のドメイン知識を得る
となる。
ドメイン知識をインプットする際に、「どの領域のドメイン知識なのか？」「このドメイン知識は何に活かせるか」を意識しながら学んでいくとそのインプットの使いどころがわかりやすいのではないか。
Appendix
「イシューからはじめよ」のうち、今回取り上げたのは「イシューからはじめよ」のメインメッセージである何故「イシュー度を上げる必要があるか」という部分ですが、書籍内には（今回書いたドメイン知識以外での普遍的な）「イシュー度」をどうやって上げ、それをもとにどうやって「解の質」上げる方法も書かれてます。更には、質の高いイシューを立てたあとそれをもとにどうビジネスを展開していくか（「イシュードリブン」という書かれ方がされてます）という今回挙げた「コンサルティング力」にまつわる話も大いに書かれています。
また、「データサイエンティストの要諦」は本記事のメインとなる「イシュー度」「コンサルティング」を兼ねる「問題設定ドメイン領域」を特に書きましたが、「活用」の部分も「コンサルティング」のひとつとして重要視して深堀りをして、これらのスキルをどうやって習得していくか？ということが書いています。特に、本書のP39 図表2「アナリティクス一連の流れ」は、前述の「問題設定」「モデリング」「活用」を更に詳細に分け、各フェーズが（DS協会のベン図と類似する）「ドメイン知識」「機械学習＆統計知識」「ITツール操作スキル」のどのスキルが必要かを◎◎△✗でわかりやすく記載されているので必見です*3。
前述のように、この「コンサルティング力」は、データサイエンティスト協会のベン図の「ビジネス力」の根底をなす部分なので、データサイエンティストの「ビジネス力」を上げたい方はこの2冊はおすすめです。
