Lock in $30 Savings on PRO—Offer Ends Soon! ⏳

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

Kenichi SUZUKI
November 26, 2024

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

アーキテクチャConference2024

Kenichi SUZUKI

November 26, 2024
Tweet

More Decks by Kenichi SUZUKI

Other Decks in Technology

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. 6 00|目次 01 本質的複雑性と偶有的複雑性 02 ログラスの開発

    03 チームトポロジー 04 パフォーマンス問題、アーキテクチャとチームトポロジー 05 マルチプロダクト開発とアーキテクチャトポロジー 本日のお品書き
  4. © 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.
  5. © 2024 Loglass Inc. 9 01 | 本質的複雑性と偶有的複雑性 Frederick P.

    Brooks, JR. 著, 滝沢徹, 牧野祐子, 富澤昇 訳. 『人月の神話』. 丸善出版 (2014)
  6. © 2024 Loglass Inc. 10 01 | 本質的複雑性と偶有的複雑性 銀の弾丸はない ー

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

    銀の弾を打ち込みたい 狼男のこと • 解こうとしている問題そのものが持つ複雑さのこと ◦ 問題そのものに内在し、避けることができない複雑さ ◦ どう向き合うかが重要
  8. © 2024 Loglass Inc. 12 • その他すべての複雑さ • 副作用として解決せざるを得ない問題 •

    偶発的に発生する複雑さというよりも、本質的問題に付随する複雑性 ◦ No Silver Bulletの続編で著者が言及 ◦ 「付随的な複雑さ」とも訳される • 例) 実装過程にまつわる複雑さ、データの永続化、セキュリティ 01 | 本質的複雑性と偶有的複雑性 偶有的複雑性(accidential complexity)
  9. © 2024 Loglass Inc. 13 本質的複雑性 (Essential) 偶有的複雑性 (Accidental) 原因

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

    原田騎郎, 永瀬美穂, 吉羽 龍太郎 訳. 『チームトポロジー: 迅速な価値提供を可能にする組織 設計』. 日本能率協会マネジメントセンター(2019)
  11. © 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. ダイナミック・ リチーミング チームトポロジー
  12. © 2024 Loglass Inc. 20 02 | チームトポロジー コンプリケイテッド・サブシ ステムチーム

    プラットフォームチーム ストリームアラインドチーム イネイブ リング チーム ファシリ テーション X -as-a-Servce X -as-a-Servce チームトポロジーの例 ストリームアライン ドチームを中心に 構成される
  13. © 2024 Loglass Inc. 21 02 | チームトポロジー ストリームアラインドチーム ストリームに沿って働くチーム

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

    X-as-a-service 最小限のコラボレーションで何かを利用または提供する ファシリテーション 障害を取り除くために他のチームを支援したり、支援を受けたりする 3つのインタラクションモード
  15. © 2024 Loglass Inc. 23 02 | チームトポロジー チームファースト思考 •

    チームを起点にした考え方、チームが機能することを優先する • システムやコードの複雑さは、チームが機能していればその複雑さをうまく 扱える • チームサイズのアーキテクチャ
  16. © 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 アプリケーション基盤 クラウド基盤
  17. © 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 流動的で適応可能な スケールの技術
  18. © 2024 Loglass Inc. 29 03 | ログラスの開発 One-time Setup

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

    自己組織化する 活動する 同期する ミーティングをファシリテート し、自己組織化して活動するた めのチームを形成できるように する 各チームは、自身が集った活 動アイテムのために計画し、 協働する 短い周期でコレクティブはミー ティングを開催し、学びを共有 し進捗して、プロダクトの状態 と現在の状況について共通の 理解を得る
  20. © 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領域
  21. © 2024 Loglass Inc. 34 03 | ログラスの開発 自己組織化による課題 •

    フィーチャー開発をしながら、生産性を落とさず、認知負荷をあげずに、根 が深い問題への対処していくことが困難 • FASTの中に入らないとサポートが難しい
  22. © 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)
  23. © 2024 Loglass Inc. 46 04 | パフォーマンス問題、アーキテクチャとチームトポロジー PostgreSQLの仕組み Parser

    Analyzer Rewriter Planner Executor SQL Result Set ここで実⾏計画が作られる stats data
  24. © 2024 Loglass Inc. 47 04 | パフォーマンス問題、アーキテクチャとチームトポロジー PostgreSQLのクエリ最適化アルゴリズム 最低コストパス

    式書き換え(前処理) リレーション情報抽出 動的計画法 ベース 遺伝アルゴリズム ベース(GEQO) クエリ実行 少ない 多い ざっくり探索 パス探索 パス探索と枝刈りは同時に行われるため、PlannerとOptimizerの区別はない 結合 パス
  25. © 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層に渡す値への変換
  26. © 2024 Loglass Inc. 52 04 | パフォーマンス問題、アーキテクチャとチームトポロジー オニオンアーキテクチャ Presentation層

    Infrastructure層 Application層 Domain層 UI Application Domain Infrastructure 依存性が反転 している
  27. © 2024 Loglass Inc. 53 04 | パフォーマンス問題、アーキテクチャとチームトポロジー オニオンアーキテクチャ Presentation層

    Infrastructure層 Application層 Domain層 UI Application Domain Infrastructure コア ノンコア パフォーマンス問題がある箇所(クエリ)をノン コアとして切り出し
  28. © 2024 Loglass Inc. 54 04 | パフォーマンス問題、アーキテクチャとチームトポロジー ストリームアラインド トポロジーの変遷

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

    - reintegrateパターン • 初期フェーズ • 問題切り出しフェーズ • 研究開発フェーズ • 解決フェーズ • 再統合フェーズ と名付けてみました
  30. © 2024 Loglass Inc. 56 04 | パフォーマンス問題、アーキテクチャとチームトポロジー トポロジー進化の decompose

    - reintegrateパターン ストリームアラインド イネーブリング 初期フェーズ コラボレーション ストリームアラインドチームをサポートする形 でパフォーマンス問題を調べ始める
  31. © 2024 Loglass Inc. 57 04 | パフォーマンス問題、アーキテクチャとチームトポロジー トポロジー進化の decompose

    - reintegrateパターン 短期で解決できないため、パフォーマンス問 題に対応する班と、機能開発を進める班で分 かれる 軽量に試せる打ち手を次々に実行していく ストリームアラインド コンプリケイテッド ・サブシステム 問題切離し フェーズ コラボレーション
  32. © 2024 Loglass Inc. 58 04 | パフォーマンス問題、アーキテクチャとチームトポロジー トポロジー進化の decompose

    - reintegrateパターン 短期で解決できないため、パフォーマンス問 題に対応する班と、機能開発を進める班で分 かれる 調査結果や技術検証結果を X-as-a-serviceとして提供 ストリームアラインド コンプリケイテッド・ サブシステム 研究開発 フェーズ
  33. © 2024 Loglass Inc. 59 04 | パフォーマンス問題、アーキテクチャとチームトポロジー トポロジー進化の decompose

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

    - reintegrateパターン 新規に取り入れた技術やモジュールの認知負荷 が最小化され、FASTの中でメンテナンス・エン ハンスできる状態 ストリームアラインド 再統合フェーズ
  35. © 2024 Loglass Inc. 61 04 | パフォーマンス問題、アーキテクチャとチームトポロジー パターンの使いどころ •

    既に問題が顕在化しており、解決に時間が掛かる • けれどもフィーチャー開発を止めたくない
  36. © 2024 Loglass Inc. 62 04 | パフォーマンス問題、アーキテクチャとチームトポロジー FASTの恩恵 •

    自己組織化を重視するため、ストリームアラインドチーム以外の周辺チーム とのトポロジーも進化・適応しやすい
  37. © 2024 Loglass Inc. 67 04 | パフォーマンス問題、アーキテクチャとチームトポロジー 付随する複雑性 本質的

    偶有的 本質的 偶有的 本質的複雑性に アプローチした場合 付随する複雑性も 小さくなる
  38. © 2024 Loglass Inc. 68 04 | パフォーマンス問題、アーキテクチャとチームトポロジー 複雑さをあぶり出し、適切なサイズに制御 分析モデル

    問題 設計モデル ソリューション 抽象 具象 問題空間 解決空間 複雑さをあぶり出 せているか (非機能設計等) 非機能を無視して リリースしていな いか 偶有的複雑性が 現出する領域
  39. © 2024 Loglass Inc. 69 04 | パフォーマンス問題、アーキテクチャとチームトポロジー 複雑さをあぶり出し、適切なサイズに制御 分析モデル

    問題 設計モデル ソリューション 抽象 具象 問題空間 解決空間 複雑さをあぶり出 せているか (非機能設計等) 偶有的複雑性が 現出する領域 本質的 非機能を無視して リリースしていな いか
  40. © 2024 Loglass Inc. 70 04 | パフォーマンス問題、アーキテクチャとチームトポロジー 複雑さをあぶり出し、適切なサイズに制御 分析モデル

    問題 設計モデル ソリューション 抽象 具象 問題空間 解決空間 複雑さをあぶり出 せているか (非機能設計等) 偶有的複雑性が 現出する領域 本質的 本質的 非機能を無視して リリースしていな いか 適切な問題空間 に狭める
  41. © 2024 Loglass Inc. 71 04 | パフォーマンス問題、アーキテクチャとチームトポロジー 複雑さをあぶり出し、適切なサイズに制御 分析モデル

    問題 設計モデル ソリューション 抽象 具象 問題空間 解決空間 複雑さをあぶり出 せているか (非機能設計等) 偶有的複雑性が 現出する領域 本質的 本質的 本質的 非機能を無視して リリースしていな いか 適切な問題空間 に狭める
  42. © 2024 Loglass Inc. 72 04 | パフォーマンス問題、アーキテクチャとチームトポロジー 複雑さをあぶり出し、適切なサイズに制御 分析モデル

    問題 設計モデル ソリューション 抽象 具象 問題空間 解決空間 複雑さをあぶり出 せているか (非機能設計等) 偶有的複雑性が 現出する領域 本質的 本質的 本質的 本質的 非機能を無視して リリースしていな いか 適切な問題空間 に狭める
  43. © 2024 Loglass Inc. 73 04 | パフォーマンス問題、アーキテクチャとチームトポロジー 複雑さとアーキテクチャとトポロジーと 本質的

    偶有的 UI Application Domain Infrastructure ストリームアラインド コンプリケイテッド・ サブシステム 依存の分離 コンウェイの法則/ チームファーストアーキテクチャ 自己組織化/ トポロジー進化
  44. © 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.
  45. © 2024 Loglass Inc. 77 05 | 今後の課題 - マルチプロダクト開発とアーキテクチャトポロジー

    マルチプロダクトの先にあるもの マルチプロダクトでは、プロダクトごとのアーキテクチャを整合させる必要性がで てくる。その際のチームインタラクションならぬアーキテクチャ・インタラクション をどうすべきか
  46. © 2024 Loglass Inc. 78 05 | 今後の課題 - マルチプロダクト開発とアーキテクチャトポロジー

    アーキテクチャのためのトポロジー プロダクトA プロダクトB プロダクトC アーキテクチャ 支援チーム アーキテクチャ 支援チーム アーキテクチャ 支援チーム コラボレーション ファシリテーション コラボレーション ファシリテーション Eduardo da Silva (2021). “Architecture Topologies”. https://esilva.net/architecture-topologies を参考に作成
  47. © 2024 Loglass Inc. 81 偶有的複雑性と戦うためのアーキテクチャとチームトポロジー まとめ • 本質的な複雑さと偶有的な複雑さは極力切り離す •

    自己組織化型アジャイルでは組織がダイナミックに変化するため、根深い課 題は切り出してx-as-a-serviceとして連携するのが1つの解決策 ◦ チームファーストの精神 ◦ まずはアナログでも認知負荷を低減することを優先 • 切り出した課題は認知負荷を減らして、再びFASTに融合させる ◦ Complicated-subsystem領域はスケーリングさせづらい ◦ 組織と課題が成熟してcomplicated-subsystemを抱えられる状態なら、チームとして 分離するのもアリ