チームトポロジーから学び、データプラットフォーム組織を考え直した話.pptx

1. チームトポロジーから学び、データプラットフォーム組織を考え直した話 June 18th, 2022 Daigoro CCBD Rakuten Group, Inc.

2. 2 導入トーク皆さん、チーム、自分(自分のメンバーが) モチベーションもあり、アウトプットもある状態ってどういう状態でしたか？それはどんなチームでしたか？チーム活動してる。モブプロや振り返りチームにメンバーが沢山ドキュメントや要件定義が明確

3. 3 今からの時間は今日は、皆さんと、ともに学ぶ４５分なぜ、そうなるのか、何が要因なのか、一緒に気づいて、考えて、なにか、一つでもおぼえていっていただければなと

4. 4 自己紹介 Name : だいごろ (DaisukeWatanabe) Group : Business Data platform Group, Manager Job : Engineer Manger for Data Platform Favorite Language : Scala InterestTech : DevOps / BigData / Programming Language Placed : Osaka > Paris >Tokyo > Fukuoka ※ 2014/08/23

5. 5 2014年にあれもしたいこれもしたいと言ってました 2014年 2022年現在ヒーラー兼魔法戦士 + メンバーが全力活躍できる基盤とサポート

6. 6 チームと仕事紹介 https://commerce-engineer.rakuten.careers/entry/branch/0002 >> “楽天データプラットフォーム daigoro”で検索 ※ 2022/06/17 https://commerce-engineer.rakuten.careers/entry/branch/0002

7. 7 チームトポロジーって何？ ※ 2022/05/17 https://books.rakuten.co.jp/rb/16928954/?l-id=search-c-item-text-01 正直、本を読むのが一番今日は、僕なりのカジュアルな解釈とその上で、どうしたかをお話したい。

