レガシーをぶっつぶせ。現場でDDD！2nd 「インプット＜アウトプット！」の参加レポート
レガシーをぶっつぶせ。現場でDDD！2nd 「インプット＜アウトプット！」の一部と二部に参加してきました。
過去に多くの勉強会に参加してきましたが、その中でも特に学びを得られた強い実感がありました。間違いなく上位に入る満足度です。
学んだことを反芻して、記憶やスキルとして定着化を図らねばもったいないと感じたのでまとめたものを記事に残しておきます。
全体的に期待していたこと
DDDは（軽量かもしれませんが）自分なりにいろいろと実践してきており、実践と内省のループから考え方がなんとなく固まってきたので新しいブレイクスルーを得るために他の人の考え方を取り入れたいと思って参加しました。
あるいは自分の考え方があっているかの答え合わせができればそれはそれで自信が持てるといいなとも期待して参加しました。1
システム設計の中でのドメインモデルの役割を体感する
このセッションの内容とされていたこと
公式のタイムテーブルより引用します。
このワークショップでは、ドメインモデルをどのように実装に落とすかではなく、 業務フローやユースケースとドメインモデルがどのように関わり、 それらの変更がどのように伝搬するか、という全体の繋がりに焦点をあてます。
当日は、仮想的なシステム(の一部分)を題材として、 業務に変更が生じた際に何が変わるのかを、 モデルに対して付箋で変更を加えながら体験していただく予定です。
その場でワークショップを体験していただくだけでなく、持ち帰って、 自分たちのチームで実際の業務を対象にして試していただけるようにしたいと考えています。
この説明文を読んで私は『業務分析からそのモデリングまでの一連の流れや手法が知れること』と『それを現実に近い例で訓練できること』を期待して参加しました。
そして、その期待はドンピシャでした。
実際にやったこと
以下のようなことでした。
- カスタマージャーニーに似ているらしい手法（一般に通じる名前はつけられてなさそう）を用いながら、現状の業務をヒアリングしフロー図に落とし込む。
- そのフローで出てきた単語（概念）や操作（振る舞い）を概念モデルとして図に表していく。
これだけ書き出してみると単純かつ簡単な工程で大した意義がないように思えますが、フロー図作成で得られた気づき・見落としをモデルに反映する、あるいはその逆というフィードバックループが存在しており、概念モデルに現実の例を当てはめても通用するような表現力が育っていくような印象を持ちました。2
また、そんな印象を持てるほどの表現力を持ったモデルであれば、その後の実装はだいぶ楽になるだろうとも思いました。
感覚的な話ですが、『気づいていなかったことに気づく、それが可視化される。それが単純に楽しい/嬉しい』という成功体験が『他にも同じようなものを見つけてアハ体験したい』というモチベーションに繋がり、正のループが回っていたように思えます。
今まで業務でやってきたことを振り返る
私は今まで業務分析では開発チームでドメインエキスパートにヒアリングし、その中でそれぞれが構築したメンタルモデルを（何らかの方法論を用いて共有しあう事をすることなく）それぞれがすぐにコードに落とし込む、というようなことを繰り返してきました。
しかし、フロー図とモデル図に表すことでタンジブルにし、他の開発メンバーの意見を聞きながら足りていなかった「何か」を相互に教えあい、それぞれの図に反映していくことでコードを書くよりも低いコストで先に合意に達しておく手段があるとしることができました。しかもそれが現実的にも可能そうな感触を得られることができました。
これに気づけたのはとても有意義なことでした。
今までは、フロー図やモデル図を書けるほど具体的なイメージが持てているのであれば、動かせるコードを書いてそこからフィードバックをもらったほうが早いと言う考えでしたが、図を用いてチーム内で合意を形成していたほうが認識のすり合わせコストが減り時間的トータルコストとしては下がるのかもしれない、また他人の力を借りてより高速に正解に近いメンタルモデルを構築できるのではないかという考え方に変わりつつあります。3
概念モデル/ドメインモデルは実装に素直に落ちるらしい
ところで、『概念モデルとドメインモデルは実装に素直に落ちる』4という意味にとれる説明がセッションの冒頭にありました。
これは私が仮説として持っている考え方だったので聞いたときは『お、おおぉっ？おまおれ？やっぱそうなんや！』と嬉しくなった瞬間でした。
概念モデルをコードに写し取る例考えて、登壇者に質問しに行きましたが、『ありえる実装だと思いますよ！』と言って頂けて少し自信が持てました。
成果物
得られたこと
- 図の作成のための議論の中で自分が持つメンタルモデルと他の人が持つメンタルモデルは当然ながら違うという再認識ができた
- そして、概念モデルの時点でもなかなか合意に至らないのに、それをやらずにコードを書いてしまえばそりゃみんなバラバラな書き方するよなと納得した
- 概念モデルなどの図を作るコストを払ったほうがいきなりコードを書くコストを払うより低く済む可能性を感じられた
- 概念モデルがうまく構築できていれば実装にも素直に落とし込めるという考え方を持っている人が他にもいることが知れた
その他の振り返り的なこと
あとから考えて面白かったのはかなりクラス図に近いものをドメインエキスパートに見せながら、多重度の話をしたり、関連の線をつなげたりして認識合わせをしていたことです。
今回私のチームの担当をして頂いた方はデザイナさんでしたが、デザイナである彼にこういう話し方が通じるのであれば完全なビジネスサイドの人にも教育すれば同じやり方が出来るのではないかという可能性を感じました。
一緒に仕事しているビジネス側担当者はPlantUMLを書いてみちゃうくらいこっちよりの感覚がある方なので、ぜひこれも試してみたいと思いました。
アクションプラン
フロー図とモデル図を試す
- (元になっているかもしれない)カスタマージャーニーを研究する
- このワークショップでやったことも踏まえて(1)を実践する（必要性を感じたら先にカスタマイズもする）。
- 現場で試す
- (3)で得られたフィードバックを元に、辞めるかカスタマイズ(を繰り返しながら)して運用を継続する。
- 繰り返し
概念モデルを使ってビジネスサイドと会話してみる
- ビジネスとの認識合わせにモデル図っぽいものを使ってみる
- そのために教育もちょっとだけ頑張ってみる
モデリングワークショップ 〜割り勘ドメイン編〜
このセッションの内容とされていたこと
これも公式のタイムテーブルより引用します。
"飲み会 会計時の割り勘をテーマにモデリングワークショップを行います。支払合計金額を人数で割る「割勘」は単純です。しかし上司なら比率多め、後から来た人や学生なら少額といった多少面倒な計算が伴います。また、幹事は負担ゼロか、同様に支払うのかのオプションもあります。
今回はこういった具体例でモデリング力を鍛えることが目的です。実際には、想定しているユースケースに対してドメインモデルを考え、すぐにコード上の型を作り(処理は後回し)チームメンバーと議論し、ワークショップを体験していただきます。
追記(11/21): 対象言語は時間的な都合で効率的にサポートできるJavaに限定させてください。Javaの言語的なサポートはスタッフが行います。不明な点はスタッフに確認してください。 また、当日はお題の公表と共に、モブプログラミング形式で5チームに分かれていただきます。その際にJavaが分かる方がドライバーとして必ずチームに含まれるように調整しますので安心してください。当日利用するテンプレートプロジェクトは運営側で用意したものを配布させていただきます。
追記(12/10): お題とひな型となるソースコードはこちらです。詳しくはREADME.mdをご覧ください。当日は2時間しか時間ないのでできれば事前にドメインについて考えてきてください。 ※スタッフのほうでもPCは持ち込みますが、ワークショップ参加予定の方々はPCはご持参ください。"
この説明文を読んで私は、書かれていること通りに『モデリング力を鍛える』体験が得られることを期待して参加しました。
期待したそのものではありませんでしたが、『モデルと実装を行き来することでモデルもコードも育つ』ことが現実にあることだという実感を得ることができました。
この強烈な体験が余韻として残っています。
実際にやったこと
以下のようなことでした。
- 想定している割り勘の文脈を登壇者よりざっくり教えてもらう
- (1)をもとにチームで用語（概念）の洗い出しと相互の関連やそれぞれの属性と振る舞いを洗い出す
- (2)を見ながら実装する
ちなみに、(3)のフェーズではドライバーを務めました。
が、『お前ファシリテータか？』と思われるくらいコードを書きながらペラペラ喋ってしまいました。
役割に徹することができず、ちょっとでしゃばっちゃったなと少し反省しています…けど楽しかったですｗ
今まで業務でやってきたことを振り返る
一部で書いたことと重複しますが、図で示す前にコードを書いていました。
コードを書いている途中で当然新しい気付きはありましたが、それを図にフィードバックしていなかったため、新しい概念を獲得したことを強く実感することなく、それにより別の箇所を改善できる可能性にきづけることもなく5コードをひたすら書いていた気がします。
しかし、モデルで可視化＆共有し合うことを知ったため、コードで得られた気づきをモデルに反映する、あるいはモデルで得られた気づきをコードに反映する、そういったそれぞれで得た気づきを反映し合うループを試しつつチームで共有する有意義さを体験できました。
成果物
ドメインモデル
ソースコード
得られたこと
- モデル図とコードを行き来することでそれぞれの足りないところを補完できる、それを複数人で実施することで足りない観点を補え合える、という体験ができた
- モデリング時には見落としていた概念が、実装の中で浮かび上がってくるという体験ができた
- モデルとコードを行き来する価値や醍醐味を知ることができた
アクションプラン
- 開発チームでモデル図を作成する
- コードを書いてフィードバックが得られればそれをもう一度モデル図に反映する
まとめ
- 今回の開催意図である『アウトプットをするほうが学びになる』の通り、ワークショップでアウトプットすることで学びとその強烈な体験を得られました。
- 個人的には、他の人の考え方を取り入れたい、あるいは答え合わせをしたいという期待で参加しましたが、そのどちらも満たせました。
- 学んだことを研究しつつもなるべく素直に現場で実践して行きます。
