ソフトウェアアーキテクチャから考える開発チームの在り方 / How a development team should be from the viewpoint of software architecture

2022-11-10 AWS DevDay Online Japan 2022の登壇資料(F-3)です。

Transcript

1. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. D E V D AY N O V E M B E R 1 0 , 2 0 2 2
2. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. ソフトウェアアーキテクチャから考える 開発チームの在り⽅ ⼩笹 佑京 (Ozasa Yuki) F - 3 CEO & VPoE 株式会社アンチパターン (Anti-Pattern Inc.)
3. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. ⾃⼰紹介 小笹 佑京(Ozasa Yuki) 株式会社アンチパターン CEO兼VPoE 日本CTO協会 Contributor Twitter: @yukiozasa
4. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. 株式会社アンチパターンについて Vision: ⽇本のソフトウェアエンジニアを憧れの職業へ 事業: • ソフトウェアエンジニア採⽤サービス engineed • ソフトウェアエンジニア特化型コミュニティスペース HarborS • ⼤学⽣向けプログラミング学習コミュニティ POSSE • ソフトウェア開発⽀援 Gateway • SaaS 事業 SaaSus Platform
5. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. 本セッションのゴール • ソフトウェアアーキテクチャとチームの関係性を理解してもらう • その上で、弊社の実体験からのナレッジをシェアすることによって、 より良いソフトウェア開発の現場が増えるきっかけを作る
6. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. • 組織構造とソフトウェアアーキテクチャとの同形性 • ソフトウェアアーキテクチャとは • チームトポロジー • SaaS 事業における設計事例 • 実体験から得た学び アジェンダ
7. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. 組織構造と ソフトウェアアーキテクチャの同形性
8. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. システムを設計する組織は、 ⾃らのコミュニケーション構造を 真似た設計を⽣み出す Melvin E. Conway “How do committees invent?” (April 1968).
9. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. コンウェイの法則 組織のコミュニケーション構造と、 設計し得るシステムのアーキテクチャには同形⼒が働き、 制約が⽣まれてしまうことを⽰唆したもの 例) If you have four groups working on a compiler, you'll get a 4-pass compiler. “The New Hacker's Dictionary” Raymond, Eric S. (October 1996).
10. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. 逆コンウェイの法則 コンウェイの法則を念頭におき、 望ましいアーキテクチャを実現するために、 それに合った組織構造やチーム構造にした⽅が良いという考え⽅ アーキテクチャから組織構造を考えることで 効果的なソフトウェア開発を進められる
11. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. ソフトウェアアーキテクチャとは
12. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. ソフトウェアーキテクチャの4要素 • システムの構造 • マイクロサービスやレイヤードなどのアーキテクチャスタイル • アーキテクチャ決定 • DB層へのアクセス制約などシステムを構築する際のルール • 設計指針 • 設計時のガイドライン • アーキテクチャ特性 (-ility) https://www.oreilly.co.jp/books/9784873119823/
13. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. ⽬的を達成するためにソフトウェアが備えなければならないもの 互いに⼲渉する項⽬もあるため、全て備えることはできない 優先すべき特性を選定し、トレードオフスライダーなどを活⽤する ソフトウェアーキテクチャの特性 Availability Reliability Testability Scalability Agility ・・・
14. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. アーキテクチャの決定に影響を与える要因 • 開発チームの能⼒ • 組織のコミュニケーション構造(=同形⼒) • エコシステムの変化 • 法令の変化
15. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. ソフトウェアアーキテクチャは トレードオフがすべてだ Mark Richards, Neal Ford. “Fundamentals of Software Architecture”, 邦題『ソフトウェアアーキテクチャの基礎』
16. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. 2要素に整理し組織設計に活⽤ • システムの構造 • アーキテクチャ決定 • 設計指針 • アーキテクチャ特性 (-ility) 逆コンウェイの法則をもとに組織について 整理するべくチームトロポジーを活⽤ • 構造 • ルールやガイドライン
17. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. チームトポロジー https://pub.jmam.co.jp/book/b593881.html
18. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. チームトポロジーとは ⾼速なデリバリーを実現することを⽬的とした実践的な適応モデル 価値提供の中⼼にはチームがあるという チームファースト思考を前提とし、 4つの基本的なチームタイプと 3つのインタラクションパターンでモデルを表現
19. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. アーキテクチャの要素を組織設計の⽂脈で捉える • 構造 • ⻑続きする⼩さくて効果的なチーム • 4つのチームタイプ • 3つのインタラクションモード • ルールやガイドライン • チーム API
20. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. 構造 - ⻑続きする⼩さくて効果的なチーム • モダンなソフトウェア開発における情報の量と質を適切に扱うには 個⼈では継続的な対応が不可能 • 責任範囲と必要なスキルを持ったチームを構成する • 互いを信頼しパフォーマンスするチームの組成には時間を要する
21. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. コミュニケーションの複雑性を抑える • ⼈数が増えると コミュニケーションパスが増⼤する • オーバーヘッドの増加 • コンウェイの法則による同形⼒が働き、 ソフトウェアも複雑になる • 共通のゴールのために働く、 5〜9名で1チームとする • Two Pizza Rule や スクラムガイド(2020年版)でも 同様の⾔及がなされている https://getlighthouse.com/blog/developing-leaders-team-grows-big/
22. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. 構造 - 4つのチームタイプ 1. ストリームアラインドチーム 2. プラットフォームチーム 3. イネイブリングチーム 4. コンプリケイテッド・サブシステムチーム Stream-aligned team Platform team Enabling team Complicated Subsystem team
23. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. ストリームアラインドチーム • ビジネスのフロー(ストリーム)に沿って配置され、 価値を提供する中⼼的なチームタイプ • 職能横断的で、デリバリーに必要な権限と能⼒を有する Stream-aligned team
24. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. プラットフォームチーム • ツールやインフラなど共通の内部サービス(プラットフォーム)を 提供するチームタイプ • ストリームアラインドチームが詳細を把握せずとも 「利⽤できる」状態にすることで認知負荷を下げる働きを持つ Platform team
25. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. イネイブリングチーム • 他のチームが新たにスキルや知識を得ることを⽀援する チームタイプ • ドメインエキスパートや特定技術領域のスペシャリストが所属 • 技術検証や探索なども⾏う Enabling team
26. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. コンプリケイテッド・サブシステムチーム • 複雑なサブシステムを取り扱うチームタイプ • ⼈⼯知能 / 画像処理 / 特殊なアルゴリズムなど Complicated Subsystem team
27. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. 3つのインタラクションモード 1. コラボレーションモード 2. X-as-a-Serviceモード 3. ファシリテーションモード Collaboration XaaS Facilitating
28. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. コラボレーションモード • 他のチームと⼀緒に働くモード • 引き継ぎがなくイノベーションと探索ができる • コラボレーションのオーバーヘッドがあるため、 効率の低下・認知負荷の増⼤リスクがある Collaboration
29. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. X-as-a-Serviceモード • コラボレーションを最⼩にしてツールやAPIを提供するモード • 適切な境界を設定できれば認知負荷を下げられる XaaS
30. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. ファシリテーションモード • ⼀⽅のチームが他⽅のチームの学習などを⽀援するモード Facilitating
31. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. ルールやガイドライン - チーム API チームを取り巻く情報を API として定義する考え⽅ チーム間の認知負荷を下げる⽬的で設定する 例) • チーム名や⽬的 • チームタイプ • サービスレベルの期待値 • Wikiでの検索語 • コミュニケーションツールでのチャンネル命名規則 • 同期的に働いている時間
32. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. アーキテクチャの要素を組織設計の⽂脈で捉える • 構造 • ⻑続きする⼩さくて効果的なチーム • 4つのチームタイプ • 3つのインタラクションモード • ルールやガイドライン • チーム API どこから始めるか︖ = チームをどのように作るか︖
33. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. チームの境界をどう定義するか 『チームトポロジー』では、以下の節理⾯などを例に挙げている。 • ビジネスドメインのコンテキスト境界 • ユーザーペルソナ • 変更のケイデンス • チームメンバーの地理的配置 • 技術 逆コンウェイの法則を活⽤し、 ソフトウェアアーキテクチャから チーム境界を設計するアプローチを実施
34. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. SaaS 事業における設計事例
35. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. BtoB SaaS を作るための SaaS
36. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. SaaS を取り巻く状況 テナントの概念 運⽤の難しさ
37. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. SaaS を取り巻く状況 • 認証 / 認可 • 料⾦プラン • 請求 • セキュリティ • 可⽤性 • 利⽤量計測 • etc… × テナント 【運⽤者視点】 アクセスしてきたユーザーにつ いて •所属するテナントは︖ •役割(ロール)は︖ •プランは︖ •どの機能を使える︖ •いくらで請求︖ 【テック視点】 •リソースの共有範囲 •テナント分離 •データパーティショニング etc…
38. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. SaaS を取り巻く状況 勤怠管理 ⼈事評価 給与振り込み 請求書処理 認証 / 認可 利⽤量計測 契約企業管理 外部サービス連携 業務ナレッジを SaaS 化した 機能群 SaaS として 必要な機能群 ※機能は⼀例
39. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. SaaSus Platform が実現すること 共通機能を SaaS 化し管理画⾯と SDK/API を提供 SaaS 提供事業者が業務ナレッジのソフトウェア化に フォーカスできるように⽀援する
40. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. サービス特性 利⽤顧客の SaaS に対する aPaaS のような役割を担う ネットワーク ハードウェア OS /ミドルウェア アプリ開発機能群 アプリケーション ネットワーク ハードウェア OS /ミドルウェア アプリケーション ネットワーク ハードウェア OS /ミドルウェア アプリケーション そのため、学習容易性やテスト容易性などよりも 可⽤性・信頼性・セキュリティなどのアーキテクチャ特性が求められる PaaS aPaaS SaaS
41. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. サービス特性 ▪セキュリティへの対応 利⽤顧客が提供する SaaS のセキュリティ要求は様々なため、 利⽤顧客ごとに AWS アカウントレベルで分離したテナントを動的に作成し、 ブリッジ型の分離モデルを採⽤ コンピュート層は共有し、データ層は AWS アカウント単位で完全分離
42. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. 設計のポイント • グローバルシェア(エコシステム)を意識した技術選定 • モジュラモノリスの採⽤ • ドッグフーディング • テナントごとの動的なインフラ構築
43. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. 採択した技術要素
44. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. API ではモジュラモノリスを採⽤ モノリスアプリケーション内で、ドメインモデル等を単位として 独⽴性を担保したモジュールに分解したもの Clean Architecture で実装 ▪採択理由 • SaaS 開発における⼀定のドメイン知識を有しており、 モジュールの分割イメージがあったため • 将来的にマイクロサービスに移⾏しやすい状態にするため • 現時点においては⼀定の Agility を担保したいため
45. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. ドッグフーディング SaaSus Platform ⾃体が SaaS であるため、 SaaSus Platform の機能を活⽤して作るフラクタル構造に設計
46. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. ソフトウェアアーキテクチャ(インフラ視点)
47. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. ソフトウェアアーキテクチャ(インフラ視点) ログイン画⾯など 共通画⾯は SaaSus Platform の機能を利⽤ 認可、請求など 共通機能は API/SDK を利⽤ 管理画⾯など 共通画⾯は SaaSus Platform の機能を利⽤
48. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. ソフトウェアアーキテクチャ(アプリケーション視点) クライアント Backends For Frontends Auth Module User Module Tenant Module Billing Module ・・・ API
49. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. チームアーキテクチャの設計ポイント • ⼩さく始めて緩やかとした拡⼤を⽬指す • 初期は意図的にコラボレーションモードを選択 • 技術を節理⾯としながら段階的にアーキテクチャを変えていく • 組織内にない知識や能⼒は 副業者やフリーランサーを活⽤することで、取り⼊れていく • チームの変化を時間軸を設定し戦略的に捉えていく
50. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. チームアーキテクチャ Frontend Team Backend Team Cloud Team Flow of change 組織内に React, Next.js, デザインシステムに関する知⾒がなかったため フリーランサーの採⽤を推進 ワンチームで下記を実装 • OpenAPI 設計 • Internal API(BFF) • Public API 動的に環境を⽣成するため IaC を推進 Freelance Team
51. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. チームアーキテクチャ Frontend Team Backend Team Cloud Team Freelance Team Application Team Flow of change Auth Team Billing Team Inner Platform Team ・・・
52. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. チームアーキテクチャ Application Team Flow of change Auth Team Billing Team Inner Platform Team ・・・ フロントから Internal API (BFF) まで実装 いち SaaSus Platform 利⽤者として振る舞う SaaSus Platform を節理⾯として チームを分割 内部はドメインごとに徐々にチームを分割し、 マイクロサービスアーキテクチャへ 変更の呼⽔は、 ソフトウェアの肥⼤もしくはチームの増員
53. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. 実体験から得た学び
54. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. ソフトウェアとチームはコインの裏表 イテレーティブで終わりのない改善活動 ソフトウェア チーム
55. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. 好むと好まざるとに関わらず変化してしまう 変化への対応を前提とした戦略が必須 ソフトウェア • お客様への価値提供 • エコシステムの変化 • 法令への対応 • セキュリティへの対応 チーム • 採⽤ • 退職 • ライフイベントへの対応
56. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. ソフトウェア企業における経営 ソフトウェア チーム 事業(+アウトカム) 無形資産ではあるものの 可視化の⽅法はある 今回のアプローチ以外にも 下記のツールも活⽤可能 • DevOps 4 keys • DX Criteria (⽇本CTO協会) 事業との戦略的連動も当然必要 CEO はもちろん COO, CTO, VPoE の連携が重要
57. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. Thank you! © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. Yuki Ozasa @yukiozasa
58. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. Please complete the session survey © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved.