事業戦略を理解してソフトウェアを設計する

#jjug_ccc 2025 Spring 発表資料

①事業戦略とソフトウェアシステムの設計
②事業戦略「超」入門
③ソフトウェア設計と事業戦略を結びつける技法

Transcript

1. 事業戦略を理解して ソフトウェアを設計する 2025年6月7日 有限会社システム設計 増田 亨 #JJUG_CCC 2025 Spring
2. 自己紹介 ◆ 業務系アプリケーション開発者 ◆大きな泥団子退治のアドバイザ ◆エンジニアの育成支援 ➢ 現代的なオブジェクト指向プログラミング ➢ 現代的なデータモデリング 有限会社システム設計 代表 since 2003 コミューン株式会社 技術アドバイザ since 2023 2 増田 亨（masuda220） 著書(2017) 訳書(2024)
3. これから話すこと ①事業戦略とソフトウェアシステムの設計 ②事業戦略「超」入門 ③ソフトウェア設計と事業戦略を結びつける技法 3
4. 4 事業戦略と ソフトウェアシステムの設計
5. どちらのエンジニアが良い設計ができるか？ 5 事業戦略を理解して 設計しているエンジニア 事業戦略を理解しないで 設計しているエンジニア
6. 6 良い設計とは？
7. 7 良い設計は変更が楽で安全 悪い設計は変更がやっかいで危険
8. 8 良い設計は変更が楽で安全 悪い設計は変更がやっかいで危険 大きな泥団子
9. 大きな泥団子が生まれる３つのシナリオ 9 大きな泥団子 修正 拡張 修正 修正 修正 修正 拡張 拡張 拡張 拡張 拡張 修正 修正 修正 拡張 修正 シナリオ① 卓越した設計でスタート シナリオ② 最少の設計でスタート シナリオ③ 小さな泥団子でスタート 積みあがるバックログ 無理な日程 度重なる仕様変更 限られたリソース 人の入れ替わり ビジネスの圧力 結果は同じ…
10. 大きな泥団子の原因と設計の改善方法 10 混在 断片化 分離 集約 重複 一元化 いろいろ同時に考える 異なる関心事は 別々に考える あちこちを同時に考える 関連が強い関心事は 一箇所に集めて考える あちこちで同じことを考える 一つの関心事は ただ一箇所で考える
11. 事業戦略を理解すると設計判断が変わる 11 混在 断片化 分離 集約 重複 一元化 いろいろ同時に考える あちこちを同時に考える あちこちで同じことを考える どう分けるか どう集めるか どう纏めるか
12. 12 事業活動と ソフトウェアシステムの一体化
13. 事業活動のデジタル化 あらゆる業務のデジタル化が進んでいる あらゆる業務でソフトウェアシステムを使う 13 販売促進 販売 受注管理 顧客 サポート 入荷物流 出荷物流 生産 加工 技術開発 人材管理 経営企画 財務 会計 法務
14. 事業活動とソフトウェアシステムの一体化 その結果 ➢ソフトウェアエンジニアが事業を理解して判断し行動すること が直接的に事業価値を生み出す ➢ソフトウェアエンジニアが事業を理解せずに判断し行動するこ とが直接的に事業の損失になる 14
15. 15 ソフトウェア開発の基本制約 「使える時間」
16. 設計に使える時間は限られている あらゆる場所の設計を洗練させることは費用対効果が悪い 優先順位をつけて取り組む • 変更を楽で安全にする価値が高いところを重点的に • そういう価値が高くないところはできるだけ簡易に 優先順位をどう見極めるか？ 16
17. ドメイン駆動設計のアプローチ 17 ⚫ ソフトウェアシステムの対象領域を事業戦略 の観点で分類し、優先順位を決める ⚫ 競争優位を生み出す領域（中核の業務領域）に 優先的に取り組む ⚫ 競争優位を生まない領域（一般、補完）は できるだけ簡易に済ませる
18. 対象の業務領域を二軸で分類 18 競合他社との差別化 中核の 業務領域 業務ロジック の複雑さ
19. 業務領域の種類と設計方針 中核 一般 補完 競争優位 ◎ × × 複雑さ 〇 〇 × 変化 〇 × × 設計方針 ドメインモデル イベント履歴 既成の解決策 CRUD/ETL 調達方法 内製 購入？模倣？ 外注？ 19
20. 20 競争優位を生み出す 差別化戦略とは？
21. 競争優位を生み出す差別化戦略 21 この本は、副題にあるように、ソフトウェア開発 と事業戦略を結びつけることを強調している しかし、事業戦略をどうやって理解するかについ ての説明が少ない この本のアプローチを実際のソフトウェア設計に 取り入れるには、競争優位の戦略を理解するため のツールや技法が必要
22. 22 事業戦略「超」入門
23. 競争優位を生み出す差別化戦略 23 マイケルポーターが提示した競争優位の戦略は 現代のさまざまな事業戦略論の基礎となっている 同じ業界で、高業績を持続できる企業とそうでな い企業の差が、なぜ生まれるのか？ 数百の業界、数千の企業を分析してモデル化 鈍器、専門書、わかりにくい… 【原典】
24. 24 もっとわかりやすく
25. 【エッセンシャル版】 25
26. 競争優位を生み出す差別化戦略とは？ 26 マイケルポーターが提示した競争優位の戦略を 平易な言葉でわかりやすくまとめなおした本 ソフトウェアエンジニアにも（ビジネスに興味 があれば）読みやすい 差別化戦略のわかりやすい具体例が豊富 【エッセンシャル版】
27. 事業戦略の要点を理解して設計する 27 事業の目標 競争の要因 差別化戦略の５つの側面
28. 事業の目標を理解して設計する • 事業が存続する絶対条件は利益の確保である • 利益（業績）とは「売上ー費用」である • 高業績をいかに持続させるかの工夫が事業戦略 ソフトウェアシステムを構築し運用する理由 28
29. 業界の 競争要因を 理解して 設計する
30. 競争要因は 利益にどう 影響するかを 理解して 設計する 30 ソフトウェア要求が生まれる背景
31. 差別化戦略の５つの側面を理解して設計する ① 自社独自の特徴のある価値提案は何か？ ② 独自の価値を顧客に提供する独自のやり方は何か？ ③ 独自性を生むどんな排他的な選択をしているか？ ④ さまざまな活動をどう戦略に適合させているか？ ⑤ 戦略を継続するために何をすべきか？ 31
32. 32 差別化戦略の５つの側面を 分析して設計判断を変える
33. 差別化戦略を理解すると設計判断が変わる 33 混在 断片化 分離 集約 重複 一元化 いろいろ同時に考える あちこちを同時に考える あちこちで同じことを考える どう分けるか どう集めるか どう纏めるか
34. ソフトウェアの設計方針を変える 34 競合他社との差別化 中核の 業務領域 業務ロジック の複雑さ
35. 業務領域の種類で設計方針を変える 中核 一般 補完 競争優位 ◎ × × 複雑さ 〇 〇 × 変化 〇 × × 設計方針 ドメインモデル イベント履歴 既成の解決策 CRUD/ETL 調達方法 内製 購入？模倣？ 外注？ 35
36. 差別化戦略の実行と ソフトウェアの実装 36
37. 差別化戦略（絵にかいた餅？） 37 差別化戦略 高業績の持続 独自の価値提案 独自の活動 排他的選択
38. 差別化戦略を実体化する取り組み 38 差別化戦略 ビジネス ルール 高業績の持続 独自の価値提案 独自の活動 排他的選択 活動の決め事 活動を刺激 活動を制約 具体化
39. おなじみのソフトウェア開発 39 ビジネス ルール 業務 ロジック 活動の決め事 活動を刺激 活動を制約 ビジネスルールに 基づく計算判断 業務特化のデータ型 業務視点の抽象化 具体化
40. こういう文脈で捉える 40 差別化戦略 ビジネス ルール 業務 ロジック 高業績の持続 独自の価値提案 独自の活動 排他的選択 活動の決め事 活動を刺激 活動を制約 ビジネスルールに 基づく計算判断 業務特化のデータ型 業務視点の抽象化 具体化 具体化
41. 41 ソフトウェア設計と 事業戦略を結びつける技法
43. 何が書いてあるか？ 43
44. 書いてあることは基本的には一つ 事業活動とソフトウェアを 一緒に発展させていくための方法 44 この本の主題であり、最初から最後まで一貫している
45. もう少し解像度をあげると 45 第１部 基本となる考え方 第Ⅱ部 実装方法の選択 第Ⅲ部、付録A 現場での取り組み方 第Ⅳ部 分散型システムへの挑戦 事業活動とソフトウェアを一緒に発展させていく
46. 設計 判断 さらに解像度をあげると 46 開発者が事業活動を理解して、その理解を設計判断に活かす 事業活動 課題 課題 仕組み 仕組み 関係者 開発者が理解 トランザクション スクリプト アクティブ レコード ドメイン モデル イベント履歴式 ドメインモデル 値オブジェクト 集約 業務サービス レイヤード ポートと アダプター CQRS Web API メッセージング 送信箱 サーガ プロセス マネージャー イベント駆動型 アーキテクチャ マイクロ サービス データメッシュ トランザクション ロールバック 排他制御 テスト戦略 イベント ストーミング 大きな リファクタリング この本の主題 かつ 今日の話の焦点 （第１章～第４章） （第５章～第１６章） （第10章、付録A）
47. 事業活動を理解して ソフトウェアを設計する 47
48. 対象の業務領域のカテゴリーを特定する 48 競合他社との差別化 中核の 業務領域 業務ロジック の複雑さ
49. 業務ロジックの実装方法を決める 49 （第５章） （第６章） （第７章） （第１章）
50. 業務ロジックの実装方法が決まると 50 アーキテクチャが決まる テスト方針が決まる （第８章） （第１０章）
51. 事業戦略と分散型アーキテクチャ 51
52. 区切られた文脈ごとに一つのチームが担当する 52 区切られた文脈 • 同じ言葉の通用する範囲 • モデルの境界 • 開発単位の境界 • チームの責任範囲の境界
53. 境界を越えてどう連係するか？ 53 対等の関係 力関係が片寄った関係
54. ドメイン駆動設計と分散型アーキテクチャ 54 マイクロサービスアーキテクチャ （第14章） イベント駆動型アーキテクチャ （第15章） データメッシュ （第1６章） 区切られた文脈の考え方で取り組む
55. 事業の成長と設計の進化 55
56. 業務領域のカテゴリーの変化と設計の進化 56 事業が成長すれば、業務領域の カテゴリーが変化する 業務領域のカテゴリーが変化すれば 設計方針が変化する
57. 57 まとめ
58. どちらのエンジニアが良い設計ができるか？ 58 事業戦略を理解して 設計しているエンジニア 事業戦略を理解しないで 設計しているエンジニア
59. 事業活動とソフトウェアシステムの一体化 その結果 ➢ソフトウェアエンジニアが事業を理解して判断し行動すること が直接的に事業価値を生み出す ➢ソフトウェアエンジニアが事業を理解せずに判断し行動するこ とが直接的に事業の損失になる 59
60. 【エッセンシャル版】 ガイドブック 60
61. エンジニアの学習と成長 最初は、誰もが初学者 • 最初は、わけがわからないことだらけ • どんなに学んでも、やっぱりわからない だから学び続ける • 基本をたいせつに • 視野の広さ、視点の多さをたいせつに 異なる知見を持ち寄って、協働して共創する 61