ChatWorkとネクストビートのDDDに対する考え方～Nextbeat (衣笠) x SmartNews(瀬良) x ChatWork(かとじゅん)トークセッション2-3～

今年3月に開催された ScalaMatsuri (https://2018.scalamatsuri.org/) の後日イベント「NextMatsuri」を5月12日にネクストビートの恵比寿本社で開催いたしました。当日、スマートニュースの瀬良様と、ChatWorkの加藤様にご来社頂き、当社CTOの衣笠とトークセッションを開催させていただいたのですが、その内容が非常に濃かったので、何回かに分けて配信させて頂いております！

過去記事：

【エンジニアイベントvol.6】3社はなぜScalaの導入に至ったのか～Nextbeat (衣笠) x SmartNews(瀬良) x ChatWork(かとじゅん)トークセッション①～

今回は、登壇者とイベント参加者様のQAセッションの模様を配信します。

Q- 私の会社では DDD とスクラムを採用して、開発に関してストーリーポイントを見積もったのですが、これなら簡単だよねと思っていたこともやってみたらめっちゃリファクタリングいるじゃん、と全然見積通りにいかないということが結構あります。そのあたりのコツがあれば伺いたいです。

加藤：

それは新規案件ですか？それも既存の改修ということですか？

質問者：

既存もあり、新規もあり、両者が絡み合っている感じです。

加藤：

スクラムのスプリントプランニングでストーリーポイントを見積もってやっているが、バーンダウンしていないという状況でしょうか？思い通りに行かないという状況でしょうか？

質問者：

そうですね。

加藤：

DDDを採用するという観点でそこを気にしているのならば、みんなまだモデル駆動にするのに慣れていない状況か、慣れているならモデルに関する議論が収束していないということかと思います。

実はドメインモデルで考えることは、オブジェクト指向で考えるのでデータモデルより難しいです。なので僕のおすすめはまずユースケースをちゃんと書いてみることです。アクター(※1）がこのシステムに求めることを曖昧な表現ではなく、日本語で明確に主語・動詞・目的語みたいな形で、プロジェクトで使える用語としてちゃんと定義すると、名称はモデル候補になります。アクターはシステムの外側なんで、「ユーザー」といっているものが実は「ユーザーアカウント」だった、みたいな話をユースケースを分析することで見えてきます。そのモデルを自立的に動作させるかという点では、例えば銀行口座だったら口座は受け身じゃなくて「口座自身のオブジェクトは何かサービスをするはずだから、振る舞いを持つはずだ」みたいな議論を最初にやっておかないと、コードを書き始めても意図したモデルの実装にはならないはずです。

実際のモデリングをやるときは、ユースケースからモデルがどんな姿であるべきか、ユーザーストーリーマッピングをしながら付箋にユースケース名を書いていって、最初のリリースで達成したいこと（MVP※2）を決めると思いますが、モデル図も書いていきます。ユースケースがよくわからなかったら、GUIのモックアップも書きます。それでモデルがイメージできたら、モデル図も更新します。これをやって1スプリント分の目標みたいなものを設定できたらそのまま開発するだけ。

問題がドメインモデル以外だったら、スクラムの問題とかXPとかアジャイルの開発の進め方の問題になると思うんですけどね。そのあたりはどっち側になりますか？DDDに起因するところなのか、DDD以外のプロジェクトの運営の問題なのかどちらですかね？

質問者：

どっちもあるんですよね。

加藤：

どっちもあるんですね。どっちが大きいかと考えると、大きい方を優先して問題解決していくのが良いかと思います。

衣笠：

あとは作り方の観点でいくと、ユースケースを考えていくときに素直にユーザーの動き方のラインをつくりつつ、例外処理を一番最初から考えすぎないのも重要かと思います。

最初に例外処理が起こるかもしれないからこういうコードをつくりました、等のデータの持ち方やフローを入れない方がいいときもあります。

結局、例外処理を作っても数千件に1回しか走らない処理だった場合、誰がはじめからそれをメンテするのかという話にもなってくるので、はじめはシンプルに作りあげるというのがテクニックかもしれないですね。

ロジックが複雑になった時にコードの可読性の点で、いろんな処理がいろんな関数にまたがってループしているような状況を避けるために、どういうふうに関数へアクセスするか、「ルールや実装レベルの落とし方」を社内的に決めておくというのも良いかもしれないですね。

瀬良：

私も質問していいですか？私は DDD を実践したことはないのですが、DDD をやっていない開発現場においても、やりたいことはエンジニア同士でデザインドキュメントを軽く書いて議論をしていくということはよく行われると思います。そのタイミングではすでにやるべきことはざっくり決まっていることが多く、なぜやるのかそもそも論の議論にあまりならず「これやりたいけどシステム的にこういう感じでやっていいと思いますか？何か考慮漏れはないですか？」という設計・実装レベルの話をすることが多いですね。

今の話を聞いていると、モデリングだけでも非常に難しくエネルギーを使うために、モデリングの議論のタイミングで「今データストアこういう状況なのでそれは難しい」というような意見・論点は「議論が発散してしまうからこの場では一旦置いておこう」ということなり、その場ではモデリングに終始するということが起きうるのかなという気がしました。

そのような場合、そこでモデリングについては確定したものの、その段階ではシステムデザインが終わっていないということは起きそうですね。そこから後半戦として別途システムデザインをしっかりやるのかと思いますが、そういうものでもないのでしょうか？また、うまくいっていないケースは、実はその後工程が抜けているということがあるのではないかと思いました。

加藤：

おっしゃる通りですね。

システムデザインも最初から全部は見れないので、まずユースケースからモデルを洗い出すことを優先しています。例えば、モデルAとBがそれぞれ独立したトランザクション境界を持ち、それに対応するエンドポイントAとBがあります。さらに、モデルAとBを一つのトランザクション境界で更新するユースケースを追加した場合、そのままやってしまうとロックが競合してしまいます。そのユースケース使っている間、他のユースケースの更新が失敗する可能性があるのですね。こういったユースケースの精査でもシステムデザインの一部だと思っています。こういったプロセス上で、整合性の境界を「結果整合」にするか、「強いトランザクション整合性を求めるか」というのを最初に最低限決めてます。

モデルを議論する時点で、ある程度整合性は考えますが、実際実装に落とし込んでみたらどうなるのかというのは、コードをみながら細かく検討していく必要があります。

瀬良：

そういうことを話した後、ドキュメント化していくときに良いフォーマットとか、やり方みたいなものはあるのですか？

加藤：

DDD だとフォーマットはその場の会話のコンテキストに必要な仕様を伝える目的に沿った絵を自分たちで考えて書こうとされています。ホワイトボードにUMLを崩したような図でもよいです。絵や図、それ自体が重要なのではなくて、絵や図が示そうとする考え方が重要です。そういう目的に沿ったドキュメントの表現だったら良いとされています。

議論の場で説明するためだけの図もよく書きます。そういった説明のためのモデルを使うことで理解が深まることが重要で、形式ありきではないというスタンスですね。

瀬良：

現実的に議事録は取らないかもしれないですが、システムレビューでなぜこういう形にしたのか見返すなど、他のチームが「なぜあのチームはあの意思決定を行ったのか」ということがわかるので、ドキュメントがあれば割と助かるかと思います。

モデルはこう作った、最終的に完成した綺麗なモデルじゃなくてそのモデルに至る思考の工程を後でトレースできると、例えば DDD を後からやろうと思ったチームにもすごい参考になるかと思いました。

一般論としてはこうだけど、ウチはこういった事情があるからあえて崩しているとか、崩している経緯は slack のこの辺りのやりとりを見ればわかるとか、リンクが張ってあるとか、そういうのがすごく助かります。

加藤：

おっしゃる通りで、僕が言ったのは DDD の一般的な考えですけど、それだけだと瀬良さんいったようなトレースできない問題があるし、チャットだとフローなので結果的にあとから苦労するのですよね。必要なのは、ストック＋フローなのですよね。

そうするとストックで歴史的な経緯とか・意思決定のプロセスがわかる資料が必要になります。どんな形式なのか、その形式はチームごとに変わると思います。意味合い的にはそういうものがあると良いなと思います。

衣笠：

弊社も Confluence を使っていて、「マニュアルを最新状態に保とう」というルールではなく、どちらかというと「記録を残そう」というルールで使っています。

1つ1つのプロジェクトに関して過去に書いたものを修正する必要がないので、とにかくプロジェクト単位でスペースをつくって、過去の記録を残していくような書き方にしています。新しく入った人が、そこから見えるものがたくさんあるので、そういう書き方にしています。

これってデザイン観点でも同じで、後から入った人が今のサービスのデザインを見た時に、なぜこんなデザインになっているのだろう、と過去の記録がないとわからない状況になります。

一番最初に考えたコンセプトがあって、そこから肉付けされ、ある一定の期間でリニューアルされた、といったところをわかりやすくするためには、デザインにおいても定期的なスナップショットを印刷するのが良いと思っています。

私が関わっているプロジェクトに関しては週に１度画面が変わったところだけ印刷してファイリングし、キングファイルにめっちゃためています（笑）もし新しく入った人に「過去のサービスどんな感じだったの」と言われたら、ファイル抜き出して「遍歴を見てください。」と言っています（笑）

※1：アクターとは、UMLユースケース図で用いられる、システムの外部に存在してシステムと相互作用する、特定の目的と役割を持つ存在で、人や組織、外部システムなどをいう

※2：最初のリリースで達成したいこと、MVP（Minimum Viable Product）

※3：「状態」ではなく、何が起きたか「イベント」だけを記録し、記録されたイベントを順番に再現することで同じ状態を再現できるという考え方

NextMaturiのレポートはまだまだ続いていきます！続編を楽しみにお待ちください！

ご参加いただいた皆さん、ありがとうございました！

これからも共にScalaコミュニティーを盛り上げていきましょう！

ネクストビートは一緒に働く仲間も募集中です。ご興味お持ちの方は是非お気軽にご連絡ください♪

興味をお持ちいただけた方は、Wantedlyで掲載中の募集職種から、ご連絡ください。Wantedly以外の経路より優先して選考のご案内を差し上げます。選考ではなく、まずは話を聞いてみたいという方も、現時点でご関心がある職種の募集ページからご連絡お願いいたします。