8. 8 チームトポロジーとはシステム、企業、組織の成長や変化組織拡大パターンフローの実現チームチームチーム目的と責任の明確化コミュニケーションの最適化継続的に変化に対処し構造を変化させる適応型の組織設計モデルさまざまな環境に応用できるパターン (だ）モチベーション高く、オーナーシップがあり、早くデリバリーするチームを作る。状況に応じてスケールしたり変化できるチーム構成や役割の明確化のパターンの学び

9. 9 フローの理解が重要より早くソフトウェアをデリバリーすることは重要（だ）フローとは、問題を解決するための流れのようなことそれが実現可能なチームのフロー作りに注力することが重要である（だ）スクラムもDevOpsもより早くサイクルを回しFBを早く得ることを根幹としているでは、チームが早いフローを実現するためには何が重要なのか？複雑になるドメインやソフトウェアにおいてどんな依存関係を作る（作らない）のことが重要なのか？システム構成とチーム構成のどんな状態であるべきなのか？チームチームチーム

10. 10 速いフローを阻害する障害 • コンウェイの法則への対抗 • 組織設計の選択による混乱 • チームが引っ張りだこ • チームにとって大きすぎるソフトウェア • 不足の事態の多発 • モチベーションの低いチーム • ブロックされてるフロー • 数年ごとの苦痛な組織再編 ※マシュー・スケルトン、マニュエル・パイス 2021年チームトポロジーP14 日本能率協会マネジメントセンターチームチームチーム

11. 11 フロー最初に目指すところサマリを説明フローを優先するために学んだこと • システムと組織構造にズレを無くす（もしくは、やりたいシステムに組織構造を合わせる • チームがオーナーシップが持てるサイズの担当範囲 • チームの役割を明確にする • コミュニケーション必要性を最小限にするチームチームコンウェイの法則認知負荷３つのドメインタイプ 4つのチームタイプ３つのインタラクションモード

12. 12 コンウェイの法則 “システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう” ※ 2022/05/30 https://www.melconway.com/Home/pdf/committees.pdf Front Team Backend Team DBA Ope UI Server Side DB Ope tools org system Front Team Backend Team UI Server Side

13. 13 コンウェイの法則 “システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう” Front Team Backend Team DBA Ope UI Server Side DB Ope tools org system Front Team Backend Team UI Server Side 逆コンウェイの法則作りたいシステム構成を意識して、それに合わせた組織を先に作ること例えば、マイクロサービス化したければ、それぞれのドメイン等に分けてチームを分けておく。 ※ 2022/05/30 https://www.melconway.com/Home/pdf/committees.pdf

14. 14 ※ 2022/05/30 https://www.melconway.com/Home/pdf/committees.pdf コンウェイの法則 “システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう” Front Team Backend Team DBA Ope UI Server Side DB Ope tools org system Front Team Backend Team UI Server Side 逆コンウェイの法則作りたいシステム構成を意識して、それに合わせた組織を先に作ること例えば、マイクロサービス化したければ１つのチームにできるメンバーを集めるこのチーム構成とSystemが噛み合ってないと、うまいこと仕事のフローが回らず余計な時間がかかったりする。将来のチーム構成を考慮して、初期段階からコード分離を意識するのも大事かな。

16. 16 認知負荷認知負荷は、ワーキングメモリにかかる負荷のこと一人の認知負荷には限界があり、同じことがチームにも言える Javaのコードの書き方、メソッドの命名規則どこでテストすればよいのか？なにが気をつけるポイントか？どんなビジネスなのか、課題は何なのか？チームは、昔からのシステムと新しいシステム両方を全部開発運用サービスも大きくなった。チームも全部扱えるように大きくなった。

17. 17 どんな種類の認知負荷があるのか • 課題内在性負荷 • 業務への直接的なタスクの負荷 • 教育などで最小化したい • 課題外在性負荷 • 環境に依存して、考えなければいけない負荷 • できるだけ自動化などで少なくしたい • 学習関連負荷 • ビジネスドメインなどの学習負荷 • より価値提供のために、時間を増やしたいプログラミングプロジェクト管理 Release知識デグレチェックテスト環境知識新規技術理解新機能要件理解 ※マシュー・スケルトン、マニュエル・パイス 2021年チームトポロジー P47 日本能率協会マネジメントセンター

18. 18 認知負荷の考えとして大事なこと • チームの責任範囲や担当 (認知負荷)が広がると • コンテキストスイッチが多く発生する、生産的な仕事ができない • 優先順位がわからない、かつ、アウトプットが出ないので、モチベーション下がる • 細部を理解することが難しいので、コードなどに対しオーナーシップが低い • (だ) 経験則による悪いループ 1. プロダクトを理解するのに時間がかかる、１人前になるのに時間がかかる 2. 部分改善が進むが、全体を把握してない部分改善だらけで、より複雑になる 3. コードベース全体が管理できなくなりオーナーシップが低い 4. モチベーションが低くなり、辞める。 1に戻る。

19. 19 認知負荷を考慮するためのドメインモデル３つに分類されるドメインで、チームが抱えてる認知負荷を図る • シンプルドメイン • タスクが明確。変更を簡単に行うことが可能 • 例) Simple なWebUI, 理解が簡単なビジネスロジック • 煩雑ドメイン • 変更に対して分析が複雑であり、簡単には解決できない • 例) 影響の多い基盤システム • 複雑ドメイン • 解決には複数回の実験と探索が必要 • 例) 機械学習、プラットフォームのコア部分の改善基本的には、２つ以上の煩雑もしくは複雑をチームが持たないようにする複雑ドメイン煩雑ドメインシンプルドメイン ※マシュー・スケルトン、マニュエル・パイス 2021年チームトポロジー P51 日本能率協会マネジメントセンター

