ドメイン駆動設計(DDD)との格闘 - 突然DDD実践チームにPOとして参加することになったら

こんにちは、株式会社FLINTERSで企画職（Product Owner、ProductManager、ProjectManager、雑用係などの総称）として働く加藤と申します。私は、主に、インターネット広告代理店などデジタルマーケティングを実践されている企業へ、Yahoo!やGoogle、Facebookなどの広告媒体が提供するAPIなどを活用した、業務用のアプリケーションを開発提供するお仕事に携わっております。

私の勤める会社は、株式会社セプテーニ・オリジナルから、2021年1月4日をもちまして、株式会社FLINTERS（読み：フリンターズ）に社名変更し、「FLINT＝火打ち石」を語源として、「未来につながる火を灯そう」をミッションに掲げて気持ち新たに頑張っております。ただいまFLINTERSでは、ブログ投稿強化月間ということで、私も恥ずかしながら駄文を投稿させていただきます。

この投稿の内容

ドメイン駆動設計(DDD)に突然、プログラミングとは無縁だった社員が放り込まれて四苦八苦しながら、ドメイン駆動設計(DDD)を実践する開発チームとお友達になるコツを紹介します。弊社及びグループ会社の開発関係者の方へ、研修や勉強会として提供させて頂いていた内容を少し改変しながら、数回に分けてお届けしたいと思います。初回となる今回は、ドメイン駆動設計(DDD)との出会いと苦悩についてです。次回以降に、ユビキタス言語(Ubiquitous Language)、ドメインの発見の仕方、境界づけられたコンテキスト(bounded context)、コンテキストマップなどについて紹介していきたいと思います。

この記事の想定読者

開発者出身ではない、Product Owner、ProductManager、ProjectManagerの方
ドメイン駆動設計(DDD)を取り入れたいけれど、開発者出身ではない意思決定者がなかなか理解を示してくれない方
FLINTERSで企画職として働いてみたい、そこのあなた

あくまで、私の体感したコツなどをご紹介するものであり、誤っている点など多々あるかとおもいますが、その場合は優しくご指摘くださいませ。

ドメイン駆動設計(DDD)との出会いと苦悩

当時発足間もなかった、グループ会社であったセプテーニ・オリジナルへ出向したのが2015年10月。

弊社では、

所属する企画者・エンジニアの指針となるよう、現在の我々の目指すところ／我々が取っている行動の理由／我々が求める姿勢、を文章化した

技術指針を定めており、少しずつ改変を加えながら現在の姿となっています。 www.flinters.co.jp

私が参加した当時から、この技術指針において、原則として開発チームはドメイン駆動設計(DDD)を採用することになっており、私が配属された開発チームももちろんドメイン駆動設計(DDD)を採用しておりました。興味のあった開発会社へ異動が決まった私は、意気込んで、上司や同僚から薦められた、アジャイル開発やScrumなどの初心者向けの文献を読んだり、社内のドキュメントを読んだりしながら過ごしていたのですが、なぜか、ドメイン駆動設計(DDD)については上司や同僚の企画職から学ぼうとすると、「ま、DDDは、今すぐじゃなくてもいいんじゃないかな」、「企画職には直接的にはあまり関係ないよ」などと、ちょっと皆、曇り顔。

ドメイン駆動設計(DDD)の学習への挑戦と挫折

でも、技術指針では以下のように、ドメイン駆動設計(DDD)について記述されており、「チーム全員で」、「エンジニア以外にも」、「プロダクトオーナーが」などと記述されており、とても自分に無関係なものとは思えません。

DDDを採用するのはチーム全員で要件の芯を捉え続けるため

我々はドメイン駆動設計を積極的に採用します。

ドメイン駆動設計はユビキタス言語という言葉と実装を一致させる言語を用いてビジネス要件の芯を設計の中核におく手法です。

「エンジニア以外にも翻訳不要で伝えることができる」「設計と実装に対する価値観が共有できる」という特徴があり、チーム全員で要件の芯を捉える助けになることを期待しています。

