エンジニアはどうDDDと向き合っていけばいいのか(1):ChatWork株式会社テックリード加藤さんインタビュー

今回はChatWork株式会社のテックリードでいらっしゃいます加藤潤一さんです。
少し技術的な内容になりますが、ドメイン駆動設計(以下 DDD)・リアクティブシステムといった話を中心にお伺いしました。

DDDを適用しやすいソフトウェアとは

愛宕　最初はやはりまずDDDについてお伺いしたいと思います。DDDというと、エリック・エヴァンスのドメイン駆動設計という本が有名です。その肝心な部分としてはソフトウェアエキスパートである開発者も、ドメインエキスパートと一緒にユビキタス言語を作りながら対象の問題を分析・設計していきましょうというようなものだと思うのですが、少し疑問があります。DDDを適用しやすいソフトウェアとそうでないものはあるのでしょうか？

加藤　基本的にプログラミング言語の制約はほとんどないと考えていますが、最初に考えたいことは、費用対効果に見合うかどうかを考えたいですね。システムの開発だけではなく運用まで含めたライフサイクルにかかるコストと効果のバランスで考える必要があります。

ソフトウェアプロジェクトでは専門家同士でコミュニケーションをして、日々の改善活動に結びつけていくのがDDDの真骨頂です。コミュニケーションにドキュメントや図だけでなく言語を使うことは必要不可欠ですが、DDDでは複雑で膨大な知識を体系化する手段としてユビキタス言語で表現されたドメインモデル(=問題を解く考え方)を使います。このような視点が、今まで少し違うところです。DDDでは、技術指向ですべてを解決するのではなく、問題領域に対する考え方を重視しています。こういう話を聞くと性能などの非機能面を軽視しているのか、と言われそうですがそうではありません。非機能面も含めて解く問題とするのであれば、それが分析・設計・実装を単一で扱うドメインモデルに現れてくるということになります。

しかし、それが目的でないようなプロジェクトに対して、DDDを適用しても効果的ではないということも事実です。例えば、緊急で作って捨ててしまうようなソフトウェアにDDDを適用してしまうのはオーバーですよね。もちろん、利害関係者の頭の中にはドメインモデルはあるはずです。しかし、結果的に捨ててしまうソフトウェアに対してはフィードバックループを回す必要がないので、DDDとは違うアプローチ(トランザクションスクリプトやSmart-UIなど)に費用対効果があるならばそれでもいいかもしれません。

ただ、そういったソフトウェアが何らかの理由で予想外に生き残って、継続的な開発が必要とされることもありえます。経験上からも、作ってすぐに捨てるようなことは、そんなに起こらないんじゃないかと思っています。ユビキタス言語を使って利害関係者同士で意図を伝え合うという考え方を意識できていない場合は、ドメインモデルがチーム内の会話・ドキュメント・図・最終的な成果物であるコードにも現れにくくなります。そのような環境で育ったコードは読んでも、設計の意図を汲み取ることが簡単ではありません。最悪なケースでは、メンテナンスコストの上昇であったり、事業の変化や成長にソフトウェア活動が追従できないなどの問題がありえます。まぁ、このような事態はよく起こるのですが、普段からドメインモデルを重視する考え方の一部でも実践して備えておくのも一考の価値はあると思います。

また、ドメインエキスパートのイケてない用語をユビキタス言語として採用して、ソフトウェアに反映しなければならいと誤解しているエンジニアをまたに見かけます。しかし、そうではありません。その道の達人といえる、ドメインエキスパートであっても、ドメインに対する表現に漏れやダブりがあったりします。彼らはそのような矛盾を頭の中で辻褄を合わせて理解しているかもしれませんが、議論で使われる表現には論理的不整合があるかもしれません。そういうときに、緻密に論理思考可能なエンジニアが適切な”国語”を使って、違和感のない整合性のとれた概念に落とし込む必要があります。分析や設計で本当に必要だったのは、国語を使ってお互いコミュニケーションしながらソフトウェアに反映することだったんですね。まぁここが一番難しいところなんですが…。

話を戻します。論理的に破綻している概念は、ソフトウェアに反映できないのは言うまでもありません。ドメインエキスパートとの言語を使ったコミュニケーションが、深い分析・設計の視点において必要です。

このユビキタス言語をうまく使えば、新しいモデルを発見することも可能です。人材ドメインの例で言えば、有益な振る舞いを持つ「正社員」と「アルバイト」というドメインモデルを考えていた場合、「パートタイム」のユースケースが入ってきたらモデリングを考え直すよい機会です。そこで、チームで議論し、既存のモデルをヒントに抽象的な「ワーカー」というモデルを導入します。その「ワーカー」の一種に、それぞれの具象的なドメインモデルがあると考えるのが自然な場合もあります。もちろん、これは一例に過ぎず先読みしすぎるのも問題なのですが、こういうコミュニケーションがその概念の輪郭を正確に捉えていくのだと思います。

愛宕　ある人がある言葉で使われていて、他の分野の人からいうと別の言葉が使われている可能性があると思います。そう言った場合はどう扱うのでしょうか？

