この記事は 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 におけるドメインエキスパートは外側のアドバイザーのような立ち位置で描かれがちですが、実務面からのアドバイスをしてくれるだけではほとんど意味がないです。
本来どうあるべきかをチームとともに議論してくれるドメインエキスパートでないと、芯を食ったソリューションは生み出せません。

弊社では①特定の顧客を想定し、②その顧客が提供しようとしている機能を利用してくれそうかを、③ドメインエキスパートの視点として検証するという行為をユーザーストーリーのタイミングで実施しています。具体と抽象を行き来するみたいなイメージですね。

当たり前のように思うかもしれませんが、意識的にドメインエキスパートの目線からどうあるべきかを担保することで、誰も使わない機能は作らずに済むようになる効果があったと感じています。

分類を委譲する
たとえば業務フローという実務一つとってもバリエーションが本当に多岐に渡るため、それをそのまま課題に結びつけてしまうとソリューションも同じだけ必要になってしまいます。
ソリューションを生み出すためのリソースはいつでも有限なので、実務に結びつく課題を導き出すためにもまずはその実務を分類する必要があります。

弊社でも要望をたくさんいただいていますが、必ずしもその要望全ての背景をヒアリングできなかったりします。
そこでドメインエキスパートには下の Excel にある背景の列を補足してもらいつつ、その背景をベースに要望の分類をしてもらいます。

ドメインと課題の整理イメージ

これにより、一見ちょっとしたバリエーションが違うだけに見えた要望でも、実はユーザーの背景は全く異なるということがひと目で把握できるようになります。
これがあるとないのとでは、チームメンバーのドメインと課題への解像度が全く変わってきます。

こうやってドメインエキスパートが活躍する場を用意するだけで、プロダクトがあるべき姿にグンと近づくことができると考えればめちゃくちゃコスパいいですよね。

まとめ

ここまで読んですでにお気づきの方もいらっしゃるかもしれませんが、ドメインエキスパートはプロダクトマネージャーと乳化した存在です。
なので組織が大きくなるまではアジリティを重視してドメインエキスパートとプロダクトマネージャーを兼務する決断も有用でしょう。

弊社でも創業当初から一貫して以下のロールがかなり被った状態となっており、この現象はスタートアップあるあるな気がします。

創業時にスーパーマンが求められてしまうの図

ですが、現在それぞれの責務が大きくなってきたこともあり、この状態の解消が組織的な課題となりつつあります。

［宣伝］というわけで、もし「デスクレスワーカー」のドメインに興味がある方やプロダクトマネージャーに興味がある方はぜひご連絡ください！エンジニアも絶賛募集中です！

現場の未来を動画技術で切り拓く Tebiki株式会社

現場の教育はOJTだけという長年の課題に、ネットワークと動画の技術で新たな仕組みを作ります。 時代の変化とともに仕事はますます複雑になり、スタッフの国籍は多様化し、現場教育の効率は落ちていく一方です。 ...

tebiki.co.jp

※1）SmartHRの初期フェーズでも似たような話があったよう

僕が入社した3ヶ月後ぐらいに労務にすごく詳しい人が入ってきたことですね。その人がいなかったら人事・労務の経験がない人達が現場感覚とずれたサービスを作り続けていただろうなと思います。
https://www.tech-street.jp/entry/2021/11/10/122124

※2）ちなみにドメインエキスパートがいない場合でも、ドッグフーディングや商談に同行したりで課題を理解することは可能だったりします

※3）三菱商事時代に食品メーカーを買収して取締役副社長兼工場長に就任して現場の改善をやりきった過去があるので、デスクレスワーカーへの教育というドメインのエキスパートと言えます