JJUG CCC 2025 Spring：エンジニアリングでビジネスを加速する。モデル駆動開発という選択肢

JJUG CCC 2025 Spring エンジニアリングでビジネスを加速する。 モデル駆動開発という選択肢 シンプレクス株式会社 長根尾 貴仁

スピーカー紹介 長根尾 貴仁 2019年シンプレクス入社 暗号資産の取引システム、web3プロダクトの開発・ 運用 代表プロジェクト：Pictrée（社会課題解決型web3 ゲーム）など 1 © 2025 Simplex Inc.

About シンプレクス株式会社 •1997年創業以来、メガバンク・大手証券会社など、 金融機関のテクノロジーパートナーとしてビジネスを 展開してきました •現在では、非金融領域でもソリューションを提供して います •21年4月にはコンサルティングファームXspear Consulting株式会社が発足 •シンプレクスとワンチームでDX推進を支援しています 2 © 2025 Simplex Inc.

シンプレクスの強み •ビジネス戦略から開発、運用保守まで一気通貫で 行う自社完結型モデル •お客様のビジネスパートナーとしてプライム受注にこ だわり、下請けへの丸投げをしない •「ビジネス」と「テクノロジー」の両面における深く広 い知見・経験を有するハイブリッド人材の採用・獲得 に注力し、全員がプレイヤーとして機能する 3 © 2025 Simplex Inc.

はじめに なぜ今「モデル駆動開発」なのか •DX時代、「ビジネスと開発の断絶」が現場の大きな 課題となっている。 •要件の頻繁な変化、現場間の認識齟齬、属人化…従 来型開発の限界 •モデル駆動開発は「変化に強い現場」を作る鍵とな るのでは！ 4 © 2025 Simplex Inc.

なぜ今、モデル駆動開発なのか 開発あるある？ •ドキュメントが形骸化 •みんな読まない・更新しない •設計書は作るが、いつの間にか実装と乖離している •ドキュメントと実装がうまくリンクしない •保守フェーズで混沌と混乱の渦に 5 © 2025 Simplex Inc.

なぜ今、モデル駆動開発なのか 開発あるある？ •仕様変更が実装者に伝わらない •仕様定義からソースコードへの道のりが長すぎる（大量 の中間ドキュメントの存在） •伝わったとしても実装への影響が把握しきれないことも •属人化 •担当者異動で現場が止まる・ベロシティ低下 6 © 2025 Simplex Inc.

なぜ今、モデル駆動開発なのか ボトルネックはどこに？ 要件定義 設計 実装 7 テスト リリース © 2025 Simplex Inc.

なぜ今、モデル駆動開発なのか ボトルネックはどこに？ ビジネス上の重要概 念がシステムの詳細 設計にかき消される 要件定義 設計 ビジネスユースケース に即したテスト設計が 困難 実装 テスト リリース 設計の解釈が実装者 に一任されている 8 © 2025 Simplex Inc.

モデルとは何か？ モデルとは？ •現実世界の業務やルールを、構造や図で抽象化し た設計図 •プロダクトの実現する業務・ビジネスルールが表現される 9 © 2025 Simplex Inc.

まず何をすればよいの、、？ 10 © 2025 Simplex Inc.

モデル駆動開発でやること まずはユースケースを洗い出す •アクター •誰起点で発生するのか •定刻に走る処理なのか •何らかの処理の完了をトリガーに発生する処理なのか 11 © 2025 Simplex Inc.

モデル駆動開発でやること まずはユースケースを洗い出す •シチュエーション •その業務が行われるモチベーションは？ •業務開始時に完了していないといけない他の業務はな いか 12 © 2025 Simplex Inc.

モデル駆動開発でやること まずはユースケースを洗い出す •実ユースケースの詳細 •具体的なビジネスルールを（現時点でわかる限り）もれ なく洗い出す • あとから追加できるので厳密になりすぎなくてもOK •ユースケース内で状態がどのように変わるのか？ • ステータス、値の変更、新たなモデルオブジェクトが作成され る 13 © 2025 Simplex Inc.

モデル駆動開発でやること まずはユースケースを洗い出す （例） 新規登録する ニックネームを 変更する 一般ユーザ アクター ユースケース 詳細 一般ユーザ 新規登録する ・同一メールア ドレスで新規登 録は不可 … ニックネームを 変更する ・特定の禁止 ワードを含むも のには変更不 可 … 報酬を稼ぐ xxxx ポイント残高を 確認する xxxx 報酬を稼ぐ ポイント残高を 確認する … 14 © 2025 Simplex Inc.