21. 21 チームは４つのタイプに分類各チームの役割をこの４つのどれかに当てはめることで、役割を明確化できる。 • ストリームアラインドチーム • ドメイン課題を解決することに集中するチームほとんどのチームはこれに該当する • イネイブリングチーム • 特殊な技術等をチームで可能にする先生チームチームに技術を教えチームのスキルを強化していく • コンプリケイテッド・サブシステムチーム • 複雑なドメインを集中して扱うチーム • プラットフォームチーム • 共通して使うプラットフォームを提供するチームランキングチーム、売上レポートチーム、 SREチームスクラム、テスト、 DevOpsのコーチングチーム機械学習チーム、COBOLチームデータプラットフォームチームログプラットフォーム ※マシュー・スケルトン、マニュエル・パイス 2021年チームトポロジー P95 日本能率協会マネジメントセンター

23. 23 ３つのインタラクションモードそれぞれのチームのコミュニケーションコストを十分かつ最低限にすることが重要である。基本的に３つのインタラクションモードに切り分けることができるインタラクションモード • コラボレーション • 同一の目標のために１時的に、綿密な協業を行う • X-as-a-Service • 基本ドキュメントのやり取りのみ • プラットフォームチームとのやりとり • ファシリテーション • イネイブリングチームがコーチングのときに行う X-as-a-Service コラボレーションファシリテーション ※マシュー・スケルトン、マニュエル・パイス 2021年チームトポロジー P164 日本能率協会マネジメントセンター

25. 25 私たちの仕事社内の分析基盤売上のダッシュボードデータ連携出店店舗様社内スタッフ他サービス * 2022/05/17 https://www.rakuten.co.jp/ * 2022/06/17 https://www.rakuten.co.jp/ec/environment/service/analysis データを社内外の様々なサービスで再活用するためのデータパイプラインや基盤を開発/運用するお仕事。

26. 26 私たちの仕事社内の分析基盤売上のダッシュボードデータ連携出店店舗様社内スタッフ他サービスここらへんデータを社内外の様々なサービスで再活用するためのデータパイプラインや基盤を開発/運用するお仕事。 * 2022/05/17 https://www.rakuten.co.jp/ * 2022/06/17 https://www.rakuten.co.jp/ec/environment/service/analysis

27. 27 データの規模感国内EC流通総額 > 5兆円(as of 2021) 商品数数億こいつが膨大な量の更新を受け取っている。 ※ 2022/05/17 https://corp.rakuten.co.jp/news/press/2022/0104_03.html

28. 28 2012年ごろフロントDB Hive on Hadoop Main Hist Tables CSV Output files CSV CSV CSV Tables Tables Tables JSON toTable HISTデータ作成様々な加工チーム数百種類のoutputファイル数多くの開発チームさらに多いデータ利用者シビアなSLA

29. 29 2016年ごろフロントDB Hive on Hadoop Main Hist Tables CSV Output files CSV CSV CSV Tables Tables Tables API チームチーム API nize automation API team

30. 30 その後もユーザーはどんどん増えるフロントDB Hive on Hadoop Main Hist Tables CSV Output files CSV CSV CSV Tables Tables Tables API どんどん増えるチームどんどん増えるチーム

31. 31 2021年からフロントDB Mirror Data Feeder Raw Raw Formatted Hive on Hadoop Main Hist Tables CSV Output files CSV CSV CSV Tables Tables Tables API チームチームデータ欠損ダメ複雑なネットワーク構成膨大な更新データ様々な種類のデータロード

32. 32 ツラミとして、実際に起きていたことプロダクトに安定（改善できてない）煩雑なものが大量にある - 少しの変更でも多くの影響をもつコードも多い - 調査がメインで、コードの変更は数行 - 改善するPRJが立ち上がるが、他の優先度で何度も停止 - 新規の開発モジュールも増加プラットフォームは多くの価値を提供している！ - 数百人のユーザからシステムの利用方法の問い合わせが来る - 変更をするのに数百人のユーザを巻き込む必要があるメンバー - 改善の意思はあるが、システムが大きすぎて、改善途中のものだらけ - 必要なスキルのカテゴリが多すぎて、採用が難しい - 全体像を把握し１人前になるのに数年かかる

