チームトポロジーから学び、 データプラットフォーム組織を考え直した話.pptx
•Download as PPTX, PDF•
0 likes•664 views
チームトポロジーというものがあります。 コンウェイの法則や認知負荷など様々な要素が組織論にはあり、チームトポロジーはそれらを組み合わせ、組織を設計するためのパターンを教えてくれます。 チームが価値創造に集中できるように、チームの役割を明確にし、コミュニケーションをデザインし、ボトルネックを見つけ出す。簡単に聞こえるけど、すごく難しいですよね？ 発表の中で、カジュアルにチームトポロジーの紹介と自分がどのように利用したかをご紹介します。
Report
Share
チームトポロジーから学び、 データプラットフォーム組織を考え直した話.pptx
- 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
- 6. 6 チームと仕事紹介 https://commerce-engineer.rakuten.careers/entry/branch/0002 >> “楽天 データプラットフォーム daigoro”で検索 ※ 2022/06/17 https://commerce-engineer.rakuten.careers/entry/branch/0002
- 8. 8 チームトポロジーとは システム、企業、 組織の成長や変化 組織拡大 パターン フローの実現 チーム チーム チーム 目的と責任の 明確化 コミュニケーシ ョンの最適化 継続的に変化に対処し 構造を変化させる 適応型の組織設計モデル さまざまな環境に応用できるパターン (だ）モチベーション高く、オーナーシップがあり、 早くデリバリーするチームを作る。 状況に応じてスケールしたり変化できるチーム構成や役割の明確化のパターンの学び
- 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が噛み合ってな いと、うまいこと仕事のフローが回らず 余計な時間がかかったりする。 将来のチーム構成を考慮して、初期段階か らコード分離を意識するのも大事かな。
- 15. 15 フロー 最初に目指すところサマリを説明 フローを優先するために学んだこと • システムと組織構造にズレを無くす （もしくは、やりたいシステムに組織構造を合わせる • チームがオーナーシップが持てるサイズの担当範囲 • チームの役割を明確にする • コミュニケーション必要性を最小限にする チーム チーム コンウェイの法則 認知負荷 ３つのドメインタイプ 4つのチームタイプ ３つのインタラクションモード
- 17. 17 どんな種類の認知負荷があるのか • 課題内在性負荷 • 業務への直接的なタスクの負荷 • 教育などで最小化したい • 課題外在性負荷 • 環境に依存して、考えなければいけない負荷 • できるだけ自動化などで少なくしたい • 学習関連負荷 • ビジネスドメインなどの学習負荷 • より価値提供のために、時間を増やしたい プログラミング プロジェクト管理 Release知識 デグレチェック テスト環境知識 新規技術理解 新機能要件理解 ※マシュー・スケルトン、マニュエル・パイス 2021年 チームトポロジー P47 日本能率協会マネジメントセンター
- 18. 18 認知負荷の考えとして大事なこと • チームの責任範囲や担当 (認知負荷)が広がると • コンテキストスイッチが多く発生する、生産的な仕事ができない • 優先順位がわからない、かつ、アウトプットが出ないので、モチベーション下がる • 細部を理解することが難しいので、コードなどに対しオーナーシップが低い • (だ) 経験則による悪いループ 1. プロダクトを理解するのに時間がかかる、１人前になるのに時間がかかる 2. 部分改善が進むが、全体を把握してない部分改善だらけで、より複雑になる 3. コードベース全体が管理できなくなりオーナーシップが低い 4. モチベーションが低くなり、辞める。 1に戻る。
- 19. 19 認知負荷を考慮するためのドメインモデル ３つに分類されるドメインで、チームが抱えてる認知負荷を図る • シンプルドメイン • タスクが明確。変更を簡単に行うことが可能 • 例) Simple なWebUI, 理解が簡単なビジネスロジック • 煩雑ドメイン • 変更に対して分析が複雑であり、簡単には解決できない • 例) 影響の多い基盤システム • 複雑ドメイン • 解決には複数回の実験と探索が必要 • 例) 機械学習、プラットフォームのコア部分の改善 基本的には、２つ以上の煩雑もしくは複雑をチームが持たないようにする 複雑ドメイン 煩雑ドメイン シンプル ドメイン ※マシュー・スケルトン、マニュエル・パイス 2021年 チームトポロジー P51 日本能率協会マネジメントセンター
- 20. 20 フロー 最初に目指すところサマリを説明 フローを優先するために学んだこと • システムと組織構造にズレを無くす （もしくは、やりたいシステムに組織構造を合わせる • チームがオーナーシップが持てるサイズの担当範囲 • チームの役割を明確にする • コミュニケーション必要性を最小限にする チーム チーム コンウェイの法則 認知負荷 ３つのドメインタイプ 4つのチームタイプ ３つのインタラクションモード
- 21. 21 チームは４つのタイプに分類 各チームの役割をこの４つのどれかに当てはめることで、役割を明確化できる。 • ストリームアラインドチーム • ドメイン課題を解決することに集中するチーム ほとんどのチームはこれに該当する • イネイブリングチーム • 特殊な技術等をチームで可能にする先生チーム チームに技術を教えチームのスキルを強化していく • コンプリケイテッド・サブシステムチーム • 複雑なドメインを集中して扱うチーム • プラットフォームチーム • 共通して使うプラットフォームを提供するチーム ランキングチーム、 売上レポートチーム、 SREチーム スクラム、テスト、 DevOpsのコーチングチーム 機械学習チーム、COBOLチーム データプラットフォームチーム ログプラットフォーム ※マシュー・スケルトン、マニュエル・パイス 2021年 チームトポロジー P95 日本能率協会マネジメントセンター
- 22. 22 フロー 最初に目指すところサマリを説明 フローを優先するために学んだこと • システムと組織構造にズレを無くす （もしくは、やりたいシステムに組織構造を合わせる • チームがオーナーシップが持てるサイズの担当範囲 • チームの役割を明確にする • コミュニケーション必要性を最小限にする チーム チーム コンウェイの法則 認知負荷 ３つのドメインタイプ 4つのチームタイプ ３つのインタラクションモード
- 23. 23 ３つのインタラクションモード それぞれのチームのコミュニケーションコストを十分かつ最低限にすることが重要である。 基本的に３つのインタラクションモードに切り分けることができる インタラクションモード • コラボレーション • 同一の目標のために１時的に、綿密な協業を行う • X-as-a-Service • 基本ドキュメントのやり取りのみ • プラットフォームチームとのやりとり • ファシリテーション • イネイブリングチームがコーチングのときに行う X-as-a-Service コラボレーション ファシリテーション ※マシュー・スケルトン、マニュエル・パイス 2021年 チームトポロジー P164 日本能率協会マネジメントセンター
- 24. 24 フロー 最初に目指すところサマリを説明 フローを優先するために学んだこと • システムと組織構造にズレを無くす （もしくは、やりたいシステムに組織構造を合わせる • チームがオーナーシップが持てるサイズの担当範囲 • チームの役割を明確にする • コミュニケーション必要性を最小限にする チーム チーム コンウェイの法則 認知負荷 ３つのドメインタイプ 4つのチームタイプ ３つのインタラクションモード
- 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 チームトポロジーの知識をもとに、議論し、実践したこと • 現状の把握 • 認知負荷をドメインとチームのマッピングで把握 • 考えられる理想を描く • 最適なドメインとチームの構成を定義 • 認知負荷の考慮 • チームタイプの定義 • コミュニケーションの意識 • フローの意識 • 現実的な最初の１歩目を決める
- 34. 34 チームトポロジーの知識をもとに、議論し、実践したこと • 現状の把握 • 認知負荷をドメインとチームのマッピングで把握 • 考えられる理想を描く • 最適なドメインとチームの構成を定義 • 認知負荷の考慮 • チームタイプの定義 • コミュニケーションの意識 • フローの意識 • 現実的な最初の１歩目を決める
- 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
- 39. 39 チームトポロジーの知識をもとに、議論し、実践したこと • 現状の把握 • 認知負荷をドメインとチームのマッピングで把握 • 考えられる理想を描く • 最適なドメインとチームの構成を定義 • 認知負荷の考慮 • チームタイプの定義 • コミュニケーションの意識 • フローの意識 • 現実的な最初の１歩目を決める
- 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の運用は 複雑かつ生産性に響く ので専属組織がほしい 根幹の改善に集中 より多くのデータを安 心安全に
- 46. 46 思い出しタイム
- 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つのチームタイプ ３つのインタラクションモード コミュニケーションのあり方を考える • 不必要なコミュニケーションを減らす • 価値創造のためのコミュニケーションを作る チーム チーム チーム チーム
- 50. 50 思い出しタイム
- 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 基本的にはドキュメン トでやり取り 必要に応じて学習サポート 依存が多いのでドキュ メントでやり取りでき る方が良い プラットフォームチームはサ ービス観点を失いがちなので 、新機能開発・既存の改善時 にはコラボレーションが有効 例) デザインスプリント
- 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. ↑フローを止める要因の可能性 ただ、巨大な１チームのときより フットワークは軽そう
- 60. 60 チームトポロジーの知識をもとに、議論し、実践したこと • 現状の把握 • 認知負荷をドメインとチームのマッピングで把握 • 考えられる理想を描く • 最適なドメインとチームの構成を定義 • 認知負荷の考慮 • チームタイプの定義 • コミュニケーションの意識 • フローの意識 • 現実的な最初の１歩目を決める
- 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 最初の状態と比べると
- 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 • 内部便利ツール開発
- 72. 72
Editor's Notes
- “システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう”
- “システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう”
- “システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう”
- 基準としては、複雑、煩雑ドメインを分ける。 ユーザコミュニケーションを専属チームに分ける。 成長させたいモジュールはシンプルのみでも、分ける