Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Rakus_Dev
March 08, 2023

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

設立20年目にして作られたフロントエンド開発組織は発足から2年経ちました。
発足時2名しかいなかったフロントエンドエンジニアは18名に増えましたが、まだまだ人手不足。課題も山積みです。
ベスト・オブ・ブリード戦略で成長してきた様々なサービスに対して、各開発課と共にサービス開発を行うストリームアラインドチームになるのか、フロントエンドのスペシャリストとして技術支援を行うイネイブリングチームになるのか、横断組織ならではの悩みにどのように取り組んで行くのか、これからの組織設計についてお話しします。

Rakus_Dev

March 08, 2023
Tweet

More Decks by Rakus_Dev

Other Decks in Technology

Transcript

  1. #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
 ※赤字は後から導入したもの 

  2. #RAKUSTechCon 開発本部
 東京拠点
 大阪拠点
 東京インフラ開発課
 大阪インフラ開発課
 楽楽精算開発部
 楽楽明細開発部
 楽楽販売開発課
 メールディーラー開発課


    配配メール開発課
 チャットディーラー開発課
 開発組織(フロントエンド開発課発足前)
 サービスごとに開発組織は分かれていました。

  3. #RAKUSTechCon フロントエンド開発課発足の背景
 各サービスでフロントエンドエンジニアの 育成が出来ない
 レガシーなフロントエンドでは、 
 デザイン通りの実装が実現できない ケースが多い
 レガシーなフロントエンドは、 


    コードが煩雑で改修の影響調査に時間が掛かる 
 モダンなフロントエンド開発経験が無いため、 
 実装に時間が掛かってしまい、 バックエンドとの両立が厳しい 
 ラクスが抱えていたフロントエンドの問題点
 年々高まるUI/UXの要求
 リードタイム短縮
 生産性の向上
 フロントエンドの
 スキルアップ/品質向上

  4. #RAKUSTechCon フロントエンド開発課発足の背景
 各サービスでフロントエンドエンジニアの 育成が出来ない
 レガシーなフロントエンドでは、 
 デザイン通りの実装が実現できない ケースが多い
 レガシーなフロントエンドは、 


    コードが煩雑で改修の影響調査に時間が掛かる 
 モダンなフロントエンド開発経験が無いため、 
 実装に時間が掛かってしまい、 バックエンドとの両立が厳しい 
 ラクスが抱えていたフロントエンドの問題点
 年々高まるUI/UXの要求
 リードタイム短縮
 生産性の向上
 フロントエンドの
 スキルアップ/品質向上
 解決に向けて
 2020年
 UI開発課(フロントエンドチーム)発足
 ※現フロントエンド開発課

  5. #RAKUSTechCon 開発本部
 東京拠点
 大阪拠点
 東京インフラ開発課
 大阪インフラ開発課
 楽楽精算開発部
 楽楽勤怠開発部
 楽楽明細開発部
 楽楽販売開発課


    メールディーラー開発課
 配配メール開発課
 チャットディーラー開発課
 開発組織(UI開発課(フロントエンドチーム)発足後)
 UI開発課
 (UIデザイン/ 
 フロントエンド) 
 横断組織としてフロントエンド問題解決の取り組みを開始しました

  6. #RAKUSTechCon サービスごとに問題は異なる
 サービス名
 問題
 
 • CSSが管理出来ていない、肥大化 
 • HTMLのネストが深く

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

  7. #RAKUSTechCon 凡例
   中途
   新卒
 サービス名
 採用人数
 2019
 2020
 2021
 ~2022/4


    
 
 
 
 
 UI開発課(フロントエンドチーム)の歩み
 新サービスの楽楽勤怠の開発参画を皮切りに、徐々に活動範囲を広げてきました
 楽楽勤怠開発に
 特化して開発を
 高速化するため、 
 4月に組織を分離

  8. #RAKUSTechCon 凡例
   中途
   新卒
 サービス名
 採用人数
 2019
 2020
 2021
 ~2022/4


    
 
 
 
 UI開発課(フロントエンドチーム)の歩み
 楽楽勤怠メンバーの分離により 14名 → 6名に

  9. #RAKUSTechCon 引き継いだときの状況
 フロントエンド開発課 
 ラクスシリーズチーム 
 楽楽明細チーム 
 1名体制
 4名体制


    國枝
 1名体制
 1名体制
 フロントエンド開発課体制(2022年5月時点)
 入社
 1名入社

  10. #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一体
 モックアップ作成 
 新機能開発
 既存機能のフロントエンド改善 

  11. #RAKUSTechCon 引き継いだときの状況
 開発プロセスは
 開発課ごとに
 異なり、作業の
 依頼方法も異なる
 楽楽精算からフロントエ ンド改善の要望は
 あるが、要員不足で
 取り組めていない


    メンバーはぞれぞれのサー ビス開発に付きっ切りで、 課の一体感は弱い
 勉強会や情報共有会が 行われていて、自己
 研鑽は活発に行われて いる
 楽楽勤怠メンバーの 
 分離で自分達もどう
 なるのか分からず、
 不安に思っている? 
 各開発課との関係 は構築中だが、
 外注っぽさがある

  12. #RAKUSTechCon チームトポロジー ~価値あるソフトウェアを素早く届ける適応型組織設計~
 2021年12月 日本能率協会マネジメントセンター刊行
 マシュー・スケルトン、マニュエル・パイス (著)
 原田 騎郎、永瀬 美穂、吉羽 龍太郎

    (翻訳)
 • チームトポロジーとは
 ◦ 実践的で段階的かつ適応型の組織設計モデル 
 ◦ ソフトウェアシステムの構築と運用を成功させるための普遍的な公式ではなく、明快な パターン
 ◦ チームの目的と責任を明確にし、チーム間の相互関係の効果の向上を目指す 
 ◦ 技術、人、ビジネスの変化に継続的に対処できるようにする 
 ◦ 構造は静的なものではなく、状況に応じて変化させていく 

  13. #RAKUSTechCon チームファースト思考で責任範囲を決める
 • 認知負荷に合うように責任範囲(ソフトウェア境界)を制限する
 ◦ 課題内在性負荷:問題領域の本質的なタスクに関するもの 
         ex. 基本的なプログラミングの知識と開発に利用する言語の知識 


    ◦ 課題外在性負荷:タスクが実施される環境に関するもの 
         ex. テスト環境の構築や、デプロイ・リリースなど 
 ◦ 学習関連負荷 :学習を進めたり高性能を実現するうえで特別な注意が 
         必要なタスクに関連するもの 
         ex. 開発手法、アルゴリズム、ドメイン知識など 

  14. #RAKUSTechCon フロントエンド開発課発足の背景
 各サービスでフロントエンドエンジニアの 育成が出来ない
 レガシーなフロントエンドでは、 
 デザイン通りの実装が実現できない ケースが多い
 レガシーなフロントエンドは、 


    コードが煩雑で改修の影響調査に時間が掛かる 
 モダンなフロントエンド開発経験が無いため、 
 実装に時間が掛かってしまい、 バックエンドとの両立が厳しい 
 ラクスが抱えていたフロントエンドの問題点
 年々高まるUI/UXの要求
 リードタイム短縮
 生産性の向上
 フロントエンドの
 スキルアップ/品質向上
 認知負荷が高い

  15. #RAKUSTechCon • 認知負荷に合うように責任範囲(ソフトウェア境界)を制限する
 ◦ 課題内在性負荷:問題領域の本質的なタスクに関するもの 
         ex. 基本的なプログラミングの知識と開発に利用する言語の知識 
 ◦

    課題外在性負荷:タスクが実施される環境に関するもの 
         ex. テスト環境の構築や、デプロイ・リリースなど 
 ◦ 学習関連負荷 :学習を進めたり高性能を実現するうえで特別な注意が 
         必要なタスクに関連するもの 
         ex. 開発手法、アルゴリズム、ドメイン知識など 
 チームファースト思考で責任範囲を決める
 チームの境界を決める節理面
 フロントエンド開発課のMission・Visionと一致

  16. #RAKUSTechCon フロントエンド開発課のMission・Vision
 Mission
 • フロントエンドの技術で快適なUXを提供する
 ◦ デザインの意図を理解して具現化する
 ◦ フロントエンド開発に秩序をもたらす
 ◦

    優秀なフロントエンドエンジニアを育成する
 Vision
 • すべてのサービスのフロントエンド開発を担うスペシャリスト集団
 ◦ 顧客が使いやすい高品質なUXを実現している
 ◦ Webパフォーマンスが高いフロントエンド機能を、素早く・効率的に提供している
 ◦ すべてのサービスにフロントエンドエンジニアが貢献している

  17. #RAKUSTechCon チームファースト思考で責任範囲を決める
 やること
 やらないこと
 • フロントエンド開発 
 ◦ 機能開発
 ◦

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

  18. #RAKUSTechCon やること
 • フロントエンド開発
 ◦ 機能開発
 ◦ 開発プロセス整備
 ◦ Webパフォーマンス検証・改善

    
 ◦ 生産性・品質向上につながるリファクタリング 
 ◦ 定量評価(生産性・品質) 
 • サポート
 ◦ フロントエンド技術導入支援 
 ◦ フロントエンドエンジニア育成 
 • 課横断の情報共有会・勉強会
 エンジニアの理想のためでなく、 
 サービス成長のためのリファクタリング 
 測定可能な状態にし、PDCAサイクルを回す 
 フロントエンドコーディングルール整備 
 フロントエンドテスト戦略策定
 スキルマップ作成
 インターンカリキュラムの刷新

  19. #RAKUSTechCon やらないこと
 • バックエンド開発
 • 要件定義
 • 必要以上のドメイン知識習得
 • 理想を押し付けたリファクタリング


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

  20. #RAKUSTechCon 目指すチームタイプ
 • ストリームアラインドチーム 
 ◦ ビジネスの主な変更フローに沿って配置されるチーム 。職能横断型で、
 他のチームを待つことなく、利用可能な機能をデリバリーする能力を持つ 


    • プラットフォームチーム
 ◦ 下位のプラットフォームを扱うチームで、ストリームアラインドチームのデリバリーを助ける。プラットフォー ムは、直接使うと複雑な技術をシンプルにし、利用するチームの認知負荷を減らす 
 • イネイブリングチーム
 ◦ 転換期や学習期に、他のチームがソフトウェアを導入したり変更したりするのを助ける 
 • コンプリケイテッド・サブシステムチーム 
 ◦ 普通のストリームアラインドチーム、プラットフォームチームが扱うには 複雑すぎるサブシステムを扱うため のチーム。本当に必要な場合にだけ編成される
 各サービスの開発課
 インフラ開発課
 横断組織?
 技術推進課
 フロントエンド開発?

  21. #RAKUSTechCon 目指すチームタイプ
 • ストリームアラインドチーム
 ◦ ビジネスの主な変更フローに沿って配置されるチーム。職能横断型で、 
 他のチームを待つことなく、利用可能な機能をデリバリーする能力を持つ 
 各サービスの開発課


    フロントエンド開発課
 +
 現在はストリームアラインドチームの一員
 各サービスの開発課が求めているのは、
 技術支援では無く、フロントエンド開発の委譲
 継続

  22. #RAKUSTechCon イネイブリングチームとしての活動
 フロントエンド改善に取り組む
 分類
 問題
 生産性低下
 資産が膨大になっている(1ファイル 1万ステップなど)ため、改修時の 影響範囲調査、
 影響確認テストに時間が掛かる

    
 既存処理流用による重複コードが多いので、改修がある場合はそれぞれ修正・テストが必要 
 資産がスパゲティ状態になっているため、AとBの画面改修を行う場合、 
 Aの改修が終わらないとBの改修ができないといった、 コンフリクトが発生している
 開発高速化
 ビジネスサイドから求められる 開発のスピード感を考えると、フロントエンドとバックエンドの 
 分離によりスピードが向上するなら、分離したい(モダンフロントエンドに移行) 
 品質問題
 HTML / CSS / JavaScript のコーディングルールが無いため、 統一感が無く、可読性が悪い 
 特にCSSは有識者がいないので、 適切な状態か判断できていない 

  23. #RAKUSTechCon 分類
 問題
 生産性低下
 資産が膨大になっている(1ファイル 1万ステップなど)ため、改修時の 影響範囲調査、
 影響確認テストに時間が掛かる 
 既存処理流用による重複コードが多いので、改修がある場合はそれぞれ修正・テストが必要

    
 資産がスパゲティ状態になっているため、AとBの画面改修を行う場合、 
 Aの改修が終わらないとBの改修ができないといった、 コンフリクトが発生している
 開発高速化
 ビジネスサイドから求められる 開発のスピード感を考えると、フロントエンドとバックエンドの 
 分離によりスピードが向上するなら、分離したい(モダンフロントエンドに移行) 
 品質問題
 HTML / CSS / JavaScript のコーディングルールが無いため、 統一感が無く、可読性が悪い 
 特にCSSは有識者がいないので、 適切な状態か判断できていない 
 イネイブリングチームとしての活動
 フロントエンド改善に取り組む
 何を提案できるのか
 検討するところから開始

  24. #RAKUSTechCon ラクス フロントエンド横断組織のあるべき姿
 • ストリームアラインドチームとして
 ◦ 各サービス開発課と永続的コラボレーション 
 • イネーブリングチームとして


    ◦ フロントエンド改善の検証・提案 
 ◦ フロントエンドエンジニア育成 
 フロントエンドの専門組織としてサービスの成長に貢献
 チームの節理面で大切にしたのはMission/Visionに一致すること
 Mission/Visionに共感して取り組むことが出来る、一体感のある組織を目指す

  25. #RAKUSTechCon • 小さく試して大きく育てる
 毎月10%の稼働を自由に使って、改善提案ネタを実験する 
 • 失敗を許容する(心理的安全性を与える)
 求める成果=上手くいくことのみではない 
 上手くいかないことを証明するのも成果として評価する

    
 • 学習し成長し続ける
 実験と学習を繰り返して目的を追求し続ける 
 実験を通じた成果を積み上げてフロントエンド改善に取り組む
 ラクス フロントエンド横断組織のあるべき姿