フィーチャーチーム化への取り組みと、それを支える組織マネジメント体制

2023-07-13（木）開発生産性Conferenceでの発表内容です
Chatwork株式会社 プロダクト本部 本部長 田中佑樹

Transcript

1. Chatwork株式会社　田中 佑樹 2023年07月13日 フィーチャーチーム化への取り組みと、 それを支える組織マネジメント体制
2. 自己紹介 2 名前 田中 佑樹（たなか ゆうき） 経歴 エンジニア󰞵 ⇢ EM󰳗 誰？ Chatwork株式会社 プロダクト本部　本部長 お仕事 プロダクト人材に関わる採用や 組織開発など。 紹介記事 ：https://chado.chatwork.com/entry/2022/01/11/100000 ※ 副本部長時代の記事です
3. 今日お話する内容
4. 今日のお話：Chatworkの開発生産性への取り組みについて Chatworkでは開発生産性向上の取り組みとして、フィーチャーチーム化を目指しています。 その挑戦の現在、または未来についてお話します。 4 私達もまだまだ道半ばです。 これまでどういったTryをしてきたか？それでなにがわかったのか？を紹介します。 現在 未来
5. お伝えしたいこと • Chatworkの生産性向上の取り組み：フィーチャーチーム化について ◦ その中で、参考になりそうな部分を持ち帰っていただきたい ◦ 私達も道半ばなところはあるので、なにかアドバイスいただけるとありがたいです ◦ 仲間がまだまだ足りないので、もし興味があれば、カジュアル面談でも… 5
6. AGENDA アジェンダ Chatworkの紹介 前提 開発生産性への取り組み ~ フィーチャーチーム化 ~ フィーチャーチームでのマネジメント わかってきたこと 今後の組織体制 1 2 3 4 5 6
7. Chatworkの紹介 1
8. 会社概要 会社名 Chatwork株式会社 代表取締役CEO 山本 正喜 従業員数 379名（2023年3月末日時点） 所在地 東京、大阪 設立 2004年11月11日 8
9. コーポレートミッション 9 働くを もっと楽しく、 創造的に 人生の大半を過ごすことになる 「働く」という時間において、 ただ生活の糧を得るためだけではなく、 1人でも多くの人がより楽しく、 自由な創造性を存分に発揮できる社会を実現する
10. Chatworkとは 10 効率的に情報共有できる グループチャット 仕事の見える化ができる タスク管理 見落としがなくなる ファイル管理 いつでも会議ができる ビデオ/音声通話
11. 前提 2
12. 組織のお話
13. 　　現在 約100名 が在籍 おおよそ エンジニア：デザイナー：PdM = 8 : 1 : 1 Chatworkの組織 13 各本部でセクションが分けられている。 プロダクト本部は以下のような職種が集まる本部門。 • エンジニア • デザイナー • プロダクトマネージャ（PdM） ※ 2023年7月現在の組織図 参考）「Chatwork会社説明資料」より抜粋 ※ 2023年7月時点での人数
14. 職能で縦割りの組織 14 現状のベースとなっている部分は職能ごとに縦割りの組織体系。 • フロントエンド開発部 • モバイルアプリケーション開発部 • サーバーサイド開発部 • etc... 「何ができるか？」によって部署が分けられている。 14
15. システムのお話
16. 高い非機能要件 16 • ビジネスチャットという特性上、トラフィック量は他社SaaSに比べて多い傾向 • 現状でも約40万社、DAU100万以上のユーザーに使っていただいているサービス • サービスの特性上、Chatworkが使用できない = 業務が止まる、影響度が大 ◦ Reliabilityの担保も非常に重要 → パフォーマンスとReliabilityをどちらも高いレベルで担保する必要がある 現状のトラフィック量 www.chatwork.comのCloudFrontのメトリクス。 リクエスト量が現時点で毎分880kほど。 秒間約15kのリクエストをさばいている。 利用ユーザーの多さ 導入社数 ※ 2022年12月期 本決算資料から引用 38.6万 登録ID数 574.1万 DAU 105.3万
17. リリースして12年目の歴史あるプロダクト 17 Chatworkは2011年にリリースし、現在で12年目。 現状は一つの巨大なモノリスのシステム上でChatworkのほぼすべての機能が実装されている。 • 10年以上運用しているサービスのため、技術的負債がたまっている状況 • 人数が増えれば増えるほど、同一のシステムを触るためコミュニケーションが複雑になる • 巨大ゆえ認知負荷が非常に高くなりやすい、事故に繋がりやすい、変更・追加が困難 → 現状は開発速度が低下しやすい状況 → その打ち手として、現在数年がかりのリプレイスPJが進行中 現状
18. 開発生産性への取り組み ~ フィーチャーチーム化 ~ 3
19. 現状の課題感
20. 職能ごとに縦割りの組織 20 各部署 Projectチーム 現状、職能による縦割りな組織。 なにかプロダクト開発の案件があると、 大きめな案件については各部署から集めたプロジェクトチームを 作っていた。 こういった開発体制のことをプロジェクト体制と呼んでいます。
21. プロジェクト体制あるある 21 プロジェクト体制のあるあるプロジェクト風景 • （案件が起案される） • EM「（このProjectするには、ここらへんの人や、こういった人材必要そうだな）」 • EM「すみません、部署AのMGRさん、XXXさんをXXX案件にアサインしていただけます か？」 ◦ （上記をアサインメンバー分繰り返す） • メンバー集まった！キックオフMTGや！プロジェクトスタート！ 〜〜〜プロジェクト進行中〜〜〜 • ついにリリース！やったー！！お疲れ様！！！！ • 解散！！！！
22. プロジェクト体制あるある 22 プロジェクト体制のあるあるプロジェクト風景 • （案件が起案される） • EM「（このProjectするには、ここらへんの人や、こういった人材必要そうだな）」 • EM「すみません、部署AのMGRさん、XXXさんをXXX案件にアサインしていただけます か？」 ◦ （上記をアサインメンバー分繰り返す） • メンバー集まった！キックオフMTGや！プロジェクトスタート！ 〜〜〜プロジェクト進行中〜〜〜 • ついにリリース！やったー！！お疲れ様！！！！ • 解散！！！！ 各部署に人員確保のため行脚
23. プロジェクト体制あるある 23 プロジェクト体制のあるあるプロジェクト風景 • （案件が起案される） • EM「（このProjectするには、ここらへんの人や、こういった人材必要そうだな）」 • EM「すみません、部署AのMGRさん、XXXさんをXXX案件にアサインしていただけます か？」 ◦ （上記をアサインメンバー分繰り返す） • メンバー集まった！キックオフMTGや！プロジェクトスタート！ 〜〜〜プロジェクト進行中〜〜〜 • ついにリリース！やったー！！お疲れ様！！！！ • 解散！！！！ 都度チームビルディングが必要
24. プロジェクト体制あるある プロジェクト体制のあるあるプロジェクト風景 • （案件が起案される） • EM「（このProjectするには、ここらへんの人や、こういった人材必要そうだな）」 • EM「すみません、部署AのMGRさん、XXXさんをXXX案件にアサインしていただけます か？」 ◦ （上記をアサインメンバー分繰り返す） • メンバー集まった！キックオフMTGや！プロジェクトスタート！ 〜〜〜プロジェクト進行中〜〜〜 • ついにリリース！やったー！！お疲れ様！！！！ • 解散！！！！ 24 機能改善・運用主体の責任が不明確になりやすい
25. 1. イニシャルコストが高くなりやすい ◦ 各部署の事情を考慮してメンバーアサインが必要 ◦ PJのたびにメンバーが異なるので、都度チームビルディングが必要 2. 運用主体が不明確になりやすい、ボールが落ちやすい ◦ 誰の持ち物？問題 プロジェクト体制の問題点 25 問題点まとめ
26. 現在の取り組み ~ フィーチャーチーム体制 ~
27. やりたいこと：DevOpsを実現した組織体系 27 開発〜運用まで一貫して責任を持ったチームを用意し、自律して活動できるような組織にしていきたい。 そのためにはどうしたらよいか？ = DevOpsを実現するためには、どうしたらよいか？
28. DevOps体制の実現方法（How）：職能横断の固定化したチーム 28 都度PJ チームを発足させるのではなく、継続して存続できるようなチームが理想。 つまり、チームに閉じて立案・開発・運用までを一貫して担当でき、オーナーシップをもって作業が できる職能横断型の自己管理化されたチームが理想。 このような職能横断型のチームをFeature（フィーチャー）チームと呼んでいる。
29. フィーチャーチーム体制の実装 29 以下の3つのチームに分けていく。 • フィーチャーチーム ◦ 事業価値を創出するチーム • プラットフォームチーム ◦ フィーチャーチームの認知負荷を下げるための職能別のチーム ◦ 支援特化型 • ピープルマネジメントチーム ◦ 横串で各チームをマネジメントを担当するチーム 現状、上記体制への移行を目指し、組織を少しづつ変化させている段階。 ※ 概念図
30. チームトポロジーとの関係性 30 チームトポロジー本でいうと… ※ チートポ本が出る前の構想だったので、名前が一致していません・・・。
31. フィーチャーチーム体制に向けた大きな課題：チームをどう分ける？ 31 チームトポ本 / Chapter 5 ストリームアラインドチームより > ストリームアラインドチームは価値のある単一の仕事のストリームに沿って働くチームで、 ストリームとは、仕事やサービスの場合もあるし、機能一式のこともあり、ユーザジャーニー やユーザペルソナの1つのような場合もある Chatworkは歴史的な積み重ねもあり、機能としては膨大。 システムを網羅的に保守していくためにも機能でもチームを分けていきたい。 では、どう分ける？
32. 前提：巨大なモノリスのシステム＆現在システムリプレイス中 32 逆コンウェイ戦略に沿って、アーキテクチャ分割をし、そこにチームを割り当てていくのが 王道パターン。 しかし、現在はシステムリプレイスが継続中。 スコープを区切りながら少しづつすすめているため、完全なる移植は先。 つまり、現状の状態ですすめるとしたらモノリスなアーキテクチャ上でフィーチャーチームを作る 必要がある。 モノリスなアーキテクチャでチームを分割すると、同じシステムを複数チームで触ることになるため コミュニケーションが煩雑になりやすい。
33. 適切な責任分解点を設定できる部分から分けていく 33 できるところからやっていく • システムは同じでも、コミュニケーションを（完全ではないせよ）疎にできる境界があるはず • その点を探りながら、フィーチャーチームを作っていく そのためには、現在のアプリケーションの深いドメイン分析が必要不可欠。 現時点でのTry
34. 適切な責任分界点？ 34 Chatworkでは分け方をいくつか試しながら現状の3つのチームを形成。 • 決済・料金プランチーム • 認証チーム • APIチーム ただし、まだ全機能に対してチームの保守範囲が網羅できているわけではない。 残りの部分は今まで通り、プラットフォームチーム（職能別のチーム）で保守運用〜開発をしている 状況。
35. 現状のフィーチャーチーム体制 35 ポイント • モバイル、フロントエンドなど、 職能別の部署はプラットフォーム チームとみなしている • フィーチャーチームはそれごとに 部署化しているわけではなく、 部署内のチームとして表している • フィーチャーチーム専属のMGRが ピープルマネジメントをしている • プラットフォームチームのMGRは 現時点ではプレイングマネージャ がほとんど（いずれはピープルマネジメントチームで見ていきたい）
36. フィーチャーチームでのマネジメント 4
37. フィーチャーチーム体制でのマネジメント 37 ここの話
38. 旧来のマネジメント体制 38 • 職能別の組織 • それぞれの部署にMGR（プレイングマネージャー）がついていた フィーチャーチームではどうするか？ いままで
39. フィーチャーチームにおけるマネジメント体制 39 案：フィーチャーチームそれぞれにEMをつける？ • 評価者を現場のチームにいれたくない ◦ 自律性を保つため ◦ Gorilla in the Room • そんなにEMいない ◦ 採用市場でも非常に希少 • MGR大変過ぎ問題 ◦ 技術的な素養に加え、ピープルマネジメントの能力も必要 ◦ 場合によっては、加えてプロジェクトマネジメントもする必要あり 問題点
40. 現在は以下のような体制を目指している • ピープルマネジメント特化のチームを作り、外からマネジメントする • このような体制をピープルマネジメント体制と呼んでいる フィーチャーチームにおけるマネジメント体制 40
41. • EMのリソース効率がよい ◦ 少ないEM人数でより多くのマネジメントができる • 冗長化が可能 ◦ 複数人でマネジメントをチームで行える • チームへの干渉を低減できる ◦ チームに自治権を与えることができる • VPoEに近い職能になるので、ハードルが高い • プレイングとマネージメントを両立したい人のキャリアパス的には不向き Why？ピープルマネジメント体制 41 メリット デメリット
42. ピープルマネジメントチームの責務 42 ピープルマネジメント業務に特化。各チームが自律性をもってうまくワークするためのサポート。 メリット • メンバーのメンタリング • 目標設定、考課査定 • 勤怠管理 • 稟議などの承認 • 予算管理 • チーム間、チーム外に落ちたボールを拾う • 採用、チームメンバーのアサインメント ※ 参考：弊社ブログ「開発組織でピープルマネージャーをやっている」 具体的な業務範囲
43. フィーチャーチームとピープルマネジメントチームの関わり 43 フィーチャーチームは経営戦略に沿った戦略実行に責務を持つ。 それらを技術的にプラットフォームチームがサポート、 人やもの、Ops整理をピープルマネジメントチームがサポートしていく。
44. その他：フィーチャーチームでの運用 （Appendix的なもの）
45. Q. フィーチャーチームの開発プロセスは？ 45 基本的にはスクラムを採用しているケースがほとんど。 POとスクラムマスターを配置し、自律的に動けるようなチームを目指している。 中にはカンプラン、ウォーターフォールの開発プロセスを選択しているチームもいる。 チームの色に合わせて各チームがそれぞれ開発プロセスを選択している。
46. Q. 各チーム間のコミュニケーションはどうしていますか？ 46 チーム横断の連携手段としての会議体が存在。代表的なものが3種類。 チーム内では解決できない課題、相談事項が各チームから持ち込まれる。 • MetaScrum ◦ プロダクトの優先順位など、戦略について話し合われる場 ◦ 　　　　PO、PdMなど、意思決定者 • EAT（Executive Action Team） ◦ 戦術について話し合われる場（現場で意思決定可能なもの） ◦ 　　　　ScM、エンジニアなど、チームの代表者 • MGR定例 ◦ 人や組織について話しあわれる場（人事系のセンシティブな内容も扱う） ◦ 　　　　各部署MGR + ピープルマネージャ （※ MetaScrumやEATについてはScrum@Scaleの考え方を参照し取り入れている） 参加者 参加者 参加者
47. Q. 各チーム間のコミュニケーションはどうしていますか？ 47 （その他補足事項） • EATはチームメンバーの補填、教育訓練などの人に関しての話題も取り扱うことがある • すべての話題がどこかにきれいに収まることはなく、「どちらで取り扱うべきか？」という グラデーションはある ◦ その場合は、とりあえずどこかの会議体に持っていき、適切な場を都度決める （場合によっては臨時の別会議体を開催） • 議題の共有範囲 ◦ MetaScrum、MGR定例：共有議事録を別途作成し、全体へ共有 ▪ まだ秘匿にする必要のあるリリース情報や人事情報などを取り扱うため ◦ EAT：基本全共有、参加も自由参加にして開放している ◦ すべてに共通していることは、議事録を作り誰でも閲覧可能な状態を作っている
48. わかってきたこと 5
49. 現状のフィーチャーチーム体制での課題感 49 巨大なモノリスなシステムのうえでフィーチャーチームを作ろうとしているので、課題感も大きい。 特に、以下の2つの課題感が大きい。 1. 担当者不在 2. スキルがチームに閉じない 課題があるのは当然なので、どこかで妥協点を探るしかない。
50. 現状のフィーチャーチーム体制での課題感：担当者不在 50 先ほども言及した通り、全機能に対してチームの保守範囲が網羅できているわけではない。 また、全機能に対して網羅的にフィーチャーチームを用意する場合、分け方次第ではあるが人員は 多く必要になりやすい。（リソース効率よりフロー効率を重要視する考え方のため） そのため担当不在機能の運用保守については、以前までと同様のスタイルで、職能別の組織（プラッ トフォームチーム）にまかせている。
51. 現状のフィーチャーチーム体制での課題感：スキルがチームに閉じない 51 チームでの獲得が難しい職能について、その職能に関しては外部に依存する必要がある。 その職能を持った専門家をチームにアサインすればいい話だが、特に専門性の高い職能は人が足りな い状況が続いており、外部チーム（プラットフォームチーム）に依存している。 特に獲得の難しいスキルセット • デザイン ◦ 基本はエンジニア中心のチームになるため、スキルセットがかなり異なる • モバイルアプリケーション開発 ◦ プラットフォーマー依存のノウハウ
52. 現状のフィーチャーチーム体制での課題感：スキルがチームに閉じない 52 スキル獲得の問題については、専門家を各フィーチャーチームに専任でアサインするのが理想。 だが、現実問題そこまで多くの人材を獲得するのが難しい。 そのため、現時点ではリソース効率を重要視するための対応を取っている。 • 派遣型：一時的にフィーチャーチームへ専門家を派遣する（期間限定） • 受諾型：フィーチャーチームからプラットフォームチームへタスク依頼 また、今後は各チームに専門家をアサインすることになるが、そうなると各専門家が単独でバリュー を出せるような環境づくりも必要になってくる。 例） • デザインシステム • デザインガイドライン これらは、各デザイナーが自律して動けるようになるための道具
53. うまくワークしているフィーチャーチーム 53 逆に、うまくワークしているチームの特徴も見えてきている。 やはり、うまくいってそうなチームは「チームで閉じている」。 • コミュニケーションがチームで閉じている ◦ ステークホルダーが外部にすくない • スキルがチームに閉じている ◦ 他チームの助けを借りずに自分たちで自走できる 他にもいろいろな変数が存在するが上記の条件が圧倒的に変数としては大きい。
54. じゃあチームに閉じればいいじゃない？ 54 現実、そうもいかない。 • 人が足りない問題 ◦ フィーチャーチーム化をする上では、人員が多く必要となりやすい ◦ リソース効率よりもフロー効率が優先されやすい（とくに移行段階ではそう感じる） • スキルのばらつき ◦ 特に獲得がむずかしい専門スキル：デザイン・モバイル 限られた人員の中で妥協点を探るしかない。
55. ジェネラリスト的な人材が合いやすい。 • フィーチャーチームでは様々な職能が必要とされやすい • そのため、ある軸のみのスペシャリストよりは、広く対応できるような人がよい • T型人材と呼ばれるような人たち とはいえ、ジェネラリストだけではだめで、プロダクト開発には先程あげたような専門性の高い人材 も必要。（モバイル、デザイン等） マインドセットとして、「私はこれしかやりません」というマインドはNG。 フィーチャーチームに適した人材 55
56. 現状のフィーチャーチーム体制での課題感：まとめ 56 完全ではないが、徐々にフィーチャーチーム化は進んでおり、そのうえでの痛みもわかってきた。 システムがモノリスな状態で進めているがゆえに妥協点も探る必要がある。 1. プラットフォームチームへの人員強化 2. フィーチャーチーム化できる責任分界点の模索 3. フィーチャーチーム作成（プラットフォームチームからの異動、外からの採用、etc...） 上記を繰り返しながら、フィーチャーチームで閉じて運用保守ができる範囲を広げていく。
57. 今後の組織 6
58. アーキテクチャ分割していきながらフィーチャーチーム化を目指す 58 そのために必要なもの（足りていないもの） • 適切な責任分界点で分けられたシステム • 人員 / 組織能力
59. フィーチャーチームがうまくワークする環境 59 とにかくチームに閉じて行動できるような環境を目指す。 • 意思決定がチームに閉じるように（戦略カスケーディング / POの責任範囲明確化） • スキルがチームに閉じるように（必要なスキルセットの特定、イネーブル、専門家のアサイン） かつ、自立して動けるような準備も必要。 • 専門家が単独でバリューを発揮できるように（ガイドライン整備など、自立して動ける環境整備） かつ、チームに閉じすぎたときのサイロ化の暗黒面をできるだけ避ける。 • 各職能別のギルドの立ち上げ（すでにボトムアップ的に複数チーム立ち上がっている） • MetaScrum / EATなどによる横の連携
60. 専門家の関わり方 60 チーム内にどっぷり入り込むか、派遣型でそのチームに能力がつくようにイネーブルするかは、獲得した い能力やチームの状況によって異なる。 例えば、セキュリティのような能力は（程度の差はあれ）各エンジニアに一定レベル獲得済みの状態、 それであれば横串のセキュリティチームが各フィーチャーチームにイネーブルするだけでもいいかもしれ ない。 これらは組織の状態やチームの状況によりけり。現在の状態を正確に捉えて使い分ける。
61. まとめ
62. 開発生産性向上への道のりは険しい 62 Chatworkの取り組みについて紹介しました。 正直、まだまだ道半ばです。 特に弊社のような歴史もあり巨大なシステムだと、一筋縄ではいかない状況です。 ですが、現在の状態をしっかりと把握し、できるところから一歩一歩あゆみ始めることもできています。
63. 目指すべきはユーザーへの価値提供ができる組織へ 63 なぜ、ここまで大変なことをしているのか？ 目的はDevOps能力の獲得、それによるユーザーへの価値提供です。 リードタイムをできる限り短くし、価値を提供し続けられる環境を用意したい。 弊社のエンジニア、デザイナー、PdMがユーザーへの価値提供を通じて自己実現できるような環境を用意 したい。 そのために、私達はこれからも学習し、変化し、適応し続けていきます。
64. We're Hiring! 64 Chatworkでは、ビジネスチャットの普及、中小企業のDXを目指す仲間を募集中です！ 一緒にDevOpsなチーム体制を目指していきましょう！ • エンジニアリングマネージャー • フィーチャーチーム • サーバーサイド（PHP / Scala） • iOS • Android • フロントエンド • UIデザイナー • SRE • QA \ ご応募お待ちしております / Chatwork募集職種一覧 ページ
65. 働くをもっと楽しく、創造的に