モデリングの費用対効果

ドメイン駆動設計を現場で実践する中で感じているモデル駆動設計のたいせつさや、モデリングの費用対効果について、まとめてみました。
・ドメイン駆動設計の要点
・なぜドメイン駆動設計か？
・複雑さに立ち向かうためのモデリング
・認知の負荷と、モデリングの効果

Transcript

1. モデリングの費用対効果 2022年5月19日 有限会社システム設計 増田
2. 自己紹介 アプリケーション開発者 Java/Springを使った業務系アプリケーション開発 ドメイン駆動設計の開発現場への導入と実践 著書『現場で役立つシステム設計の原則』 ～変更を楽で安全にするオブジェクト指向の実践技法 技術者コミュニティ「現場から学ぶモデル駆動設計」主催 2022/5/19 2
3. ドメイン駆動設計 2022/5/19 3
4. ドメイン駆動設計という開発アプローチ ① 事業活動の複雑さに照準を合わせる設計 ② 変更を楽で安全にするためのモデル駆動設計 ③ 現代的なオブジェクト指向プログラミング ④ XP的な開発の考え方とやり方 2022/5/19 4 カプセル化と契約プログラミング イミュータブル（変更不可） 控えめなサブタイピング コミュニケーション インクリメンタルな開発 リファクタリング 関心を分離する境界の明示 関心の依存関係の単純化 モデル-設計-実装の整合性維持 開発者が事業活動を理解する 事業活動の構造をコードで表現 ドメインモデルパターン
5. なぜドメイン駆動設計か？ 2022/5/19 5
6. なぜドメイン駆動設計か？ （私への仕事の依頼のパターン） 2022/5/19 6 損保系 基幹システム 通販系 基幹システム 健康管理アプリ サブスク課金向けSaaS 老舗 通信系サービス(ISP) 運用維持の コスト負担 修正拡張の コスト 変更の スピード 200X年から DOA系独自言語 創業から5年 事業の急拡大 創業から10年 PHPで増改築 200X年から JSP/CORBA/C 200X年から COBOL/汎用機 ???
7. なぜドメイン駆動設計か？ （私への仕事の依頼のパターン） 2022/5/19 7 損保系 基幹システム 通販系 基幹システム 健康管理アプリ サブスク課金向けSaaS 老舗 通信系サービス(ISP) 運用維持の コスト負担 修正拡張の コスト 変更の スピード 200X年から DOA独自言語 創業から5年 事業の急拡大 創業から10年 PHPで増改築 200X年から JSP/CORBA/C 200X年から COBOL/汎用機 クラウド マイクロサービス ドメイン駆動設計
8. なぜドメイン駆動設計か？ ソフトウェア提供サイクルの変化 2022/5/19 8 構想立案～要件定義～設計・開発・テスト～移行～運用保守～廃棄 20年 × １回 ５年 × 4回
9. 2022/5/19 9 構想立案～要件定義～設計・開発・テスト～移行～運用保守～廃棄 20年 × １回 ５年 × 4回 1年 × 20回 半年 × 40回 ３カ月 × 80回 毎月 × 240回 隔週 × 480回 毎週 × 960回 毎日 × 5000回 なぜドメイン駆動設計か？ ソフトウェア提供サイクルの変化
10. 2022/5/19 10 構想立案～要件定義～設計・開発・テスト～移行～運用保守～廃棄 20年 × １回 ５年 × 4回 1年 × 20回 半年 × 40回 ３カ月 × 80回 毎月 × 240回 隔週 × 480回 毎週 × 960回 毎日 × 5000回 クラウド/コンテナ アプリケーション分割 データベース分割 CI/CDパイプライン ドメイン駆動設計 商流のデジタル化/多元化 金流のデジタル化/多様化 物流のデジタル化/多頻度化 事業環境の変化 事業活動の変化 実行環境の変化 アーキテクチャの変化 設計開発手法の変化 なぜドメイン駆動設計か？ ソフトウェア提供サイクルの変化 実現可能性 必要性
11. 複雑さへの挑戦 2022/5/19 11
12. 事業活動／ソフトウェア 2022/5/19 12 さまざまな要素が 複雑に絡み合い 多元的に変化する
13. 事業活動／ソフトウェア 2022/5/19 13 さまざまな要素が 複雑に絡み合い 多元的に変化する 理解の負荷 思考の負荷 伝達の負荷 情報量 vs. 人間のワーキング メモリ 状況判断 意思決定 背景知識の違い 注目点の違い
14. モデリング＝簡略化 2022/5/19 14 さまざまな要素が 複雑に絡み合い 多元的に変化する 情報量 vs. 人間のワーキング メモリ 状況判断 意思決定 背景知識の違い 注目点の違い 理解を助ける 簡略化 伝達を助ける 簡略化 思考を助ける 簡略化
15. モデル（成果物）とモデリング（過程） ① 組織/チームでソフトウェアを開発する時、効果を生み出すの は、モデル(成果物)よりもモデルを作るための認識合わせを する活動 ② モデルは、状況の変化・理解の変化・判断の変化によって変 わっていく（成果物として固定の完成形/最終形はない） ③ モデリングという「簡略化のための活動」が価値を生み出す 2022/5/19 15
16. モデリング（簡略化活動）の費用対効果 2022/5/19 16 モデリングの時間 モデリングの時間 モデリングの時間 時間をかければ効果が大きくなるわけではない いかに少ない時間で大きな効果をだすか 効果がでていないモデリングの時間をどう減らすか 理解しやすくなった 判断しやすくなった 伝わりやすくなった
17. モデリングスキルの三段階 2022/5/19 17 基礎知識 技法とツール 用途と期待効果 効果の認識能力 費用の認識能力 費用対効果を改善する能力 費用対効果を判断する能力
18. 持続的な進化のためのモデリング 2022/5/19 18
19. 機敏なモデリング いつでも どこでも 誰でも 少しずつ 繰り返し 持続的に 2022/5/19 19 ソフトウェアの提供サイクルが短い 開発・提供の単位が小さい 変更の影響範囲を限定できている
20. 多面的なモデリング（並行＆連動） 構想 事業活動の分析 要件定義 設計 • アプリケーション • ソフトウェア • システム（実行環境） 実装 テスト設計 移行 2022/5/19 20 例えば 配送区分を追加するコードの変更は 事業環境の変化、事業活動の変化、 システム化構想の変化と連動している
21. モデリング(簡略化活動)のコントロール 視点の切り替え 構造（関連） 振る舞い（時間軸/循環系） 相互作用 視点を組み合わせた整合性の検証（モデリングの品質改善） 解像度を切り替える 視界を広げる/狭める 照準の対象を変える 2022/5/19 21
22. 機敏なモデリングの道具 ① 手書き（いつでも、どこでも） ② お絵描きツール（ネット上で共有） ③ テキストエディタ＆可視化（変更容易性・履歴・解析検査） • Plant UML(独自文法） • Mermaid (mark down) • JIG(Java) 2022/5/19 22
23. 実際どんな感じでやっているか A) 事業活動を理解するためのモデリング B) 設計のモデリング C) 実行環境や運用設計のモデリング 2022/5/19 23
24. 事業活動を理解するためのモデリング 2022/5/19 24 三つの視点 商流 金流 物流 業務フロー （アクティビティ図） ユースケースモデル ユースケース記述(代替コース） イベントシーケンス （時系列分析） (イベントストーミング） 状態マシン ガード条件 情報モデル 識別番号 発生タイミング 制約記述 (OCL→Java) 画面 帳票 価格表/割引条件 契約書/利用規約 業務マニュアル 事業活動の構造や制約に関わる側面を重視した分析・整理をしている
25. 設計のモデリング 2022/5/19 25 視点 パッケージ クラス テーブル API ツールでモデルや設計の状態を評価 ・可視化(関連図など)して構造を評価 ・健全性を数値解析（LCOM*, CC, 命名,サイズ, … ) ・要点の抽出・ソート・分類 テキストで記述(Java/DDL) ・ラフスケッチ段階から ・整合性を文法的にチェック ・モデリング/設計が安定してくる＝そのまま動く
26. 実行環境のモデリング 2022/5/19 26 AWS構成図 (ほぼ配置図＋コンポーネント図） 依存管理とビルドスクリプト(gradle/groovy) 環境構築のスクリプト（Terraform) パイプラインのスクリプト(yaml) 実行環境は基本的に仮想化 （クラウド／コンテナ） 「機器」という概念はない OSレベルの操作もない世界 DSLで記述 マクロ化 実行状況の可視化・ログ化 白紙から検討しモデリングという機会がなくなりつつある パターンやテンプレートのカタログからの選択＋設定でカストマイズするイメージ
27. モデリングの教え方 2022/5/19 27
28. 私の活動範囲で肌で感じていること 開発の現場は モデリングが役に立つ 機会にあふれている モデリングや設計の必要性は なんとなく理解している いつ、何を、どうやるか やり方がわからない それっぽいことをやってみるが あまりうまくできていない ・流通系の基幹システム刷新、損保系の次世代基幹システム構築 ・離陸に成功したスタートアップ（介護、健康、飲食、会計、…）の技術負債との戦い ・「現場から学ぶモデル設計」技術者コミュニティ（4000人超/16回の勉強会）の反応 2022/5/19 28
29. モデリング：何が足りていないのか 知識？ 練度？ 動機？ 2022/5/19 29
30. モデリング：知識が不足しているなら 知識に触れる機会を増やす → 現場の経験談、実践報告 → ライトな解説書（マンガでわかる…） → 教材＋座学＋知識テスト → 説明役/教え役のロールプレイング 2022/5/19 30
31. モデリング：練度が不足しているなら 実際にやってみて体験知を増やす → 継続的にモデリング（理解度や練度の差分の体験） → 複数モデルを作って比較して気づきを増やす → 教科書的知識と実践とのギャップを体験 → 視点・解像度・視界・照準のコントロールの練習 → 複数モデル間の整合性をチェックして品質改善の練習 2022/5/19 31
32. モデリング：動機が不足しているなら アメ and/or ムチ？ → うまみを体験する • 理解しやすくなった • 判断しやすくなった • 伝わりやすくなった → うまみの体験を強化する（ほめる） → モデリング不足の痛みの具体例を見つける（ソフトなペナルティ） → わかりにくい/判断しにくい/伝わりにくいをフィードバック 2022/5/19 32
33. まとめ 2022/5/19 33
34. 事業活動／ソフトウェア 2022/5/19 34 さまざまな要素が 複雑に絡み合い 多元的に変化する
35. 事業活動／ソフトウェア 2022/5/19 35 さまざまな要素が 複雑に絡み合い 多元的に変化する 理解の負荷 思考の負荷 伝達の負荷 情報量 vs. 人間のワーキング メモリ 状況判断 意思決定 背景知識の違い 注目点の違い
36. モデリング＝簡略化 2022/5/19 36 さまざまな要素が 複雑に絡み合い 多元的に変化する 情報量 vs. 人間のワーキング メモリ 状況判断 意思決定 背景知識の違い 注目点の違い 理解を助ける 簡略化 伝達を助ける 簡略化 思考を助ける 簡略化
37. モデリングスキルの三段階 2022/5/19 37 基礎知識 技法とツール 用途と期待効果 効果の認識能力 費用の認識能力 費用対効果を改善する能力 費用対効果を判断する能力