■ 1. ワークショップ1:モデル駆動設計の実践
- 開催概要:
- 講師は増田氏と佐藤氏である
- 先週月曜日に4時間(13時から17時)で開催された
- 会場はNEC本社を借用した
- ワークショップの内容説明15分、モデリング3時間、増田氏によるレビュー45分で構成された
- 2人から4人のテーブルに分かれてワークを行い、30分に1回程度全体で議論した
- 参加者属性:
- 申し込み者数は26人で当日参加が23人、アンケート回収数が15である
- システムエンジニアとプログラマーの方が多数を占めた
- 現業務現場でのモデリング経験がある方が66.7%で、3人に2人はモデリング経験がある
- UMLの利用経験が3年以上の方が40%、1から3年が26.7%、1年未満が20%で、約80-90%がUML利用経験を持つ
- ワークショップの内容:
- モデル駆動設計とはという導入部を6個のスライドで説明した
- 調整さんのようなものをテーマにルールをコードで記述することを課題とした
- シンプル版として特定の日付に決定するルールをプログラミング言語で表現することから始めた
- 終わった方から段々ルールを複雑にしていくことに取り組んだ
- 参加動機:
- 講演内容に興味があった(モデル駆動設計)
- 講演者に興味があった
- モデリング技術に関する最新情報収集のため
- 会社からの案内、UMTPのメールとホームページ、川島氏のXのポストが情報源となった
- 満足度と使用ツール:
- 非常に満足と満足を合わせて73%の満足度があった
- 使用ツールはJavaが10件、Goが5件、UMLが5件、C#、Python、Ruby、Mermaidも使用された
- プラス評価:
- 最後45分間の増田氏による3人の方の実際のコードレビューが非常に良かった
- グループで30分に1回程度どういう風にやっているかを話した際の意見や解釈、感覚を共有したのは収穫であった
- 調整さんの表から分かる表からモデルコードに落とし込む作業が予想以上に大変だったことを体感できた
- モデルをコードで表現するという観点を強く意識する機会となった
- 4時間集中して取り組む時間になった
- 改善点:
- 増田氏ならどのような実装になるのか見てみたかった(あえて模範回答を用意しない方針だった)
- 増田氏のレビューを受けたかったのでレビュー時間を長くして欲しい(45分でも足りなかった)
- コードによるモデリング方法の具体的な説明がなくモデル駆動設計の解像度が上がらなかった
- モデル=コードという考え方が伝わらなかった
- コードではなくても(図などで)レビューして欲しかった
- チーム分けで得られるものが異なり、テーブル内で同じような接近になってしまった
■ 2. モデル駆動設計の核心概念
- モデル=コードの原則:
- 今回のポイントはコードでモデルを表現することである
- モデル=コードが理解して欲しいポイントである
- ドメイン駆動設計(エヴァンス本)では「モデルと設計の下」において、モデルと設計及びコードを単一の活動として改良し続けることを説明している
- 1つ作ればモデルにもなるし設計にもなるというのがポイントである
- モデルで表現すべきもの:
- 事業、業務、業務ルール(ビジネスルール)をコードで表現してモデルにもなる
- テクニックとしてDDDで語られているエンティティ、値オブジェクト、ユビキタス言語を使った命名などがある
- モデルとコードの乖離:
- 手続き型で処理順に書いていってしまうとモデルとコードが乖離していく
- 実際に多くの参加者のコードでこの乖離状態が見られた
- 実装が進んでレベルの高い方でもこの問題が発生していた
- 具体的な問題点:
- 重要概念がクラスではなくプリミティブ型の変数で表現されていたため、重要概念がモデルとして伝わってこない
- 処理が書いてあってそこにコメントで一生懸命説明しているが、それがコードに現れてきていない
- このような状態ではモデルとコードが乖離している
■ 3. 開催者の所感
- モデリングの習得における課題:
- モデリングを頭で理解するのと体得の間には崖がある
- 実際に参加者がモデリングしているところを見てこれを実感した
- 本を読んで頭で理解したつもりでも実際やってみるとできないというギャップがある
- ワークショップの価値:
- モデリングの体得のきっかけとしてワークショップという場は価値がある
- 頭で理解したつもりだったけども実際やってみるとできないということに気づくきっかけとなる
- 気づいたら自分で色々書いてみたり、実プロジェクトで部分的にやってみたり、師に習う(お互いにレビューし合ったり、習得した人に見てもらう)ことが重要である
- AI時代におけるモデリング体得の必要性:
- 生成AIがモデリングをするにしても人が体得することは必要である
- 生成AIがモデリングして人がそのAIが作ったモデルの良し悪しを判断できないと体得していないので良いか悪いか判断できない
- 判断できないと知らないうちに歪んだ設計がソフトウェアに埋め込まれていく
- AIで動くものは作っていくが知らないうちにソフトウェアの内側から劣化して開発生産性や品質が低下し、リリーススピードが低下して事業に悪影響を長期的には及ぼす
- 生成AIがモデリングしたとしても人がAIが作ったモデルの良し悪しを判断して最終的には受け入れ判断をする必要がある
- そうするとソフトウェアの内側が綺麗に保たれて変更容易性が高まって生産性が上がって事業にどんどんリリースできるので事業に貢献できる
- ドメインのところをソースコードから綺麗に保っていくことでソフトウェアの変更容易性が高まって事業に貢献できることにつながる
■ 4. ワークショップ2:モデルとは何かの本質洞察
- 開催概要:
- 11月19日にリモートで開催された
- 参加者は16名で19人で実施された
- 企画の方、アーキテクトの方、学生、プロダクトデザイナーなど多様なバリエーションの参加者がいた
- 最も多かったのはシステムエンジニアとプログラマーである
- 目的:
- モデルについてみんなで対話を重ねて深く考える時間を持つこと
- いろんな立場の様々な視点の人々との対話からモデルとは何かを探っていく
- 自然言語でモデルとは何かを思考実験して検討していく
- 特定のUMLを使うことは目指していない
- 概念工学に近いことをみんなで体感する
- 本質洞察の実践という形で自分の実感体験と言葉によるある程度明確な記述をいかにすり合わせて近づけていくかを繰り返す
- 共通性を見つけ本質の定義に近づいていく
- いろんなエピソードを少しでも広くカバーできるような概念を見つけ出す
- 実感体感と一般化、抽象化、理想化、形式化の間を行ったり来たりしながらうまい表現記述を見つけ出す
- 参加者属性:
- モデリングの現場での経験がある方が83%である
- UMLの利用経験が3年以上の方が33%、1から3年が10%未満、1年未満が16%で、40%の方は使ったことがない
- 満足度と感想:
- それなりに満足度は高かった
- モデリングの良い経験になった
- グループで異なる方と議論ができた
- モデルに対する理解を深めることができた
- 業務で役立つ知識を得られたような感じはしなかった(目的はそこではなかった)
- モデリングを学んだというよりモデリングについて学んだという感じで実務には役立たなさそうだった
- ワークショップではかなり良い体験ができた
- 新モデリング宣言に関して哲学とソフトウェア工学をどのように結びつけられるかを知ることができた
- モデリングとは何かを再確認し、またモデリングを展望する機会となった
■ 5. ワークショップの流れ
- エピソード収集:
- モデルやモデリングというキーワードを含んだ自分の実体験のエピソードを2つ以上書く(200字以上400字未満程度で2つ分)
- 文章をお互いに見せ合い説明し合いながら自己紹介タイムを実施した
- 体験、実感というものが大事で、これが核になって初めて共同感覚を引き出せる
- 多様なエピソード:
- プラモデルを作るというモデリング経験
- 救援活動の納得感を構成するためのモデリング
- PTA活動の際の組織構成の構造を作る経験
- 日常生活業務やIT開発設計業務など様々な場面でのモデリングの実感を伴ったエピソードが集まった
- 本質洞察の実践:
- 本質洞察とは何かを説明した上でモデルの本質とはどんなところにあるのかを語ったエピソードの中から共通性を抽出する作業を実施した
- カードに書いていく形式で進めた
- 揺さぶりをかける新しい視点:
- 画家が絵を描く際のモデルさんというモデル
- ファッションモデルは一体何のモデルなのかという問いかけ
- 数学の理論に対してその理論を適用した具体例のことをモデルと数学では呼ぶが、その理論とモデルがITやエンジニアリングの分野のモデルの扱いと逆転しているように見えるのはなぜか
- チームごとの整理:
- Aチームはモデルの目的やモデルの特徴をいろんな観点で整理した
- Bチームはソフトウェア開発という分野に絞ってモデルの共通性を導こうと努力した
- Cチームは複雑な内容を短時間で共有するというコミュニケーションに着目してそれを整理しようとした
- 追加された観点:
- 型という観点、お手本という観点、具体例という観点、象徴という観点、抽象化、予測可能性といった観点が追加された
■ 6. モデルの定義試作
- Aチームの定義:
- 共通言語、コミュニケーション、文法がある程度存在する
- 抽象度を変えることができて可視化できる
- 関係性が明確化に明確になっている
- Bチームの定義:
- モデルとは共通認識の形成のために作られ、関心ごとの対象をシンプルかつ他人に共有可能な形式で表現したものである
- さらに洗練してモデルとは現実世界を認識再利用するためにモデルを共有する人や社会が共通に理解できる表現対象である(50文字以内に収まった)
- Cチームの定義:
- 物事の基準で再現可能なものである
- 目的に応じた要素に絞り複数要素とそれらの関係で構成する
■ 7. モデルの語源と二重構造
- モデルの語源:
- ラテン語で測定器具や基準という意味から始まっている
- 伝統的なモデリング:
- 画家の人やファッションモデルのようにある基準がモデルで、それを参照して何か作品を作るモデリングの仕方がまず最初に現れた
- 工学的モデリング:
- 工学の世界では色々な具体事例をうまくコントロール制御してより良い製品、より良い作品をするためにはどんなお手本があったらいいだろうということを考える
- 今度は具体的な作品事例から逆算してモデルというものを作るということが行われるようになってきた
- 二重構造の統合:
- 従来のお手本から作品を作るという次元のモデリングと、具体例を基準となる作品を作る際にお手本にするといいようなエッセンスを人工的な構成物として作り出すという新しい活動が二重に重なっている
- アジャイルなぐるぐるモデリングのように、作品が色々ある中からいい基準を見つけ出してそれをモデルとして抽出し、それに基づいて作品をまた作り、それをまた妥当性を判断し、それをまた抽象化するということがぐるぐる回るようなエンジニアリング的な活動に移ってきた
- UMTP新モデリング宣言との関連:
- このような従来のお手本としてのモデルが工学的な活動の中で三角関係になっていき、ぐるぐる回るモデリングに移行してきた
- これはUMTP新モデリング宣言で呼ばれるところのリベラルアーツとしてのモデリングに通じる