実践チームトポロジー：プラットフォーム性とイネイブリング性の戦略 / Practical Team Topologies in Timee

by Go Akazawa

Slide 1

Slide 1 text

株式会社タイミーエンジニアリング本部 VPoE 赤澤剛実践チームトポロジー：プラットフォーム性とイネイブリング性の戦略 2024.06.29 開発生産性カンファレンス #開発生産性con_ﬁndy_4C

Slide 2

Slide 2 text

自己紹介  赤澤剛 @go0517go エンジニアリング本部 VP of Engineering 2 2009-2018　株式会社ワークアプリケーションズ（SWE, VP）　Works Applications Singapore Pte. Ltd.（SWE, VP） 2018-2020　LINE Financial株式会社（Technical PjM） 2020-2024　株式会社ユーザベース　　株式会社アルファドライブ（執行役員CTO） 2024- 　株式会社タイミー（VPoE）プロレス・ゲーム・アニメ・漫画・特撮ヒーローが好きです！  「ええやん！」が仕事をする上でも口癖なので最近はVP of Eeyanといじられたりもしてます。  2

Slide 3

Slide 3 text

タイミーの事業及びサービス紹介

Slide 4

Slide 4 text

タイミーとは｢働きたい時間｣と｢働いてほしい時間｣をマッチングするスキマバイトサービス従来の「求人サイト」でも「派遣」でもない 4

Slide 5

Slide 5 text

タイミーの特徴 5

Slide 6

Slide 6 text

登録ワーカーの属性 6

Slide 7

Slide 7 text

タイミーの実績スキマバイト No.1 ※1 ※2 [調査方法]インターネット調査 [調査期間]2024 年 2 月 9 日~11 日 [調査概要]スキマバイトアプリサービスの実態調査 [調査委託先]株式会社マクロミル利用率・リピート率 ※1 ※2 導入事業者数 98,000企業ワーカー数 700万人 7

Slide 8

Slide 8 text

募集人数の推移コロナ禍においても、過去に例を見ない程の加速的高成長を実現。 ※1：2023年4Qと2022年4Qの比較 8

Slide 9

Slide 9 text

Vision 一人ひとりの時間を豊かに「人生の時間は有限である」これは代表の小川が尊敬していた祖父の急逝をきっかけに得た教訓です。有限だからこそ時間をより価値あるものにする方法をすぐに見つけられすぐに実行できる世界をつくりたい。この想いから、時間を豊かにする選択肢の一つとして、好きな時間に働ける「タイミー」が着想されました。私たちは「働く」に留まらない多様なアプローチで、一人ひとりの時間が豊かになるきっかけを提供していきます。 9

Slide 10

Slide 10 text

Mission 「はたらく」を通じて人生の可能性を広げるインフラをつくる時間にとらわれず、好きな場所で、好きな仕事を。少し前には考えられないような自由な働き方を、タイミーは提供しています。この新しい「働く」は、ただ自由であることにその魅力を留めません。「働く」を通じた、多くの人との出会いと経験の積み重ねは、自分自身の新たな価値を発見し、可能性を広げる糧になると私たちは信じています。タイミーは、新しい「働く」インフラとして、一人ひとりが自分の可能性を広げていける社会を目指します。 10

Slide 11

Slide 11 text

11 事業及びサービス紹介はここまで！  ここからが本日の本題です！  11

Slide 12

Slide 12 text

実践チームトポロジー：プラットフォーム性とイネイブリング性の戦略

Slide 13

Slide 13 text

前提  13 本セッションは主には「Team Topologies」の書籍を読了済、ないし組織への適用を実施または検討中の方を主に対象としております。  冒頭で最低限の解説としてチームトポロジーの概要に触れますが、セッションでは事例含めて個別のパートを取り上げますので、ご興味ありましたら書籍自体をご覧ください。    また、タイミーでも様々に変化するビジネスや環境に適応する組織づくりのためにチームトポロジーを組織適用し常に課題とともに試行している状況です。書籍との照らし合わせや差分含めて事例として聞いてくださったチームの強化と改善の一助になれば幸いです。  13

Slide 14

Slide 14 text

今日お話ししたいこと  14 ● タイミーの事業やプロダクトの現在地点について    ● 様々に変化する市場環境の中、その変化に対して適応的な開発を継続強化するためにどのようにチームトポロジーを組織に適用しているか    ○ タイミーでのストリームアラインドチームのあり方と文化形成    ○ プラットフォーム性とイネイブリング性の使い分け  14

Slide 15

Slide 15 text

チームトポロジーとは

Slide 16

Slide 16 text

組織と開発生産性に関するタイミーでの必読書  16 16

Slide 17

Slide 17 text

未読の方へのオススメ！  17 本書の共訳者である吉羽龍太郎（@ryuzee）さんの「30分で分かった気になるチームトポロジー」を参照してから書籍本編に入るのもオススメです！（読了されている方は振り返りにも！）  Ryuzee.com.「【資料公開】30分で分かった気になるチームトポロジー」 .https://www.ryuzee.com/contents/blog/14566,（参照2024-06-07） 17

Slide 18

Slide 18 text

チームトポロジーとは？  ソフトウェア開発において素早く安定した価値提供フローで  顧客価値の最大化を実現するための適応型の組織設計モデル  ● 技術、人、ビジネスの変化に継続的に対処するために組織も変化することが前提 = 適応型     ● チームの目的と責任を明確にし、チーム間の相互関係の効果の向上を目指す     ● 唯一絶対のトポロジーはなく適応型組織モデルのテンプレートと捉える   18

Slide 19

Slide 19 text

フロー実現の上でチームトポロジーが中心に据えたもの  19 ● コンウェイの法則  ● チームファースト  ● チームAPI  ● 4つのチームタイプ  ● 3つのインタラクションモード  ● 組織的センシング  ● トポロジー進化  Ryuzee.com.「【資料公開】30分で分かった気になるチームトポロジー」 .https://www.ryuzee.com/contents/blog/14566,（参照2024-06-07） 19

Slide 20

Slide 20 text

本日特にフォーカスしてお話しする点  20 ● コンウェイの法則  ● チームファースト  ● チームAPI  ● 4つのチームタイプ  ● 3つのインタラクションモード  ● 組織的センシング  ● トポロジー進化  Ryuzee.com.「【資料公開】30分で分かった気になるチームトポロジー」 .https://www.ryuzee.com/contents/blog/14566,（参照2024-06-07） 20

Slide 21

Slide 21 text

４つのチーム  21 ストリームアラインドチーム   ビジネスの主な変更フロー=ストリームに沿って配置されるチーム     職能横断型であり、他のチームを待つことなく、要求探索から本番運用までのデリバリー一式を担える。4タイプの中心となるチームで、他のチームタイプはストリームアラインドチームをいかに強化するかを担う。  プラットフォームチーム   インフラや共通的な基盤などを提供するチーム     ストリームアラインドチームが詳細を知らなくても安定的かつ高速にデリバリーを担えるようにサポートすることで負荷を下げる。   イネイブリングチーム   他のチームに対して新しいケイパビリティの獲得（新技術やスキルの導入）を支援するチーム    特定領域のスペシャリストが主な構成メンバーで、組織においてCenter of Practiceとなる。   コンプリケイテッド・  サブシステムチーム   複雑性が高い（高度な専門スキルやドメイン知識が必要など）サブシステムやコンポーネントを提供するチーム  4つのチームタイプに絞り、目的・役割・責任を明確にすることでチーム間の関係性や組織全体の構造を認知しやすくする  21

Slide 22

Slide 22 text

3つのインタラクションモード  22 4つのチームタイプ間のコミュニケーションや連携方法を3つのインタラクションモードとして定義し、チームのタイプやフェーズに応じて使い分ける  コラボレーション  共通の目的に対して他のチームと綿密に協力し合うモード     素早く探索や検証、そこからの学習を進める必要がある、領域の初期フェーズにおいて有効性が高いが、責務境界面を一定に曖昧にすることで短期的生産性は落ちる。  X-as-a-Service  あるチームが他のチームの提供物をサービスとして利用するモード     ブラックボックスとして利用する関係性で、責任境界やオーナーシップも明確で最小限のチーム連携になるが、相手の領域に踏み込まない力学が働くことで境界面でのイノベーションを起こりにくくする可能性もある。  ファシリテーション  あるチームが他のチームに対して新技術の導入や習得をサポートするモード     組織においてCenter of Practiceを担える経験豊富なメンバーが中心となり、ティーチング・コーチングなどを用いて学習支援や習得の支援となる障害を取り除くアクションを行う。   22

Slide 23

Slide 23 text

チーム構造を超簡略化して表現すると...  23 ストリームアラインドチームと最強の仲間たち！  23

Slide 24

Slide 24 text

チームトポロジーでの典型的なチーム連携  24 ストリームアラインドチーム   イネイブリングチーム      ファシリテーション  コンプリケイテッド・サブシステムチーム  X-as-a-Service  X-as-a-Service  プラットフォームチーム   24

Slide 25

Slide 25 text

サービス開発組織の全体像指標で計測可能なビジネスドメインごとに、組織の分割を進めています。 25

Slide 26

Slide 26 text

タイミーの開発組織をチームトポロジーで表すと...  　　マッチングTribe  　　（ストリームアラインドチームの集合）  　　スポットワークシステムTribe  　　（ストリームアラインドチームの集合）      QA&  Process Enabling チーム  （イネイブリング   チーム）      開発プラットフォームTribe  （プラットフォームチーム）  ファシリテーション  コラボレーション  ファシリテーション  X-as-a-Service  X-as-a-Service  SAチーム間のインタラクション     ユーザージャーニーに基づくSAチームは機能領域においてAPIを提供し、X-as-a-Serviceとして振る舞い、時に共通の顧客価値のためにコラボレーションして開発する   開発プラットフォームTribe     組織の初期段階ではコラボレーション型で強く連携し開発を進めていたが、組織の段階的な成熟により、X-as-a-Servide型に徐々に移行中  イネイブリングチームの振る舞い     特定の専門領域においてCenter of Practiceとして主にファシリテーション型でSAチームと関わるが、新しい技術や知見の導入時には意図的にコラボレーション型を用いて深く関与し進行する  （SAチームへのEmbed）   26

Slide 27

Slide 27 text

タイミーでのストリームアラインドチームのあり方と文化形成

Slide 28

Slide 28 text

タイミーでの標準的なストリームアラインドチーム  28 28

Slide 29

Slide 29 text

チームの実例 - マッチングTribe  29 PO/PdM   SM  EM  Designer   Work Well Squad Engineer Members   PO/PdM   SM  EM  Designer   Working Relations Squad Engineer Members   Other Squad Other Squad Tribeの内部にバリューストリームによってさらに分割されたSquadが内包されている  29

Slide 30

Slide 30 text

チームに不足したケイパビリティの診断と獲得  30 ● ストリームアラインドチームは定義したバリューストリームに沿った価値提供を素早く安定的に行うため、その達成に不足するケイパビリティを自己診断し、複数の方法で獲得する    ● 不足したケイパビリティの診断と獲得はPdM・スクラムマスター・エンジニアいずれも主体となって行うが、タイミーでは特にEM（エンジニアリングマネージャー）にその役割を委ねている  30

Slide 31

Slide 31 text

チームに不足したケイパビリティの診断と獲得  31 ストリームアラインドチームが不足したケイパビリティ=解決すべきチーム課題を認識できる状態を両サイドから作る    ● ストリームアラインドチーム：不足したケイパビリティの自己診断を行い、プラットフォームチームやイネイブリングチームに対して言語化し連携する    ● プラットフォームチーム・イネイブリングチーム：SAチーム外から課題を認識し、 SAチームと共通認識を作り、そして能力獲得を支援する  31

Slide 32

Slide 32 text

ケイパビリティの不足 ≠ リソースの不足  32 ケイパビリティの不足とリソースの不足は同一視しない。  リソースだけの投入では、人が増えてコミュニケーションコストや認知負荷は上がったが、本来の目的であるケイパビリティは獲得できていないことも往々に発生する。  32

Slide 33

Slide 33 text

SAチームでの新たなケイパビリティを獲得するための手段例  33 ● 採用  ● （一時的な）外部人材の知見  ● 組織内での人材アロケーション  ● チームメンバーの成長と挑戦（育成・自己学習・新領域への挑戦）  ● イネイブリングチームによる学習サポート  ● プラットフォームチームやコンプリケイテッド・サブシステムチームによるサービス提供  33

Slide 34

Slide 34 text

プロダクトエンジニアの定義 β版 in タイミー 34 お客様の課題解決のために専門領域や役割を広げる越境性を持ってプロダクトの成長に取り組むエンジニア    「越境性を持つ」の意図    - チームの責務領域やAPIを明確にするからこそ、境界面での連携やイノベーションが鈍化したり、ボールが落ちることを防ぐために適切にオーバーラップして進行する     - 自身が越境する側だけでなく、越境して自チームと連携してくれるチームやメンバーを歓迎し、適切なインタラクションで課題解決を加速できる   34

Slide 35

Slide 35 text

プロダクトエンジニアは高い専門性の追求の否定では一切ないプロダクトエンジニア ≠ フルスタックエンジニア  プロダクトエンジニア ≠ フルサイクルエンジニア      プロダクトエンジニアとは、全員に個のエンジニアとしてフルスタック性やフルサイクル性を要求するものではない（1つの形としてもちろんそれらも歓迎する）   フルサイクル性をもつべきはストリームアラインドチームであり、個の強みや尖りを重ねてチームを強固にする    特定領域への高い専門性や専任性も明確にプロダクトエンジニアのあり方であり、等しく大歓迎！（そもそも特定領域への専門性の高まりが隣接領域の知見を引き上げ、越境可能性を加速するとも言える）  35 35

Slide 36

Slide 36 text

SAチームとしてのファシリテーションモードの受け方  36 イネイブリングでの新しい技術や知識の獲得・学習に対してオープンなマインドを組織文化として醸成する  “ストリームアラインドチームの人はイネイブリングチームに助けてもらうことに対してオープンである必要がある。新しいアプローチに対して心を開き、イネイブリングチームはもっと良いアプローチを見てきたのだろうと認識することが必要なのだ。” マシュー・スケルトン , マニュエル・パイス著, 原田騎郎, 永瀬美穂, 吉羽龍太郎訳.『チームトポロジー価値あるソフトウェアをすばやく届ける適応型組織設計』 .日本能率協会マネジメントセンター .2021年,280p 36

Slide 37

Slide 37 text

没個性でないチーム：「VPoE Mission in タイミー」より抜粋  37 37

Slide 38

Slide 38 text

プラットフォーム性とイネイブリング性の使い分け

Slide 39

Slide 39 text

タイミーの開発組織をチームトポロジーで表すと...  　　マッチングTribe  　　（ストリームアラインドチームの集合）  　　スポットワークシステムTribe  　　（ストリームアラインドチームの集合）      QA&  Process Enabling チーム  （イネイブリング   チーム）      開発プラットフォームTribe  （プラットフォームチーム）  ファシリテーション  コラボレーション  ファシリテーション  X-as-a-Service  X-as-a-Service  SAチーム間のインタラクション     ユーザージャーニーに基づくSAチームは機能領域においてAPIを提供し、X-as-a-Serviceとして振る舞い、時に共通の顧客価値のためにコラボレーションして開発する   開発プラットフォームTribe     組織の初期段階ではコラボレーション型で強く連携し開発を進めていたが、組織の段階的な成熟により、X-as-a-Servide型に移行している   イネイブリングチームの振る舞い     特定の専門領域においてCenter of Practiceとして主にファシリテーション型でSAチームと関わるが、新しい技術や知見の導入時には意図的にコラボレーション型を用いて深く関与し進行する  （SAチームへのEmbed）   39

Slide 40

Slide 40 text

タイミーでの代表的なプラットフォーム及びイネイブリングチーム  40 ● Agile Practiceチーム  ○ Process Enabling = 適応型開発の推進     ● QA Enablingチーム    ● Dev Platformチーム  ○ Platform Engineering  ○ Enabling Site Reliability Engineering     ● Dev Enableチーム  ○ 学習文化の推進  ○ エンジニアがエンジニアリングに集中するための環境と制度の提供   40

Slide 41

Slide 41 text

タイミーでのプラットフォームチームとイネイブリングチーム  41 ● タイミーでは「プラットフォーム」または「イネイブリング」を冠するチームがプロダクト開発組織内に複数存在する    ● 実体のチームの動き方として、それぞれの専門領域においてストリームアラインドチームを支援する手段としてプラットフォーム的振る舞いとイネイブリング的振る舞いの両面をもち、使い分けている    ● ストリームアラインドチームへの支援を最大化するための主な振る舞いによってチームタイプとチーム名称を決定づけている  41

Slide 42

Slide 42 text

チームタイプ別の主なインタラクションモード  42 コラボレーション X-as-a-Service ファシリテーションストリームアラインドチーム典型的典型的偶発的イネイブリングチーム偶発的典型的コンプリケイテッド・サブシステムチーム偶発的典型的プラットフォームチーム偶発的典型的 42

Slide 43

Slide 43 text

チームタイプ別の主なインタラクションモード  43 イネイブリングチーム及びプラットフォームチームは課題や不足したケイパビリティの把握、提供するサービスの利用促進のために適切にコラボレーションモードを使い、SAチームに深く関与する必要がある  コラボレーション X-as-a-Service ファシリテーションストリームアラインドチーム典型的典型的偶発的イネイブリングチーム偶発的典型的コンプリケイテッド・サブシステムチーム偶発的典型的プラットフォームチーム偶発的典型的 43

Slide 44

Slide 44 text

「偶発的」の意味するところ  44 領域のフェーズやチームの成熟度に応じて意図的に引き起こす  44

Slide 45

Slide 45 text

タイミーでの代表的なプラットフォーム及びイネイブリングチーム  45 ● Agile Practiceチーム  ○ Process Enabling = 適応型開発の推進     ● QA Enablingチーム    ● Dev Platformチーム  ○ Platform Engineering  ○ Enabling Site Reliability Engineering     ● Dev Enableチーム  ○ 学習文化の推進  ○ エンジニアがエンジニアリングに集中するための環境と制度の提供   45

Slide 46

Slide 46 text

タイミーでの標準的なストリームアラインドチーム  46 Engineering Manager 46

Slide 47

Slide 47 text

Agile Practiceチームの例タイミーのプロダクト開発組織には、適応型な開発を行える組織作りを推進するための専門チーム「Agile Practiceチーム」を組成しています。     アジャイル開発のCenter of Practiceを担い、SAチームの成熟課程の初期では専任のスクラムマスターとしてストリームアラインドチームにEmbedする形で内部からリードします。   PO/P dM  SM  EM  Desig ner  SAチーム Engineer Members   Agile Practiceチーム専任スクラムマスター  としてEmbed  47

Slide 48

Slide 48 text

Agile Practiceチームの例組織全体の成長や成熟の過程で段階的にインタラクションモードを変化させている    ● SAチームによっては専任スクラムマスターとして関与しているチームに加え、SAチーム内のエンジニアまたはEMがスクラムマスターを担い、ファシリテーションモードで連携するパターンにも遷移している。    ● SPACEフレームワークを用いて多角的に生産性を計測するためのダッシュボードを提供するなどプラットフォーム性も担い、X-as-a-Serviceとしての振る舞いの割合も増えている。（現在まさに取り組みとしてトライアル進行中！）  SAチーム  Agile Practice チーム  コラボレーション  SAチーム  Agile Practice チーム  SAチーム  ファシリテーション  Agile Practice チーム  48

Slide 49

Slide 49 text

タイミーでの代表的なプラットフォーム及びイネイブリングチーム  49 ● Agile Practiceチーム  ○ Process Enabling = 適応型開発の推進     ● QA Enablingチーム    ● Dev Platformチーム  ○ Platform Engineering  ○ Enabling Site Reliability Engineering     ● Dev Enableチーム  ○ 学習文化の推進  ○ エンジニアがエンジニアリングに集中するための環境と制度の提供   49

Slide 50

Slide 50 text

QA Enablingチームのケースプラットフォーム性  ● 品質分析(観点カバレッジやDDPモニタリングなど)の実施障害分析  ● SET Infra の提供  ● SET ライブラリの開発など    イネイブリング性  ● SET Infra やライブラリの利用浸透  ● インプロセスQA  ● QAコーチ  50

Slide 51

Slide 51 text

QAファンネルにおけるQA Enablingチームの主な役割  Yasuharu Nishi.「品質を加速させるために、テスターを増やす前から考えるべき QMファンネルの話（3D 版）」.https://www.slideshare.net/slideshow/quality-management-funnel-3d-how-to-organize-qarelated-roles-and-specialties/249498558,（参照2024-06-07）インプロセスQA（コラボレーション）とQAコーチ（コラボレーション→ファシリテーション）が現在の主な役割  51

Slide 52

Slide 52 text

QAコーチの例  チームで品質についてディスカッション  QAメンバーはアドバイザーとして参加  チームで目指すQAの姿をディスカッション  QAメンバーはコーチとして参加し  トレーニングの計画も担当  52

Slide 53

Slide 53 text

