※この記事はnoteからのコピペです。

バーティカルSaaSで良く使われる設計手法にドメイン駆動設計（DDD）があります。自分がこの概念を知ったのは今年が初めてで、いかに日々の活動に落とし込むかを手探り中です。この中で創業初期の探究フェーズ=ドメインの解像度を高めている段階における気づきがいくつかあったので、noteに纏めておこうと思います。

ドメイン駆動設計とは？

Wikipediaによると、DDDとは以下の設計手法のことを指します。

ドメイン駆動設計（英: domain-driven design, DDD）とはソフトウェアの設計手法であり、「複雑なドメインの設計は、モデルベースで行うべき」であり、また「大半のソフトウェアプロジェクトでは、システムを実装するための特定の技術ではなく、ドメインそのものとドメインのロジックに焦点を置くべき」であるとする。

Wikipedia

この名称は Eric Evans 氏が2004年に発行した同名の著作の中で用いたとされ、同著はこの分野におけるバイブル的な存在となっています。

そもそも何かのプロダクトを作る際、対象となるユーザーとそのコンテキストを理解する必要があります。特にバーティカルSaaSの場合、ユーザーのコンテキストは同業種の同じ部署なら一定のコンテキストを共有しています。メーカーならメーカー、金融なら金融のプロトコルがあり、企業によって完全一致はしないまでも、かなり似たようなやり方で日々の業務を遂行しています。DDDではこれをドメインと呼びます。

難しいのはこのドメインというものが、観察者や解決したい課題によって変わることです。製造業と言っても製品の種類（to B/to C）、部門、生産方式（セル型orライン型）などによってドメインの切り方は無限に存在します。また当然企業ごとの揺らぎもあるので、ドメインの唯一絶対解というものは存在しません。解決したい課題とユーザー、両方の境界をかなり意識的に設けないとカオスな状態を生みます。

選択したドメインが事業の方向性を支配する

SaaS型のプロダクトは同じソフトウェアをマルチテナントに対し提供していくため、このドメインの定義が今後の事業展開に大きく影響すると考えています。プロダクトが進化する前提だとしても最大公約数的なドメインの選定、TAMを広げていけるだけの拡張性を持った設計など、考慮すべき要素が沢山あります。創業初期の、プロダクトもチームもふわっとした状態を具体に落とし込む意思決定は本当に難しい・・・

創業初期のチーム

チームの話になりますが、創業初期はエンジニア、ハスラー、デザイナーの三人の組み合わせが良いとされています。Thingsも1月からこの体制になります。

一般的に理想的だと言われている創業チームの構成は、「デザイナー・ハッカー・ハスラー」の3者から成っています。Airbnbの創業チームが典型的な例です。Joe Gebbia氏が「デザイン」したプロダクトを、Nathan Blecharczyk氏が開発し、Brian Chesky氏がCEOとして「ハッスル」、つまり資金調達から採用、その他全ての必要な業務を率いたのです。

成功するスタートアップチームの共通点
by Coral Capital

この3人に加え、ドメインエキスパートがいれば0→1フェーズのバーティカルSaaSにおける最低限の役者が揃います。

エンジニア

ソフトウェアを設計してコードを書く人たちです。実際に顧客に納品するプロダクトをアウトプットとするため、具体のレベルがチームの中で最も高い存在です。DDDにおけるエンジニアはかなりビジネスに接近しながら、抽象的なドメイン理解を設計に落とし込む蒸留作業を行っています。

デザイナー

デザイナーは人間観察のプロです。何度かつよつよのデザイナーのユーザーインタビューに同席させてもらいましたが、FBIの方ですか？と思うほど相手の行動や表情を観察されていました。ペルソナやカスタマージャーニーを用いてチームの共通理解を醸成しながら、概念に形を与えていきます。

ハスラー（ビジネス）

ビジネスサイドの一番の関心ごとは雑に言えば「それが儲かるか？」です。ミッションやビジョンを現実世界で成立させる為に資本主義の仕組みを駆使して、継続的に目的を達成できる仕組みを構築することを生業としています。マーケットイシュー、収益構造、顧客の課題、競合（代替手段）などに目を光らせ、成約というゴールから逆算したプロダクト設計という視点を提供します。

ドメインエキスパート

ドメインエキスパートの定義はこちらのブログが非常にわかりやすかったのでご参照ください。

エリック・エヴァンスのドメイン駆動設計by Eric Evans自分の知っていることを蒸留して本質を抽出するように強いられることによって、しばしば自分の理解を精緻にし、ソフトウェアプロジェクトが必要とする概念を理解するようになる。

業界についての専門知識を有し、チームのドメイン設計をサポートしていく存在です。平たく言えば業界の専門家です。

メンバー同士の専門領域を超えた探究活動

DDDの難しさはドメインの定義が即設計に反映される点だと思います。今の体制ではハスラー、デザイナー、ドメインエキスパート的な振る舞いを自分がしていますが、生半可な理解でドメインを定義しようとして何度か派手に失敗しています。

何とかこのドメイン駆動設計を組織の型に昇華させようと模索する中、マインドとして納得感が高い文章に出会いました。

1.　ドメインエキスパートも自分の業務を知り尽くしているわけではない。 ドメインエキスパートから学ぶことはもちろん多いが、ドメインエキスパートが開発者から学ぶことも大いにある。チームで（ドメインエキスパートｘ開発者）学び成長いくことでソフトウェアで必要な概念を理解していくということでしょう。ドメインエキスパートだけでも、開発者だけでもソフトウェアは作れない。

2.　リードは開発者がする ドメイン駆動設計は設計とソースコードが一体化しています。だから必要な知識の噛み砕きは開発者がリードして会話していくことが多いでしょう。 また、ドメインエキスパートは業務に必要な知識を有していますが、プロジェクトに必要な知識以上に知っています。開発者がリードしてプロジェクトに必要な知識を蒸留していきましょう。

ドメインエキスパートは誰だ！〜ちょっとずつ読むIDDD 1by @YasuhiroKimesawa(株式会社ZOZO)

DDDにおいてはソフトウェアはドメインの写像となるため、エンジニア以外のメンバーにも一定のソフトウェア理解が求められます。最低限の勘所が無いと必要な知識を蒸留する工程に支障をきたすためです。一方でエンジニアにも必要な知識をドメインエキスパートから引き出すための、実務/ビジネスへの踏み込みが求められます。尚、この関係性はエンジニアとドメインエキスパートのみだけでなく、プロダクトに関わる全てのメンバー間で成り立ちます。

メンバー全員が軸足となるスキルを持ちつつ、他の領域にオーバーラップした理解を持つ必要があるため、それなりにアクロバティックな習得が求められます。理想状態を築くにはどうやら特効薬は無く、地道に対話を続ける以外の方法は無さそうです。一方この型が定着すれば、それはカルチャーと呼ばれるThingsの見えない重要資産になると考えています。

DDDの良い点は、より理想的なドメインを探求する過程で各メンバーが対等に会話できる事だと思います。誰かから誰かに対して「教える」では無く「互いに理解を深める」事を反復する事がそもそもドメインを探求するという行為に内包されています。

ドメインは観測者や解決したい課題によって姿を変えるため絶対解はありませんが、より良いアングル、定義を探求する過程でチーム共通の理解が生まれ、プロダクトのアンカーに昇華されていくのだと思います。