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
470
プロジェクト体制→スクラムへ Chatworkの開発プロセスの変遷
shibe23
July 21, 2023
Tweet
Share
More Decks by shibe23
See All by shibe23
巨大なSPAの技術的負債と向き合い続けるテクニック(2023年秋)
shibe23
4
8.2k
認知負荷で考えるフロントエンドの組織体制
shibe23
1
1.9k
巨大なSPAの技術的負債と向き合い続けるテクニック
shibe23
3
2.6k
マネージャーからみたスクラムと自己管理化
shibe23
1
2.3k
組織フェーズを見据えたWebフロントエンドのアーキテクチャと変遷
shibe23
4
5.9k
Other Decks in Technology
See All in Technology
軽いノリで"自動化"に取り組んではいけないという話
tetsuyaooooo
1
460
受託開発でもアジャイル開発できました / Agile in Contract Development
takaking22
0
130
見えづらい活動の成果の伝え方は日頃からめちゃくちゃ悩んでるけど、実際こんな取り組みをしな がら温度感を合わせにいってるよ / Conveying Hard-to-See Results
kakehashi
2
390
DenoでもViteしたい!インポートパスのエイリアスを指定してラクラクアプリ開発
bengo4com
1
1.9k
エムスリー全チーム紹介資料 / Introduction of M3 All Teams
m3_engineering
1
280
KDD2024参加報告
cyberagentdevelopers
PRO
1
310
Oracle Database 23ai 新機能#4 Application Continuity
oracle4engineer
PRO
0
110
【shownet.conf_】ローカル5Gを活用したウォーキングツアーの体感向上
shownet
PRO
0
320
Assisted reorganization of data structures
ennael
PRO
0
250
Rubyはなぜ「たのしい」のか? / Why is Ruby a programmers' best friend? #tqrk15
expajp
4
1.8k
AWSの初級者向けAI・ML資格『AWS Certified AI Practitioner』の傾向と対策/So You Want To Pass AWS Certified AI Practitioner
quiver
0
120
LINEヤフー新卒採用 コーディングテスト解説 アルゴリズム問題編
lycorp_recruit_jp
0
13k
Featured
See All Featured
Building a Scalable Design System with Sketch
lauravandoore
459
32k
Into the Great Unknown - MozCon
thekraken
30
1.4k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.1k
Testing 201, or: Great Expectations
jmmastey
38
7k
The MySQL Ecosystem @ GitHub 2015
samlambert
250
12k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
27
1.9k
Imperfection Machines: The Place of Print at Facebook
scottboms
264
13k
Become a Pro
speakerdeck
PRO
24
4.9k
Gamification - CAS2011
davidbonilla
80
5k
A Philosophy of Restraint
colly
202
16k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
37
1.7k
A better future with KSS
kneath
237
17k
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募集職種一覧 ページ
働くをもっと楽しく、創造的に