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

Slide 1

Slide 1 text

Slide 2

Slide 2 text

© 2024 Loglass Inc. 2 自己紹介 NTTデータで大規模ミッションクリティカルシステムや基幹システムのアーキテクチャ設計、開発統括業務に従事した後、より堅牢な開発を求めてプログラム言語理論（型システム、関数型等）の研究に踏み込む。その後、よりセキュアな世界を目指して、Visional（BizReach）にてサイバーセキュリティ事業の立ち上げや開発、プロダクトマネジメントをリード。ContractS にて開発部長、プロダクト部長、技術戦略室長、VP of Developmentを経て、 2023年に株式会社ログラスにジョイン。株式会社ログラス開発本部 Enabling&Platform部部長鈴木健一 Kenichi Suzuki（knih） X: @_knih

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

© 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.

Slide 9

Slide 9 text

Slide 10

Slide 10 text

© 2024 Loglass Inc. 10 01 | 本質的複雑性と偶有的複雑性銀の弾丸はないーソフトウェアエンジニアリングの本質と偶有的事項すべてのソフトウェア構築には、本質的作業として抽象的なソフトウェア実体エンティティを構成する複雑な概念構造体を作り上げること、および、偶有的作業としてそうした抽象的実在をプログラミング言語で表現し、それをメモリスペースとスピードの制約内で機械言語に写像することが含まれている。 Frederick P. Brooks, JR. 著, 滝沢徹, 牧野祐子, 富澤昇訳. 『人月の神話』, 第16章. 丸善出版（2014） “

Slide 11

Slide 11 text

Slide 12

Slide 12 text

© 2024 Loglass Inc. 12 ● その他すべての複雑さ ● 副作用として解決せざるを得ない問題 ● 偶発的に発生する複雑さというよりも、本質的問題に付随する複雑性 ○ No Silver Bulletの続編で著者が言及 ○ 「付随的な複雑さ」とも訳される ● 例）実装過程にまつわる複雑さ、データの永続化、セキュリティ 01 | 本質的複雑性と偶有的複雑性偶有的複雑性（accidential complexity）

Slide 13

Slide 13 text

© 2024 Loglass Inc. 13 本質的複雑性 (Essential) 偶有的複雑性 (Accidental) 原因問題そのものの性質解決方法や設計、実装の選択に起因作業頭の中で概念構造体をつくる実装過程避けられるか避けられない適切な選択やリファクタリングである程度回避可能例ビジネスロジック、ドメインのルール技術的負債、不適切なツール選択 01 | 本質的複雑性と偶有的複雑性本質的複雑性と偶有的複雑性 “私が本質と言っているソフトウェア構築の部分は頭の中で概念構造体を作ることであり、偶有的事項と言っている部分はインプリメンテーション過程のことなのだ。ー「人月の神話」第17章より

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

© 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. ダイナミック・リチーミングチームトポロジー

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

© 2024 Loglass Inc. 21 02 | チームトポロジーストリームアラインドチームストリームに沿って働くチームストリームとは、ビジネスドメインや組織の能力に沿った仕事の継続的な流れ（サービス、機能、ユーザージャーニー等）ビジネス目標に直結した価値デリバリーの安定したフローを生み出すことを目指すコンプリケイテッド・サブシステムチーム認知負荷を下げるため、ストリームアラインドチームが直接扱うには複雑すぎる領域を担当判断基準は、チームの認知負荷イネーブリングチーム複数のストリームアラインドチームを横断的に支援し、ケイパビリティ獲得を助けるストリームアラインドチームの不適切なプラクティスや、品質の低いコード等に起因する問題を解決するために存在するのではないプラットフォームチーム開発チームが簡単かつ効率的に製品やサービスをデプロイできるように、自己サービスプラットフォームを提供する開発者体験を向上させ、生産性を最大化する 4つのチームタイプ

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

© 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 アプリケーション基盤クラウド基盤

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