具体的には、やらねばならないことのコストをプロダクトオーナーが認識しやすくなる／レビューや仕様検討時に、言葉と実装が一致しているか、というチェックを行えるようになる／設計や概念がまずい場合、言葉にすると自然と大仰に成り危険な感じになる、といった効能を期待しています。なお、“レイヤードアーキテクチャを採用する”ではないため、上記効能を維持出来るアーキテクチャであればどの手法でも構いません。

そこで、企画職ではなく、開発チームにDDDについて学びたいと伝えると、、、はい、紹介されたのは鈍器でした。

エリック・エヴァンスのドメイン駆動設計

作者:Eric Evans
発売日: 2013/11/20
メディア: Kindle版

実践ドメイン駆動設計

作者:ヴォーン・ヴァーノン
発売日: 2015/03/19
メディア: Kindle版

ドメイン駆動設計(DDD)を行う方はEric Evans本とその実践について触れたこの2冊は必携の本であると今では理解できますが、1冊で数百ページを超えており、通勤カバンに入れて自宅と会社を往復するだけで肩が抜けそうになります。鈍器あるいは、デスクでお昼寝するときの枕に最適なサイズです。ただ、いくら枕にしていても妖精が読み上げてくれるわけではないので、なんとか最初から読もうとして、文字面を目で追っていくのですが、惨敗です。まったく内容が頭に入らなかったといっても過言では有りません。 「ま、DDDは、今すぐじゃなくてもいいんじゃないかな」と言っていた上司の言葉は確かに正しかったと思います。

また薄い本として、社内で通称Quicklyと呼ばれる、素晴らしい日本語訳、しかも無料のドキュメントがあるのですが、こちらは、まったくの開発プロジェクトの初心者にとっては、上記の2冊の鈍器より、さらに難解だと思います。ある程度理解されている方が、短時間での知識の再定着などを目的に読むといいかなあと思います。

Domain Driven Design（ドメイン駆動設計） Quickly 日本語版

非プログラマーにドメイン駆動設計(DDD)のすべてを理解することは無理である

その後、数年かけて、なんとなく非開発者として、ドメイン駆動設計(DDD)との付き合い方を身につけることができたのは、近年まで弊社の技術メンターをしていただいていた、かとじゅん氏が、数度にわたり社内向けにセミナーを開催して頂いていたり、新規の開発プロジェクト立ち上げ時に設計のサポートをしていただいたおかげだと思います。また、この有用性を実感するようになったのは、ベトナムハノイにあるグループ会社であるSEPTENI TECHNOLOGY（FLINTERS VIETNAMに商号変更予定）と、国境を超えた開発プロジェクトに参加するようになってからです。

ここで、ズバリ断言します（と、著名なプログラマーな人をマネてみた）。プログラミングの知識や経験が無ければ、ドメイン駆動設計(DDD)のすべてを理解することは無理です。この考え方は、オブジェクト指向プログラミング(object-oriented-programming OOP)と深く結びついており、その考え方や技法を実践できなければ、ドメイン駆動設計(DDD)を理解し、実践することは、不可能です（もちろん、超天才の方とかは別だと思います）。

ただし、非開発出身の企画職としても、開発チームがドメイン駆動設計(DDD)を実践し、よい開発をすることに貢献することはできます。貢献できるどころか、開発チームが成功するためには企画職が適切に価値を発揮することが不可欠です。

企画職に求められるドメイン駆動設計(DDD)への貢献

おそらく、ドメイン駆動設計(DDD)の開発プロジェクトへ企画者として参加する場合、ドメイン （一旦、ここでは、その開発プロジェクトで解決したいビジネス上の課題というような定義にしておきましょう）にたいして、そのエキスパートである、または、相対的にチーム内で知見があり、発注者・利用者の中のドメインエキスパートから課題や知識をヒアリングし、ソフトウェアで解決できるように落とし込んでいくことが期待されていると思います。

こうした、期待に応えるために、企画職として実践できるようになっておきたい、ドメイン駆動設計(DDD)の手法は4つです。