
「事業ドメインの専門家と対等に話せるエンジニア」になるための最短学習Tips
※この記事は2023年12月28日に執筆した記事です。
エンジニアが仕事をするとき、特定のドメインに関連したソフトウェア作りをすることが多いでしょう。例えば、ファストドクターならば医療というドメイン領域がそれにあたります。
ソフトウェアエンジニアは、ある課題を解決するために動くソフトウェアを作る仕事をします。その過程で、ドメイン専門家とのコラボレーションは不可欠です。DDD(ドメイン駆動設計)のような開発手法で、コラボレーションの質を高める方法があります。今回は開発手法というよりも学習方法という切り口でこのコラボレーションの質を高めるアプローチについて記述したいと思います。
CTOのキースキルとしての「ドメイン知識学習能力」
良いソフトウェアを作るのに、ドメイン領域への理解は不可欠です。
ソフトウェアはドメインの課題を解決するものです。ドメインにおいてインパクトが大きなテクノロジーを省コストで継続的に開発できるようにすることが、チームをリードするエンジニアの責務であると思います。インパクトを測るためには、ドメインの構造の理解が必要です。また、ユーザーペインを掘り下げていくプロセスにおいてドメイン専門家へのインタビューが必要になりますが、インタビューを行うにもベースとなるドメイン知識が必須です。
アンチパターン: そんなことも知らないの? と面倒がられてしまう
ドメイン領域未経験のエンジニアがドメイン知識を知らないのは当然のことです。
専門知識は専門家に教えてもらおう!と意気込んで「教えてください!」とお願いすると、最初のうちは丁寧に教えてくれるかもしれません。しかし、それが繰り返されると「こちらも忙しい」「業務の邪魔」とクレームをもらってしまうこともあります。
当然ですが、ドメイン専門家も本来の業務で忙しいのです。
人に教えるという行為は本能的に心地良いものであると思います。しかし同時に、精神的に疲れる行為でもあると思います。
これは私の感覚値なのですが、教育をなりわいにしていない人の場合、他人に教えるのに集中力を維持できるのは20分程度であるように思います。
教えるという行為は、複雑な知的活動です。目の前の人が「何を知っているのか」を感じながら、その人が知りたい内容を伝える必要があります。なかなか痺れます。
教える側が疲れやすいのは、人にものを教えるという活動が「期待」と「ギャップ」の連続であるからだと思います。感情が動きやすいのですね。教えることをなりわいとする人は、期待値を適切にコントロールできるから疲れにくいのですが、多くのドメイン専門家は教育のプロフェッショナルではありません。
ドメイン知識の獲得はこういった人間ならではの現象に向き合わなければなりません。
ドメイン知識を身に付けるためのポイント
ドメイン知識を身に付けていくためのポイントを3点説明します。
学習方法がない → 自分で設計する
言葉を知らないと理解できない → まず語彙を獲得する
「教えてもらうこと」は案外難しい → 気持ち良く教えてもらえる好循環を作る
学習方法がない → 自分で設計する
整備された学校教育と違って、ドメイン知識を学ぶためのコースは提供されないことがほとんどです。多くの場合は独習する必要があるでしょう。
教育学では学習方法のことを学習方略といいます。自分に合った教科書がない状況では、学習方略を自分で考えるしかありません。
しかし、学習方法について学ぶ機会は少なく、これを自分で設計できる人はあまりいないのではないでしょうか。
私は前職でEdTechのプロダクトを作っていて、学習方法について深く考える機会がありました。ドメイン知識の獲得においても自分なりの方法論を持っています。この記事では私なりの学習アプローチを紹介できればと思います。
言葉を知らないと理解できない → まず語彙を獲得する
語学学習の研究では、人が文章を理解するのに必要な語彙のカバー率は90%〜95%と言われています。
専門領域の日本語においても7割程度の用語を理解していないと、専門家の説明内容についていけません。つまり効率良く語彙を獲得することが最初のキーポイントになります。
私の学習方法では「抽象度の高い基礎用語」からカバレッジを上げるアプローチを取ります。
「教えてもらうこと」は案外難しい → 気持ち良く教えてもらえる好循環を作る
学校教育の中では教える人と教わる人、という関係性が明確です。エンジニアの世界でもシニアプログラマーが新人プログラマーに教えるときには、「自分がたどってきた方法」を伝えるという手段をとることができます。
一方で、ドメイン専門家は教育の専門家ではありません。私も非エンジニアにプログラミングを教えるのは提供すべき前提条件が変わってくるので、難しく感じます。
そのため、ドメイン専門家から効果的に教えてもらうにも工夫が必要になります。
インタビューの技法をとり入れた「うまく教えてもらう」ための準備方法を紹介したいと思います。
ゴール設定:「限定された領域」で専門家と議論ができるレベルに可能な限り早く到達する
ドメイン専門家と同等な知識を身に付けることは不可能です。キャリアの大半においてそのドメイン領域で働いてきた人が費やした時間や経験を再現することはできません。
「限定した範囲において専門家との議論が成り立つレベル」
を私はゴールラインとしています。
専門家とディスカッションする場を継続できるようになれば、どんどん知識が身に付きます。自然に学習が進む入り口に立つことができます。逆にディスカッションするのに知識が不十分なままだと議論に呼ばれず、学習する機会を得ることができません。そのスタートラインに立てる程度の知識を効率良く身に付けたいところです。
ポイントは
限定した範囲でよいこと
議論が成り立つこと
語彙を獲得するために初学する
専門領域の知識に効率良く入門するための方法を説明します。
ステップ0: ながらインプットから始める
この記事を読んでいる方は、そもそも専門外の分野の知識獲得に充てられる時間が少ないかもしれません。時間がある方はステップ1から始めていただきたいのですが、そうでない方は、片手間で行えるながらインプットから始めるのが良いと思います。
例えば、通勤時にラジオを聞いたり、家事をしている間にYouTubeをつけっ放しにしたりするといったことです。
ここでのポイントは、無理にがんばって知識習得をする意識を持とうとするのではなく、あくまでながら作業に留めようとすることです。継続的に学習を続けるためには、緩やかに学習強度を上げたほうが良いと、私は思います。
このような「ながらインプット」によって、以下の知識セットがふんわりと集まってきます。
そのドメインの関心事のスコープがどこからどこまでなのか
そのドメインに含まれるサブドメインにはどのようなものがあるか
どのような単語が登場しやすいか
これらを把握しておくことで、自分の真の関心事や、次ステップの入門書の選択に役立つと考えます。
ステップ1: 入門書を選ぶ
私なりの王道の取り組み方は、初学者向けの書籍を用語とキーとなる文章に着目してじっくり読むことです。
ドメイン専門家におすすめの書籍を聞くと、難しい専門書をすすめられることもありますが、できるだけ簡単な書籍を選ぶべきです。専門家に聞くときには、一番簡単な書籍を教えてもらいましょう。
シンプルにAmazonで「はじめての◯◯」「わかりやすい◯◯」などの書籍を検索することをおすすめします。
ステップ2: マインドマップに章立てを書き起こす
ツールは何でもよいのでマインドマップに章立てをひとしきり書きます。
私は会社でオンラインホワイトボードのMiroを契約しているため、Miroのマインドマップを使うことが多いです。
マインドマップを選ぶのは次ステップで説明する用語の整理がしやすいからです。
まず、これから学習する準備のために章立てを何も考えずに書き起こします。
プログラミング学習でもそうなのですが「写経」は効率が良いアプローチだと思います。文章を読むだけでは理解できていないことも多いです。書くことで自分の理解を確認しながら読むことができます。
また、初学の時期こそ学習を「書く」という作業として進めたほうが効率的です。
ステップ3: 用語の関係性に着目してメモを取りながら読む
用語とキーとなる文章を知識として獲得するために、メモを取りながら読み進めます。章節の配下に「用語」「トピック」「気づき」という項目を作って、そこにメモを取りながら読み進めます。

