Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
プロジェクト体制→スクラムへ Chatworkの開発プロセスの変遷
Search
shibe23
July 21, 2023
Technology
1
510
プロジェクト体制→スクラムへ Chatworkの開発プロセスの変遷
shibe23
July 21, 2023
Tweet
Share
More Decks by shibe23
See All by shibe23
巨大なSPAの技術的負債と向き合い続けるテクニック(2023年秋)
shibe23
4
8.3k
認知負荷で考えるフロントエンドの組織体制
shibe23
1
2k
巨大なSPAの技術的負債と向き合い続けるテクニック
shibe23
3
2.6k
マネージャーからみたスクラムと自己管理化
shibe23
1
2.4k
組織フェーズを見据えたWebフロントエンドのアーキテクチャと変遷
shibe23
4
6k
Other Decks in Technology
See All in Technology
社内イベント管理システムを1週間でAKSからACAに移行した話し
shingo_kawahara
0
210
C++26 エラー性動作
faithandbrave
2
840
いまからでも遅くないコンテナ座学
nomu
0
150
Oracle Cloudの生成AIサービスって実際どこまで使えるの? エンジニア目線で試してみた
minorun365
PRO
4
310
Opcodeを読んでいたら何故かphp-srcを読んでいた話
murashotaro
0
340
レンジャーシステムズ | 会社紹介(採用ピッチ)
rssytems
0
300
React Routerで実現する型安全なSPAルーティング
sansantech
PRO
2
320
マイクロサービスにおける容易なトランザクション管理に向けて
scalar
0
190
宇宙ベンチャーにおける最近の情シス取り組みについて
axelmizu
0
130
TypeScript開発にモジュラーモノリスを持ち込む
sansantech
PRO
3
740
GitHub Copilot のテクニック集/GitHub Copilot Techniques
rayuron
39
17k
UI State設計とテスト方針
rmakiyama
4
860
Featured
See All Featured
How STYLIGHT went responsive
nonsquared
96
5.2k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
44
9.3k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
7
530
How GitHub (no longer) Works
holman
311
140k
Speed Design
sergeychernyshev
25
680
Designing Dashboards & Data Visualisations in Web Apps
destraynor
229
52k
Build The Right Thing And Hit Your Dates
maggiecrowley
33
2.4k
Statistics for Hackers
jakevdp
796
220k
The Language of Interfaces
destraynor
155
24k
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
The World Runs on Bad Software
bkeepers
PRO
66
11k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
8
1.2k
Transcript
Chatwork株式会社 澁谷 哲也 2023年07月21日 プロジェクト体制→スクラムへ Chatworkの開発プロセスの変遷
自己紹介 2 名前 澁谷 哲也(しぶたに てつや) 経歴 フロントエンドエンジニア -> MGR
-> EM 役割 Chatwork株式会社 ピープルマネジメントチーム 兼 フロントエンド開発部 MGR お仕事 エンジニアに関わるピープルマ ネジメントや組織開発 紹介記事 :https://chado.chatwork.com/entry/2021/11/02/100000
Chatworkの紹介 1
会社概要 会社名 Chatwork株式会社 代表取締役CEO 山本 正喜 従業員数 379名(2023年3月末日時点) 所在地 東京、大阪含む全国のwework
設立 2004年11月11日 4
Chatworkとは 5 効率的に情報共有できる グループチャット 仕事の見える化ができる タスク管理 見落としがなくなる ファイル管理 いつでも会議ができる ビデオ/音声通話
前提: 開発を取り巻く環境 2
現在 約100名 が在籍 おおよそ エンジニア:デザイナー:PdM = 8 : 1 :
1 Chatworkの組織 7 各本部でセクションが分けられている。 プロダクト本部は以下のような職種が集まる本部門。 • エンジニア • デザイナー • プロダクトマネージャ(PdM) ※ 2023年7月現在の組織図 参考)「Chatwork会社説明資料」より抜粋 ※ 2023年7月時点での人数
職能ごとに縦割りの組織 8 各部署 Projectチーム これまでは職能による縦割りな組織が主な機能開発を担当していた なにかプロダクト開発の案件があると、 大きな案件については各部署から集めたプロジェクトチームを作って いた こういった開発体制のことをプロジェクト体制と呼んでいる
プロジェクト体制の課題 3
プロジェクト体制について 10 案件ごとに各部署からメンバーをアサインしてバーチャルチームを結成する形式 • 部署・プロジェクトともに組織体制としてベーシックなため分かりやすい • 主体となる部署は技術領域ごとに分離されているため、職種内の意思疎通がしやすい ◦ フロントエンド(SPA)・モバイルアプリ・サーバーサイドという分かりやすい構成 •
一方で、以下のようなプロセスを毎回行う必要がある 起案 メンバーア サイン チームビル ディング 要件定義 ~ 開発 リリース 振り返り 解散
プロジェクト体制の課題 ~ 開発 ~ 11 職能別のチームが運用・保守のオーナーシップを持つため、各職能組織が技術面でのステークホル ダーになってしまう • 大半のプロジェクトで「この方針でいいか部署に持ち帰って精査しますね」が発生する •
プロジェクトによっては各部署のコードレビューが必要になることも また、関連するチームや部署が多くなりがちで合意コストが大きい そのためにプロジェクトマネジメントの難易度が高く、担えるメンバーが限られる問題もあった
プロジェクト体制の課題 ~ 運用・保守 ~ 12 プロジェクト -> 部署への運用・保守の引き継ぎが発生してしまう • 適宜、またはプロジェクト終了後に仕様について部署に共有する必要がある
• 監視体制など、負荷の大きな運用をどう行うか都度検討しなくてはならない
プロジェクト体制の課題 ~ チーム・組織 ~ 13 都度チームビルディングが必要となり、立ち上げのコストが高い • チームとして開発プロセスのナレッジが共有しづらい ◦ 同じような失敗を各プロジェクトで繰り返してしまう
• 部署としてチーム感を出しづらい ◦ 各メンバーが何かしらのプロジェクトに参加していて、同じ仕事をしないことも ◦ 職能ごとに都度メンバーを確保するため「◦◦エンジニアがいないのでプロジェクト が進められない」になりがち ▪ リソース効率にフォーカスしてしまいやすい
プロジェクト型 -> スクラムへの移行 3
やりたいこと:DevOpsを実現した組織体系 15 開発 ~ 運用まで一貫して同じチームで責任を持ち、自律して活動できるような組織にしていきたい。 そのためにはどうすればいいだろう? DevOpsを実現するためには、どんなチームがいいだろう?
DevOps体制の実現方法(How):職能横断の固定化したチーム 16 都度PJ チームを発足させるのではなく、継続して存続できるようなチームが理想。 つまり、チームに閉じて立案・開発・運用までを一貫して担当でき、オーナーシップをもって作業が できる職能横断型の自己管理化されたチームが理想。 このような職能横断型のチームをFeature(フィーチャー)チームと呼んでいる。 開発プロセスとしてプロジェクト型 -> スクラム主体となる
※ チームの裁量に委ねるため、必ずしもスクラムである必要はない
フィーチャーチーム体制の実装 17 以下の3つのチームに分けていく。 • フィーチャーチーム ◦ 事業価値を創出するチーム • プラットフォームチーム ◦
フィーチャーチームの認知負荷を下げるための職能別のチーム ◦ 支援特化型 ◦ チームトポロジーの「プラットフォームチーム」とは異なる • ピープルマネジメントチーム ◦ 横串で各チームをマネジメントを担当するチーム 現状、上記体制への移行を目指し、組織を少しづつ変化させている段階。 ※ 概念図
移行にあたっての課題とポイント 3
巨大なワンプロダクトであるが故の難しさ Chatworkは巨大なモノリスであり、事業としても単一のアプリケーションである • リリースして12年目の歴史あるプロダクトで技術的負債も大きい • 単一のリポジトリを複数のチームで編集する必要がある • 各チームへどのように権限と責任を委譲し、オーナーシップを持ってもらうかが課題 ◦ 特にクライアントサイドはチャットという「一画面に複雑な機能が依存しあっている」性質から
分割が難しい • 現状は分割の境界面を模索しながら、切り出せる箇所を分割している段階 19
巨大なワンプロダクトであるが故の難しさ 「フィーチャーチーム」と聞くと機能単位で閉じたチームが常に施策を回しているイメージが強い。 しかし、巨大なワンプロダクトにおいては、ある時点で事業として注力する領域は運用・保守が必要なシス テムに対して網羅的ではない • 機能単位で無理に分割しても、運用・保守しかしないチームができてしまう • 分割は意識しつつ、粒度や一つのチームが持つ領域のバランスは注意が必要 20
運用・保守を念頭に置いたチーム設計が必要 事業の変化に対して、システムは簡単に追従できない • 施策を行う中で、方針転換が入るのは当たり前のこと • システムを作ってしまうと運用・保守が発生するため、施策の変化に追従するのに時間がかかってし まう • 施策に最適化された組織・システムを作ってしまうと、事業の状況変化によって負債化するシステム が増える危険性がある
• 必ずしも施策 = チームではない 21
まとめ
プロジェクト体制 -> スクラム体制への移行の手応え 23 難易度が高いチャレンジではあるものの、一定の手応えはある • 開発プロセスとして意思疎通のコストは間違いなく下がっている • PRレビューなどチーム間の合意はまだ必要な部分はあるものの、一部ではチーム内で完結して 開発を進められている
• フィーチャーチームとして独立しているチームもいくつか存在しており、チームに閉じて施策 を実行できている プロジェクト体制 / スクラム体制ともにメリット・デメリットが存在しており、組織規模や目指す開 発体制によって最適な形は異なるはず
より詳しく知りたい方は • 本部長の田中が「開発生産性Conference」で発表したスライドをご覧ください 24 https://speakerdeck.com/tanakayuki/huitiyatimuhua-henoqu-rizu-mito-sorewozhi-eruzu-zhi-manesimentoti-zhi
We're Hiring! 25 Chatworkでは、ビジネスチャットの普及、中小企業のDXを目指す仲間を募集中です! 一緒にDevOpsなチーム体制を目指していきましょう! • エンジニアリングマネージャー • フィーチャーチーム •
サーバーサイド(PHP / Scala) • iOS • Android • フロントエンド • UIデザイナー • SRE • QA \ ご応募お待ちしております / Chatwork募集職種一覧 ページ
働くをもっと楽しく、創造的に