※この記事は 2021年12月02日に Medium で公開されたものを、ブログ移行に伴い再掲載したものです。内容は当時のままですので、一部情報が古くなっている可能性があります。
この記事は AWS Startup Community Advent Calendar 2021 の2日目の記事です。
弊社が提供する「現場向け動画教育プラットフォーム tebiki」は法人向けクラウドサービスで、一般的には BtoB SaaS と分類されます。 今回はこういった「BtoB のプロダクトを作る上でドメインエキスパートという存在はどれくらい重要か、ドメインエキスパートに活躍してもらうにはどうすればよいか」について書いてみたいと思います。
（渋谷 @shibukk）
ドメインエキスパートとは何か
皆さんは「ドメインエキスパート」という言葉を知っていますでしょうか？エンジニアの方だと聞いたことがある人のほうが多いかもですね。
私がこの言葉を一番最初に聞いたのはドメイン駆動設計（DDD）の文脈でした。 2003 年に刊行された DDD の原典である『エリック・エヴァンスのドメイン駆動設計』ではドメインエキスパートについてこのように解説されています。
”ドメインエキスパート（domain expert） ソフトウェアプロジェクトのメンバで、ソフトウェア開発ではなく、アプリケーションのドメインの担当者。ソフトウェアの単なるユーザと違い、ドメインエキスパートはその対象に関する深い知識を持っている。” エリック・エヴァンスのドメイン駆動設計 ― Eric Evans
ざっくりまとめると「開発しているソフトウエアの適用領域（ドメイン）に深く通じている人」を指します。会社によってはドメインスペシャリストと呼ぶところもあるようです。
BtoBにおけるドメインエキスパートの重要性
BtoB のソフトウエア開発においては特に、このドメインエキスパートがチーム内にいることが重要となります。
例えば ISO9001 という品質管理の国際規格があるのですが、その取得要件として文書管理における変更履歴が必要であると定められています。その変更履歴にはどんな項目が必要かをご存知でしょうか。
検索するとすぐに資料は出てきますが、実はその資料そのままの現場は意外と少なく、各社それぞれが独自のフローで運用していたりします。 BtoB だとエンジニアがリアルな現場に触れる機会が少ないので、想像するのが難しいですよね。
ここでドメインエキスパートの登場です。彼らはドメインを深く理解しているので、数ある運用のバリエーションをどう解釈すべきかの示唆を与えてくれます。この示唆により、我々のチームはどの課題を解決すべきかを判断できるのです。
もしドメインエキスパートがいないと BtoB 特有のビジネス構造や業務フローといった実務の解釈を誤り、結果として顧客の課題を解決しないソリューションを生み出してしまう可能性があります。
たとえば ISO9001 のために変更履歴を作ろうとしたはずなのに「変更した箇所が見れればうれしいとユーザーインタビューで聞いたので、GitHub のように変更点が diff で見れる機能を提供しました」みたいなことになってしまいます。 （単にいつ誰が更新したかのログだけがあればほとんどの顧客の課題は解決できるのに！）
正しいソリューション、つまりプロダクトのあるべき姿を導き出すには、ドメインとプロダクトが解消しようとしている課題を結びつけるロールが必須なのです。 ※1 ※2
BtoB のプロダクトを開発している企業でドメインエキスパートの求人が急増しているのも、現実世界をどうデジタル化していくかという DX の観点から、よりドメインの知識が重要と見なされるようになったからでしょう。
ドメインエキスパートが活躍するには
ですが単にドメイン知識のある人がいるだけでは、ドメインと顧客の課題を正しく結びつけることはできません。深いドメイン知識を意識的にチーム開発に染み込ませることで、初めてそれが達成できます。 これは弊社のドメインエキスパートである CEO の貴山 ※3 と働いていく中で強く実感したことでもあります。
弊社が染み込ませるために具体的に行ったことは「開発サイクルの初期に組み込む」「要望を分類してもらう」の2つでした。
開発サイクルの初期に組み込む DDD におけるドメインエキスパートは外側のアドバイザーのような立ち位置で描かれがちですが、実務面からのアドバイスだけではほとんど意味がありません。 本来どうあるべきかをチームとともに議論してくれるドメインエキスパートでないと、芯を食ったソリューションは生み出せません。
弊社では ①特定の顧客を想定し ②その顧客が提供しようとしている機能を利用してくれそうかを ③ドメインエキスパートの視点として検証する という行為をユーザーストーリーのタイミングで実施しています。具体と抽象を行き来するみたいなイメージですね。
当たり前のように思うかもしれませんが、意識的にドメインエキスパートの目線からどうあるべきかを担保することで、誰も使わない機能は作らずに済むようになります。
要望を分類してもらう 業務フローという実務一つとってもバリエーションが本当に多岐に渡るため、それをそのまま課題に結びつけてしまうとソリューションも同じだけ必要になってしまいます。 ソリューションを生み出すためのリソースはいつでも有限なので、実務に結びつく課題を導き出すためにもまずはその実務を分類する必要があります。
弊社でも要望をたくさんいただいていますが、必ずしもその要望全ての背景をヒアリングできなかったりします。 そこでドメインエキスパートの観点でユーザーの背景を補足してもらいつつ、要望の分類をやってもらいます。
ドメインと課題の整理イメージ（背景列がある）
これにより、一見ちょっとしたバリエーションが違うだけに見えた要望でも、実はユーザー背景は全く異なるというのを拾えることができ、課題がひと目で把握できるようになります。 これがあるとないのとでは、チームメンバーのドメインと課題への解像度が全く変わってきます。
こうやってドメインエキスパートが活躍する場を用意するだけで、プロダクトがあるべき姿にグンと近づくことができると考えればめちゃくちゃコスパいいですよね。
まとめ
ここまで読んですでにお気づきの方もいらっしゃるかもしれませんが、ドメインエキスパートはプロダクトマネージャーと乳化した存在です。 なので組織が大きくなるまではアジリティを重視してドメインエキスパートとプロダクトマネージャーを兼務する決断も有用でしょう。
弊社でも創業当初から一貫して以下のロールがかなり被った状態となっており、この現象はスタートアップあるあるな気がします。
創業時にスーパーマンが求められてしまうの図
ですが、現在それぞれの責務が大きくなってきたこともあり、この状態の解消が組織的な課題となりつつあります。
【宣伝】 というわけで、もし「デスクレスワーカー」のドメインに興味がある方やプロダクトマネージャーに興味がある方はぜひご連絡ください！エンジニアも絶賛募集中です！ 3.エンジニア の求人一覧 - Tebiki株式会社 Tebiki株式会社が公開している、3.エンジニア の求人一覧ですherp.careers
※1）SmartHRの初期フェーズでも似たような話があったよう
僕が入社した3ヶ月後ぐらいに労務にすごく詳しい人が入ってきたことですね。その人がいなかったら人事・労務の経験がない人達が現場感覚とずれたサービスを作り続けていただろうなと思います。 https://www.tech-street.jp/entry/2021/11/10/122124
※2）ちなみにドメインエキスパートがいない場合でも、ドッグフーディングや商談に同行したりで課題を理解することは可能だったりします
※3）三菱商事時代に食品メーカーを買収して取締役副社長兼工場長に就任して現場の改善をやりきった過去があるので、デスクレスワーカーへの教育というドメインのエキスパートと言えます