モデル駆動開発でやること まずはユースケースを洗い出す アクター ユースケース 詳細 一般ユーザ 新規登録する ・同一メールア ドレスで新規登 録は不可 … ニックネームを 変更する ・特定の禁止 ワードを含むも のには変更不 可 … 報酬を稼ぐ xxxx ポイント残高を 確認する xxxx 15 © 2025 Simplex Inc.

モデル駆動開発でやること まずはユースケースを洗い出す アクター ユースケース 詳細 一般ユーザ 新規登録する ・同一メールア ドレスで新規登 録は不可 … ニックネームを 変更する ・特定の禁止 ワードを含むも のには変更不 可 … 報酬を稼ぐ xxxx ポイント残高を 確認する xxxx 一般ユーザ メールアドレス ニックネーム 報酬 ポイント残高 16 © 2025 Simplex Inc.

モデル駆動開発でやること まずはユースケースを洗い出す 一般ユーザ メールアドレス 1. 各モデルをクラスとして定義する 2. モデルごとの“振る舞い”を洗い 出し、紐づくメソッドとして実装する ニックネーム 報酬 ポイント残高 17 © 2025 Simplex Inc.

モデル駆動開発とは MDDのメリットと本質 •要件変更や追加に強い構造になる •モデル修正→影響箇所特定→実装・テスト反映が明確 •関係者全員が「同じ絵」を見て議論できる •開発者・非開発者の壁を超えやすい •ドキュメントの陳腐化/属人化を防げる •コードやテストとモデルの一貫性 18 © 2025 Simplex Inc.

モデル駆動開発と現場フィードバック フィードバックに“迅速”に応える •仕様変更をモデルに即時反映 •モデルを中心に議論する •関連する設計・実装へ素早い変更が可能 •影響箇所が明確になっている •ビジネスサイドのフィードバックを短サイクルで反映 19 © 2025 Simplex Inc.

モデル駆動開発と現場フィードバック フィードバックに“迅速”に応える •仕様変更をモデルに即時反映 •モデルを中心に議論する •関連する設計・実装へ素早い変更が可能 •影響箇所が明確になっている •ビジネスサイドのフィードバックを短サイクルで反映 20 © 2025 Simplex Inc.

いざ実装を始めると 21 © 2025 Simplex Inc.

困ったことが起こる、、 22 © 2025 Simplex Inc.

開発が始まった！ 開発あるある？ •「一般ユーザー」ね、、まずはuserテーブルを作るか •おもむろにDDLを書き始める •リクエストからユーザのIDがもらえるから findByIdっと、、 •突然のJpaRepository登場 23 © 2025 Simplex Inc.

開発が始まった！ 開発あるある？（続き） •あーリクエストから取得できるのは別システム上の IDっぽいわ •じゃあ、別システムが用意してるREST APIを叩い て、、 •お馴染みのRestTemplate 24 © 2025 Simplex Inc.

開発が始まった！ 開発あるある？（続き） •実装終わったからUT書くで！ •あれ、RESTからユーザを取得しないとユーザの hogehoge()メソッドのテストが書けない、、 •Stub作りたくないよ… 25 © 2025 Simplex Inc.

開発が始まった！ 開発あるある？（続き） •やべ、IDで取得するつもりが実はニックネームを引 数に渡してた、両方String型だし仕方ないね •よし、再発防止のため、レビュー時チェックリストに 「引数の型を確かめたこと」を追加するで！ 26 © 2025 Simplex Inc.

開発が始まった！ 開発あるある？（続き） •やべ、IDで取得するつもりが実はニックネームを引 数に渡してた、両方String型だし仕方ないね •よし、再発防止のため、レビュー時チェックリストに 「引数の型を確かめたこと」を追加するで！ 27 © 2025 Simplex Inc.

何をすべきだったか？ 28 © 2025 Simplex Inc.

モデル駆動開発の心得 実装の詳細は、あとから考える！ •実装の詳細に含まれるもの •データベース設計、外部システムとの接続、プレゼンテー ション戦略 etc. •「何を実現したいのか」の目的から考える •実装の詳細は後回しでよいので、モデル・ビジネス ルールを優先的に考えたい 29 © 2025 Simplex Inc.

