フロントエンド横断組織のチームトポロジー/20230208_kunieda

Slide 1

Slide 1 text

Slide 2

Slide 2 text

#RAKUSTechCon 國枝洋志  メーカーで医療系のシステム開発・運用を経験した後、SIerとして主に官公庁・公共系システムのWebアプリ開発を経験。  その後、マネージャーとして自社サービス開発や開発標準を推進。  2022年にラクスに入社し、新組織のフロントエンド開発課の  マネージャーを担当。  会社のe-Sportsサークルに所属。  好きなゲームはスプラトゥーンですが、そろそろPS VR2が発売になるので、そちらも楽しみにしています。 

Slide 3

Slide 3 text

#RAKUSTechCon ラクスにはどんなサービスがあるか  ご存知でしょうか？ 

Slide 4

Slide 4 text

#RAKUSTechCon ラクスのサービスとフロントエンドの技術スタック  20年以上、様々なサービスを提供し続けています。以下はサービスの一部です。  サービス名  リリース  フロントエンドの技術スタック  開発拠点    　　　　　経費精算システム   2009年07月  JSP、jQuery  東京    　　　　　WEB帳票発行システム   2013年08月  JSP、jQuery、React、TypeScript    　　　　　勤怠管理システム   2020年10月  Vue.js、TypeScript    　　　　　電子帳簿保存システム   2022年04月  React、TypeScript    　　　　　販売管理業務システム   2008年10月  PHP、jQuery  大阪    　　　　　メール共有・管理システム   2001年04月  PHP、jQuery、Vue.js、TypeScript    　　　　　メルマガ配信システム   2007年05月  PHP、jQuery、Vue.js    　　　　　Webチャットシステム   2017年07月  PHP、jQuery、Vue.js  ※赤字は後から導入したもの  

Slide 5

Slide 5 text

#RAKUSTechCon フロントエンド開発課発足前の話 

Slide 6

Slide 6 text

#RAKUSTechCon 開発本部  東京拠点  大阪拠点  東京インフラ開発課  大阪インフラ開発課  楽楽精算開発部  楽楽明細開発部  楽楽販売開発課  メールディーラー開発課  配配メール開発課  チャットディーラー開発課  開発組織（フロントエンド開発課発足前）  サービスごとに開発組織は分かれていました。 

Slide 7

Slide 7 text

#RAKUSTechCon フロントエンド開発課発足の背景  各サービスでフロントエンドエンジニアの育成が出来ない  レガシーなフロントエンドでは、   デザイン通りの実装が実現できないケースが多い  レガシーなフロントエンドは、   コードが煩雑で改修の影響調査に時間が掛かる   モダンなフロントエンド開発経験が無いため、   実装に時間が掛かってしまい、バックエンドとの両立が厳しい   ラクスが抱えていたフロントエンドの問題点  年々高まるUI/UXの要求  リードタイム短縮  生産性の向上  フロントエンドの  スキルアップ／品質向上 

Slide 8

Slide 8 text

Slide 9

Slide 9 text

#RAKUSTechCon 開発本部  東京拠点  大阪拠点  東京インフラ開発課  大阪インフラ開発課  楽楽精算開発部  楽楽勤怠開発部  楽楽明細開発部  楽楽販売開発課  メールディーラー開発課  配配メール開発課  チャットディーラー開発課  開発組織（UI開発課（フロントエンドチーム）発足後）  UI開発課  （UIデザイン／   フロントエンド）   横断組織としてフロントエンド問題解決の取り組みを開始しました 

Slide 10

Slide 10 text