33. 33 チームトポロジーの知識をもとに、議論し、実践したこと • 現状の把握 • 認知負荷をドメインとチームのマッピングで把握 • 考えられる理想を描く • 最適なドメインとチームの構成を定義 • 認知負荷の考慮 • チームタイプの定義 • コミュニケーションの意識 • フローの意識 • 現実的な最初の１歩目を決める

35. 35 思い出しタイム

36. 36 1-1.システムに存在しているドメインを把握するフロントDB Mirror Data Feeder Raw Raw Formatted Hive on Hadoop Main Hist Tables CSV Output files CSV CSV CSV Tables Tables Tables API 複雑ドメイン煩雑ドメインシンプルドメイン Stream Data Pipeline Realtime Data Monitoring Stream Data Transform Platform Operation Platform Monitoring Transform Module Load Module AdminWeb AccessWeb AdminAPI Load(API) Module API Core API Monitoring Platform Enabling API Enabling Platform Support API Support チームチーム Data Platform Core

37. 37 1-2. ドメインを利用してチームの状態を把握フロントDB Mirror Data Feeder Raw Raw Formatted Hive on Hadoop Main Hist Tables CSV Output files CSV CSV CSV Tables Tables Tables API 複雑ドメイン煩雑ドメインシンプルドメイン Stream Data Pipeline Realtime Data Monitoring Stream Data Transform Platform Operation Platform Monitoring Transform Module Load Module AdminWeb AccessWeb AdminAPI Load(API) Module API Core API Monitoring Platform Enabling API Enabling Platform Support API Support チームチーム Data Platform Core DataAPI Team Data Platform

38. 38 1-2. ドメインを利用してチームの状態を把握複雑ドメイン煩雑ドメインシンプルドメイン Team Platform Operation Platform Monitoring Realtime Data Monitoring Stream Data Pipeline Platform Enabling Data Platform Transform Module Load Module Data Platform Core AdminWeb AccessWeb AdminAPI DataAPI API Enabling Load (API) Module API Core API Monitoring Stream Data Transform Platform Support API Support

40. 40 認知負荷を考慮した組織図を書くフローチームチームチーム認知負荷３つのドメインタイプ 4つのチームタイプ３つのインタラクションモード

41. 41 認知負荷を考慮した組織図を書くフローチームチームチームチームチーム認知負荷３つのドメインタイプ 4つのチームタイプ３つのインタラクションモード認知負荷の調整 • プロダクトとコードにオーナーシップが持てるようにする • 改善モチベーションが生まれる時間と余裕を作る

42. 42 複雑ドメイン煩雑ドメインシンプルドメイン Team Platform Operation Platform Monitoring Realtime Data Monitoring Stream Data Pipeline Platform Enabling Data Platform Transform Module Load Module Data Platform Core AdminWeb AccessWeb AdminAPI DataAPI API Enabling Load (API) Module API Core API Monitoring Stream Data Transform Platform Support API Support 2-1. 認知負荷を考慮したドメインとチームのマッピング

43. 43 2-1. 認知負荷を考慮したドメインとチームのマッピング複雑ドメイン煩雑ドメインシンプルドメイン Team SRE Platform Operation Platform Monitoring Realtime Data Monitoring Stream Data Pipeline Platform Enabling Data Platform Transform Module Load Module Data Platform Core AdminWeb AccessWeb AdminAPI DataAPI API Enabling Load (API) Module API Core API Monitoring Stream Data Transform Platform Support API Support Data Flow PF Enabling Platform Experience