モデル駆動開発の心得 依存性逆転の原則（DIP）を使おう •具体ではなくより抽象に依存する UseCase UserRepository 30 © 2025 Simplex Inc.

モデル駆動開発の心得 依存性逆転の原則（DIP）を使おう •具体ではなくより抽象に依存する <I> UseCase UserRepository 31 UserRepositoryImpl © 2025 Simplex Inc.

モデル駆動開発の心得 実装の詳細は、あとから考える！ •依存性逆転の原則（DIP）を徹底 •ビジネスルール層（ドメイン）は外部詳細（DB/外部API 等）に依存しない •インフラ詳細は「外部」に隠蔽 • 「設計は抽象→詳細」へと流れるべき 32 © 2025 Simplex Inc.

モデル駆動開発の心得 実装の詳細は、あとから考える！ •“Clean Architecture”のアイデアに通ずる •内部にはEnterprise Business Rule（モデル）、外部 にはAdapter（実装の詳細） •内部は外部に依存してはならず、依存する場合は Interfaceに依存する •Interfaceは外部から実装される 33 © 2025 Simplex Inc.

モデル駆動開発の心得 実装の詳細は、あとから考える！ •ビジネス上の仕様変更時にはビジネスルール層のみ を着目すればよい！ •外部詳細は無視できる •自動テストの実装も容易 34 © 2025 Simplex Inc.

モデル駆動開発の心得 ArchUnitによる設計ルール自動化 •ArchUnitで「パッケージ間依存」「命名規則」等の 設計ルールをJavaで記述 •ドメイン層はアプリケーション層に依存してはならない、ド メイン層はインフラ層に依存してはならない、など •CI/CDに組み込み、逸脱検知を自動化 35 © 2025 Simplex Inc.

モデル駆動開発の心得 ArchUnitによる設計ルール自動化 36 © 2025 Simplex Inc.

開発が始まった！ 開発あるある？ Part2 •一般ユーザーをXXXする機能を実装してみよ •関係するオブジェクトから必要な情報をgetXXX() して… 37 © 2025 Simplex Inc.

開発が始まった！ 開発あるある？ Part2 （続き） •一般ユーザのsetXXX()を呼び出して… •おしまい！ •念のためバリデーションもgetXXX()前に書いてお いたで！ 38 © 2025 Simplex Inc.

開発が始まった！ 開発あるある？ Part2（続き） •なんと、仕様変更でバリデーションが1つから4つに 増えた… •しかも、設定する値も増えたからいろんなsetXXX()を 何回も呼ばなきゃいけなくなった 39 © 2025 Simplex Inc.

開発が始まった！ 開発あるある？ Part2（続き） •さらに、バリデーションのメソッドを1つ呼び出し忘れ てたから見事に結合テストでバグ検知したで！ 40 © 2025 Simplex Inc.

開発が始まった！ 開発あるある？ Part2（続き） •さらに、バリデーションのメソッドを1つ呼び出し忘れ てたから見事に結合テストでバグ検知したで！ 41 © 2025 Simplex Inc.

何をすべきだったか？ 42 © 2025 Simplex Inc.

モデル駆動開発の心得 “手続き的”から“振る舞い的”へ •設計時、ユースケースを文章でザーッと書いてしまう と、手続き的なコーディングになりがち •サービスクラスにつらつらとバリデーション→get→set が延々と書いてある •基本設計・詳細設計の段階から、どのモデルの振る 舞いとするかを明確にすべき 43 © 2025 Simplex Inc.

モデル駆動開発の心得 “手続き的”から“振る舞い的”へ •つまり、「ある処理があったときに、それがどのクラス （モデル）の何というメソッドとして実装されるべきか」 を設計時点で考える必要があり、かつそれが実装時 に実現されるドキュメンテーションが求められる！ 44 © 2025 Simplex Inc.

モデル駆動開発の心得 “手続き的”から“振る舞い的”へ •例：一連の処理で関連するエンティティ・振る舞いの 関係を定義したドキュメント 45 © 2025 Simplex Inc.

モデル駆動開発の心得 “手続き的”から“振る舞い的”へ •UseCaseでは、モデルのpublicメソッドを淡々と呼 び出していくだけになる •“Don’t ask, tell.” •モデルのpublicメソッドは、内部にビジネスロジック を保持し、外部から隠蔽する •モデルは高凝集なクラスとなり、他のどのコードよりも Valuableとなる 46 © 2025 Simplex Inc.

