_Architecture_Modernization_から学ぶ現状理解から設計への道のり.pdf

アーキテクチャモダナイゼーション - 技術と組織にどう向き合うか
https://findy.connpass.com/event/385693/
にて話させていただいた資料になります

Transcript

1. 『Architecture Modernization』から学ぶ 現状理解から設計への道のり アーキテクチャモダナイゼーション - 技術と組織にどう向き合うか 株式会社スリーシェイク Sreake事業部 佐藤慧太 Copyright © 3-shake, Inc. All Rights Reserved. 1
2. 自己紹介 佐藤 慧太@SatohJohn • 2023/1 株式会社スリーシェイク入社 • Google Cloud Partner Top Engineer ’24、’25、’26 選出 • お客様の労苦 <Toil>を減らす • 娘のお世話を精一杯やっています • 本書籍の一部翻訳を担当
3. Copyright © 3-shake, Inc. All Rights Reserved. 会社名 株式会社スリーシェイク（3-shake, Inc.） 設立 2015 年 1 月 代表者 代表取締役社長　吉田 拓真 所在地 東京都中央区銀座8-21-1 住友不動産汐留浜離宮ビル7F 社員数 176名（2026年2月時点） 提供開始 2018/8 シリーズB 総額 8.48億 円 総額 5億円 調達・資本業務提携 総額 10億円 提供開始 提供開始 提供開始 2018/10 2020/12 2021/12 シリーズA 総額5億円 2021/1 2022/5 2024/11 沿革 Googleクラウド・AWSの両方のエンジニアリングに強みを持つ Kubernetes Certified Service Provider(KCSP)を取得 資格関連 会社概要
4. モダナイゼーション、どこから手をつけますか？ 4 よくある失敗 いきなり マイクロサービス化 いきなり リファクタリング 技術を変えれば 解決するという 思い込み 本書のアプローチ: 現状を理解してから設計する
5. Architecture Modernization（Nick Tune 著） • DDD、チームトポロジー、 ウォードリーマッピングなどの定評ある手法 • 技術・組織・戦略の3つの視点から システム刷新を解説 • 詳細な技術書というより概念や考え方などを 通して広く学べる • 株式会社スリーシェイク 5名にて翻訳 5 https://www.shoeisha.co.jp/book/detail/9784798195063
6. 書籍の全体像 - 全17章の構成 6 章 タイトル 内容 1 アーキテクチャモダナイゼーションとは モダナイゼーションの核心概念とバリューストリーム 2 モダナイゼーションという旅に向けた準備 開始前の重要トピックとよくある課題 3 ビジネス目標 モダナイゼーションとビジネス目標の接続 4 ヒアリングとマッピングのツアー ステークホルダーから現状を聞き出す 5 ウォードリーマッピング バリューチェーンと進化段階の戦略的可視化 6 プロダクト分類体系 プロダクト中心のアーキテクチャ設計 7 ビッグピクチャーイベントストーミング 協働ワークショップでドメイン全体を俯瞰 8 プロダクトとドメインのモダナイゼーション 全面書き換えを避け反復的にドメインを刷新
7. 書籍の全体像 - 全17章の構成 7 章 タイトル 内容 9 ドメインとサブドメインの識別 ビジネスをドメインに整理し境界を設計 10 戦略的ITポートフォリオ 価値と複雑さでアーキテクチャを投資判断 11 チームトポロジー チーム構造の設計原則とパターン 12 疎結合なソフトウェアアーキテクチャ チーム構造と推進体制を整える 13 内部開発者プラットフォーム 進化を加速するプラットフォーム設計 14 データメッシュ データメッシュの原則と相互依存関係 15 AMET（イネーブリングチーム） モダナイゼーションを支援・推進する非中央集権チーム 16 戦略とロードマップ 説得力あるストーリーと進化的ロードマップ 17 学習とスキルアップ 組織の人材育成とアーキテクチャ能力の向上
8. ざっくり解説 8 本書の目的 高速フローのためのアーキテクチャと組織の設計 モダナイゼーションの理由 レガシーアーキテクチャはビジネスリスクであり競争上の不利 — 変更に時間がかかり、コストが増し、信頼性が下がる負のサイクルに陥る モダナイゼーションの価値判断軸 BVSSH (Better Value Sooner Safer Happier)
9. 9 全部説明する時間はないので 一番説明効果が高そうな（個人的主観） 「モダナイゼーションの現状理解から設計の流れ」についてフォーカス
10. ウォードリーマッピング（第5章） ビジネス環境を「地図」として視覚化する手法。 孫子の五要素とOODAループを基盤としており、戦略サイクルの景観のステップで作成される → 地図なしの意思決定は、直感や2x2マトリクスに頼る勘頼みの戦略になる → ビジネスと技術の多様なメンバーが同じ景観を見て議論でき、投資すべき場所・買うべきもの・ 革新が不足している領域が視覚的に浮かび上がる 10 戦略サイクル 要素 問い 内容 目的(Purpose) なぜ存在するのか 組織のミッション・存在意義を明確にする 景観(Landscape) 今どこにいるのか バリューチェーンで現状を地図として可視化する 気候(Climate) 何が変わりつつあるのか 競合・規制・技術革新など制御不能な外的要因を把握する 協議(Doctrine) どう組織を動かすのか 「共通言語を使う」「戦略は反復的」等の運営原則 リーダーシップ 何をするのか 景観と気候を踏まえた意図的な戦略行動
11. ビッグピクチャイベントストーミング（第7章） 11 部門・職種を超えた全員が一堂に会し、ビジネスプロセス全体を時系列で可視化する 協働ワークショップ手法 コードやドキュメントからは見えない暗黙知を引き出す → ドメイン境界が自然に浮かび上がる。ビジネスとエンジニアが同じ言葉と全体像を共有できる → 「正確なモデル」ではなく学びとコラボレーションの最大化が目的 1. オレンジ色の付箋にドメインイベント（ビジネスで起きた事実）を過去形で書く 2. 参加者全員が一斉に書き出して壁に貼る（混沌とした探索） 3. 時系列に並べ、整理し、全員でウォークスルーする 4. ホットスポット（問題）を赤い付箋、機会を緑の付箋で追加 やり方
12. 言葉が設計を決める – 「アクティベート」問題 12 事例 北米の スマートシティ / IoTデバイス業界 品質エンジニアとソリューションアーキテクトが「アクティベート」の意味をめぐり約30分議論 設置前に倉庫で アクティベートすべき （不具合検出のため） 設置後にアクティベート すべき （設定は場所に依存する） 同じ言葉が異なるステップを指していた
13. 言葉が設計を決める – 「指標計算」問題 13 事例 金融アドバイス企業で「この指標はどう計算している？」と質問 対象の指標について、エンジニアが説明したアルゴリズムと、マーケティング担当の認識が 不一致 誤った計算でレポートを出していた この指標は A から取得して 実装 この指標は B から使われてい ると認識して利用
14. 言葉が設計を決める 14 同じ言葉 異なる概念 過剰に複雑な ソフトウェア 共通の概念 シンプルな ソフトウェア 誤った意思決定 正しい意思決定 曖昧なドメインモデル 整理したドメインモデル
15. ドメインとサブドメインの識別（第9章） 15 よいドメイン境界がもたらす価値 ドメイン識別の原則 • 結合の低減 • 凝集性の向上 • チームの自律性 • イノベーション • 境界はゴールの変化に応じて変わる • すべての依存関係が同じコストではない • 進化に備える 5つのヒューリスティック 最適な境界を見つけるための「考え方の道具」 ヒューリスティック 内容 ビジネス 戦略的に重要なもの ドメイン 概念の自然な凝集 組織 チームの自律的性 技術 技術的制約内での実現 ユーザ体験 一貫したUXの実現
16. コアドメインチャート（第10章） 16 コアドメインチャート ビジネスの差別化 × モデルの複雑さ の2軸 象限 内容 コアドメイン (高差別化・高複雑) 最高の人材と最大の投資 支援ドメイン (高差別化・低複雑) 社内開発だが過剰投資しない 汎用ドメイン (低差別化・低複雑) 既製品・SaaSを活用 「すべてを同じ品質で作る必要はない」— 戦略的に投資する
17. 疎結合なソフトウェアアーキテクチャ（第12章） 17 結合の4タイプ 結合タイプ 何を知っているか 侵入的結合 実装の詳細を知っている 機能的結合 ビジネスルール・ドメインロジックを知っている モデル的結合 ドメインモデルの概念を知っている 契約的結合 明示的なインターフェースのみ知っている 痛みの公式 : 痛み = 強度 x 変動性 x 距離 変動性の高いところを優先的に疎結合にする — 一度に全部を分離する必要はない
18. gigsプラットフォーム（第12章） 18 事例 採用担当者を介さず、雇用主と求職者が短期の仕事をマッチングするシステム。 3年で「大きな泥だんご」化。 Ruby on Rails + Active RecordパターンでドメインモデルとDBが強結合 アプローチ 1. イベントストーミングセッションでドメインを再発見 2. バブルコンテキスト → 自律型バブル → ACL（腐敗防止層）で段階的移行 3. 新市場対応時、新しい境界づけられたコンテキストを既存コードから完全に分離 一度に全部を書き換えるのではなく、段階的に移行する
19. なぜ「現状理解」が先なのか 19 「アクティベート」問題、「指標計算」問題 現状理解を怠ると同じ言葉が異なる概念を指す → 設計が歪む、ビジネスに悪影響を及ぼす gigs 事例 「大きな泥だんご」化した後、EventStormingで 現状理解からやり直して成功
20. なぜ「現状理解」が先なのか 20 「アクティベート」問題、「指標計算」問題 現状理解を怠ると同じ言葉が異なる概念を指す → 設計が歪む、ビジネスに悪影響を及ぼす gigs 事例 「大きな泥だんご」化した後、EventStormingで 現状理解からやり直して成功 現状理解なき設計 手戻り・過剰な複雑さ 現状理解ありの設計 段階的・持続可能な変化
21. 設計プロセスの全体像 21 ステップ 手法 現状の地図を描く ウォードリーマッピング 業務フローを発見する イベントストーミング 境界を見極める ドメイン識別 投資判断をする コアドメインチャート 構造を描く 疎結合アーキテクチャ
22. まとめ Copyright © 3-shake, Inc. All Rights Reserved. 22
23. この本から持ち帰ってほしいこと 1. モダナイゼーションは「技術の入れ替え」ではなく「設計プロセス」 ◦ 現状理解 → 設計 → 実行 の順序を守る 2. 境界の設計がすべてを左右する ◦ ドメイン境界の良し悪しが、チームの自律性・開発速度・保守性を決定する 3. 協働的な発見プロセスが不可欠 ◦ ビジネスとエンジニアが同じ言葉を獲得する場をつくる 23
24. この本を読んで学んでほしいこと 24 エンジニアへ 設計は「コードを書く前」に始まっている ウォードリーマッピングやイベントストーミングで現状を可視化する力 境界の設計は技術判断であり、ビジネス判断でもある コアドメインチャートで投資判断を構造化する力 開発リーダー・テックリードへ 疎結合は「すべてを分離する」ことではない 痛みの公式（強度 x 変動性 x 距離）で優先順位をつける力 アーキテクトへ
25. 最後に 25 持続可能な変化は組織の内部から生まれなければならない — Joao Rosa (第15章) アーキテクチャモダナイゼーションについてご相談ございましたら 次のお問い合わせ先にご連絡ください お問い合わせ先： 株式会社スリーシェイク URL: 　https://sreake.com/contact/ Email: 　sreake-sales@3-shake.com ※お知り合いのスリーシェイク社員経由でも構いません
26. ありがとうございました Copyright © 3-shake, Inc. All Rights Reserved. 26