44. 44 2-1. 認知負荷を考慮したドメインとチームのマッピング複雑ドメイン煩雑ドメインシンプルドメイン Team SRE Platform Operation Platform Monitoring Realtime Data Monitoring Stream Data Pipeline Platform Enabling Data Platform Transform Module Load Module Data Platform Core AdminWeb AccessWeb AdminAPI DataAPI API Enabling Load (API) Module API Core API Monitoring Stream Data Transform Platform Support API Support Data Flow PF Enabling Platform Experience ドキュメントが不十分で問い合わせが多い。技術的支援が必要便利系は改善が後回しになりがちだが、生産性の向上に必須 PFが多チームに渡るので問い合わせの一本化 DataPlatformの運用は複雑かつ生産性に響くので専属組織がほしい根幹の改善に集中より多くのデータを安心安全に

45. 45 チームタイプの定義フローチームチーム認知負荷３つのドメインタイプ 4つのチームタイプ３つのインタラクションモードチームタイプを定義 • チームへの期待値を明確にするチームチームチームチーム

47. 47 2-2. 認知負荷を考慮したドメインとチームのマッピング複雑ドメイン煩雑ドメインシンプルドメイン Team SRE Platform Operation Platform Monitoring Realtime Data Monitoring Stream Data Pipeline Platform Enabling Data Platform Transform Module Load Module Data Platform Core AdminWeb AccessWeb AdminAPI DataAPI API Enabling Load (API) Module API Core API Monitoring Stream Data Transform Platform Support API Support Data Flow PF Enabling Platform Experience ストリームアラインドコンプリケイテッドサブシステムイネイブリングプラットフォーム

48. 48 2-2. 認知負荷を考慮したドメインとチームのマッピング複雑ドメイン煩雑ドメインシンプルドメイン Team SRE Platform Operation Platform Monitoring Realtime Data Monitoring Stream Data Pipeline Platform Enabling Data Platform Transform Module Load Module Data Platform Core AdminWeb AccessWeb AdminAPI DataAPI API Enabling Load (API) Module API Core API Monitoring Stream Data Transform Platform Support API Support Data Flow PF Enabling Platform Experience ストリームアラインドコンプリケイテッドサブシステムイネイブリングプラットフォームまだユーザ提供という段階でない。ユーザサポートとトレーニングを中心に行うコア改善に集中 Platformユーザの快適さの価値を届けるフローに集中運用改善のフローに集中

49. 49 インタラクションモードの設計フローチームチーム認知負荷３つのドメインタイプ 4つのチームタイプ３つのインタラクションモードコミュニケーションのあり方を考える • 不必要なコミュニケーションを減らす • 価値創造のためのコミュニケーションを作るチームチームチームチーム

51. 51 2-3. インタラクションモードの設計複雑ドメイン煩雑ドメインシンプルドメイン Team SRE Platform Operation Platform Monitoring Realtime Data Monitoring Stream Data Pipeline Platform Enabling Data Platform Transform Module Load Module Data Platform Core AdminWeb AccessWeb AdminAPI DataAPI API Enabling Load (API) Module API Core API Monitoring Stream Data Transform Platform Support API Support Data Flow PF Enabling Platform Experience ストリームアラインドコンプリケイテッドサブシステムイネイブリングプラットフォーム

52. 52 2-3. インタラクションモードの設計 SRE Data Platform DataAPI Data Flow PF Enabling ストリームアラインドコンプリケイテッドサブシステムイネイブリングプラットフォーム X-as-a-Service コラボレーションファシリテーション Service A Service B Service C Platform Experience プラットフォームユーザ

53. 53 2-3. インタラクションモードの設計 SRE Data Platform DataAPI Data Flow PF Enabling ストリームアラインドコンプリケイテッドサブシステムイネイブリングプラットフォーム X-as-a-Service コラボレーションファシリテーション Service A Service B Service C Platform Experience

