モデリングフォーラム2025参加レポート：モデルは「完成品」より「フィードバック装置」
2025年11月26日にオンラインで開催された「モデリングフォーラム2025」に参加しました。ちょうど最近、自分の関心が「データモデル」や「ドメインモデル」に寄っていたので、まさにタイミングの良いイベントでした。
この記事では、フォーラムで印象に残った講演の内容と、そこから考えたことを共有します。タイムテーブルや講演動画・発表資料は以下のリンクから確認できます。
参加の背景：データモデルとドメインモデルへの関心
この数年、データモデルや型への関心が強くなっていて、関連する本を何冊か読んでいました。そのなかで浮かんできた疑問が、「ドメインモデルって結局何だろう？」「データモデリングとどう違うのだろう？」ということでした。
そういう問いを抱えていたところにモデリングフォーラムの存在を知り、すぐに申し込みました。
当日の構成と全体の印象
フォーラムは、基調講演・複数の専門家による講演・パネルディスカッションという構成でした。パネルディスカッションは時間が合わずリアルタイムでは見られませんでしたが、講演だけでも十分に刺激的でした。登壇者の専門分野が違っていて、その”ズレ”がむしろ面白く感じたからです。同じ「モデル」という言葉でも、何を価値として置いているかが講演ごとにはっきり出ていました。
今回のフォーラムで特に思い出したのは、ダイクストラの「私たちの知的能力はどちらかというと静的な関係を使いこなすことに向いており、時間の経過とともに進化するプロセスを可視化する力は比較的弱い」（EWD215 “A Case against the GO TO Statement”）という言葉です。静的なもの（＝モデル）を使ってフィードバックを回し、より良いものを作る。テストもまた、開発者にとってのフィードバック装置である。そんな見方がフォーラム全体を通じた自分のテーマになりました。
基調講演：モデルの「類型」を整理する視点
基調講演は、関西大学総合情報学部の植原亮准教授による「科学的思考におけるモデル：説明、創造、そして概念工学へ」でした。モデルを3つに分類して紹介していました。
- 物理的モデル — 路線図のように、実物を簡略化して表現するもの
- 数理モデル — 運動を数式で表すもの
- 数値計算モデル — シミュレーションに使うもの
ドメインモデルは、この中だと「図解などで人が理解しやすい形にした物理的モデル」に近いのかもしれない、と聞きながら考えていました。
印象に残った講演メモ
各講演で印象に残った話を、簡潔にまとめます。
- 全社データ基盤×MDM（真野正氏 / 株式会社データアーキテクト）：入力されたデータを経営へのフィードバックに変える視点。開発者が日常的にいじる対象というよりは、組織全体のデータガバナンスに関わる話で、フィードバックの時間軸も長めでした
- 仕様駆動開発（川島義隆氏 / 株式会社ウルフチーフ）：コードに寄りすぎず、データにも寄せすぎず、「もの（モデル）」として捉え直す提案
- AIコーディング（前田尚人氏・鈴木昴裕氏 / 株式会社東芝）：設計メタモデルを基盤に、生成AIで上流設計書から下流設計書を自動生成するプロトタイプの紹介。AIを”生成器”として扱い、人が品質を担保する分担で、ミッションクリティカル領域ならではの温度感が印象的でした
- RDRA×AI（神崎善司氏 / 株式会社バリューソース）：「要件定義の中心にモデルを置きLLMが出力した要件に責任をもつ」という、要件定義工程のモデリングにAIを使う実践の話
いちばん刺さった話：仕様駆動開発と「DSL」という原点の設定
特に面白かったのが、川島さんの「仕様駆動開発」でした。言葉だけ聞くと、最近の”仕様から一気に作る”系（短時間でウォーターフォールを回す、みたいな連想）に寄りそうですが、自分には力点が違って見えました。
ポイントは、「モデルからコードを生成する」流れで起きがちな落とし穴を、どう避けるかという話だったと思います。
- データモデルから始める場合：コードが”画面とデータをつなぐだけ”になりがち
- コード中心で進める場合：後から必要な情報が取れなくなったり、特定の言語やフレームワークに寄りすぎたりする
そこで提案されたのが「ドメイン特化言語（DSL）で記述する」という方法です。
エリック・エヴァンスが『ドメイン駆動設計』で書いたように、ドメイン駆動の主眼は「開発者とドメインエキスパートが同じ言葉で話す」ことにあります。コードとデータに引っ張られず、仕事や概念そのものをモデルとして捉えることが大事だと改めて感じました。
俗に言う「仕様書駆動開発」との違いは、おそらくここにあります。仕様書が画面やデータベースに囚われてしまうと、仕事や概念のモデルではなく、それを画面やデータベースから見た情報だけが残ってしまう。DSLで記述するアプローチは、その罠を避けるための原点の設定なのだと思います。
関連して思い出した3つの話
この話を聞いて、個人的に「近い論点だな」と感じたものが3つありました。
1) COBOLからJavaへのキャリアチェンジが難しかった理由（データ観の違い）
「スキルの問題ではなく、厳密なデータ観と緩やかなデータ観のミスマッチ」という整理です。特に「データが決まれば処理が決まる」という発想は、今回の”モデルの置き方”とつながって見えました。
2) Railsの設計とイベント（texta.fm No.3の話）
RailsでAPIを設計するとき、イベントがうまく設計できると「前処理・後処理などの置き場所がおさまる」という話です。フレームワークの制約が強い世界では、設計がハマると綺麗に作れる一方、ハマらないとインピーダンスミスマッチが残ります。だからこそ「モデルをどう捉えるか」が大事、という自分なりの結論につながりました。
3) ロバストネス図を「書き捨てる」という発想（米久保剛さんの書籍）
今回の登壇ではありませんが、米久保剛さんが『アーキテクトの教科書』の中で、アーキテクチャ設計の際にロバストネス図を書き捨てる（＝理解のための道具に割り切る）ことを提案しています。モデルを「完成品として残すもの」ではなく「理解を深めるためのフィードバック装置」として使うという姿勢は、今回のフォーラムで感じたテーマとも重なります。
もう一つの発見：モデルは「完成品」より「フィードバックを得る道具」
今回もう一つ面白かったのは、「フィードバックの取り方（＝モデルの使い方）」が登壇者の主戦場によって違っていたことです。
- MDM：入ってきたデータを経営に返すためのフィードバック。開発者が直接触る対象というよりは、組織全体で長い時間軸をかけて回すもの
- 要件定義×AI：成果物（モデル）の叩き台を作ってレビュー可能にするフィードバック
- DDDの文脈：開発者とドメインエキスパートが”同じモデルで会話する”ためのフィードバック
テスト駆動開発で「コードとテストが開発者にとってのフィードバックになる」という話も、同じ着眼点だと思います。
つまり、モデルの価値は「完成品」として残すことではなく、「フィードバックを回すための装置」として使うことにあるのではないか。マスターデータマネジメントでは経営に対してのフィードバック、テスト駆動ではコードに対してのフィードバック、ドメインモデルでは関係者間の共通理解に対してのフィードバック。対象やサイクルの長さは違っても、モデルを介して改善を回すという構造は共通しています。
まとめ
実践系の動画とは違い、いろいろなことを考えさせられるフォーラムでした。「モデル」という同じ言葉を使いながらも、登壇者ごとに力点が異なっていて、その違いから自分なりの気づきを得ることができました。
今回のフォーラムに直接は関係しませんが、このエントリの背景にあった参考文献やリンクを以下に挙げます。
参考文献・リンク
- 『事業分析・データ設計のためのモデル作成技術入門』（佐藤正美著）— データを Resource と Event に分けて考える切り口が紹介されている
- 『システム開発・刷新のための データモデル大全』（渡辺幸三著）— 多様な「事実」を柔軟に表現する発想が紹介されていて刺激的
- 『データモデリングでドメインを駆動する』（杉本啓著）— 基幹システムの”基本の型”、疎結合の考え方、マネジメント／アクティビティなど学びが多い
- 『ドメイン駆動設計をはじめよう』（Vlad Khononov著）— イベントソーシングとドメイン駆動設計をつなげる
- 『関数型ドメインモデリング』（Scott Wlaschin著）— DDDでどうコードを書くかについて書かれていて面白い
- 『エリック・エヴァンスのドメイン駆動設計』（Eric Evans著）
- 『アーキテクトの教科書』（米久保剛著）— ロバストネス図の活用など、アーキテクチャ設計の基礎を解説
- 川島さんのCosense（旧Scrapbox） — イミュータブルデータモデルなどの知見が公開されている
UnsplashのAlina Grubnyakが撮影した写真
