社内でDDD勉強会をやった

DDD (Domain Driven Design/ドメイン駆動設計) についての学習気運があり，その勉強会を社内でやったのでその経過を記すものです．
DDDに関する詳細な内容には触れません (良い本や資料が巷には溢れています)．読書会自体をどうやったか的な話です．

前提

developer.hatenastaff.com

基本的にこのスタイルを真似しました．

読んだ本

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

実践ドメイン駆動設計

エリック・エヴァンスのドメイン駆動設計 (青本) を読んでから，実践ドメイン駆動設計 (IDDD/赤本) を読んだという流れです．

．ＮＥＴのエンタープライズアプリケーションアーキテクチャ　第２版 (マイクロソフト公式解説書)

やっていませんが，続いて上記の本 (黒本) を読むというのもありかも知れないね，という話を会のメンバーとしました．

現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法

も良いかもわかりません．

が，とにかく青本をやってから赤本をやるということにしました．理由としてはやはり原典を読んで知識を付けてから実践に行ったほうが良いであろうという考えからです．確かにDDDを形作るエッセンスが青本には記されており，一読しておいて損はないと思いましたが，しかし後になって思い返すと別に赤本だけでも問題ない気もしました (もしかしたら青本の代わりにInfoQのDomain Driven Design Quicklyを読むのでも十分なのかもしれない)．読みたい本を読むべきです．

進め方

• 1週間に1回開催 (やむを得ない場合は開催されないこともある)
• 1回あたりに1章やる (1章が長い場合は2回程度に分割する．話を忘れてしまうので2回を超えて分割しないほうが良いと思っている)
• 全員があらかじめ該当する範囲を読んでおく
• 週替りで当番を決め，当番になった人はその章の中で疑問に思ったことや議論したいことをmarkdownにまとめてGitHubのrepositoryにpull requestとして投げる
  • あくまで疑問点や議論したいポイントをまとめるのであって，内容をまとめるわけではない
  • 当番でない人も，疑問に思ったことや議論したい点についてはpull requestのコメント等で表明していく
  • 当番になった人はその回の司会もやる
• そのmarkdownをベースとしながら疑問の解消や議論等を行なう (適宜本の内容をなぞっていく)
• 勉強会が終わったら飲みにいく

重要な点は，「参加する全員が本をしっかり読み込んでおく」という点と「疑問点や議論したい点をまとめる」という点です．
前者が成り立つからこそ，後者も成り立ちます．しかし後者は慣れるまでなかなか難しい．うっかり内容のまとめになってしまいがちなので「全員しっかり本を読んでいる」という事を意識していく必要があると思いました．

そして個人的に重要だと思ったのは「勉強会が終わったら飲みに行く」というものです．これは勉強会の延長のようなもので，ざっくばらんに議論してみたり，あるいは「最近こういうことで困ってるんだけど，今日のこのアプローチでいけないか」などという感じで軽く相談が出来るので，なかなか良かったと思いました．また飲み会が勉強会のモチベーションのひとつにもなる (個人の意見です)。
飲み会が嫌いな人には合わないかもしれませんが，幸いにも今回の勉強会のメンバーはみんな飲み会が好きな人が集まったので，これはよくドライブしたように思います．

なおGitHub使うかどうかとかは重要な問題ではなく，チームや企業に合ったツールを使えば良いと思います．

規模

今回は4人でした．これくらいの人数でちょうどよかったな，という感想です．
勉強会の規模が大きくなっていくとどうしても自分事感が希薄になっていき「俺が読んでなくても大丈夫だろう」「議論に参加しなくても問題ないだろう」という感じになっていきがちですが，この程度の規模感だとそうなりにくく，全員参加型でほどよい緊張感を持って進めていけるので良いと思いました (あとこれくらいの人数だと飲み会の予約も取りやすいし)．

困った点

DDDに本当に詳しいエキスパートが不在だったため，「これで本当に合っているのか」などといった疑問に襲われることが何度かありました．
そういう時は一応議論をしつつインターネットで調べながら手探りで答えを探してゆき「まあこういうことなんじゃないか」と全員で認識を合わせることで乗り切っていきましたが，もしかしたら間違えた知識を身につける可能性も孕んでいます．
勉強する分野のプロがいた方が良いな〜というのには首肯するところであります．

所感

なんやかやこういうスタイルで1年近く継続して勉強ができて良かったです．
独習に向く分野もあれば，複数人で学ぶのが向いている分野もあると思っており，DDDは後者に近いと思いました．その理由というのも，DDDには方法論だけではなく，プロジェクトに関わる全員に関係のある組織論に近い要素が含まれていると思ったためです．複数人で議論をし，認識を合わせ，不明な点を少なくしていくというスタイルは実際のDDDにも通じるものであり，その結果このような勉強会のスタイルは上手くマッチしたのではないかと思いました．

今後も何か興味深い分野があったら，このようにやってみたいものです．