フロー指向アーキテクチャ ドメイン駆動設計、Wardley Mapping、チームトポロジーによる適応型システム

詳細目次

シリーズエディターによるまえがき
まえがき
序文
目次

第I部　概念と基礎

第1章　Wardley Mappingによるビジネス戦略
1.1　戦略サイクル
1.2　目的：ビジネスの「なぜ」
1.3　状況の可視化：Wardley Map
Column　Wardley Mapのスコープを定義する
ユーザーとユーザーニーズの特定
コンポーネントの特定と依存関係や位置の決定
進化段階の決定
不安定な要素と関連するリスクの特定
1.4　効率性のギャップの評価
1.5　状勢の理解
すべては需要と供給の競争で進化する
特徴は変化する
効率がイノベーションを可能にする
上位システムが新しい価値の源泉を生み出す
競合企業の動向がゲームを変える
過去の成功が慣性を生み、慣性が組織を滅ぼす
進化の局面を予測する
Column　サーバーレスとは何か
1.6　指針の適用
ユーザーを知る
ユーザーニーズを重視する
詳細を知る
前提を疑う
共通言語を使う
状況認識を重視する
進化段階ごとに適切な手法を使う
小さく考える（契約のように）
小さなチームで考える
目的・熟達・自律を提供する
適性と態度を考える
文化はひとつではない
フローを最適化する
絶え間ない進化を前提に設計する
1.7　戦略的行動の決定（指揮とゲームプレイ）
1.8　まとめ

第2章　戦略的ドメイン駆動設計とWardley Mappingによる問題空間の探索
2.1　コラボレーションしながらドメイン知識を獲得する
2.2　DDDのパターンとプラクティス
2.3　サブドメインの発見と進化段階のマッピング
コアドメイン
補助サブドメイン
汎用サブドメイン
2.4　サブドメインの型と進化段階で開発か調達かを決定する
Column　内製とカスタムビルド
2.5　まとめ

第3章　戦略的ドメイン駆動設計による解決空間の設計
3.1　ドメインモデルと境界付き文脈
ドメインモデル
ユビキタス言語
境界の型
3.2　ドメインモデルと境界付き文脈の設計
3.3　モデリング手法の概要
EventStorming
ドメインストーリーテリング
実例マッピング（Example Mapping）
ユーザーストーリーマッピング
3.4　境界付き文脈とアーキテクチャスタイル
モノリスか分散か
データの配置
通信方式の選択
Column　ADRとは
3.5　境界付き文脈と進化段階
3.6　戦略的設計とWardley Mappingの指針
3.7　高凝集と疎結合
境界付き文脈内は高凝集
境界付き文脈間は疎結合
3.8　文脈マップの概要
別々の道（Separate Ways：SW）
公開言語（Published Language：PL）
汚染防止層（Anticorruption Layer：ACL）
順応者（Conformist：CF）
公開ホストサービス（Open-Host Service：OHS）
顧客／供給者（Customer-Supplier：CUS-SUP）
共有カーネル（Shared Kernel：SK）
パートナーシップ（Partnership：PS）
大きな泥だんご（Big Ball of Mud：BBoM）
文脈マップを組み合わせた例
3.9　文脈マップで暗黙的な依存関係を明らかにする
3.10　コアドメインと連携するときの変更結合度の評価
3.11　カンファレンス運営システムの文脈マップ
3.12　通信方式と文脈マップ
3.13　まとめ

第4章　戦術的ドメイン駆動設計によるドメインモデルの実装
4.1　ドメイン駆動モデルの構成要素
4.2　ポート＆アダプターアーキテクチャと戦術的設計
アプリケーションサービス
集約
4.3　まとめ

第5章　チームトポロジーによる変更フローの最適化
5.1　コンウェイの法則で明らかにするシステムの影響
5.2　職能型サイロチームの課題
5.3　チームの視点から見たフロー最適化の要件
5.4　ソフトウェアデリバリーのパフォーマンスへの影響
5.5　チームの認知負荷と精神的作業負荷
5.6　チームトポロジーの基本
5.7　チームのインタラクションモード
5.8　チームタイプ間の典型的なインタラクション
5.9　Wardley Mappingの指針を適用したチームトポロジー
5.10　まとめ

第II部　フロー指向アーキテクチャ

