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