Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
事業戦略を理解してソフトウェアを設計する
Search
増田 亨
PRO
June 06, 2025
Programming
2
29
事業戦略を理解してソフトウェアを設計する
#jjug_ccc 2025 Spring 発表資料
①事業戦略とソフトウェアシステムの設計
②事業戦略「超」入門
③ソフトウェア設計と事業戦略を結びつける技法
増田 亨
PRO
June 06, 2025
Tweet
Share
More Decks by 増田 亨
See All by 増田 亨
これだけは知っておきたいクラス設計の基礎知識 version 2
masuda220
PRO
24
7.2k
ビジネスモデリング道場 目的と背景
masuda220
PRO
10
1.8k
ソフトウェアエンジニアの成長
masuda220
PRO
13
2.5k
分散型アーキテクチャとドメイン駆動設計
masuda220
PRO
9
3.6k
ソフトウェア開発の複雑さに立ち向かう
masuda220
PRO
13
16k
『ドメイン駆動設計をはじめよう』のモデリングアプローチ
masuda220
PRO
9
1.1k
現場で役立つモデリング 超入門
masuda220
PRO
16
4.3k
『ドメイン駆動設計をはじめよう』中核の業務領域
masuda220
PRO
9
2.7k
ソフトウェアの実装と事業戦略を結びつける
masuda220
PRO
19
7.8k
Other Decks in Programming
See All in Programming
ユーザーにサブドメインの ECサイトを提供したい (あるいは) 2026年函館で一番熱くなるかもしれない言語の話
uvb_76
0
170
「MCPを使ってる人」が より詳しくなるための解説
yamaguchidesu
0
590
【TSkaigi 2025】これは型破り?型安全? 真実はいつもひとつ!(じゃないかもしれない)TypeScript クイズ〜〜〜〜!!!!!
kimitashoichi
1
300
衛星の軌道をWeb地図上に表示する
sankichi92
0
250
List Unfolding - 'unfold' as the Computational Dual of 'fold', and how 'unfold' relates to 'iterate'"
philipschwarz
PRO
0
130
テスト分析入門/Test Analysis Tutorial
goyoki
11
2.7k
"使いづらい" をリバースエンジニアリングする UI の読み解き方
rebase_engineering
0
110
ソフトウェア品質特性、意識してますか?AIの真の力を引き出す活用事例 / ai-and-software-quality
minodriven
19
6.6k
TypeScript エンジニアが Android 開発の世界に飛び込んだ話
yuisakamoto
6
950
AI Coding Agent Enablement in TypeScript
yukukotani
17
7.1k
iOSアプリ開発もLLMで自動運転する
hiragram
6
2.1k
try-catchを使わないエラーハンドリング!? PHPでResult型の考え方を取り入れてみよう
kajitack
3
290
Featured
See All Featured
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3.2k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
29
9.5k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
25
2.8k
The Cult of Friendly URLs
andyhume
78
6.4k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
160
15k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
5
620
Bash Introduction
62gerente
614
210k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
106
19k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
12k
Code Review Best Practice
trishagee
68
18k
It's Worth the Effort
3n
184
28k
Transcript
事業戦略を理解して ソフトウェアを設計する 2025年6月7日 有限会社システム設計 増田 亨 #JJUG_CCC 2025 Spring
自己紹介 ◆ 業務系アプリケーション開発者 ◆大きな泥団子退治のアドバイザ ◆エンジニアの育成支援 ➢ 現代的なオブジェクト指向プログラミング ➢ 現代的なデータモデリング 有限会社システム設計
代表 since 2003 コミューン株式会社 技術アドバイザ since 2023 2 増田 亨(masuda220) 著書(2017) 訳書(2024)
これから話すこと ①事業戦略とソフトウェアシステムの設計 ②事業戦略「超」入門 ③ソフトウェア設計と事業戦略を結びつける技法 3
4 事業戦略と ソフトウェアシステムの設計
どちらのエンジニアが良い設計ができるか? 5 事業戦略を理解して 設計しているエンジニア 事業戦略を理解しないで 設計しているエンジニア
6 良い設計とは?
7 良い設計は変更が楽で安全 悪い設計は変更がやっかいで危険
8 良い設計は変更が楽で安全 悪い設計は変更がやっかいで危険 大きな泥団子
大きな泥団子が生まれる3つのシナリオ 9 大きな泥団子 修正 拡張 修正 修正 修正 修正 拡張
拡張 拡張 拡張 拡張 修正 修正 修正 拡張 修正 シナリオ① 卓越した設計でスタート シナリオ② 最少の設計でスタート シナリオ③ 小さな泥団子でスタート 積みあがるバックログ 無理な日程 度重なる仕様変更 限られたリソース 人の入れ替わり ビジネスの圧力 結果は同じ…
大きな泥団子の原因と設計の改善方法 10 混在 断片化 分離 集約 重複 一元化 いろいろ同時に考える 異なる関心事は
別々に考える あちこちを同時に考える 関連が強い関心事は 一箇所に集めて考える あちこちで同じことを考える 一つの関心事は ただ一箇所で考える
事業戦略を理解すると設計判断が変わる 11 混在 断片化 分離 集約 重複 一元化 いろいろ同時に考える あちこちを同時に考える
あちこちで同じことを考える どう分けるか どう集めるか どう纏めるか
12 事業活動と ソフトウェアシステムの一体化
事業活動のデジタル化 あらゆる業務のデジタル化が進んでいる あらゆる業務でソフトウェアシステムを使う 13 販売促進 販売 受注管理 顧客 サポート 入荷物流
出荷物流 生産 加工 技術開発 人材管理 経営企画 財務 会計 法務
事業活動とソフトウェアシステムの一体化 その結果 ➢ソフトウェアエンジニアが事業を理解して判断し行動すること が直接的に事業価値を生み出す ➢ソフトウェアエンジニアが事業を理解せずに判断し行動するこ とが直接的に事業の損失になる 14
15 ソフトウェア開発の基本制約 「使える時間」
設計に使える時間は限られている あらゆる場所の設計を洗練させることは費用対効果が悪い 優先順位をつけて取り組む • 変更を楽で安全にする価値が高いところを重点的に • そういう価値が高くないところはできるだけ簡易に 優先順位をどう見極めるか? 16
ドメイン駆動設計のアプローチ 17 ⚫ ソフトウェアシステムの対象領域を事業戦略 の観点で分類し、優先順位を決める ⚫ 競争優位を生み出す領域(中核の業務領域)に 優先的に取り組む ⚫ 競争優位を生まない領域(一般、補完)は
できるだけ簡易に済ませる
対象の業務領域を二軸で分類 18 競合他社との差別化 中核の 業務領域 業務ロジック の複雑さ
業務領域の種類と設計方針 中核 一般 補完 競争優位 ◎ × × 複雑さ 〇
〇 × 変化 〇 × × 設計方針 ドメインモデル イベント履歴 既成の解決策 CRUD/ETL 調達方法 内製 購入?模倣? 外注? 19
20 競争優位を生み出す 差別化戦略とは?
競争優位を生み出す差別化戦略 21 この本は、副題にあるように、ソフトウェア開発 と事業戦略を結びつけることを強調している しかし、事業戦略をどうやって理解するかについ ての説明が少ない この本のアプローチを実際のソフトウェア設計に 取り入れるには、競争優位の戦略を理解するため のツールや技法が必要
22 事業戦略「超」入門
競争優位を生み出す差別化戦略 23 マイケルポーターが提示した競争優位の戦略は 現代のさまざまな事業戦略論の基礎となっている 同じ業界で、高業績を持続できる企業とそうでな い企業の差が、なぜ生まれるのか? 数百の業界、数千の企業を分析してモデル化 鈍器、専門書、わかりにくい… 【原典】
24 もっとわかりやすく
【エッセンシャル版】 25
競争優位を生み出す差別化戦略とは? 26 マイケルポーターが提示した競争優位の戦略を 平易な言葉でわかりやすくまとめなおした本 ソフトウェアエンジニアにも(ビジネスに興味 があれば)読みやすい 差別化戦略のわかりやすい具体例が豊富 【エッセンシャル版】
事業戦略の要点を理解して設計する 27 事業の目標 競争の要因 差別化戦略の5つの側面
事業の目標を理解して設計する • 事業が存続する絶対条件は利益の確保である • 利益(業績)とは「売上ー費用」である • 高業績をいかに持続させるかの工夫が事業戦略 ソフトウェアシステムを構築し運用する理由 28
業界の 競争要因を 理解して 設計する
競争要因は 利益にどう 影響するかを 理解して 設計する 30 ソフトウェア要求が生まれる背景
差別化戦略の5つの側面を理解して設計する ① 自社独自の特徴のある価値提案は何か? ② 独自の価値を顧客に提供する独自のやり方は何か? ③ 独自性を生むどんな排他的な選択をしているか? ④ さまざまな活動をどう戦略に適合させているか? ⑤
戦略を継続するために何をすべきか? 31
32 差別化戦略の5つの側面を 分析して設計判断を変える
差別化戦略を理解すると設計判断が変わる 33 混在 断片化 分離 集約 重複 一元化 いろいろ同時に考える あちこちを同時に考える
あちこちで同じことを考える どう分けるか どう集めるか どう纏めるか
ソフトウェアの設計方針を変える 34 競合他社との差別化 中核の 業務領域 業務ロジック の複雑さ
業務領域の種類で設計方針を変える 中核 一般 補完 競争優位 ◎ × × 複雑さ 〇
〇 × 変化 〇 × × 設計方針 ドメインモデル イベント履歴 既成の解決策 CRUD/ETL 調達方法 内製 購入?模倣? 外注? 35
差別化戦略の実行と ソフトウェアの実装 36
差別化戦略(絵にかいた餅?) 37 差別化戦略 高業績の持続 独自の価値提案 独自の活動 排他的選択
差別化戦略を実体化する取り組み 38 差別化戦略 ビジネス ルール 高業績の持続 独自の価値提案 独自の活動 排他的選択 活動の決め事
活動を刺激 活動を制約 具体化
おなじみのソフトウェア開発 39 ビジネス ルール 業務 ロジック 活動の決め事 活動を刺激 活動を制約 ビジネスルールに
基づく計算判断 業務特化のデータ型 業務視点の抽象化 具体化
こういう文脈で捉える 40 差別化戦略 ビジネス ルール 業務 ロジック 高業績の持続 独自の価値提案 独自の活動
排他的選択 活動の決め事 活動を刺激 活動を制約 ビジネスルールに 基づく計算判断 業務特化のデータ型 業務視点の抽象化 具体化 具体化
41 ソフトウェア設計と 事業戦略を結びつける技法
42
何が書いてあるか? 43
書いてあることは基本的には一つ 事業活動とソフトウェアを 一緒に発展させていくための方法 44 この本の主題であり、最初から最後まで一貫している
もう少し解像度をあげると 45 第1部 基本となる考え方 第Ⅱ部 実装方法の選択 第Ⅲ部、付録A 現場での取り組み方 第Ⅳ部 分散型システムへの挑戦
事業活動とソフトウェアを一緒に発展させていく
設計 判断 さらに解像度をあげると 46 開発者が事業活動を理解して、その理解を設計判断に活かす 事業活動 課題 課題 仕組み 仕組み
関係者 開発者が理解 トランザクション スクリプト アクティブ レコード ドメイン モデル イベント履歴式 ドメインモデル 値オブジェクト 集約 業務サービス レイヤード ポートと アダプター CQRS Web API メッセージング 送信箱 サーガ プロセス マネージャー イベント駆動型 アーキテクチャ マイクロ サービス データメッシュ トランザクション ロールバック 排他制御 テスト戦略 イベント ストーミング 大きな リファクタリング この本の主題 かつ 今日の話の焦点 (第1章~第4章) (第5章~第16章) (第10章、付録A)
事業活動を理解して ソフトウェアを設計する 47
対象の業務領域のカテゴリーを特定する 48 競合他社との差別化 中核の 業務領域 業務ロジック の複雑さ
業務ロジックの実装方法を決める 49 (第5章) (第6章) (第7章) (第1章)
業務ロジックの実装方法が決まると 50 アーキテクチャが決まる テスト方針が決まる (第8章) (第10章)
事業戦略と分散型アーキテクチャ 51
区切られた文脈ごとに一つのチームが担当する 52 区切られた文脈 • 同じ言葉の通用する範囲 • モデルの境界 • 開発単位の境界 •
チームの責任範囲の境界
境界を越えてどう連係するか? 53 対等の関係 力関係が片寄った関係
ドメイン駆動設計と分散型アーキテクチャ 54 マイクロサービスアーキテクチャ (第14章) イベント駆動型アーキテクチャ (第15章) データメッシュ (第16章) 区切られた文脈の考え方で取り組む
事業の成長と設計の進化 55
業務領域のカテゴリーの変化と設計の進化 56 事業が成長すれば、業務領域の カテゴリーが変化する 業務領域のカテゴリーが変化すれば 設計方針が変化する
57 まとめ
どちらのエンジニアが良い設計ができるか? 58 事業戦略を理解して 設計しているエンジニア 事業戦略を理解しないで 設計しているエンジニア
事業活動とソフトウェアシステムの一体化 その結果 ➢ソフトウェアエンジニアが事業を理解して判断し行動すること が直接的に事業価値を生み出す ➢ソフトウェアエンジニアが事業を理解せずに判断し行動するこ とが直接的に事業の損失になる 59
【エッセンシャル版】 ガイドブック 60
エンジニアの学習と成長 最初は、誰もが初学者 • 最初は、わけがわからないことだらけ • どんなに学んでも、やっぱりわからない だから学び続ける • 基本をたいせつに •
視野の広さ、視点の多さをたいせつに 異なる知見を持ち寄って、協働して共創する 61