#RAKUSTechCon サービスごとに問題は異なる  サービス名  問題    ● CSSが管理出来ていない、肥大化   ● HTMLのネストが深く複雑  ● 膨大になったJavaScriptの影響調査、修正に時間が掛かる   （フロントエンドの開発がボトルネックになっている）  ● 機能開発が優先されるためUI改善にリソースを割けない    ● 新サービスはFE/BEを分離して開発をしたいが、社内でノウハウが無い   ● モダンなフロントエンドの開発経験者が少ない     ● 動的生成されるHTML/JavaScriptにより可読性が悪い  ● CSSファイルの肥大化  ● モダンフロントエンドの開発実績が無い    ● CSSが管理出来ていない   ● jQueryとVue.jsが混在している  ● モダンフロントエンドの開発実績が少ない     ● CSSが管理出来ていない、肥大化   ● レガシー技術では実現困難なUI要望が増えている  

Slide 11

Slide 11 text

#RAKUSTechCon 凡例  　　中途  　　新卒  サービス名  採用人数  2019  2020  2021  ～2022/4            UI開発課（フロントエンドチーム）の歩み  新サービスの楽楽勤怠の開発参画を皮切りに、徐々に活動範囲を広げてきました  楽楽勤怠開発に  特化して開発を  高速化するため、   4月に組織を分離 

Slide 12

Slide 12 text

#RAKUSTechCon 凡例  　　中途  　　新卒  サービス名  採用人数  2019  2020  2021  ～2022/4          UI開発課（フロントエンドチーム）の歩み  楽楽勤怠メンバーの分離により 14名 → 6名に 

Slide 13

Slide 13 text

#RAKUSTechCon 2022年5月にUI開発課は  フロントエンド開発課・プロダクトデザイン課に分離  （ここで私は入社しました） 

Slide 14

Slide 14 text

#RAKUSTechCon 引き継いだときの状況  フロントエンド開発課   ラクスシリーズチーム   楽楽明細チーム   1名体制  4名体制  國枝  1名体制  1名体制  フロントエンド開発課体制（2022年5月時点）  入社  1名入社 

Slide 15

Slide 15 text

#RAKUSTechCon 引き継いだときの状況  各サービスの開発内容  サービス名  技術スタック  開発手法  担当工程  チーム構成  主な開発内容    React  TypeScript  スクラム  画面設計  ～結合テスト  FE/BE別  新機能開発、リリース   運用    Vue.js  jQuery  PHP(Laravel)  W/F  実装  単体テスト  FE/BE一体  既存機能のUI刷新   ・既存機能を読み解いて   　モックアップ作成   ・実装    Vue.js  jQuery  PHP(Laravel)  W/F  実装  単体テスト  FE/BE一体  新機能開発  既存機能のFE/BE分離   （blade→Vue.js）   既存機能のUI不具合対応     Vue.js  jQuery  PHP(Ethna)  W/F  実装  単体テスト  FE/BE一体  モックアップ作成   新機能開発  既存機能のフロントエンド改善  

Slide 16

Slide 16 text

#RAKUSTechCon 引き継いだときの状況  開発プロセスは  開発課ごとに  異なり、作業の  依頼方法も異なる  楽楽精算からフロントエンド改善の要望は  あるが、要員不足で  取り組めていない  メンバーはぞれぞれのサービス開発に付きっ切りで、課の一体感は弱い  勉強会や情報共有会が行われていて、自己  研鑽は活発に行われている  楽楽勤怠メンバーの   分離で自分達もどう  なるのか分からず、  不安に思っている？   各開発課との関係は構築中だが、  外注っぽさがある 

Slide 17

Slide 17 text

#RAKUSTechCon フロントエンド横断組織のあるべき姿を  明確にして一体感のある組織にしたい 

Slide 18

Slide 18 text

#RAKUSTechCon チームトポロジー～価値あるソフトウェアを素早く届ける適応型組織設計～  2021年12月　日本能率協会マネジメントセンター刊行  マシュー・スケルトン、マニュエル・パイス (著)  原田騎郎、永瀬美穂、吉羽龍太郎 (翻訳)  ● チームトポロジーとは  ○ 実践的で段階的かつ適応型の組織設計モデル   ○ ソフトウェアシステムの構築と運用を成功させるための普遍的な公式ではなく、明快なパターン  ○ チームの目的と責任を明確にし、チーム間の相互関係の効果の向上を目指す   ○ 技術、人、ビジネスの変化に継続的に対処できるようにする   ○ 構造は静的なものではなく、状況に応じて変化させていく  

