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
600
プロジェクト体制→スクラムへ Chatworkの開発プロセスの変遷
shibe23
July 21, 2023
Tweet
Share
More Decks by shibe23
See All by shibe23
チームと一緒に育つために考えたこと - 属人性・期日・関係性のバランスと向き合う
shibe23
0
54
巨大なSPAの技術的負債と向き合い続けるテクニック(2023年秋)
shibe23
4
8.7k
認知負荷で考えるフロントエンドの組織体制
shibe23
1
2.1k
巨大なSPAの技術的負債と向き合い続けるテクニック
shibe23
3
2.8k
マネージャーからみたスクラムと自己管理化
shibe23
1
2.5k
組織フェーズを見据えたWebフロントエンドのアーキテクチャと変遷
shibe23
4
6.2k
Other Decks in Technology
See All in Technology
ドキュメントはAIの味方!スタートアップのアジャイルを加速するADR
kawauso
3
340
「守る」から「進化させる」セキュリティへ ~AWS re:Inforce 2025参加報告~ / AWS re:Inforce 2025 Participation Report
yuj1osm
1
110
ECS モニタリング手法大整理
yendoooo
1
120
AIエージェント就活入門 - MCPが履歴書になる未来
eltociear
0
430
生成AI利用プログラミング:誰でもプログラムが書けると 世の中どうなる?/opencampus202508
okana2ki
0
190
つくって納得、つかって実感! 大規模言語モデルことはじめ
recruitengineers
PRO
19
4.9k
Goでマークダウンの独自記法を実装する
lag129
0
210
攻撃と防御で実践するプロダクトセキュリティ演習~導入パート~
recruitengineers
PRO
1
140
サービスロボット最前線:ugoが挑むPhysical AI活用
kmatsuiugo
0
190
Yahoo!ニュースにおけるソフトウェア開発
lycorptech_jp
PRO
0
330
EKS Pod Identity における推移的な session tags
z63d
1
200
Evolution on AI Agent and Beyond - AGI への道のりと、シンギュラリティの3つのシナリオ
masayamoriofficial
0
170
Featured
See All Featured
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
1.8k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
Side Projects
sachag
455
43k
How to train your dragon (web standard)
notwaldorf
96
6.2k
Testing 201, or: Great Expectations
jmmastey
45
7.6k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
358
30k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
161
15k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Navigating Team Friction
lara
189
15k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
23
1.4k
Build your cross-platform service in a week with App Engine
jlugia
231
18k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
8
480
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募集職種一覧 ページ
働くをもっと楽しく、創造的に