偶有的複雑性と戦うためのアーキテクチャとチームトポロジー

アーキテクチャConference2024

Transcript

1. © 2024 Loglass Inc. 1 © 2024 Loglass Inc. アーキテクチャConference 2024 偶有的複雑性と戦うための アーキテクチャとチームトポロジー 株式会社ログラス 鈴木 健一
2. © 2024 Loglass Inc. 2 自己紹介 NTTデータで大規模ミッションクリティカルシステムや基幹システムのアーキテク チャ設計、開発統括業務に従事した後、より堅牢な開発を求めてプログラム言語 理論（型システム、関数型等）の研究に踏み込む。 その後、よりセキュアな世界を目指して、Visional（BizReach）にてサイバーセ キュリティ事業の立ち上げや開発、プロダクトマネジメントをリード。ContractS にて開発部長、プロダクト部長、技術戦略室長、VP of Developmentを経て、 2023年に株式会社ログラスにジョイン。 株式会社ログラス 開発本部 Enabling&Platform部 部長 鈴木 健一 Kenichi Suzuki（knih） X: @_knih
3. © 2024 Loglass Inc. 3
4. © 2024 Loglass Inc. 4 Loglassについて
5. © 2024 Loglass Inc. 5 Loglassについて
6. © 2024 Loglass Inc. 6 00｜目次 01 本質的複雑性と偶有的複雑性 02 ログラスの開発 03 チームトポロジー 04 パフォーマンス問題、アーキテクチャとチームトポロジー 05 マルチプロダクト開発とアーキテクチャトポロジー 本日のお品書き
7. © 2024 Loglass Inc. 7 01 本質的複雑性と偶有的複雑性
8. © 2024 Loglass Inc. 8 No Silver Bullet ー　essence and accidents of software engineering Brooks, Fred P. (1986). “No Silver Bullet — Essence and Accident in Software Engineering”. Proceedings of the IFIP Tenth World Computing Conference: 1069–1076.
9. © 2024 Loglass Inc. 9 01 | 本質的複雑性と偶有的複雑性 Frederick P. Brooks, JR. 著, 滝沢徹, 牧野祐子, 富澤昇 訳. 『人月の神話』. 丸善出版 （2014）
10. © 2024 Loglass Inc. 10 01 | 本質的複雑性と偶有的複雑性 銀の弾丸はない ー ソフトウェアエンジニアリングの本質と偶有的事項 すべてのソフトウェア構築には、 本質的作業として抽象的なソフトウェア 実体エンティティを構成する複雑な概念構造体を作り上げること、 およ び、 偶有的作業としてそうした抽象的実在をプログラミング言語で表現 し、 それをメモリスペースとスピードの制約内で機械言語に写像するこ とが含まれている。 Frederick P. Brooks, JR. 著, 滝沢徹, 牧野祐子, 富澤昇 訳. 『人月の神話』, 第16章. 丸善出版 （2014） “
11. © 2024 Loglass Inc. 11 01 | 本質的複雑性と偶有的複雑性 本質的複雑性（essential complexity） 銀の弾を打ち込みたい 狼男のこと • 解こうとしている問題そのものが持つ複雑さのこと ◦ 問題そのものに内在し、避けることができない複雑さ ◦ どう向き合うかが重要
12. © 2024 Loglass Inc. 12 • その他すべての複雑さ • 副作用として解決せざるを得ない問題 • 偶発的に発生する複雑さというよりも、本質的問題に付随する複雑性 ◦ No Silver Bulletの続編で著者が言及 ◦ 「付随的な複雑さ」とも訳される • 例） 実装過程にまつわる複雑さ、データの永続化、セキュリティ 01 | 本質的複雑性と偶有的複雑性 偶有的複雑性（accidential complexity）
13. © 2024 Loglass Inc. 13 本質的複雑性 (Essential) 偶有的複雑性 (Accidental) 原因 問題そのものの性質 解決方法や設計、実装の選択に起因 作業 頭の中で概念構造体をつくる 実装過程 避けられるか 避けられない 適切な選択やリファクタリングである 程度回避可能 例 ビジネスロジック、ドメインの ルール 技術的負債、不適切なツール選択 01 | 本質的複雑性と偶有的複雑性 本質的複雑性と偶有的複雑性 “私が本質と言っているソフトウェア構築の部分は頭の 中で概念構造体を作ることであり、 偶有的事項と言って いる部分はインプリメンテーション過程のことなのだ。 ー「人月の神話」第17章より
14. © 2024 Loglass Inc. 14 偶有的複雑性を最小化することを目指す 本質的な複雑さと偶有的な複雑さを分離する
15. © 2024 Loglass Inc. 15 02 チームトポロジー
16. © 2024 Loglass Inc. 16 02 | チームトポロジー マシュー・スケルトン、マニュエル・パイス 著, 原田騎郎, 永瀬美穂, 吉羽 龍太郎 訳. 『チームトポロジー: 迅速な価値提供を可能にする組織 設計』. 日本能率協会マネジメントセンター（2019）
17. © 2024 Loglass Inc. 17 02 | チームトポロジー チームトポロジーとは 価値の迅速なフローを実現するために、チーム同士の組織設計を行うアプローチ であり、開発組織を効果的に設計・運営するためのチーム構造と連携のフレーム ワーク
18. © 2024 Loglass Inc. 18 02 | チームトポロジー 開発者の認知負荷の変遷 Luca Galante, Matt Campbell (2023). “Platform Engineering 101: What You Need to Know about This Hot New Trend”. https://www.infoq.com/articles/platform-engineering-primer/. accessed at Nov, 2024. ダイナミック・ リチーミング チームトポロジー
19. © 2024 Loglass Inc. 19 02 | チームトポロジー 『チームトポロジー: 迅速な価値提供を可能にする組織設計』. 9章より 中心となるアイデア
20. © 2024 Loglass Inc. 20 02 | チームトポロジー コンプリケイテッド・サブシ ステムチーム プラットフォームチーム ストリームアイランドチーム イネイブ リング チーム ファシリ テーション X -as-a-Servce X -as-a-Servce チームトポロジーの例 ストリームアライン ドチームを中心に 構成される
21. © 2024 Loglass Inc. 21 02 | チームトポロジー ストリームアラインドチーム ストリームに沿って働くチーム ストリームとは、ビジネスドメインや組織の能力に沿った仕事の継続 的な流れ（サービス、機能、ユーザージャーニー等） ビジネス目標に直結した価値デリバリーの安定したフローを生み出す ことを目指す コンプリケイテッド・サブシス テムチーム 認知負荷を下げるため、ストリームアラインドチームが直接扱うには 複雑すぎる領域を担当 判断基準は、チームの認知負荷 イネーブリングチーム 複数のストリームアラインドチームを横断的に支援し、ケイパビリティ 獲得を助ける ストリームアラインドチームの不適切なプラクティスや、品質の低い コード等に起因する問題を解決するために存在するのではない プラットフォームチーム 開発チームが簡単かつ効率的に製品やサービスをデプロイできるよ うに、自己サービスプラットフォームを提供する 開発者体験を向上させ、生産性を最大化する 4つのチームタイプ
22. © 2024 Loglass Inc. 22 02 | チームトポロジー コラボレーション 他のチームと密接に協力して作業する X-as-a-service 最小限のコラボレーションで何かを利用または提供する ファシリテーション 障害を取り除くために他のチームを支援したり、支援を受けたりする 3つのインタラクションモード
23. © 2024 Loglass Inc. 23 02 | チームトポロジー チームファースト思考 • チームを起点にした考え方、チームが機能することを優先する • システムやコードの複雑さは、チームが機能していればその複雑さをうまく 扱える • チームサイズのアーキテクチャ
24. © 2024 Loglass Inc. 24 03 ログラスの開発
25. © 2024 Loglass Inc. 25 03 | ログラスの開発 以前の開発体制 これまでのログラスの開発 TL Engineers Designer PdM TL Engineers Designer PdM TL Engineers Designer PdM QA QA QA Enabling &Platform TL Engineers TL Engineers アプリケーション基盤 クラウド基盤
26. © 2024 Loglass Inc. 26 さらなるスケールのために スクラム体制からFASTに移行
27. © 2024 Loglass Inc. 27 FAST・・・？
28. © 2024 Loglass Inc. 28 03 | ログラスの開発 Rich Picture by Per Beining FAST, https://www.fastagile.io/. © Cron Technologies LLC © Cron Technologies LLC Fluid Adaptive Scaling Technology 流動的で適応可能な スケールの技術
29. © 2024 Loglass Inc. 29 03 | ログラスの開発 One-time Setup コレクティブの形成 BigPictureの定義 自律的で、十分な権限を 持ち、自己組織化してい て、自己管理できる人た ちの集まり 活動の可視化 コレクティブの目的とミッション を決める 日々の作業が大きな目標にどう 貢献しているかが理解しやすくな る 活動に対する現在の理解と進捗を コレクティブに示すため、目に見え る形で表現する
30. © 2024 Loglass Inc. 30 03 | ログラスの開発 Value Cycle 自己組織化する 活動する 同期する ミーティングをファシリテート し、自己組織化して活動するた めのチームを形成できるように する 各チームは、自身が集った活 動アイテムのために計画し、 協働する 短い周期でコレクティブはミー ティングを開催し、学びを共有 し進捗して、プロダクトの状態 と現在の状況について共通の 理解を得る
31. © 2024 Loglass Inc. 31 つまり 自己組織化された自律性を重視するアジャイル ルールが非常に少ない
32. © 2024 Loglass Inc. 32 FASTを支える Enabling&Platform
33. © 2024 Loglass Inc. 33 03 | ログラスの開発 プラットフォーム領域 ガバナンス領域 コンプライアンス・プライバシー ポリシー 相互運用ポリシー （データ標準化） ドキュメントポリシー ベストプラクティス 実装例 チームへの提案 イネーブリング 領域 セキュリティポリシー ストレージ・ クエリエンジン データカタログ データ契約管理 ポリシー自動化 モニタリング・ 分析ツール 分析 データ 契約 運用 データ データプロダクト ドメインA ドメインB ドメインC ドメインD ドメインE Jochen Christ, ,Larysa Visengeriyeva, Simon Harrer, et al. DATA MESH ARCHITECTURE https://www.datamesh-architecture.com/ を参考に作成 Enabling&Platform領域
34. © 2024 Loglass Inc. 34 03 | ログラスの開発 自己組織化による課題 • フィーチャー開発をしながら、生産性を落とさず、認知負荷をあげずに、根 が深い問題への対処していくことが困難 • FASTの中に入らないとサポートが難しい
35. © 2024 Loglass Inc. 35 04 パフォーマンス問題 アーキテクチャとチームトポロジー
36. © 2024 Loglass Inc. 36 04 | パフォーマンス問題、アーキテクチャとチームトポロジー
37. © 2024 Loglass Inc. 37 データが急増
38. © 2024 Loglass Inc. 38 その結果... クエリ負荷が増大！
39. © 2024 Loglass Inc. 39 04 | パフォーマンス問題、アーキテクチャとチームトポロジー CPUが高負荷状態に 長時間クエリでロックが発 生しやすい状態に 高負荷状態に
40. © 2024 Loglass Inc. 40 結合が多い…！ 問題のあるクエリ
41. © 2024 Loglass Inc. 41 04 | パフォーマンス問題、アーキテクチャとチームトポロジー 結合の計算コスト Nested Loop Join O(N × M) Sort Merge Join O(N log N) + O(M log M) + O(N + M) Hash Join O(N) + O(M) b-treeインデックスが効く場合は、 O(log n)
42. © 2024 Loglass Inc. 42 04 | パフォーマンス問題、アーキテクチャとチームトポロジー 計算コストのモデル化
43. © 2024 Loglass Inc. 43 04 | パフォーマンス問題、アーキテクチャとチームトポロジー コスト試算
44. © 2024 Loglass Inc. 44 04 | パフォーマンス問題、アーキテクチャとチームトポロジー コスト試算 https://en.wikipedia.org/wiki/Japanese_numerals
45. © 2024 Loglass Inc. 45 04 | パフォーマンス問題、アーキテクチャとチームトポロジー 計算量の増加イメージ https://www.bigocheatsheet.com/
46. © 2024 Loglass Inc. 46 04 | パフォーマンス問題、アーキテクチャとチームトポロジー PostgreSQLの仕組み Parser Analyzer Rewriter Planner Executor SQL Result Set ここで実⾏計画が作られる stats data
47. © 2024 Loglass Inc. 47 04 | パフォーマンス問題、アーキテクチャとチームトポロジー PostgreSQLのクエリ最適化アルゴリズム 最低コストパス 式書き換え（前処理） リレーション情報抽出 動的計画法 ベース 遺伝アルゴリズム ベース（GEQO） クエリ実行 少ない 多い ざっくり探索 パス探索 パス探索と枝刈りは同時に行われるため、PlannerとOptimizerの区別はない 結合 パス
48. © 2024 Loglass Inc. 48 計算コストが変動的で複雑
49. © 2024 Loglass Inc. 49 04 | パフォーマンス問題、アーキテクチャとチームトポロジー ソフトウェア構造体における概念上の複雑性の大半は、 アプリケーションそのものの自由さがもたらす複雑性か らきている “ Frederick P. Brooks, JR. 著, 滝沢徹, 牧野祐子, 富澤昇 訳. 『人月の神話』, 第17章. 丸善出版 （2014）
50. © 2024 Loglass Inc. 50 04 | パフォーマンス問題、アーキテクチャとチームトポロジー パフォーマンス問題とプロダクト開発 パフォーマンス問題はあれど、価値デリバリーのペースを落としたくない どうにか問題を分離できないか・・・？
51. © 2024 Loglass Inc. 51 04 | パフォーマンス問題、アーキテクチャとチームトポロジー オニオンアーキテクチャ Presentation層 Infrastructure層 UseCase層 Domain層 Repository（実装クラス） ・Entityの永続化/検索 Repository (Interface) ・Repositoryの仕様定義 Entity, Value Object, Domain Service ・ドメイン知識（ルール/制約） の表現 Controller ・エンドポイント定義 ・HttpRequestで渡された値とUseCase層に 渡す値のマッピング ・入力値のValidation UseCase ・ユースケースの実現 ・Entity, Value Objectの 生成、使用、永続化依頼 ・EntityからPresentation層に渡す値への変換
52. © 2024 Loglass Inc. 52 04 | パフォーマンス問題、アーキテクチャとチームトポロジー オニオンアーキテクチャ Presentation層 Infrastructure層 Application層 Domain層 UI Application Domain Infrastructure 依存性が反転 している
53. © 2024 Loglass Inc. 53 04 | パフォーマンス問題、アーキテクチャとチームトポロジー オニオンアーキテクチャ Presentation層 Infrastructure層 Application層 Domain層 UI Application Domain Infrastructure コア ノンコア パフォーマンス問題がある箇所（クエリ）をノン コアとして切り出し
54. © 2024 Loglass Inc. 54 04 | パフォーマンス問題、アーキテクチャとチームトポロジー ストリームアラインド トポロジーの変遷 イネーブリング ストリームアラインド コンプリケイテッド ・サブシステム ストリームアラインド ストリームアラインド コンプリケイテッド・ サブシステム ストリームアラインド コンプリケイテッド・ サブシステム 初期フェーズ 問題切離し フェーズ 研究開発 フェーズ 解決 フェーズ 再統合フェーズ コラボレーション コラボレーション
55. © 2024 Loglass Inc. 55 04 | パフォーマンス問題、アーキテクチャとチームトポロジー トポロジー進化の decompose - reintegrateパターン • 初期フェーズ • 問題切り出しフェーズ • 研究開発フェーズ • 解決フェーズ • 再統合フェーズ と名付けてみました
56. © 2024 Loglass Inc. 56 04 | パフォーマンス問題、アーキテクチャとチームトポロジー トポロジー進化の decompose - reintegrateパターン ストリームアラインド イネーブリング 初期フェーズ コラボレーション ストリームアラインドチームをサポートする形 でパフォーマンス問題を調べ始める
57. © 2024 Loglass Inc. 57 04 | パフォーマンス問題、アーキテクチャとチームトポロジー トポロジー進化の decompose - reintegrateパターン 短期で解決できないため、パフォーマンス問 題に対応する班と、機能開発を進める班で分 かれる 軽量に試せる打ち手を次々に実行していく ストリームアラインド コンプリケイテッド ・サブシステム 問題切離し フェーズ コラボレーション
58. © 2024 Loglass Inc. 58 04 | パフォーマンス問題、アーキテクチャとチームトポロジー トポロジー進化の decompose - reintegrateパターン 短期で解決できないため、パフォーマンス問 題に対応する班と、機能開発を進める班で分 かれる 調査結果や技術検証結果を X-as-a-serviceとして提供 ストリームアラインド コンプリケイテッド・ サブシステム 研究開発 フェーズ
59. © 2024 Loglass Inc. 59 04 | パフォーマンス問題、アーキテクチャとチームトポロジー トポロジー進化の decompose - reintegrateパターン 検証済みの解決策が見つかり、プロダクト本体 に実装していくフェーズ オニオンアーキテクチャにより、影響範囲は限定 的だが、ナレッジトランスファーのためにスト リームアラインドチームと協働する ストリームアラインド コンプリケイテッド・ サブシステム 解決 フェーズ
60. © 2024 Loglass Inc. 60 04 | パフォーマンス問題、アーキテクチャとチームトポロジー トポロジー進化の decompose - reintegrateパターン 新規に取り入れた技術やモジュールの認知負荷 が最小化され、FASTの中でメンテナンス・エン ハンスできる状態 ストリームアラインド 再統合フェーズ
61. © 2024 Loglass Inc. 61 04 | パフォーマンス問題、アーキテクチャとチームトポロジー パターンの使いどころ • 既に問題が顕在化しており、解決に時間が掛かる • けれどもフィーチャー開発を止めたくない
62. © 2024 Loglass Inc. 62 04 | パフォーマンス問題、アーキテクチャとチームトポロジー FASTの恩恵 • 自己組織化を重視するため、ストリームアラインドチーム以外の周辺チーム とのトポロジーも進化・適応しやすい
63. © 2024 Loglass Inc. 63 切り出した問題 その複雑性はどこから来たか
64. © 2024 Loglass Inc. 64 切り出した問題 その複雑性はどこから来たか
65. © 2024 Loglass Inc. 65 偶有的複雑性は 本質的複雑性に「付随」する
66. © 2024 Loglass Inc. 66 04 | パフォーマンス問題、アーキテクチャとチームトポロジー 付随する複雑性 本質的 偶有的
67. © 2024 Loglass Inc. 67 04 | パフォーマンス問題、アーキテクチャとチームトポロジー 付随する複雑性 本質的 偶有的 本質的 偶有的 偶有的複雑性にのみア プローチした場合
68. © 2024 Loglass Inc. 68 04 | パフォーマンス問題、アーキテクチャとチームトポロジー 付随する複雑性 本質的 偶有的 本質的 偶有的 本質的複雑性に アプローチした場合 付随する複雑性も 小さくなる
69. © 2024 Loglass Inc. 69 04 | パフォーマンス問題、アーキテクチャとチームトポロジー 複雑さをあぶり出し、適切なサイズに制御 分析モデル 問題 設計モデル ソリューション 抽象 具象 問題空間 解決空間 複雑さをあぶり出 せているか （非機能設計等） 非機能を無視して リリースしていな いか 偶有的複雑性が 現出する領域
70. © 2024 Loglass Inc. 70 04 | パフォーマンス問題、アーキテクチャとチームトポロジー 複雑さをあぶり出し、適切なサイズに制御 分析モデル 問題 設計モデル ソリューション 抽象 具象 問題空間 解決空間 複雑さをあぶり出 せているか （非機能設計等） 偶有的複雑性が 現出する領域 本質的 非機能を無視して リリースしていな いか
71. © 2024 Loglass Inc. 71 04 | パフォーマンス問題、アーキテクチャとチームトポロジー 複雑さをあぶり出し、適切なサイズに制御 分析モデル 問題 設計モデル ソリューション 抽象 具象 問題空間 解決空間 複雑さをあぶり出 せているか （非機能設計等） 偶有的複雑性が 現出する領域 本質的 本質的 非機能を無視して リリースしていな いか 適切な問題空間 に狭める
72. © 2024 Loglass Inc. 72 04 | パフォーマンス問題、アーキテクチャとチームトポロジー 複雑さをあぶり出し、適切なサイズに制御 分析モデル 問題 設計モデル ソリューション 抽象 具象 問題空間 解決空間 複雑さをあぶり出 せているか （非機能設計等） 偶有的複雑性が 現出する領域 本質的 本質的 本質的 非機能を無視して リリースしていな いか 適切な問題空間 に狭める
73. © 2024 Loglass Inc. 73 04 | パフォーマンス問題、アーキテクチャとチームトポロジー 複雑さをあぶり出し、適切なサイズに制御 分析モデル 問題 設計モデル ソリューション 抽象 具象 問題空間 解決空間 複雑さをあぶり出 せているか （非機能設計等） 偶有的複雑性が 現出する領域 本質的 本質的 本質的 本質的 非機能を無視して リリースしていな いか 適切な問題空間 に狭める
74. © 2024 Loglass Inc. 74 04 | パフォーマンス問題、アーキテクチャとチームトポロジー 複雑さとアーキテクチャとトポロジーと 本質的 偶有的 UI Application Domain Infrastructure ストリームアラインド コンプリケイテッド・ サブシステム 依存の分離 コンウェイの法則／ チームファーストアーキテクチャ 自己組織化／ トポロジー進化
75. © 2024 Loglass Inc. 75 05 マルチプロダクト開発と アーキテクチャトポロジー
76. © 2024 Loglass Inc. 76 05 | 今後の課題 - マルチプロダクト開発とアーキテクチャトポロジー マルチプロダクト化を目指すログラス
77. © 2024 Loglass Inc. 77 05 | 今後の課題 - マルチプロダクト開発とアーキテクチャトポロジー アプリケーションやドメインを跨ぐ アーキテクチャ意思決定をどうす るか R. Malan and D. Bredemeyer, "Less is more with minimalist architecture," in IT Professional, vol. 4, no. 5, pp. 48-47, Sept.-Oct. 2002, doi: 10.1109/MITP.2002.1041178.
78. © 2024 Loglass Inc. 78 05 | 今後の課題 - マルチプロダクト開発とアーキテクチャトポロジー マルチプロダクトの先にあるもの マルチプロダクトでは、プロダクトごとのアーキテクチャを整合させる必要性がで てくる。その際のチームインタラクションならぬアーキテクチャ・インタラクション をどうすべきか
79. © 2024 Loglass Inc. 79 05 | 今後の課題 - マルチプロダクト開発とアーキテクチャトポロジー アーキテクチャのためのトポロジー プロダクトA プロダクトB プロダクトC アーキテクチャ 支援チーム アーキテクチャ 支援チーム アーキテクチャ 支援チーム コラボレーション ファシリテーション コラボレーション ファシリテーション Eduardo da Silva (2021). “Architecture Topologies”. https://esilva.net/architecture-topologies を参考に作成
80. © 2024 Loglass Inc. 80 まとめ
81. © 2024 Loglass Inc. 81 ソフトウェアにもたらした自由は、 その自由に付随する複雑さに対して 価値があるか
82. © 2024 Loglass Inc. 82 偶有的複雑性と戦うためのアーキテクチャとチームトポロジー まとめ • 本質的な複雑さと偶有的な複雑さは極力切り離す • 自己組織化型アジャイルでは組織がダイナミックに変化するため、根深い課 題は切り出してx-as-a-serviceとして連携するのが１つの解決策 ◦ チームファーストの精神 ◦ まずはアナログでも認知負荷を低減することを優先 • 切り出した課題は認知負荷を減らして、再びFASTに融合させる ◦ Complicated-subsystem領域はスケーリングさせづらい ◦ 組織と課題が成熟してcomplicated-subsystemを抱えられる状態なら、チームとして 分離するのもアリ
83. © 2024 Loglass Inc. 83