モデル駆動開発の心得 “手続き的”から“振る舞い的”へ •殊に、モデルのフィールドはモデル内部で利用される ことがほとんどを占めることになる •フィールドは原則privateにし、外部に公開しない •外部からの勝手な変更も許さない •結果として、モデルのクラスはテスト容易性が格段に 高まる！ 47 © 2025 Simplex Inc.

モデル駆動開発の心得 “手続き的”から“振る舞い的”へ 以下をいずれも満たす理想的なクラスが完成！ 高凝集性 外部から 意図せず 変更されない 48 フレームワーク 非依存 © 2025 Simplex Inc.

モデル駆動開発の心得 コードが“生きたドキュメント”となる •ドメイン知識はドメインモ デルクラスの振る舞い（つ まりメソッド）に記載される •ビジネスルールを知りた ければ振る舞いだけを見 ればよい！ 49 class User ( val name: Name ) { fun addXXX(hoge: Hoge) { doSomething1() } fun moveYYY(fuga: Fuga) { doSomething2() } } © 2025 Simplex Inc.

モデル駆動開発の心得 コードが“生きたドキュメント”となる •モデル・設計意図がテストケースからも読み取れる •テスト失敗＝モデル・実装のズレを即時に検知可能 •新規参画者・ビジネスステークホルダが自動単体テ ストの実行結果を読んでいれば業務仕様がわかる世 界 50 © 2025 Simplex Inc.

その他Tips 51 © 2025 Simplex Inc.

その他Tips① “一覧取得”系との親和性 •モデルはあくまでビジネス上の振る舞いに特化した 設計 •一覧表示などのユースケースで多数のデータを取 得しようとするとかなりのオーバーヘッドが発生する 場合がある 52 © 2025 Simplex Inc.

その他Tips① “一覧取得”系との親和性 対処法： •モデルとは別のDTOを作成し、必要な情報を返却す るための最適なフェッチ戦略を検討する 53 © 2025 Simplex Inc.

その他Tips① “一覧取得”系との親和性 対処法： •例えば、Spring Data JPAだと、同名のテーブルに 対して複数種類の@Entityクラスを実装可能 •一覧取得用の別@Entityクラスを定義し、専用のDTOと して取り扱う •いわゆるCQRS戦略（データソースは同一） 54 © 2025 Simplex Inc.

その他Tips② 大きすぎるユースケース •処理の長大なユースケースが稀に爆誕する •特にコアドメインに近いものほど神ユースケースを生み出 す傾向にある 55 © 2025 Simplex Inc.

その他Tips② 大きすぎるユースケース 対処法 •ユースケース内で、処理の区切りごとに“イベント”オ ブジェクトを発火 •分割の単位は「1つのモデルに変更（値の更新）が入る ごと」程度が目安 56 © 2025 Simplex Inc.

その他Tips② 大きすぎるユースケース •イベントを引数にとる別ユースケースに後続処理を 移植し、ユースケースの分割を図る •マイクロサービスにせずにクラスレイヤーでのイベント駆 動アーキテクチャを実現するようなイメージ •Readability, Testabilityが格段に向上する UseCase A event UseCase B 57 event UseCase C © 2025 Simplex Inc.

その他Tips② 大きすぎるユースケース •参考 •弊社セッション @ JJUG CCC 2024 fall • https://docswell.com/s/Simplex/ZJ4XQE-simplex_sugawara01 58 © 2025 Simplex Inc.

• https://docswell.com/s/Simplex/ZJ4XQE-simplex_sugawara01

まとめ 59 © 2025 Simplex Inc.

まとめ モデル駆動開発を通じて得た学び •ビジネスユースケースを洗い出しモデルを抽出する ことによって、ビジネスサイドとテクノロジーサイドの両 者の共通言語を生み出すことができ、両者の垣根を 下げるアプローチとなりうる。 60 © 2025 Simplex Inc.

まとめ モデル駆動開発を通じて得た学び •また、モデル駆動開発で取り入れるべきエッセンスは いずれも基礎的なプログラミングの原則が根底にあ る。 61 © 2025 Simplex Inc.

まとめ モデル駆動開発を通じて得た学び •ビジネスサイドとの共通言語を駆使して開発者が直 接対話することで、ユーザーからのフィードバックを迅 速にプロダクトに反映でき、かつ認識齟齬のない高 品質なエンジニアリングが可能となる。 62 © 2025 Simplex Inc.

ご清聴ありがとうございました！ 63 © 2025 Simplex Inc.