認知負荷で考えるフロントエンドの組織体制

こちらは2023年9月21日に開催された「フロントエンドの開発生産性〜オンラインカンファレンス〜」の登壇資料です。
https://findy.connpass.com/event/294482/

チームトポロジーという書籍には「チームの認知負荷を制限することが重要である」という話があります。Chatworkは、安全に速くリリースできる開発体制を目指して、従来の職能別組織から職能横断型組織への移行を目指しています。しかし巨大なワンプロダクトという特性から、認知負荷とどのように向き合うかが大きな課題となっています。

このセッションでは、Chatworkで実際に向き合っている課題に触れながら、職能型の組織を職能横断の組織に移行する際の課題や考慮すべきポイントについてお話したいと思います。

Transcript

1. Chatwork株式会社 澁谷 哲也 2023年09月21日 認知負荷で考える フロントエンドの組織体制
2. 自己紹介 2 名前 澁谷 哲也（しぶたに てつや） 経歴 フロントエンドエンジニア -> MGR -> EM 役割 プロダクト本部 ピープルマネジメントチーム 兼 フロントエンド開発部 MGR お仕事 エンジニアに関わるピープルマ ネジメントや組織開発 紹介記事 ：https://chado.chatwork.com/entry/2021/11/02/100000
3. Chatworkについて 1
4. Chatworkとは 4 効率的に情報共有できる グループチャット 仕事の見える化ができる タスク管理 見落としがなくなる ファイル管理 いつでも会議ができる ビデオ/音声通話
5. 従業員数の推移 5 • 2020年頃から、従業員数の増加ペースがアップ • 2022年9月には300人を超え、従業員数は上場時の約3倍に 25人 25人 56人 77人 89人 91人 107人 162人 251人 312人 411人 2011/3 法人化 （設立） 13人 Chatwork リリース 2015/4 シリーズA 3億 2016/1 シリーズB 15億 マザーズ 上場 2004/11 2005 2008 2011 2015 2016 2017 2018 2019 2020 2021 2022 2023/6* *2023年度からグループ従業員数
6. 組織構造 プロダクト本部について メンバー エンジニア、デザイナー、プロダクトマネージャーが所属 現在約100名が在籍 エンジニア：デザイナー：プロダクトマネージャー = 8:1:1 ※おおよその比率 6 人数 人数比率
7. ChatworkのWebFrontendの特徴 7 • 巨大なSPA、かつ利用中ほとんどリロードされずに使われるアプリケーション • 双方向性があり、ユーザーからのアクション以外で状態が変わる • JavaScriptだけで16万行 • CSSも1万7千行 ◦ Styled-Componentを利 用しているため、実際に はもっと多い 巨大なコードベース • ブラウザベースのアプリケー ションとしては珍しく、URL単 位でアプリケーションとして分 割されていない • 再読み込みのない一枚のページ で全UIが動作している 純粋なSinglePageApplication • Webサイトベースの「入力 -> 確認 -> 完了」と情報が一方向な Webアプリではない • Google SpreadSheetのような GUIアプリとしての複雑さを持 つ GUIアプリとしての複雑性
8. 目指す開発体制と課題 2
9. 職能ごとに縦割りの組織 9 各部署 Projectチーム これまでは職能による縦割りな組織が主な機能開発を担当していた なにかプロダクト開発の案件があると、 大きな案件については各部署から集めたプロジェクトチームを作って いた こういった開発体制のことをプロジェクト体制と呼んでいる
10. 職能横断型の組織に移行したい • 組織拡大に伴い、開発チームも拡大が急務 • 職能別チームだとスケールできる人数には限りがある ◦ 全員がそれぞれ違う施策を担当する ◦ 単純にリソース貸出所のようになってしまう懸念 • 職能ごとに運用・保守が分散しているため、各部署に合意形成が必要になる ◦ 「この要件だとXXの懸念があるので、一旦部署に持ち帰りますね」が起きる ◦ 部署ごとにやることの優先度がつけられているため、ボトルネックが発生すると全施策に影響する • 施策に対するコミュニケーションパスを減らし、運用・保守を含めてスケールするチーム体制にしたい ◦ 職能別のチーム体制 -> 職能横断のチームを複数作る体制へ 10 モバイルアプリ WebFrontend サーバーサイド 職能横断チーム 職能横断チーム 職能横断チーム
11. 巨大なワンプロダクトであるが故の難しさ Chatworkは巨大なモノリスであり、事業としても単一のアプリケーションである • WebFrontendにおける主戦場はChatworkのコア機能であるチャット画面 ◦ リリースして12年目の歴史あるプロダクトで技術的負債も大きい • モジュール分割はできたとして、単一のモジュールとしてチームを運用する旨味が少ない • スケールするためには、単一のリポジトリを複数のチームで編集する必要がある ◦ これまで1チームで開発していたコードを複数チームで開発できるようにしなくてはならない 11 どうやって巨大なワンプロダクトで職能横断型の組織に移行すればいいだろう？
12. 「認知負荷」を手がかりにする
13. 認知負荷とは何か • 1988年に心理学者ジョン・スウェラーが提唱した概念 • 人間の脳はある瞬間に脳に留めておける情報量に限りがある ◦ チームも同じ • チームの責任範囲と担当範囲が広がりすぎると、自分の仕事に熟達する余裕がなくなり、担当業務のコンテキストス イッチに悩まされる • 我々は昔から伝統的な階層構造で認知負荷をコントロールしてきたとも考えられる • 認知負荷を分割しないと組織としてパフォーマンスを発揮できなくなる 13 参考元: マシュー・スケルトン (著), マニュエル・パイス (著), 原田 騎郎 (翻訳), 永瀬 美穂 (翻訳), 吉羽 龍太郎 (翻訳) (2021)『チームトポロジー』日本能率協会マネジメントセンター
14. 認知負荷の種類 • 3種類に分類される • 付加価値があるのは課題内在性負荷と学習関連負荷 ◦ 課題内在性負荷は最小限に抑える ◦ 課題外在性負荷は取り除く • あくまで「学習効果」についての話であり、組織設計として必要か不要かという話ではない 14 名前 説明 例 課題内在性負荷 問題領域の本質的な複雑さ ユーザー課題や要件 課題外在性負荷 その問題を解決することを妨げたり、間接的に複 雑さを与えるもの どのようにデプロイを行うか 学習関連負荷 対象を理解するために発生する負荷 ドメイン固有の知識や技術 参考元: マシュー・スケルトン (著), マニュエル・パイス (著), 原田 騎郎 (翻訳), 永瀬 美穂 (翻訳), 吉羽 龍太郎 (翻訳) (2021)『チームトポロジー』日本能率協会マネジメントセンター
15. 認知負荷を下げるためのチームタイプ • 4つのチームタイプが定義されている ◦ 3つのインタラクションモードについては今回は割愛 • 今回のスライドでは下記の用語として定義する(太字がこのスライドで登場するチームタイプ) ◦ 社内でも認識が揃っていないケースがある 15 タイプ名 役割 関連する認知負荷 ストリームアラインド アプリケーションにおける価値を提供する (信頼性など、事業価値以外も含まれる) 課題内在性 プラットフォーム ストリームアラインドに直接関係ない領域をプラットフォームとして提 供する 課題外在性 イネイブリング ストリームアラインドチームの能力ギャップを埋めるための支援をす る 学習関連負荷 コンプリケイテッド・サブシス テム 複雑で専門性の高い領域を閉じることで外部から利用しやすくする 課題外在性 参考元: マシュー・スケルトン (著), マニュエル・パイス (著), 原田 騎郎 (翻訳), 永瀬 美穂 (翻訳), 吉羽 龍太郎 (翻訳) (2021)『チームトポロジー』日本能率協会マネジメントセンター
16. どうやって認知負荷を下げる？ 3
17. これまでの体制 • 職能別チームは「全てのWebFrontendに関わる領域」を担当している • 認知負荷がとても大きい • 主戦場はChatworkアプリだが、普段は保守をしていない領域も暗黙的に担当している 17 WebFrontend チーム Chatwork アプリ ログイン 管理画面 … …
18. WebFrontendをプラットフォームチーム化する • 「価値に直接貢献する」チームとそれを支援するチームに分割する ◦ チームトポロジーの「ストリームアラインドチーム」と「プラットフォームチーム」を分割する 18 WebFrontend チーム Chatwork アプリチーム Chatwork アプリ ログイン 管理画面 … … Chatwork アプリ
19. Chatwork アプリチーム 切り出せる領域は切り出す • 他の領域をプラットフォームチームとして切り出す • 基盤として切り出せる箇所はコードとしても分離しやすい 19 WebFrontend チーム 認証基盤 チーム Chatwork アプリ ログイン 管理画面 … … ログイン
20. Chatwork アプリチーム まだ大きな認知負荷を抱えるチームが残る • 主戦場だったChatworkアプリ自体は巨大なまま分割されていない • チームのサイズも大きくなるため、複数チームで開発できるようにしなくてはならない 20 WebFrontend チーム 認証基盤 チーム Chatwork アプリ 管理画面 … … ログイン
21. コンポーネントチームとフィーチャーチーム • Chatworkアプリを複数チームで開発する方法として、コンポーネントチームとフィーチャーチームが考えられる • コンポーネントチーム ◦ 1つのチームが単一のコンポーネントを扱う ◦ 施策によってはコンポーネントを横断する必要があり、他のチームと協力する必要がある ◦ チーム単体でユーザー価値がデリバリーできるとは限らない • フィーチャーチーム ◦ ユーザー価値の提供を目的としたチーム ◦ コンポーネントを持たず、複数のコンポーネントを横断して開発する ◦ クロスファンクショナル & クロスコンポーネント ◦ 難易度が高い ◦ (https://featureteamprimer.org/jp/) • 社内でも用語の認識が揃っていないケースがある 21 参考元: 常松 祐一 (著), 川口 恭伸 (監修), 松元 健 (監修) (2023)『アジャイルプラクティスガイドブック 』翔泳社
22. コンポーネントチームとフィーチャーチーム コンポーネントチーム 22 フィーチャーチーム メッセージ ルーム 検索 チーム A チーム B チーム C 機能開発 A 機能開発 B 機能開発 C メッセージ ルーム 検索 チーム A チーム B チーム C 機能開発 A 機能開発 B 機能開発 C 参考元: 常松 祐一 (著), 川口 恭伸 (監修), 松元 健 (監修) (2023)『アジャイルプラクティスガイドブック 』翔泳社
23. コンポーネントチームとフィーチャーチーム、どちらがいいか • 「巨大なワンアプリである」というところに難しさがある ◦ 1つのチームが1つのコンポーネントに閉じて開発するのは現実的ではない ◦ ストリームアラインドチームを分割してもコミュニケーションパスが増えるだけ ▪ 課題内在性が減るわけではない ◦ 少なくともチームとして適切な境界面は現時点で見つかっていない • 課題外在性としての認知負荷はプラットフォームとして切り出しつつ、メインとなるチャットアプリ部分はフィーチャー チーム体制を敷く、というのが現時点ではよさそう ◦ 今後、事業環境の変化やドメインへの分析が進むことで方針が変わる可能性がある 23
24. 晴れて認知負荷を下げることができました、めでたしめでたし....? • ではない • ここまでは「現時点での理想のチーム境界」の話 • システムを運用・保守している以上、チームを分割するためには様々な考慮が必要になる • 体制としては道半ばなものの、現時点で組織として向き合った課題や、フィーチャーチームを組織する上での考慮ポイン トをご紹介したい 24
25. 職能別チームと フィーチャーチームの連携における考慮ポイント 4
26. 現在の体制 • フィーチャーチームとしてPMと連携して施策を進めているのがChatworkアプリチーム ◦ 現在は事業戦略上、グロースに注力したチームになっている ◦ 運用・保守やリファクタリング系のタスクはまだWebFrontendチームが担っている状態 ◦ チームトポロジーのプラットフォームチームになれていない 26 Chatwork アプリチーム WebFrontend チーム Chatwork アプリ 管理画面 … … Chatwork アプリ フィーチャーチーム プラットフォームチーム
27. コードのオーナーシップの問題 • 一番問題になりやすいのが「コードレビューをどう行うか」 ◦ フィーチャーチームの人数が増えるほど、職能別チームにレビュー負荷がかかる構図になる ◦ フィーチャーチーム内でレビューが完結する仕組みを作ることが重要 ▪ 既存のコードに精通したメンバーにフィーチャーチームへ参加してもらう ▪ 難しい場合はメンターとしてフィーチャーチームを支援する ◦ 現在はChatworkアプリチームに閉じてレビューが実現できている • スケールした際に全体のアーキテクチャに対してどのように意思疎通を行うかは課題 ◦ チーム横断で課題感や情報共有ができるギルドを結成する、といった仕組みもセットで検討が必要 27 タスク ルーム 検索 リポジトリ Chatwork アプリ WebFrontend レビュー依頼
28. 施策と技術領域のバランス問題 • フィーチャーチームではWebFrontend以外にも、サーバーサイドやモバイルアプリも触る必要がある ◦ フルスタックな志向性を持つメンバーがフィーチャーチームに向いている • 一方で、事業として注力するべき施策が全ての領域をカバーしているとは限らない ◦ 「モバイルの招待数を増やしたいので、iOS / Androidに注力します」はあり得る • 職能別組織では経験しづらい他領域の開発ができる反面「慣れないうちに触る機会が減ってしまった」という状態にな ることも ◦ 触れる機会が少ないと忘れてしまい、定着しづらい • チーム内で希望する領域に関わるための仕組みや、自分の軸ではない領域を積極的にキャッチアップできる仕組みづく りが必要 28
29. コンテキストスイッチの問題 • 自身が得意でない言語を触ったり、一つの施策で領域を横断して開発するとコンテキストスイッチが発生する ◦ サーバーサイドはPHP、WebFrontendはTypeScript、モバイルはSwift, Kotlin ◦ 現在は人数が増えたこともあり、自分の得意領域を軸にして余力があれば他の領域に関与していくスタイルに • 最適な開発体制は模索中 29
30. 安全にリリースするためにこれらが重要 • レビュー負荷をできるだけ下げつつ、複数チームで開発するためには安全性を担保する仕組みが重要 ◦ 複数チームで安全に触るための仕組み ◦ エラーにすぐ気づくための仕組み ◦ 万が一不具合がリリースされてもすぐに切り戻せる仕組み 30 https://speakerdeck.com/shibe23/ju-da-naspanoji-shu-de-fu-zhai-toxiang-kihe-isok-kerutekunituku
31. まとめ • 巨大なワンプロダクトにおいては、境界を区切って認知負荷を下げる部分と、ある程度の認知負荷を抱えながらもデリバ リーを最大化するために方向性の模索が必要な領域がある • 職能別組織からの移行は、コードのオーナーシップを委譲し、複数チームで共同して開発していくための仕組みづくりが 重要 • 全てがきれいに分割できるわけではなく、一つ一つの改善を泥臭く積み重ねていくことが大事 ◦ スケールする組織を目指すには技術だけでなく、組織・文化と向き合う必要がある ◦ コードを適切に分割できればすべてがうまくいくわけではない • 組織体制の構築は、事業、システム、メンバーそれぞれの観点を持つことが大事 ◦ 地道にコツコツと改善しています 31
32. 最後に • Chatworkではフロントエンドエンジニア、フィーチャーチームで活躍いただける方を募集しています • 一緒に組織の課題と向き合い、進み続けてくださる方、ぜひご応募ください 32 採用ページはこちら
33. 働くをもっと楽しく、創造的に