© 2024 Loglass Inc. 29 03 | ログラスの開発 One-time Setup コレクティブの形成 BigPictureの定義自律的で、十分な権限を持ち、自己組織化していて、自己管理できる人たちの集まり活動の可視化コレクティブの目的とミッションを決める日々の作業が大きな目標にどう貢献しているかが理解しやすくなる活動に対する現在の理解と進捗をコレクティブに示すため、目に見える形で表現する

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

© 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領域

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Slide 40

Slide 40 text

Slide 41

Slide 41 text

Slide 42

Slide 42 text

Slide 43

Slide 43 text

Slide 44

Slide 44 text

Slide 45

Slide 45 text

Slide 46

Slide 46 text

Slide 47

Slide 47 text

Slide 48

Slide 48 text

Slide 49

Slide 49 text

Slide 50

Slide 50 text

Slide 51

Slide 51 text

© 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層に渡す値への変換

Slide 52

Slide 52 text

Slide 53

Slide 53 text

Slide 54

Slide 54 text

© 2024 Loglass Inc. 54 04 | パフォーマンス問題、アーキテクチャとチームトポロジーストリームアラインドトポロジーの変遷イネーブリングストリームアラインドコンプリケイテッド・サブシステムストリームアラインドストリームアラインドコンプリケイテッド・サブシステムストリームアラインドコンプリケイテッド・サブシステム初期フェーズ問題切離しフェーズ研究開発フェーズ解決フェーズ再統合フェーズコラボレーションコラボレーション

Slide 55

Slide 55 text

Slide 56

Slide 56 text

Slide 57

Slide 57 text

Slide 58

Slide 58 text

Slide 59

Slide 59 text

© 2024 Loglass Inc. 59 04 | パフォーマンス問題、アーキテクチャとチームトポロジートポロジー進化の decompose - reintegrateパターン検証済みの解決策が見つかり、プロダクト本体に実装していくフェーズオニオンアーキテクチャにより、影響範囲は限定的だが、ナレッジトランスファーのためにストリームアラインドチームと協働するストリームアラインドコンプリケイテッド・サブシステム解決フェーズ

Slide 60

Slide 60 text

Slide 61

Slide 61 text

Slide 62

Slide 62 text

Slide 63

Slide 63 text

Slide 64

Slide 64 text

Slide 65

Slide 65 text

Slide 66

Slide 66 text

Slide 67

Slide 67 text

Slide 68

Slide 68 text

Slide 69

Slide 69 text

Slide 70

Slide 70 text

Slide 71

Slide 71 text

Slide 72

Slide 72 text

Slide 73

Slide 73 text

Slide 74

Slide 74 text

Slide 75

Slide 75 text

Slide 76

Slide 76 text

© 2024 Loglass Inc. 76 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.

Slide 77

Slide 77 text

Slide 78

Slide 78 text

© 2024 Loglass Inc. 78 05 | 今後の課題 - マルチプロダクト開発とアーキテクチャトポロジーアーキテクチャのためのトポロジープロダクトA プロダクトB プロダクトC アーキテクチャ支援チームアーキテクチャ支援チームアーキテクチャ支援チームコラボレーションファシリテーションコラボレーションファシリテーション Eduardo da Silva (2021). “Architecture Topologies”. https://esilva.net/architecture-topologies を参考に作成

Slide 79

Slide 79 text

Slide 80

Slide 80 text

Slide 81

Slide 81 text

© 2024 Loglass Inc. 81 偶有的複雑性と戦うためのアーキテクチャとチームトポロジーまとめ ● 本質的な複雑さと偶有的な複雑さは極力切り離す ● 自己組織化型アジャイルでは組織がダイナミックに変化するため、根深い課題は切り出してx-as-a-serviceとして連携するのが１つの解決策 ○ チームファーストの精神 ○ まずはアナログでも認知負荷を低減することを優先 ● 切り出した課題は認知負荷を減らして、再びFASTに融合させる ○ Complicated-subsystem領域はスケーリングさせづらい ○ 組織と課題が成熟してcomplicated-subsystemを抱えられる状態なら、チームとして分離するのもアリ

Slide 82

Slide 82 text