Slide 19

Slide 19 text

#RAKUSTechCon チームファースト思考で責任範囲を決める  ● 認知負荷に合うように責任範囲（ソフトウェア境界）を制限する  ○ 課題内在性負荷：問題領域の本質的なタスクに関するもの   　　　　　　　　ex. 基本的なプログラミングの知識と開発に利用する言語の知識   ○ 課題外在性負荷：タスクが実施される環境に関するもの   　　　　　　　　ex. テスト環境の構築や、デプロイ・リリースなど   ○ 学習関連負荷　：学習を進めたり高性能を実現するうえで特別な注意が   　　　　　　　　必要なタスクに関連するもの   　　　　　　　　ex. 開発手法、アルゴリズム、ドメイン知識など  

Slide 20

Slide 20 text

Slide 21

Slide 21 text

#RAKUSTechCon ● 認知負荷に合うように責任範囲（ソフトウェア境界）を制限する  ○ 課題内在性負荷：問題領域の本質的なタスクに関するもの   　　　　　　　　ex. 基本的なプログラミングの知識と開発に利用する言語の知識   ○ 課題外在性負荷：タスクが実施される環境に関するもの   　　　　　　　　ex. テスト環境の構築や、デプロイ・リリースなど   ○ 学習関連負荷　：学習を進めたり高性能を実現するうえで特別な注意が   　　　　　　　　必要なタスクに関連するもの   　　　　　　　　ex. 開発手法、アルゴリズム、ドメイン知識など   チームファースト思考で責任範囲を決める  チームの境界を決める節理面  フロントエンド開発課のMission・Visionと一致 

Slide 22

Slide 22 text

#RAKUSTechCon フロントエンド開発課のMission・Vision  Mission  ● フロントエンドの技術で快適なUXを提供する  ○ デザインの意図を理解して具現化する  ○ フロントエンド開発に秩序をもたらす  ○ 優秀なフロントエンドエンジニアを育成する  Vision  ● すべてのサービスのフロントエンド開発を担うスペシャリスト集団  ○ 顧客が使いやすい高品質なUXを実現している  ○ Webパフォーマンスが高いフロントエンド機能を、素早く・効率的に提供している  ○ すべてのサービスにフロントエンドエンジニアが貢献している 

Slide 23

Slide 23 text

#RAKUSTechCon チームファースト思考で責任範囲を決める  やること  やらないこと  ● フロントエンド開発   ○ 機能開発  ○ 開発プロセス整備   ○ Webパフォーマンス検証・改善   ○ 生産性・品質向上につながるリファクタリング   ○ 定量評価（生産性・品質・スキル）   ● サポート  ○ フロントエンド技術導入支援   ○ フロントエンドエンジニア育成   ● 課横断の情報共有会・勉強会   ● バックエンド開発   ● 要件定義  ● 必要以上のドメイン知識習得   ● 理想を押し付けたリファクタリング   ● 1人1商材担当  あとで決めること   ● フロントエンド技術的負債の解消の取り組み（どこまでやるべきか）   ● 共通コンポーネントの開発   ● チームAPIを定義した仕事のやり方   やること・やらないことを明確にする 

Slide 24

Slide 24 text

#RAKUSTechCon やること  ● フロントエンド開発  ○ 機能開発  ○ 開発プロセス整備  ○ Webパフォーマンス検証・改善   ○ 生産性・品質向上につながるリファクタリング   ○ 定量評価（生産性・品質）   ● サポート  ○ フロントエンド技術導入支援   ○ フロントエンドエンジニア育成   ● 課横断の情報共有会・勉強会  エンジニアの理想のためでなく、   サービス成長のためのリファクタリング   測定可能な状態にし、PDCAサイクルを回す   フロントエンドコーディングルール整備   フロントエンドテスト戦略策定  スキルマップ作成  インターンカリキュラムの刷新 