用語は「抽象度の親子関係」「構成の親子関係」に着目しながらメモします。
抽象度の親子関係 → オブジェクト指向の「kind of」
構成の親子関係 → オブジェクト指向でいう「consists of」
ある用語はそれ単体で存在するものではありません。用語同士のつながりがあります。用語同士のつながりの中でも、抽象度の親子関係、構成の親子関係が特に重要です。マインドマップでメモを取ると、整理しながら用語を獲得することができます。
用語を含む重要と感じた文章を、トピックの下に書き起こしていきます。文章と共に用語を獲得するのが学習において本質的だからです。
英単語集には、単語の意味だけでなく例文も添えられています。単語がどのように用いられるのかと、どのような意味なのかは本質的に不可分です。日本語で新しい分野を学んでいくときにも、ある用語がどのような文章で用いられるのかをセットで学ぶと効率良く理解を蓄積できます。
主観的に「面白いな」「そういうことか」「なるほど」と感じたことは 気づき の配下にメモします。
記憶に残りやすいのは感情が動いたときです。脳の長期記憶のメカニズムがそのように作られています。感情が少しでも動いたなと感じたことをメモしておくと、効率良く知識化していくことができます。
ベースの知識を身に付けた後の「教えてもらい方」
学校で習ったり、自分で学習したりする機会は少ないのですが、「教えてもらう」ことにもノウハウがあります。
インタビューの技法の中から参考となる技法を紹介します。
ラポール(信頼関係)作り
仮説を示しながら質問する
ラポール(信頼関係)作り
関係性のない相手に対しては、ラポール(信頼関係)作りは特に配慮すべきです。
「これから教えてもらう関連領域を事前に学んでいる」というのは敬意を持った振る舞いであると思います。ぜひ前項の学習のプロセスを経た上であれば自信を持って取り組んでほしいと思います。
信頼関係作りには、セットされた場ではなく、日常の業務中から細かくコミュニケーションを取るのが基本です。この信頼関係で重要なポイントは、
相手(専門家)のことを(あなたが)知っていると思ってもらうこと
相手(専門家)に自分(あなた)のことを知ってもらうこと
当たり前のことですが、ドメインの知識の有無にかかわらず、知らない人とコミュニケーションを取ること自体、負荷が高いです。そのハードルを下げるために1の活動が大事と捉えます。雑談から日々の業務の忙しさとか、そういう細かなコミュニケーションがそれを実現していくかと思います。その際には、以下のポイントを押さえると良いでしょう。
相手の仕事への関心を示す
どういうところがすごいと認識しているか
どこが面白いところだと認識しているか
また、2の相手に自分のことを知ってもらうことも大事です。自分はどういう人間であり、日々どういう業務をしているかなど、自己開示をし、自分がどういうところに興味を持っているかを伝えることで、専門知識を教える際の相手側の納得感を生むことができるからです。
知っている・知られているの関係性の構築によって、ラポール(信頼関係)が築かれます。
仮説を示しながら質問する
日々の活動で信頼関係を築いたら、専門家にドメイン知識を教えてもらう場をセットしましょう。そこでは、コミュニケーションの取り方のポイントを押さえると良いと思います。信頼関係があっても、質問にまとまりがないと、相手への負荷が高まり、持続的に教えてもらう機会を設けにくくなります。
コミュニケーションのポイントは、以下の2点です。
自分の仮説・考えをあらかじめ準備し、クローズドクエスチョンを4〜5個程準備しておく
自分では答えを出せない領域において、相手にオープンクエスチョンを投げかける
ゼロベースで回答するのは、説明する側の思考体力が必要です。「私はこう思っているのですが、合っていますか?」という趣旨の問いだと、説明する側の負荷も下がり、会話の進行がスムーズになります。
仮説が間違っていても、YES/NOで答えられる質問を提示することが大事なので、NOだったとしても問題はありません。
リアルタイムに議事録を取りながらインタビューする
教えてもらった後に、自身の中で反すうしたり、他者へ展開したりすることもよくあるでしょう。そのためにも教えてもらう場で、議事録を取っておくことが大事です。
その場でわかったつもりになっても、細部まで覚えていなかったり、口頭での認識合わせがうまくいっておらず曲解してしまったり、ということはよくあります。
また、議事録を取ることによって、相手が「自分の話をちゃんと聞いてもらっている」という実感を得やすくなり、より前向きな場になるでしょう。
プログラマーはタイピングが速い人が多いと思います。議事録はその強みを活かす絶好の機会です。
最初にメモを取ることの断りを入れてから、議事録を取ることをおすすめします。
まとめ
エンジニアがより良いプロダクトを作るためには、1次情報をとりに行くことが必要不可欠な状況になりつつあります。そのためには、ドメインの知識を最低限携えて、現場に自ら入っていく必要があるでしょう。
そのための大きな学習の方向性としては以下の2つがありました。
語彙を身に付ける
近くの専門家に教えてもらう
1に関しては個人で行える活動であり、なるべく学習のハードルが下がる方向に工夫をするのが良いです。そのために、ラジオやYouTubeの視聴だったり、入門書を読んだりして、インプットの負荷を下げましょう。
2に関しては信頼関係を築いた上で、教えてもらう場をセットするのが良いです。専門家と、知っている・知られているの関係になってから、ちゃんとしたインタビューの場をセットし、説明する側の負荷を上げ過ぎないようにコミュニケーションに工夫を施しましょう。
これらの活動を通してドメイン知識を身に付けることで、自分自身がより強い納得感を持ってプロダクト開発をできるようになり、それがチームメンバーのやりがいの大きさにもつながります。ぜひ、実践してプロダクト開発に活かしていきましょう。