加藤　ユビキタス言語では、一つのチームに一つの言語というのが原則です。一つのチームでドメインエキスパートと開発者が別々の言語を使っていると、通訳が発生してしまうからです。通訳すると元々の文脈が欠落してしまうことがあります。通訳はそもそもコストがかかる行為なので、伝達速度が低下しますし、表現の正確さも失われるかもしれません。このような事態を避けるためにユビキタス言語を作るわけですね。

また、ここでいう文脈とは、DDDでは境界づけられたコンテキスト(Bounded Context = BC)と呼びます。モデルの有効範囲と説明されることが多いのですが、簡単にいうとそのドメインモデルを想像している人たちが立っている場所(立場)のことです。たとえば、同じ図形であっても人によっては横顔であったり壺に見える、図と地があいまいなルビンの壺という絵があります。地を白とみるか、黒とみるかで図の解釈が変わってしまうのです。このように、お互いに同じモデルを想像していても、立場によって解釈が違うこともあります。その場合はBCが違うかもしれないと疑うのもありでしょう。その異なるBCがチーム内で暗黙知である場合は、それを投影したソフトウェアに破壊的なリファクタリングが行われるかもしれません。そういう意味ではBCの違いが何かをお互いに意識した方がいいでしょう。

DDDの価値をエンジニア以外にどう伝えていけばいいのか

愛宕　DDDの考え方は、ドメインエキスパートとソフトウェアエキスパート(開発者)、双方が同じように解釈できる言葉を使うことで、プロジェクトに関連する人たちを巻き込んでいこうというものだと思います。しかし、ソフトウェアを知らない人に、どうやってメリットを伝えて巻き込んで行けば良いのでしょうか？

加藤　ドメインエキスパートとソフトウェアエキスパートもお互いに、長年の価値観があってそれぞれの立場の言語を使って説明しようとすることがありました。それによって、意図が伝わりにくいということがあります。僕はプライベート活動として、たまにモデリングワークショップというものをやっていて、違う職種の人同士をグループにして模造紙と付箋を使ってユビキタス言語を作って会話する練習をしてもらっています。

例えば、自動販売機のドメインでお金を入れると商品とお釣りが出てくる、という仕組みをモデリングするとします。まず難しいのが、お互いが理解できる簡潔な日本語を作ることです。すぐにエンジニアは「これって外部キーどうなってんの？」とか、「こんなことやったらフルテーブルスキャンになっちゃうじゃん」などと言いがちなのです。この時点では、ドメインモデルの戦略について話しているので、その先の実装の話はまだ早いという感じです(笑)

今の問題は、釣り銭とは何かという議論なんですね。釣り銭なんて簡単だよと思っていましたが、なかなか難しいんですよ(笑)まずドメインエキスパート役の釣り銭に詳しい人に対して、まず知識の噛み砕き(知識を引き出して何が重要な概念なのかを理解すること)をする必要があります。彼らは例えば「500円入れて100円の飲料(今どき100円の飲み物はないと思うが…。)を買うんだったら500-100=400円出せばいいじゃん」とかいうわけです(笑) 引き算すればいいじゃんと。一見違和感ありませんが、もう少し言語化しないとお釣りを出すには不十分ですし、このレベルではソフトウェアに仕組みを反映することは無理です。
100円の飲み物を買うために500円玉を入れました、釣り銭が出ますか？ 100円玉3枚しかありませんよね(笑) そこでやっとドメインエキスパートはソフトウェアエキスパートになぜ言いたいことが伝わらないのかを知ります。ここで重要なのは、利用している言葉が技術用語やビジネス専門用語でもなくて、”おつりとして百円玉が4枚ある/ない(10円玉40枚は間違いではないが好ましくない…。)”などの、利害関係者でわかる国語の話なんですよね。

愛宕　身近にあるものでやるからこそエンジニア以外の職種にも伝わるんでしょうね。

加藤　そうなんです。まずは「ユビキタス言語」や「ドメイン駆動」などの伝わりにくい代名詞を言わなくても、このようなワークショップで体感してもらうと、それぞれの立場でその重要性を感じてもらえます。
オブジェクト指向設計で考えるのも重要ですが、まず最初に事業の競争力を向上・維持するために、ドメインに対してフォーカスできる状況を作ることが重要だと思います。

愛宕　CODEAL(コデアル)のサービス開発の現場では、できるだけ人力で言葉に落とすことができてから、プログラムを書くようにしてるんですね。できるだけプログラムを書かずに必要なところだけ作ることをやっています。

加藤　それは妥当ですね。従来からあるドメインが定まっている金融のようなビジネスと違って、ネットを介した人材紹介ビジネスを提供するならば、モデリングに試行錯誤が続くと思うんですよね。一般的に、金融と比べたらWeb業界には専門家が少ないし重要視されない風潮があるので、エンジニアは個々人の技術的指向に注目してしまってドメインに対する洞察がおろそかになってしまうこともあるんじゃないかと思っています。とはいえ、すぐに頼れるドメインエキスパートがいないとしても、チームで補完しあってメンバーがドメインの一翼を担っていくことが必要ですね。

エンジニアはどうDDDと向き合っていけばいいのか(2)へ続きます。これからはもう少し実務的な話をお伺いしていきます。