Slide 25

Slide 25 text

#RAKUSTechCon やらないこと  ● バックエンド開発  ● 要件定義  ● 必要以上のドメイン知識習得  ● 理想を押し付けたリファクタリング  ● 1人1商材担当  認知負荷が高くならないように、ドメイン知識は   フロントエンド開発に必要な範囲に留める   要件定義・深いドメイン知識はプロダクトデザイン課・各サービス開発課にお任せする  チーム内で要員を流動的に配置できる体制を作り、   属人化と心理的安全性の低下を抑止する  

Slide 26

Slide 26 text

#RAKUSTechCon 目指すチームタイプ  ● ストリームアラインドチーム   ○ ビジネスの主な変更フローに沿って配置されるチーム。職能横断型で、  他のチームを待つことなく、利用可能な機能をデリバリーする能力を持つ   ● プラットフォームチーム  ○ 下位のプラットフォームを扱うチームで、ストリームアラインドチームのデリバリーを助ける。プラットフォームは、直接使うと複雑な技術をシンプルにし、利用するチームの認知負荷を減らす   ● イネイブリングチーム  ○ 転換期や学習期に、他のチームがソフトウェアを導入したり変更したりするのを助ける   ● コンプリケイテッド・サブシステムチーム   ○ 普通のストリームアラインドチーム、プラットフォームチームが扱うには複雑すぎるサブシステムを扱うためのチーム。本当に必要な場合にだけ編成される  各サービスの開発課  インフラ開発課  横断組織？  技術推進課  フロントエンド開発？ 

Slide 27

Slide 27 text

#RAKUSTechCon 目指すチームタイプ  ● ストリームアラインドチーム  ○ ビジネスの主な変更フローに沿って配置されるチーム。職能横断型で、   他のチームを待つことなく、利用可能な機能をデリバリーする能力を持つ   各サービスの開発課  フロントエンド開発課  ＋  現在はストリームアラインドチームの一員  各サービスの開発課が求めているのは、  技術支援では無く、フロントエンド開発の委譲  継続 

Slide 28

Slide 28 text

#RAKUSTechCon 目指すチームタイプ  ● イネイブリングチーム  ○ 転換期や学習期に、他のチームがソフトウェアを導入したり変更したりするのを   助ける  Vision  ● すべてのサービスのフロントエンド開発を担うスペシャリスト集団 

Slide 29

Slide 29 text

#RAKUSTechCon 目指すチームタイプ  ● イネイブリングチーム  ○ 転換期や学習期に、他のチームがソフトウェアを導入したり変更したりするのを   助ける  中長期的に目指すべきチームの形  社内の様々なフロントエンド課題解決を支援する  2つのチームタイプで活動する組織を目指す 

Slide 30

Slide 30 text

#RAKUSTechCon イネイブリングチームとしての活動  稼働時間10%を使って取り組み 

Slide 31

Slide 31 text

#RAKUSTechCon イネイブリングチームとしての活動  フロントエンド改善に取り組む  分類  問題  生産性低下  資産が膨大になっている（1ファイル 1万ステップなど）ため、改修時の影響範囲調査、  影響確認テストに時間が掛かる   既存処理流用による重複コードが多いので、改修がある場合はそれぞれ修正・テストが必要   資産がスパゲティ状態になっているため、AとBの画面改修を行う場合、   Aの改修が終わらないとBの改修ができないといった、コンフリクトが発生している  開発高速化  ビジネスサイドから求められる開発のスピード感を考えると、フロントエンドとバックエンドの   分離によりスピードが向上するなら、分離したい（モダンフロントエンドに移行）   品質問題  HTML / CSS / JavaScript のコーディングルールが無いため、統一感が無く、可読性が悪い   特にCSSは有識者がいないので、適切な状態か判断できていない  

