プロジェクト体制→スクラムへ Chatworkの開発プロセスの変遷

Transcript

1. Chatwork株式会社 澁谷 哲也 2023年07月21日 プロジェクト体制→スクラムへ Chatworkの開発プロセスの変遷
2. 自己紹介 2 名前 澁谷 哲也（しぶたに てつや） 経歴 フロントエンドエンジニア -> MGR -> EM 役割 Chatwork株式会社 ピープルマネジメントチーム 兼 フロントエンド開発部 MGR お仕事 エンジニアに関わるピープルマ ネジメントや組織開発 紹介記事 ：https://chado.chatwork.com/entry/2021/11/02/100000
3. Chatworkの紹介 1
4. 会社概要 会社名 Chatwork株式会社 代表取締役CEO 山本 正喜 従業員数 379名（2023年3月末日時点） 所在地 東京、大阪含む全国のwework 設立 2004年11月11日 4
5. Chatworkとは 5 効率的に情報共有できる グループチャット 仕事の見える化ができる タスク管理 見落としがなくなる ファイル管理 いつでも会議ができる ビデオ/音声通話
6. 前提: 開発を取り巻く環境 2
7. 　　現在 約100名 が在籍 おおよそ エンジニア：デザイナー：PdM = 8 : 1 : 1 Chatworkの組織 7 各本部でセクションが分けられている。 プロダクト本部は以下のような職種が集まる本部門。 • エンジニア • デザイナー • プロダクトマネージャ（PdM） ※ 2023年7月現在の組織図 参考）「Chatwork会社説明資料」より抜粋 ※ 2023年7月時点での人数
8. 職能ごとに縦割りの組織 8 各部署 Projectチーム これまでは職能による縦割りな組織が主な機能開発を担当していた なにかプロダクト開発の案件があると、 大きな案件については各部署から集めたプロジェクトチームを作って いた こういった開発体制のことをプロジェクト体制と呼んでいる
9. プロジェクト体制の課題 3
10. プロジェクト体制について 10 案件ごとに各部署からメンバーをアサインしてバーチャルチームを結成する形式 • 部署・プロジェクトともに組織体制としてベーシックなため分かりやすい • 主体となる部署は技術領域ごとに分離されているため、職種内の意思疎通がしやすい ◦ フロントエンド(SPA)・モバイルアプリ・サーバーサイドという分かりやすい構成 • 一方で、以下のようなプロセスを毎回行う必要がある 起案 メンバーア サイン チームビル ディング 要件定義 ~ 開発 リリース 振り返り 解散
11. プロジェクト体制の課題 ~ 開発 ~ 11 職能別のチームが運用・保守のオーナーシップを持つため、各職能組織が技術面でのステークホル ダーになってしまう • 大半のプロジェクトで「この方針でいいか部署に持ち帰って精査しますね」が発生する • プロジェクトによっては各部署のコードレビューが必要になることも また、関連するチームや部署が多くなりがちで合意コストが大きい そのためにプロジェクトマネジメントの難易度が高く、担えるメンバーが限られる問題もあった
12. プロジェクト体制の課題 ~ 運用・保守 ~ 12 プロジェクト -> 部署への運用・保守の引き継ぎが発生してしまう • 適宜、またはプロジェクト終了後に仕様について部署に共有する必要がある • 監視体制など、負荷の大きな運用をどう行うか都度検討しなくてはならない
13. プロジェクト体制の課題 ~ チーム・組織 ~ 13 都度チームビルディングが必要となり、立ち上げのコストが高い • チームとして開発プロセスのナレッジが共有しづらい ◦ 同じような失敗を各プロジェクトで繰り返してしまう • 部署としてチーム感を出しづらい ◦ 各メンバーが何かしらのプロジェクトに参加していて、同じ仕事をしないことも ◦ 職能ごとに都度メンバーを確保するため「◦◦エンジニアがいないのでプロジェクト が進められない」になりがち ▪ リソース効率にフォーカスしてしまいやすい
14. プロジェクト型 -> スクラムへの移行 3
15. やりたいこと：DevOpsを実現した組織体系 15 開発 ~ 運用まで一貫して同じチームで責任を持ち、自律して活動できるような組織にしていきたい。 そのためにはどうすればいいだろう？ DevOpsを実現するためには、どんなチームがいいだろう？
16. DevOps体制の実現方法（How）：職能横断の固定化したチーム 16 都度PJ チームを発足させるのではなく、継続して存続できるようなチームが理想。 つまり、チームに閉じて立案・開発・運用までを一貫して担当でき、オーナーシップをもって作業が できる職能横断型の自己管理化されたチームが理想。 このような職能横断型のチームをFeature（フィーチャー）チームと呼んでいる。 開発プロセスとしてプロジェクト型 -> スクラム主体となる ※ チームの裁量に委ねるため、必ずしもスクラムである必要はない
17. フィーチャーチーム体制の実装 17 以下の3つのチームに分けていく。 • フィーチャーチーム ◦ 事業価値を創出するチーム • プラットフォームチーム ◦ フィーチャーチームの認知負荷を下げるための職能別のチーム ◦ 支援特化型 ◦ チームトポロジーの「プラットフォームチーム」とは異なる • ピープルマネジメントチーム ◦ 横串で各チームをマネジメントを担当するチーム 現状、上記体制への移行を目指し、組織を少しづつ変化させている段階。 ※ 概念図
18. 移行にあたっての課題とポイント 3
19. 巨大なワンプロダクトであるが故の難しさ Chatworkは巨大なモノリスであり、事業としても単一のアプリケーションである • リリースして12年目の歴史あるプロダクトで技術的負債も大きい • 単一のリポジトリを複数のチームで編集する必要がある • 各チームへどのように権限と責任を委譲し、オーナーシップを持ってもらうかが課題 ◦ 特にクライアントサイドはチャットという「一画面に複雑な機能が依存しあっている」性質から 分割が難しい • 現状は分割の境界面を模索しながら、切り出せる箇所を分割している段階 19
20. 巨大なワンプロダクトであるが故の難しさ 「フィーチャーチーム」と聞くと機能単位で閉じたチームが常に施策を回しているイメージが強い。 しかし、巨大なワンプロダクトにおいては、ある時点で事業として注力する領域は運用・保守が必要なシス テムに対して網羅的ではない • 機能単位で無理に分割しても、運用・保守しかしないチームができてしまう • 分割は意識しつつ、粒度や一つのチームが持つ領域のバランスは注意が必要 20
21. 運用・保守を念頭に置いたチーム設計が必要 事業の変化に対して、システムは簡単に追従できない • 施策を行う中で、方針転換が入るのは当たり前のこと • システムを作ってしまうと運用・保守が発生するため、施策の変化に追従するのに時間がかかってし まう • 施策に最適化された組織・システムを作ってしまうと、事業の状況変化によって負債化するシステム が増える危険性がある • 必ずしも施策 = チームではない 21
22. まとめ
23. プロジェクト体制 -> スクラム体制への移行の手応え 23 難易度が高いチャレンジではあるものの、一定の手応えはある • 開発プロセスとして意思疎通のコストは間違いなく下がっている • PRレビューなどチーム間の合意はまだ必要な部分はあるものの、一部ではチーム内で完結して 開発を進められている • フィーチャーチームとして独立しているチームもいくつか存在しており、チームに閉じて施策 を実行できている プロジェクト体制 / スクラム体制ともにメリット・デメリットが存在しており、組織規模や目指す開 発体制によって最適な形は異なるはず
24. より詳しく知りたい方は • 本部長の田中が「開発生産性Conference」で発表したスライドをご覧ください 24 https://speakerdeck.com/tanakayuki/huitiyatimuhua-henoqu-rizu-mito-sorewozhi-eruzu-zhi-manesimentoti-zhi
25. We're Hiring! 25 Chatworkでは、ビジネスチャットの普及、中小企業のDXを目指す仲間を募集中です！ 一緒にDevOpsなチーム体制を目指していきましょう！ • エンジニアリングマネージャー • フィーチャーチーム • サーバーサイド（PHP / Scala） • iOS • Android • フロントエンド • UIデザイナー • SRE • QA \ ご応募お待ちしております / Chatwork募集職種一覧 ページ
26. 働くをもっと楽しく、創造的に