モデル駆動設計をやってみよう ワークショップ開催報告(Modeling Forum2025) / model driven design workshop report

Modeling Forum2025のワークショップの開催報告資料です。

https://umtp-japan.org/event-seminar/mf2025/76609

Transcript

1. モデル駆動設計をやってみよう ワークショップ開催報告 UMTP モデリングフォーラム 2025
2. ワークショップ開催報告 アジェンダ • 講師、日時/会場/進行/ワークショップの様子 • ワークショップの内容 • ワークショップアンケート結果 • 開催しての感想 2
3. ワークショップ開催報告 アジェンダ • 講師、日時/会場/進行/ワークショップの様子 • ワークショップの内容 • ワークショップアンケート • 開催しての所感 3
4. 講師 4
5. 日時/会場/進行 2025年11月17日(月) 13:00-17:00 会場：NEC様 本社 • ワークショップ内容説明 13:00〜13:15 • モデリング 13:15〜16:15 • 増田亨さんレビュー(３組) 16:15〜17:00 5
6. ワークショップの様子 6 2〜4人のテーブルに分かれてワーク& 議論
7. ワークショップの様子 7 2〜4人のテーブルに分かれてワーク& 議論
8. ワークショップ開催報告 アジェンダ • 講師、日時/会場/進行/ワークショップの様子 • ワークショップの内容 • ワークショップアンケート結果 • 開催しての所感 8
9. 9 導入部：モデリング駆動設計とは
10. 10 候補日 佐藤さん 鈴木さん 高橋さん １２月３日 〇 〇 × １２月７日 〇 〇 〇 １２月８日 × 〇 〇 １２月７日に決定！ なぜ？ モデリングテーマの説明：日程調整
11. テーマ(シンプル版) １２月７日に決定するルールを、プログラミング言語で 表現してください ① 判断の元になる情報（日程調整表）を、プログラミン グ言語でどう表現するか？ ② 判定結果を、プログラミング言語でどう表現するか？ ③ 判定ロジックをどう記述するか？ 11
12. 日程の決定ルールを少しずつ複雑に a. 全員参加できる候補日が複数あった場合の決定ルール （例えば、最早）を追加 b. 出欠回答に△（出席可能だができれば避けたい）を追 加し、◦△×を重みづけし参加可能人数の期待値が最 大の候補日に決定するルールを追加 c. 最大の期待値が一定以下の場合は再調整と判定する ルールを追加 12
13. ワークショップ開催報告 アジェンダ • 講師、日時/会場/進行/ワークショップの様子 • ワークショップの内容 • ワークショップアンケート結果 • 開催しての所感 13
14. 申込、出席数（アンケート回収数） • 申込者数：26 • 出席者数：23 • アンケート回収数：15 14
15. ワークショップアンケート 15
16. ワークショップアンケート 16 経験あり 経験なし
17. ワークショップアンケート 17 3年以上 1〜3年 1年未満 なし
18. ワークショップアンケート 18
19. ワークショップアンケート 19
20. ワークショップアンケート 20 非常に満足 満足 普通 不満
21. 何を使ってモデリングしたか 21 • Java：10 • Go ：5 • UML:5 • C#:3 • Python:2 • Ruby:2 • Mermeid:2
22. 参加者のコメント要約(プラス) 22 • 最後の増田さんの講評が非常に良かった。 • 他の人のモデリングへの意見や解釈、感覚を知れたのが収穫 • 人間が何となく見て分かる表からモデル、コードに落とし込む作業が予 想以上に大変で勉強になった • モデル(仕様)をコードで表現するという観点を強く意識する機会となっ た • 集中して取り組む時間になった
23. 参加者のコメント要約(伸びしろ) 23 • 増田さんならどのようなコードになるのかを見てみたかった • 増田さんの講評を受けたかった（講評の時間を長くしてほしい） • コードによるモデリング方法の具体的な説明がなく、モデル駆動設計の解像度が上がらなかった。 • コードのみでドメインのルールがわかるようにというのは全面的に同意するが、モデル駆動では ないのでは • コードではなくても（例：クラス図）、レビューしてほしかった • チーム分けで得られるものが異なる。同じ境遇の人が多く、同じような設計になってしまった • テーブル以外のメンバーと話す機会がなかった • スタッフのおしゃべりが気になる時があった
24. ワークショップ開催報告 アジェンダ • 講師、日時/会場/進行/ワークショップの様子 • ワークショップの内容 • ワークショップアンケート結果 • 開催しての所感 24
25. 開催しての感想 25 • モデリングを「頭で理解する」のと「体得」の間には崖がある • モデリングの「体得」のきっかけとしてワークショップは価値がある • モデリングを「体得」する必要があるのか
26. （DDDの）モデル駆動開発のポイント 26 モデル = コード モデル=コードである
27. モデル=コード 27
28. （DDDの）モデル駆動開発のポイント 28 事業、業務を表現する 事業、業務を表現する モデル = コード
29. モデル=コードにするテクニック(DDD) 29 モデル = コード 事業、業務を エンティティ、値オブジェクト、 ユビキタス言語(同じ言葉) で表現する 事業、業務を表現する
30. 「モデル=コード」では無くなる時 30 手続き型で 処理を記述する 事業、業務を表現する モデル ≠ コード
31. モデリングを「頭で理解する」のと「体得」の間には崖がある 実践してみると・・・(今回のワークショップでのレビュー指摘事項の例） ・コードが意図を語っていない（処理は書いてある） ・重要概念がクラスではなく、プリミティブ型の変数で表現されている ・コメントで重要概念を説明しているが、コード上では表現されていない やってみると 頭で理解
32. モデリングのワークショップは、 体得のきっかけとして価値がある 実践 ・ワークショップで実践 ・自分で書いてみる ・実プロジェクトで実装 ・師に習う 頭で理解 体得
33. 生成AIがモデリングをするにしても、 人が体得することは必要 生成AIがモデリング ↓ AIがつくったモデルの良し悪しを判断できない ↓ 知らぬうちに、歪んだ設計がソフトウェアに埋め込まれる(AIで動くものはつくれる) ↓ ソフトウェアの内側から劣化する。 ↓ 開発生産性や品質が低下し、事業に悪影響
34. 生成AIがモデリングをするにしても、 人が体得することは必要 生成AIがモデリング ↓ AIがつくったモデルの良し悪しを判断し、最終的に受け入れ判断 ↓ ソフトウェアの内側が、きれいに保たれる ↓ 変更容易性が高まり、開発生産性が上がり、事業に貢献
35. 参加者の方々、会場を貸していただいたNEC様、 UMTP運営の方々、ワークショップを告知頂いた方々.. ありがとうございました！ 35