タイミーでの代表的なプラットフォーム及びイネイブリングチーム  53 ● Agile Practiceチーム  ○ Process Enabling = 適応型開発の推進     ● QA Enablingチーム    ● Dev Platformチーム  ○ Platform Engineering  ○ Enabling Site Reliability Engineering     ● Dev Enableチーム  ○ 学習文化の推進  ○ エンジニアがエンジニアリングに集中するための環境と制度の提供   53

Slide 54

Slide 54 text

Dev Platformチームでのプラットフォーム性の例 Release Engineering  より素早く安全に機能をDeliveryでき、SAチームが自身で変更可能なCI/CD Pipelineを提供  SLI/SLO Metrics  SAチームがSLI/SLOを運用、メンテナンスできる仕組み（SLIの設定インターフェース、Dashboardなど）を提供   IaC  SAチームがコード(with Terraform/)で宣言的に定義するだけでインフラの開発運用をソフトウェアエンジニアリングできるIaC基盤を提供  Monitoring/Log  SAチームが自律的にObservability、アラート/モニタリングを向上できるようなPrimal Signal/Golden Signal収集基盤を提供  プラットフォーム性（Platform Engineerning）  54

Slide 55

Slide 55 text

Dev Platformチームでのイネイブリング性の例 SLI/SLO  信頼性指標を観測可能(定義・収集）にしSAチームが自らリライアビリティとアジリティに対して DataDrivenな判断や議論を行えるようにSLOの定義などをガイド  Monitoring/Alert  ユーザー体験を損なう原因となっている項目に対するモニタリングを、SAチームがAPMなどを含め追加できる (USE/REDなどのフレームワークを利用する)状態をリード   Incident Response  SAチームがユーザー影響、データ欠損などの事象に対する緊急対応を自律的に行え、コマンダーとしての役割も全うすることができる状態をリード  Capacity Planning  SAチームがメトリクスを元にシステム需要などを予測しコンピューティングリソースの追加を行うことができる状態をリード  Eliminating Toil  SAチームがトイルの定義に基づいてトイルを発見することができる状態をリード  イネイブリング性（Enabling Site Reliability Engineering）  55

Slide 56

Slide 56 text

タイミーでの代表的なプラットフォーム及びイネイブリングチーム  56 ● Agile Practiceチーム  ○ Process Enabling = 適応型開発の推進     ● QA Enablingチーム    ● Dev Platformチーム  ○ Platform Engineering  ○ Enabling Site Reliability Engineering     ● Dev Enableチーム  ○ 学習文化の推進  ○ エンジニアがエンジニアリングに集中するための環境と制度の提供   56

Slide 57

Slide 57 text

プロダクト開発メンバーの進化に特化した専門部署「 DevEnable室」開発組織の一人ひとりが能力とモチベーションを最大限発揮し続けるための環境づくりをMissionとした「DevEnable室」を設立。メンバーの学習機会の充実や、キャリアアップのサポートなどを通して「メンバーの進化」に伴走します。 57

Slide 58

Slide 58 text

10の新制度を運用開始［ TDE10（Timee Dev Enable）］プロダクト本部・エンジニアリング本部は、新しいプロダクトやサービスを創造するために必要な成長支援制度を運用し、メンバーのクリエイティビティを支えることを目指しています。「DevEnable室」と「10の新制度」をご紹介します。 58 詳しく見る

Slide 59

Slide 59 text

タイミーでのチームトポロジー実践例のポイント 59   ● ストリームアラインドチーム足りうるために不足ケイパビリティの自己診断や獲得をプロダクトエンジニア的な考え方やEMやSMの役割で継続強化している     ● 唯一絶対の静的なチーム構造やインタラクションで固定せず、ビジネスの状況やチームの成熟状況に応じてインタラクションモードだけでなくチームタイプも変える（プラットフォーム性とイネイブリング性）    ● プラットフォームチームとイネイブリングチームでは初手からX-as-a-Serviceやファシリテーション的な振る舞いを綺麗に行おうとせず、コラボレーションモードを意図的に用いてSAチームに深く関与（Embed）し、課題の把握と解決を担う   ケイパビリティとリソースの話、他チームから見た時のSAチームのケイパビリティと課題の把握、今日深掘らなかったコンウェイや境界面の話はまたどこかでお話しできれば...ご興味ある方は会場や懇親会、SNSなどで気軽に話しかけてください！  59

Slide 60

Slide 60 text

【宣伝】ブース出典しております！気軽にお立ち寄りください！！ノベリティも配布しております！  60 60

Slide 61

Slide 61 text

ご清聴ありがとうございました！  61