DDDに詳しい松岡幸一郎さんをお招きしました

以前から親交があり、創業時からブログ等を参考にさせていただいていた松岡さんを弊社にお招きし、社内勉強会を開催しました！

3/08 19:00 ~ は、松岡さん主催の1100人以上が集まるオンライン勉強会が行われました！

GOLDスポンサーをさせていただきました！

「ウチも社内でDDD勉強会をやってほしい！」という方は、是非松岡さんにお問い合わせ下さい！

BtoB SaaSスタートアップだからこそ、DDDを

ログラスは、経営企画向けのSaaSを提供するスタートアップです。
会社の概要は以下を。

我々は、“BtoB SaaSスタートアップだからこそ、DDDを”と考えています。

DDDにおいて、ソフトウェアがどのアーキテクチャを用いるか？は決してコアな部分ではありません。
Eric Evansは、DDD Referece（PDF） で、以下のように書いています。

Domain-Driven Design is an approach to the development of complex software in which we:
1. Focus on the core domain.
2. Explore models in a creative collaboration of domain practitioners
and software practitioners.
3. Speak a ubiquitous language within an explicitly bounded context.

ここで言うモデルとは、Eric Rvans曰く

ドメインの特定の側面を表現し、そのドメインに関連する問題の解決に利用出来る抽象化されたシステム
※ DDD Referece（PDF） より

まとめると、
ドメインの真の関心事に集中し、ソフトウェア開発者とドメインに関わる者（セールスやカスタマーサクセス、何より顧客）が（境界付けられたコンテキストにおいて）共通の言葉を用い、システムをそのドメインに関連する問題の解決に役立つように発展させていく開発手法そのものが、DDDだと私は理解しています。

BtoBだからこそ、DDDを
SaaSにおける著名VCの一つであるBEENEXTの前田ヒロ氏は、PMFを達成するために必要な「4つのフィット」として、プロダクトフィットを最初にあげている。

まず達成すべきは、ターゲットとなる顧客が持つ『課題』に適したプロダクト/ソリューションを提供すること。そして、高い顧客満足度を得ること。

BtoB SaaSは、顧客の業務において、“お金を払ってでも、今すぐ解決したい！”という『課題』を解決する為に存在します。
それが、頻繁に直面するものであったり、従来の方法では解決にコストがかかるものであるほど、SaaSとして取り組む価値が高まります。

BtoB SaaSのプロダクトフィットが難しいのは、ソフトウェア開発者はドメイン（対象の業務）に関して通常は無知であるにも関わらず、個社毎のカスタマイズを行わず、高い顧客満足度を得られる様なソリューションを提供する必要があることも一つの要因です。

顧客だけが知る、そのドメインでは常識と言える知識が膨大に存在し、プロダクトのUXに大きく影響を与えます。
業種業界特化型のVartical SaaSであれば言うまでもありませんが、弊社のようなHorizontal SaaSであっても、それは変わりません。

同じくHorisontal SaaSのSmartHR社でも、ある社員（10年以上の労務担当者の実務経験のある方）からの愛のある指摘から始まる全社的な改革は必読です。

率直に言うと「まったくこれは労務の現場では使えません」ということがつらつらと書かれていて、私たち開発者は「やばい」と。「なんでこんなことになってしまったんだ。ヒアリングとはなんだったのか？」という感じで、心臓がざわざわするような経験をしました。

我々もこんな組織を目指したいものです。


我々は、β版の設計時よりもずっと前から、エンジニアとドメインエキスパートである社長、共同創業者、外部の協力者の方とで徹底的に認識のすり合わせを行ってきました。

こんな風に、膨大な量のGoogleドキュメントで、モデルや、対象のドメインについて非同期にも意見を交わし、スキーマ設計のレビューまで行うことで、エンジニア、非エンジニアで共通の言語として整理してきました。

※注: 現在とは、かなり仕様が違います

勉強会当日の様子

非エンジニアも巻き込んで、DDDの基本を教わる

松岡さんにアドバイスをいただきつつ、社長、共同創業者も参加して、今回テーマにした「予算策定の経営企画のユースケース」を次々書き出していく。

ホワイトボードで今回対象にしたモデルの特徴、制約、他のモデルとの関係を書き出す。松岡さんの助言もあり、モデルがより鮮明になっていく。

勉強会を通じて、今回対象にした狭いドメインについては話し尽くしてきたはずなのに、まだまだ発見がありました。エンジニアとビジネスサイドが同じ言葉で業務のモデル化に取り組む大きな意義がここにあります。

社内にドメインエキスパートがいることは、良いプロダクトを作りたいエンジニアにとって非常に良い環境と言えます。

勉強会で分かったログラスのコード課題

勉強会の後、エンジニアと松岡さんで個別のコードについても相談させていただきました。
短時間でしたが、得られた学びは以下です。

・Serviceがユースケースに即した形式で記述されていないものが少なくない
・一部のRepositoryで、テーブルそのままのモデルを返している

今後の改善方針

Repository

・Repositoryは、エンティティを返すものに変えていく
・Repositoryは、エンティティを取得、保存するだけの、I/Fとしては、ListやMapでMock出来るぐらいシンプルなものにしよう。

Service（ユースケース層）

・現状のように、Serviceでエンティティを作成しない。ユースケースで記述する。
・Serviceという名前を避け、きちんとJavaDocを書けるようなクラスを作成しよう。Serviceは、Builder、Factory、ReConstructor、Converter、XXUseCaseなどの具体的に何をするクラスなのか？が分かるものにしよう。

今後も、ログラスはエンジニアがコードを誇れるチームであり、コードとビジネスが共に進化するチームを目指していきます！

We are hiring!!!

Loglassは経営の中枢ど真ん中に入り込むエンタープライズSaaSスタートアップです。

少しでもご関心を頂けた方はWantedlyからぽちっとご連絡して頂ければ！！
ぜひランチや、オンライン、オフラインでお話しましょう！！