本記事は、ドメイン駆動設計#1 Advent Calendar 2019の7日目です。
はじめに
私自身がDDDを知ったのは、2017年の11月頃でした。
そのとき、増田さんの現場で役立つシステム設計の原則を読み始め、「intやStringなどプリミティブ型をそのまま使うのはよくない、オブジェクト指向ってこう使うのか…！」という感動を覚え、その流れでドメイン駆動設計というものを知りました。
完全なる肌感覚となってしまいますが、
私がDDDを知った時の状況と比べて、DDD自体日本でも最近取り上げられるようになってきて、
それこそ全く興味ないという人でも、「全く知らない」から、「名前ぐらいは聞いたことある」という状況になっているのではないかと感じています。
そんな状況になってきた今でも、DDD関連の勉強会やイベントに出ていると、 「そもそも、DDDを組織で広めるにはどうしたらいいのか」 といった質問はよく耳にします。
私自身、いまのチームでDDDはしておらず、実戦経験としてはほぼ無いに等しい状況ではありますが、
それでも今の組織で「DDDとはなにか。これをすると、こんなメリットがあるよ」というものを地道に広めている状況ではあります。
※社内でDDDをやっている、というチームはまだありません
そんな未だにDDD童貞を拗らせている自分だからこそ語れるような、
「DDDをいかに組織に広めるか」という話を、経験談ベースで語っていけたらと思います。
私の状況と組織の状況
まずは前提として、いまの私の状況と、組織の状況を語らせて頂ければと思います。
そんなものどうでもいいんじゃーという方は、組織に広めるために、自分がやってきたことからご覧いただけたらと思います。
とりあえず何をやったか素早く知りたい方は、まとめをご覧ください。
私の状況
もともと、SES業界でC#とASP.NETで(Excelで)詳細設計をやっていた人間です。
いまの会社に入って、1年と5ヶ月目になります。
いまのチームはBashをメインにアプリケーションを組んでいて、型やクラスとは無縁の生活を送っています。
組織の状況
事業会社の完全子会社という立ち位置です。
規模としては50〜60名ぐらいです。
主に自社の販売員が使うシステムや、ECサイトなどを内製でやっています。
（一部外販もしています）
設立当時はBashで組み、いまはPythonで刷新し直すということをやっています。
当時は小売の人間をそのままエンジニアとして育てあげるため、オブジェクト指向とかそういう細かい話は置いておき、とにかくBashで必要なデータを抽出するスクリプトを組み上げる、といったことをやっていたので、
俗に言うトランザクションスクリプトがすごい量残っています（今ではだいぶマシみたいですが）
事業会社の子会社であり、オフィスも隣り合っている為、ビジネスサイド側の人間との距離はとても近いです。
親会社から出向して、そのままPOをやっていらしゃる方もいます。
組織風土としては、技術向上のため勉強会に行くのは推奨レベル（その勉強会も業務時間にしてOK）
あと何かしら技術発信をすると、誰か1人くらいは食いついてくれることが多い。
また、チームごとに技術選定が出来るため、いろんな言語・フレームワークが使われている（その分、組織全体的に技術の統一感が薄く、チーム間での技術情報交換がままならないこともある）
※最近はPython、Vue.jsをメインにしようという流れはできています
コミュニケーションツールはSlackを導入。
有志があればお昼にランチLTとかが出来たりします。
組織に広めるために、自分がやってきたこと
Slackを大いに活用する
分報チャンネルにて、刷り込み作業をする
エンジニアの会社であれば、何かしらのチャットツールは導入されていると思います。
私が入社したときも、Slackが既に活用されており、分報チャンネルを皆さん作られていました。
分報ってのはなに？ という方に簡単にご説明しますと、社内版Twitter的なやつです。
プライベートチャンネルではなくて、みんなが見れるパブリックなチャンネルを自分専用として使っています（他の人がチャンネルにJoinするもしないも自由。Twitterのフォローみたいな感じ）
分報のやり方や効果などは、以下の記事が参考になります。
- Slackで簡単に「日報」ならぬ「分報」をチームで実現する3ステップ〜Problemが10分で解決するチャットを作ろう | | Craftsman Software Inc.
- 分報で各自の作業を可視化したら、メンバー間の協力が加速された話 - Qiita
- 楽しく情報共有できるSlack活用術｜ハンズラボエンジニアブログ｜ハンズラボ株式会社
私もご多分に漏れず、この分報チャンネルというものを作り、日々のやること・やったこと・気になったことなどをアウトプットしていきました。
外部のDDD勉強会で学んだことも、この分報チャンネルでアウトプットをしました。
このように、こまめにDDDについて学んだこと（ネットの記事だったり、本を読んだ内容だったり）を書いていきました。
それを続けていくと、「なかじまさんって、DDDっていうのを最近勉強しているんですね」と雑談ベースで言われるようになっていきます。
eventチャンネルで、DDDの勉強会やイベントを宣伝・周知する
勉強会や各種イベント情報をシェアする、eventチャンネルというものが作ってあったので、そこに積極的にDDD関連の勉強会やイベントのURLを貼っていきました。
始めのうちは無反応なことが多かったですが、
根気よく続けていると、実は興味ある人、ちょっと行ってみようかな？ という人が何人か釣れてきます。
ちょうど転機となったのは、ボトムアップドメイン駆動設計 - connpassのイベントで、
このとき、私以外に3人一緒にイベント参加することになりました。
イベント用チャンネルを作る
上記のイベントの際に、Slackでイベント用チャンネルを作り、参加している4人がそれぞれ学んだことを呟けるようにしてみました。
（Twitterでいう、ハッシュタグ的な位置づけです）
そうしていると、イベント行くほどでも無いけど、興味はあるみたいな人も、ちょっと覗こうかなって思って、チャンネルにJoinしてきたりします。
そうなってきたら、これ見よがしにワイガヤして楽しそうな雰囲気を演出してみたりしました（いや、実際に楽しいんですよ）。
1on1で最近勉強していることとしてDDDを話す
1on1を取り入れている組織も、最近増えてきたかと思われます。
私も上司と毎週1on1をしていますが、その中で「DDDというものに興味がありまして〜」という話をして、自分の興味を語るようにしていました。
これをやるとすごい、いいんだっていう感じで、時には熱も交えて語ってみたり。
上司に対しての刷り込み作業は、1on1を通して行った部分が大きいと思っていたりします。
後の外部のエンジニアに、講師として社内に来て頂くのところで、外部講師を招く際の説明にも、この下地があったおかげで説明しやすかった部分はあります。
外部のエンジニア達とDDD勉強会をする
ここからは少し飛び、今年の春ぐらいになったときに、
「ECサイトのモデリングから、実際のコードに落とし込むような勉強会をしたい」という話が、知り合いのエンジニアから出てきて、興味があり参加しました。
通称：八百屋モデリング会
このとき、月イチ4〜5時間くらいでやってみましたが、みなさんモデリングについてとか、DDDの知識が豊富だったので、やっていて大変楽しかったです。
このときも、自分がやっていることを分報チャンネルに書いたり、
GitHubのリポジトリのリンクも貼ったりして、社内で小さく細かくアピールするのは忘れずにやっていきました。
勉強会に社内の人間も巻き込む
分報チャンネルなどに投稿していると、何人か興味を示してくれたエンジニアがいた為、「一緒に参加してみないですか」と勧誘をして、この八百屋モデリング会に呼んだりしました。
実際に落とし込んだコードはこちらです（私はKotlinほぼ書いてなくて、PlantUMLでモデル図を整形したくらいですが）
https://github.com/ginyolith/ddd-modeling-ec-mob-kt
2019/12/10追記
この外部のエンジニアとの勉強会については、とにかく集まれる人（やる気ある人）がやろう、というスタンスであった為、
スキルセットとか、対象業務（ECサイト）への熟知度に関しては、完全バラバラでした。
ECサイトをお題として選んだのは、Amazonや楽天などを普段から使用している分、想像がしやすかったからです（後に、八百屋が発注書を作るためのシステム、という風になりましたが）。
実際に今回コードを落とす時にはKotlin。ツールとしてはIntelliJを選択しました。
選定理由は、集まったメンバーの中でKotlinに強い人&他のメンバーがKotlinに興味を持ったからです。
このバラバラのスキルセットに関しては、モブプログラミングをすることによって解決をしていきました。
社内でモデリング勉強会をしてみる
レガシーをぶっつぶせ。現場でDDD！のイベントでBiglobeさんが開催していたモデリングハンズオンのセッションがありました。
このセッションに同僚と一緒に参加した結果、「社内でもやろう！」という熱が高まり、まずは3人で開始。
とりあえずモデリングを週一で1時間ほど設けてやってみました（残念ながら、その後業務が忙しくなり、3回くらいで終わっています。。）
会議室を借りるでも良かったですが、あえてフリースペースでやってみることを選択をしました。
あまり固くならずに、フランクにやりたかったというのもありますが、あえてオープンな場でやることによって他のエンジニアの目に留まるようにしたかった、という思いも若干あったりします。
RDRAを利用して要件定義、既存システムの可視化をやってみる
DDDとは直接は関連性が無いかと思われますが、
RDRAと呼ばれるモデリングのフレームワークを利用し、要件定義に挑戦をしてみました。
RDRAを利用してのモデリングした図が、顧客やチームとの会話のキッカケにもなり、
ただスプレッドシートやパワポに要件をまとめていくより、ずっとやりやすさを感じました。
その時得た知見を社内のLTで紹介してみました。
外部のエンジニアに、講師として社内に来て頂く
やはり独学だと限界があるため、外部のDDDを実践しているエンジニアにお願いをして、社内で開いて頂きました。
ただ、このへんは正直ハードルが高いので、お願いをするにしても、ある程度顔を合わせておかないとやりづらいなーという感じでしたので、DDD-Community-jpのアンカンファレンスイベントであるDDD Talk MeetUpで対面でお願いをしてみました。
この辺り、どう開催したかについては、下記ブログを参照していただけたらと思います。
ドメイン駆動設計のモデリングハンズオンを開催して頂きました！｜ハンズラボエンジニアブログ｜ハンズラボ株式会社
別チームのモデリングに参加させて頂く
外部講師を招いての勉強会に参加していた別チームのエンジニアから、
「自分のチームが扱っているドメインをモデリングしてみたい」という話を受け、実際にやってみました。
最初は、私とそのエンジニアの二人で、モデリングをやってみようって話になりましたが、いつの間にか見学という形で、そのエンジニアのチーム全員が見に来ました。
「こうやってホワイトボードに整理するのもいいですね」っていう感想も出ていたので、概ね良い印象で終われたと思います。
2019/12/10 追記
別チームについての捕捉をさせて頂きます。
私のチーム：Bashがメイン。対象領域はとある顧客の小売の売上・在庫・仕入などを管理する基幹系のシステム。
別のチーム：Pythonがメイン。対象領域は親会社の商品管理などの内製システム。
私自身と別チームは内製と外販でそもそも担当領域が違う、ということはありましたが、同じ小売系の業界ではあるため、モデリングをやる上でそこまで大きな障害はありませんでした。
むしろ、「業務のことそこまで知らないかつ、そこそこシステム作ったことある人間」が聞き手役としていると、対象業務の深堀りにも一役買える感覚がありました。
1年やってみた結果、どうなった？
未だにDDDを利用してのプロジェクトはありませんが、社内の3〜4人くらいのエンジニアたちには、「DDDって聞いたことある」→「なんとなく概要を理解した」ぐらいまで持っていけたように思えます。
※試しにSlack上で「ドメイン駆動」というワードで去年と今年で検索してみましたが、1.5倍くらいに増えていました（あと発言しているエンジニアも私だけじゃなくて、数人増えている）
上司からは、せっかく講師を呼んで勉強会を開いて貰ったので、どこかのプロジェクトで試して欲しい、といった話も（雑談ベースですが）頂けました。
すぐには難しいですが、機会があれば実現出来る可能性が出てきました（まだまだ道半ばではありますが）
少なくとも1年前よりは広まったのではないか、土壌は少しは出来たのではないか、という実感は出てきています。
所感的なアレコレ
以下、自分なりの所感をいくつか書かせて頂きます。
人間、ストーリーが無いと動きづらい
DDDを広めるにあたって、重要視しておきたいのが、
ストーリーをちゃんと説明することだと思います。
DDDの話とは関係ありませんが、私自身がチームでタスクボードを導入しようとした時、いきなりやるぞ！ と言っても、別に今のままで良いんだけど……と言い返されたことがあります。
それは自分が、タスクボードを導入するために、必要なストーリーが語れてなかったのが原因でした。
まず間違いなく、この記事を読まれている皆さんの中にはDDDをやる動機というものがあるはずです。
ですが、それを言語化して他人に伝えない限りは、「いきなり何を言っているのこの人。面倒くさいな……」で終わってしまう可能性が高いです。
どんなことでさえ、「何かを始める」というのはエネルギーが要ります。それが他人から言われたことであれば、なおさらです。
そのため、いまは◯◯な状況で、△△な状態に持っていきたい（理想）から、こういった事（DDD）を試してみたいんだ、という「ストーリー」や「なぜ」を語り、相手にしっかり腹落ちさせてあげる、ということは大事だと感じます。
近道としては、社内勉強会や読書会を主催すること
ここ1年で感じたことは、
外に行ってまで勉強会に行く熱量は無いけど、社内のどっかの会議室で勉強会やるなら参加してみる勢というのが、結構いらっしゃいます。
そういう人たちも巻き込んでいくのなら、やはり自分たちで読書会なり勉強会なりを開催するのが、広めるにあたっての近道ではないかと思います。
とはいえ、いきなりDDD勉強会やります！ って言ったところで「え、なにそれ怖い……」で引き気味になる人が多いかと思われるので、事前に地道なアウトプットをしていき、下地を作る必要性はあると思います。
強いエンジニアなら、コードで示すのが手っ取り早い？
私自身が強いエンジニアであれば、たぶんこの選択肢を取れたかもしれません。
とはいえ、コードで示せば明日からチーム全員がそれでやってくれるか、というと難しいのではないか、とも思ったりします。
結局レベル感の話もありますし、そもそもユーザの問題領域をしっかり扱い（戦略的DDD）、モデルを表現した変更に強いコードを書くテクニック（戦術的DDD）の2つの意図をメンバー全員に腹落ちさせずに進めてしまうと、いずれ強いエンジニアが離れた時に、クリーンなコードを維持できない恐れが高いのではないか、と感じています。
総務・経理の方々と仲良くなるのもオススメ
これは前職時代からの完全なる持論ですが、総務や経理などと仲良くなっておくのをオススメします。
というのも、総務の方と仲良くなっておくと割と社内的なお願い（会議室借りたり、外部講師呼ぶ際に協力してくれたり）を通しやすくなったり、実際にお金を握っている人たちの心象を良くしておくと、会社でお金を出すってなった時にも割とスムーズだったりします。
組織的に離れていたり難しい場合が多いかもしれませんが、同じフロアで目と鼻の先であれば、ちょっとしたお菓子なんか持参して二言三言レベルの雑談しに行ったりして社内営業活動するのも一つの手だと思われます。
明日からできること
いろいろと語りましたが、
個人的にオススメだと思っている広め方で、たぶん明日からでも出来るやり方をご紹介します。
それは
ホワイトボードを買ってモデリングを始める
昨今ではホワイトボードの重要性はどこの企業も認識していると思われますので、ホワイトボードを買うこと自体にそこまでの抵抗感は無いと思います。
さすがに大きなホワイトボードは無理でも、30cmくらいの小さなホワイトボードなら100均でも売っているので、まずはそれでもOKだと思います。
用意したら、開発の現場でおもむろにモデリングをし始める。
UMLはエンジニアの皆さんだったら抵抗が無いと思うので、ユースケースやオブジェクト図、クラス図を書いていく過程で、業務ルールやらを洗い出していく。
プロジェクト的に可能であれば、そこでDDDの戦術的パターンを使ってみたりして実装する。
しばらく続けていくと、「そんな手法があるんですか？」と気になってくる人が少なからず出てきます（たぶん、きっと……）
ポイントとしては、みんなに目がつきやすいよう、これ見よがしにやる。
組織風土的に目立ってはいけないとかもあるでしょうけど、ホワイトボードにお絵かきするくらい、たぶんそこまで悪目立ちではないと思うので、許されるはず……です。
まとめ
最後に、私が今までやったことを箇条書きにしてみます。
- Slackの分報チャンネルを使い、DDDの情報を小出しにして、刷り込み作業をした
- Slackで、こんなDDDイベントあるんですよーという周知をした
- SlackでDDD勉強会、イベント参加中のワイガヤチャンネル作って、アウトプットや雰囲気を出した
- 1on1の中で上司にDDDの話をしてみた。
- 外部のエンジニアたちと勉強会を開き、社内のエンジニアも誘った
- 業務モデリング会をやった
- RDRAで要件定義、既存業務の可視化をしてみる→それについて社内LTをしてみた
- 外部講師を読んで、DDDに関するセミナー・勉強会を開いた
- 他チームのモデリングに参加してみた
おわりに：まずは自分から発信し、仲間を見つけるところから
いろいろ書きましたが、
一番良いのは、まずは一緒にやれる仲間を見つけることです。
自分一人だけで広める、というのはなかなか根気もいるし、エネルギーの要る作業です。
最初は良くても、いずれはエネルギーが枯渇して、せっかく頑張ってきたことが継続できなくなり、風化してしまう恐れがあります。
そんなエネルギー切れを防ぐためにも、仲間の存在は重要だと感じています。
仲間にもいくつか種類があると考えており、
- とりあえず、興味があるので何か勉強会等やるなら参加してみる仲間（フォロワー）
- 一緒に行動を起こしてくれる仲間（サポーター）
- 実践してつまづいた時に質問できる仲間（マスターセンセイ）
※カッコ内の名付けは完全に私のイメージで付けました。
行動を一緒に起こしてくれる人が見つかると嬉しいですが、
いきなり見つけるのは難しいと思うので、フォロワー気質の仲間をまずは見つけ、増やしていくのを意識すると良いのかもしれません。
そのためには、社内Slackでつぶやいたり、勉強会で得た内容を周りに伝えたりする、という地道なアピールをやっていくことが重要だと思います。
あと、これは意外と重要だと感じているのが、自分自身も仲間のサポーターであろうとすることです
別にDDDに限らず、「私、社内でこういうのやってみたいんだけど…」という発言に、少しでも興味があれば「いいじゃないですか、やりましょう！」と全力で乗っかります。
そういう姿勢を見せると、自分が何かをやろう、という時も一緒になって動いて助けてくれる（サポーターになってくれる）割合が多いように感じます。
マスターセンセイについては、DDD-Community-jpというDDDを普段から実践されているような人たちが集まるコミュニティもあります。
そういったところで質問すると、皆さんお答えしてくれると思うので、どんどん活用していくと良いと思います。
それでは以上となります。
本記事が、「どのように広めたら良いのかわからない」と悩まれている方にとって、なにかしらのヒントになれば嬉しく思います。