Slide 32

Slide 32 text

#RAKUSTechCon 分類  問題  生産性低下  資産が膨大になっている（1ファイル 1万ステップなど）ため、改修時の影響範囲調査、  影響確認テストに時間が掛かる   既存処理流用による重複コードが多いので、改修がある場合はそれぞれ修正・テストが必要   資産がスパゲティ状態になっているため、AとBの画面改修を行う場合、   Aの改修が終わらないとBの改修ができないといった、コンフリクトが発生している  開発高速化  ビジネスサイドから求められる開発のスピード感を考えると、フロントエンドとバックエンドの   分離によりスピードが向上するなら、分離したい（モダンフロントエンドに移行）   品質問題  HTML / CSS / JavaScript のコーディングルールが無いため、統一感が無く、可読性が悪い   特にCSSは有識者がいないので、適切な状態か判断できていない   イネイブリングチームとしての活動  フロントエンド改善に取り組む  何を提案できるのか  検討するところから開始 

Slide 33

Slide 33 text

#RAKUSTechCon イネイブリングチームとしての活動  フロントエンド開発課に何ができるのか  ○ 大規模リファクタリングの経験者はいない  ○ サービスのドメイン知識は無い  ○ サービスの機能開発は止められない  理想をもとに改善計画を立てても、納得感は得られない  提案する側は効果の根拠を示せない 

Slide 34

Slide 34 text

#RAKUSTechCon イネイブリングチームとしての活動  未知の領域への取り組みは、実験を通じた成果を積み上げて  答えを発見していく  検証結果をもとに提案する価値があるか判断する  （問題は解決するのか、喜ばれるのか）   メンバーそれぞれ強みを活かした改善案を考える  現状把握（コードリーディング）  実験して期待する効果があるか検証する 

Slide 35

Slide 35 text

#RAKUSTechCon イネイブリングチームとしての活動 

Slide 36

Slide 36 text

#RAKUSTechCon ラクスフロントエンド横断組織の  あるべき姿 

Slide 37

Slide 37 text

#RAKUSTechCon ラクスフロントエンド横断組織のあるべき姿  ● ストリームアラインドチームとして  ○ 各サービス開発課と永続的コラボレーション   ● イネーブリングチームとして  ○ フロントエンド改善の検証・提案   ○ フロントエンドエンジニア育成   フロントエンドの専門組織としてサービスの成長に貢献  チームの節理面で大切にしたのはMission／Visionに一致すること  Mission／Visionに共感して取り組むことが出来る、一体感のある組織を目指す 

Slide 38

Slide 38 text

#RAKUSTechCon ● 小さく試して大きく育てる  毎月10%の稼働を自由に使って、改善提案ネタを実験する   ● 失敗を許容する（心理的安全性を与える）  求める成果＝上手くいくことのみではない   上手くいかないことを証明するのも成果として評価する   ● 学習し成長し続ける  実験と学習を繰り返して目的を追求し続ける   実験を通じた成果を積み上げてフロントエンド改善に取り組む  ラクスフロントエンド横断組織のあるべき姿 

Slide 39

Slide 39 text

#RAKUSTechCon ● 共通デザインコンポーネントの開発  今後の新サービス開発に向けて   ● チームAPIを定義した仕事のやり方  各サービス開発課との一体感の大切にして、外注っぽくならないように注意   もう少し先の話  ラクスフロントエンド横断組織のあるべき姿 

Slide 40

Slide 40 text

#RAKUSTechCon 最後に 

Slide 41

Slide 41 text

#RAKUSTechCon 最後に  ● 一緒に働きたい人を募集しています！  ● 具体的な話しや、実際に働いている人と  話してみたいという人は、カジュアル面談で！！ 

Slide 42

Slide 42 text

#RAKUSTechCon ご清聴ありがとうございました 