54. 54 2-3. インタラクションモードの設計 SRE Data Platform DataAPI Data Flow PF Enabling ストリームアラインドコンプリケイテッドサブシステムイネイブリングプラットフォーム X-as-a-Service コラボレーションファシリテーション Service A Service B Service C Platform Experience 基本的にはドキュメントでやり取り必要に応じて学習サポート依存が多いのでドキュメントでやり取りできる方が良いプラットフォームチームはサービス観点を失いがちなので、新機能開発・既存の改善時にはコラボレーションが有効例) デザインスプリント

55. 55 フローフローインタラクションモードの設計フローチームチーム認知負荷３つのドメインタイプ 4つのチームタイプ３つのインタラクションモード Platformチームのフローを考える Serviceチームのフローを考えるチームチームチームチーム

56. 56 1) Platformチームのフローを確認する Platformチームのフロー • インタラクション • ドキュメントベースで各チームとやり取り • PF Enablingチームがサポートと教育の負荷を代替 • コラボレーションして開発をすすめる • 新規データパイプライン with Data Flow • 運用改善 with SRE • 新規開発 • 基本ドキュメント更新 • 大きな変更管理はPF Enablingとユーザ調整

57. 57 1) Serviceチームのフローを確認する例えば、データを変換して、API経由で、UIでエンドユーザに見せたいときユーザのフロー 1. (User) データを集める • ドキュメントを読めばOK • 必要に応じてEnablingチームにトレーニングを受ける 2. (User) 集計ロジックを作る • 必要に応じてEnablingチームに聞く 3. (User) APIにデータを転送する • 新規APIFunctionが必要な場合コラボ 4. (User) UIにAPIからデータを表示する

58. 58 2) Serviceチームのフローを確認する例えば、新規ドメインのデータを集め、APIを提供するミッションのチームがいる場合ユーザのフロー 1. 様々なデータを集める • ドキュメントを読めばOKだが。 • 新規のデータラインの場合DataPlatformチームとコラボが多く必要 • ↑フローを止める要因の可能性 2. APIの機能を増やす 1. DataAPIチームとコラボが必要 1. ↑フローを止める要因の可能性

59. 59 2) Serviceチームのフローを確認する例えば、新規ドメインのデータを集め、APIを提供するミッションのチームがいる場合ユーザのフロー 1. 様々なデータを集める • ドキュメントを読めばOKだが。 • 新規のデータラインの場合DataPlatformチームとコラボが多く必要 • ↑フローを止める要因の可能性 2. APIの機能を増やす 1. DataAPIチームとコラボが必要 1. ↑フローを止める要因の可能性ただ、巨大な１チームのときよりフットワークは軽そう

61. 61 3-1. ファーストステップを決める(理想) 複雑ドメイン煩雑ドメインシンプルドメイン Team SRE Platform Operation Platform Monitoring Realtime Data Monitoring Stream Data Pipeline Platform Enabling Data Platform Transform Module Load Module Data Platform Core AdminWeb AccessWeb AdminAPI DataAPI API Enabling Load (API) Module API Core API Monitoring Stream Data Transform Platform Support API Support Data Flow PF Enabling Platform Experience ストリームアラインドコンプリケイテッドサブシステムイネイブリングプラットフォーム

62. 62 3-1. ファーストステップを決める(１歩目) 複雑ドメイン煩雑ドメインシンプルドメイン Team SRE Platform Operation Platform Monitoring Realtime Data Monitoring Stream Data Pipeline Platform Enabling Transform Module Load Module Data Platform Core AdminWeb AccessWeb AdminAPI DataAPI API Enabling Load (API) Module API Core API Monitoring Stream Data Transform Platform Support API Support Data Flow PF Enabling Platform Experience ストリームアラインドコンプリケイテッドサブシステムイネイブリングプラットフォーム Data Platform

