さんによるドメインオブジェクトとユースケースの関係についてでした。今回は私とDDDの話をしようかなと思います。ここでは、手法の話はしません。手法の話をご期待の場合は、ご期待には沿えませんので、どうぞこちらでおかえりください。私がDDDに出会ったのはおおよそ二年前のことでした。Amazonの購入履歴を見るに、わたしは2016/02/21にエリック・エヴァンスのドメイン駆動設計を買ったようです。その時は第一部を読んで満足したような気がします。言うと良さがあんまりわからずに、途中で読むのをやめちゃったんですね。DBにうまく値を格納するかに熱心でした。あるテーブルのデータをPDFに乗せるとか、テーブルのデータを使って一覧画面をつくりソートするとかですね。(これは弊社の今の画面なので、とても奇麗ですが昔はもっとおぼこい感じでした。Bookという世の業務アプリケーションで使われているモデリングはこうなっているんだよという本を熱心に読んでいました。うまくテーブル設計できていれば、モデルの設計はあとからちゃんとついてくると信じていました。何なら、DDDなんか知らなくても、俺は俺の最強のアプリケーション作れると信じていました。なんなら英語の本まで参照しちゃう俺すごい、くらいに思っていました。今思うと、それは正しい局面もあれば、少し複雑になると正しくない局面もあると教えてあげたいですね。そんなこんなで私はDDDと出会いはするものの、すぐに興味をなくし、データモデリングという違う技術にご執心でした。2019時間が2時間ぐらいしかないけどさっとチームビルディングしたいっていうときにおすすめなのがノーミングセッションです。自分が果たすべき役割と責任ほかのメンバーに期待することチーム全体のルールであるグラウンドルールを決めることにあります。このセッションを経てチームメンバーはどうなるのか?自分が果たすべき役割や責任の認識齟齬がなくなります。メンバーがある役割については自分がすることに対して、心理的な障壁が少なくなり、その役割におけるメンバーの心理的安全性が増します。グラウンドルールは判断できることを増やし、意思決定が早くなります。やる方法としては、以下のような手順で開催します。模造紙をチームメンバー分用意してチームメンバーに配ります。メンバーに配られた模造紙は彼のことが書かれる模造紙になります。次にチームメンバーに自分が果たすべきだと思っている役割と責任を自分に配られた模造紙書いてもらいます。(15分)ここでメンバーは自分が期待されていると思っていることを書き出しています。次にチームメンバーはほかのチームメンバーに期待していることを付箋に書き出していき、それをほかのメンバーの模造紙に貼ります。(5分×人数分)この段階であるメンバーが果たそうと思った役割とほかのメンバーから期待されている役割の認識齟齬が可視化されます。メンバーに対して一人ずつ、自分はどう思ってこの模造紙に記載したのか、ほかのメンバーはその人に対して、どう思って期待していることを書いたのかを話し合って、どこが期待値がずれていたのかを話し合います。(20分×人数分)最後に、この辺は上記の話し合いの結果を何かに反映します。(10分)チームが決めておいた方が良いグラウンドルールを決めてもよいし役割が比較的明らかになった場合は明示的に役割分担してもよいです。おすすめなシチュエーションチームの役割分担が良く分からんという課題感がある場合チームの目標が明らかな場合。4人くらいのチームだと2時間くらいです。