第6章　点と点をつなげる
6.1　適切な変更のストリームを特定する
6.2　変更フローを評価する
6.3　依存関係を分析する
6.4　制約を管理する
Column　バリューストリームマッピング
6.5　チームの所有権の境界を見つける
6.6　小さなチームを対象にする
6.7　チームの認知負荷を最適化する
Column　クネビンフレームワーク
6.8　適応型チームのマインドセットの組み合わせを考える
Column　3X（Explore-Expand-Extract）
6.9　変更フローをサポートするサービスを特定する
6.10　考えられるチーム編成
6.11　能力のギャップを特定する
6.12　まとめ

第7章　Wardley Mapによるチームの視点の可視化
7.1　PFチームから見たWardley Map
プラットフォームのバリューチェーン
インフラのプラットフォームのバリューチェーンとウォードリーの進化段階
マイクロサービスのインフラと運用の複雑さをマッピング
7.2　ENチームから見たバリューチェーン
7.3　まとめ

第8章　フロー指向アーキテクチャ・キャンバス
8.1　現在の状況を評価する
現在のチームの状況と働き方の説明
現在の変更フローの評価
現在のビジネス環境の可視化
問題空間の分類
8.2　思い描く状況（to-be）を設計する
解決空間のモジュール化
将来の状況の可視化
将来のチーム編成の検討
8.3　まとめ

第III部　フローに合わせたレガシーシステムの進化

第9章　フローに合わせたレガシーシステムの設計
9.1　レガシーシステムの現状評価の例
9.2　目的：ビジネスの「なぜ」
9.3　現在のチームを調査する
9.4　現在の変更フローを評価する
Column　職能型サイロに対するチームトポロジーのチームタイプとインタラクションモード
9.5　Wardley Mapで現在のビジネス環境を可視化する
問題領域を表すユーザーとユーザーニーズを特定する
現在のバリューチェーンをマッピングする
9.6　適切な変更のストリームを特定する
9.7　問題領域を分類してコアドメインを発見する
9.8　解決空間のモジュール化：境界付き文脈を設計する
オンラインスクールの境界付き文脈とドメインモデル
全体像のEventStormingでドメインを探索する
イベントを分類する
プロセスモデリングのEventStormingでズームイン
ソフトウェア設計のEventStormingを掘り下げる
9.9　文脈マップを設計する
9.10　将来のビジネス環境を可視化する
境界付き文脈を進化段階にマッピングする
効率性のギャップを評価する
9.11　適切なチームの所有権の境界を発見する
9.12　チームの認知負荷を最適化する
9.13　変更フローをサポートするサービスを特定する
9.14　今後のチーム構成を考える
9.15　能力のギャップを特定する
9.16　まとめ

第10章　フロー最適化の実装
10.1　活動の「なぜ」を共有する
10.2　システムに合わせたチームの編成とインタラクションの進化
10.3　ダイナミックリチーミングで移行する
10.4　探索PFチームを編成する
Column　ソフトウェアチーミング
10.5　クラウド移行戦略で効率性のギャップを埋める
10.6　クラウド移行をリプラットフォーミングから始める
データベースを移行する
検索エンジンを移行する
メッセージブローカーを移行する
SMTPサーバーを移行する
アプリケーションを移行する
10.7　残りのインフラチームのメンバーをPFチームにマージする
10.8　最初のSAチームを作る：リファクタリングを開始する
10.9　大きな泥だんごを段階的なリファクタリングで分割する
Column　ストラングラーフィグパターン
10.10　チームトポロジーのインタラクションモードの進化
10.11　UIの処理
10.12　次の境界付き文脈をリファクタリングする
10.13　マージしたPFチームを複数のチームに分割する
10.14　戦術的設計とサーバーレス技術で境界付き文脈を実装する
Column　トランザクショナルアウトボックスパターン
10.15　まとめ

第11章　継続的改善の促進と将来の変化の推進
11.1　手放したものと取り入れたもの
11.2　チームをスイッチする機会を与える
11.3　組織文化と安全思考
11.4　学習する組織
自己マスタリー
メンタル・モデル
共有ビジョン
チーム学習
システム思考
Column　コミュニティ・オブ・プラクティス
11.5　次に進むべきところ
11.6　まとめ

第12章　結論

参考文献

訳者あとがき

索引