63. 63 3-1. ファーストステップを決める(１歩目) 複雑ドメイン煩雑ドメインシンプルドメイン Team SRE Platform Operation Platform Monitoring Realtime Data Monitoring Stream Data Pipeline Platform Enabling Transform Module Load Module Data Platform Core AdminWeb AccessWeb AdminAPI DataAPI API Enabling Load (API) Module API Core API Monitoring Stream Data Transform Platform Support API Support Data Flow PF Enabling Platform Experience ストリームアラインドコンプリケイテッドサブシステムイネイブリングプラットフォーム Data Platform 技術的に難しく分離可能なものを分ける大きく依存も多く、分離も難しいため、わけないまずは、Enablingチームのトレーニングをしていく全体でフローがうまくいくかをまずは検証

64. 64 最初の状態と比べると

65. 65 改めて導入トークみなさん、チーム、自分(自分のメンバーが) モチベーションもあり、アウトプットもある状態ってどういう状態でしたか？それはどんなチームでしたか？チームにメンバーが沢山ドキュメントや要件定義が明確チーム活動してる。モブプロや振り返り

66. 66 改めて導入トークみなさん、チーム、自分(自分のメンバーが) モチベーションもあり、アウトプットもある状態ってどういう状態でしたか？それはどんなチームでしたか？チームにメンバーが沢山ドキュメントや要件定義が明確チーム活動してる。モブプロや振り返りアーキテクチャの形と組織図が合う。 + 役割が明確で、チームが管理できる量のドメインである + コミュニケーションの必要性は正しく設計されている開発するときに、最低限のコミュニケーションで価値を出せる = 開発フローが阻害されず、チームがオーナーシップを持っており、モチベーションを持っている

67. 67 ただ、みなさん、こういうことないですか？普段の業務と関わりがないやり取りに価値があった • 別チームの知り合いがいていい情報をくれた • 一緒に学習する仲間がいたので、技術を採用できた案外成功したときに必要だったのは、チーム外コミュニケーションが有効だったりしません？フロー重視しすぎて、横のつながりが希薄になると実はそれはそれで問題。それを改善するために、僕らはこんな活動もしています。 • Guild • TechOffice • Labday

68. 68 自分が組織にしていたこと紹介 Guild(ギルド): チームやグループをまたいで、同じテーマで学びたい人を、ギルドという単位でまとめ、週1程度集まって学び合います。 Chopter Chopter Tribe Chopter Tribe Community > Structure Chopter Guild ギルド例： • テクニカルスキル • ピープルマネジメントスキル • プロジェクトマネジメントスキル • ソフトスキル • 日本語スキル出典: https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf

69. 69 自分が組織にしていたこと紹介 Tech Office : 250名以上の組織の中で、エンジニアとニーズを結びつけ、ビジネスチャンスとエンジニアの価値を最大化する組織横断型のコミュニティ Tech Office 例： • Architect Office • Data Office • DevOps Office XXX Office 開発組織先生生徒相談 & 学ぶ知見を共有現場で活用する

70. 70 自分が組織にしていたこと紹介 Lab Day: 新しい技術にチャレンジしたり、今のプロジェクトや日々の作業の改善活動を1日で行う。 • アイディアを貯める • 新しい技術を見つける Daily working • アイディアを実現する LabDay • 結果を活用する • 新しいアイディアを見つける Daily Working Lab Day例： • SQLチューニング • Dockerでアプリを動かす • Tableauで視覚化してみる • OSSに新規機能追加PR • 内部便利ツール開発

71. 71 宣伝楽天グループ大阪支社でミートアップイベントをやります。

72. 72

チームトポロジーから学び、データプラットフォーム組織を考え直した話.pptx

チームトポロジーから学び、データプラットフォーム組織を考え直した話.pptx

Recommandé

Contenu connexe

Tendances

Tendances(20)

Similaire à チームトポロジーから学び、データプラットフォーム組織を考え直した話.pptx

Similaire à チームトポロジーから学び、データプラットフォーム組織を考え直した話.pptx(20)

Plus de Rakuten Commerce Tech (Rakuten Group, Inc.)

Plus de Rakuten Commerce Tech (Rakuten Group, Inc.)(6)

Dernier

Dernier(8)