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

Transcript

1. Chatwork株式会社 澁谷 哲也
   2023年09月21日
   認知負荷で考える
   フロントエンドの組織体制
   

   View Slide

2. 自己紹介
   2
   名前 澁谷 哲也（しぶたに てつや）
   経歴 フロントエンドエンジニア ->
   MGR -> EM
   役割 プロダクト本部
   ピープルマネジメントチーム
   兼 フロントエンド開発部 MGR
   お仕事 エンジニアに関わるピープルマ
   ネジメントや組織開発
   紹介記事
   ：https://chado.chatwork.com/entry/2021/11/02/100000
   

   View Slide

3. Chatworkについて
   1
   

   View Slide

4. Chatworkとは
   4
   効率的に情報共有できる
   グループチャット
   仕事の見える化ができる
   タスク管理
   見落としがなくなる
   ファイル管理
   いつでも会議ができる
   ビデオ/音声通話
   

   View Slide

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年度からグループ従業員数
   

   View Slide

6. 組織構造
   プロダクト本部について
   メンバー エンジニア、デザイナー、プロダクトマネージャーが所属
   現在約100名が在籍
   エンジニア：デザイナー：プロダクトマネージャー
   = 8:1:1 ※おおよその比率
   6
   人数
   人数比率
   

   View Slide

7. ChatworkのWebFrontendの特徴
   7
   ● 巨大なSPA、かつ利用中ほとんどリロードされずに使われるアプリケーション
   ● 双方向性があり、ユーザーからのアクション以外で状態が変わる
   ● JavaScriptだけで16万行
   ● CSSも1万7千行
   ○ Styled-Componentを利
   用しているため、実際に
   はもっと多い
   巨大なコードベース
   ● ブラウザベースのアプリケー
   ションとしては珍しく、URL単
   位でアプリケーションとして分
   割されていない
   ● 再読み込みのない一枚のページ
   で全UIが動作している
   純粋なSinglePageApplication
   ● Webサイトベースの「入力 ->
   確認 -> 完了」と情報が一方向な
   Webアプリではない
   ● Google SpreadSheetのような
   GUIアプリとしての複雑さを持
   つ
   GUIアプリとしての複雑性
   

   View Slide

8. 目指す開発体制と課題
   2
   

   View Slide

9. 職能ごとに縦割りの組織
   9
   各部署
   Projectチーム
   これまでは職能による縦割りな組織が主な機能開発を担当していた
   なにかプロダクト開発の案件があると、
   大きな案件については各部署から集めたプロジェクトチームを作って
   いた
   こういった開発体制のことをプロジェクト体制と呼んでいる
   

   View Slide

10. 職能横断型の組織に移行したい
    ● 組織拡大に伴い、開発チームも拡大が急務
    ● 職能別チームだとスケールできる人数には限りがある
    ○ 全員がそれぞれ違う施策を担当する
    ○ 単純にリソース貸出所のようになってしまう懸念
    ● 職能ごとに運用・保守が分散しているため、各部署に合意形成が必要になる
    ○ 「この要件だとXXの懸念があるので、一旦部署に持ち帰りますね」が起きる
    ○ 部署ごとにやることの優先度がつけられているため、ボトルネックが発生すると全施策に影響する
    ● 施策に対するコミュニケーションパスを減らし、運用・保守を含めてスケールするチーム体制にしたい
    ○ 職能別のチーム体制 -> 職能横断のチームを複数作る体制へ
    10
    モバイルアプリ
    WebFrontend
    サーバーサイド 職能横断チーム
    職能横断チーム
    職能横断チーム
    

    View Slide

11. 巨大なワンプロダクトであるが故の難しさ
    Chatworkは巨大なモノリスであり、事業としても単一のアプリケーションである
    ● WebFrontendにおける主戦場はChatworkのコア機能であるチャット画面
    ○ リリースして12年目の歴史あるプロダクトで技術的負債も大きい
    ● モジュール分割はできたとして、単一のモジュールとしてチームを運用する旨味が少ない
    ● スケールするためには、単一のリポジトリを複数のチームで編集する必要がある
    ○ これまで1チームで開発していたコードを複数チームで開発できるようにしなくてはならない
    11
    どうやって巨大なワンプロダクトで職能横断型の組織に移行すればいいだろう？
    

    View Slide

12. 「認知負荷」を手がかりにする
    

    View Slide

13. 認知負荷とは何か
    ● 1988年に心理学者ジョン・スウェラーが提唱した概念
    ● 人間の脳はある瞬間に脳に留めておける情報量に限りがある
    ○ チームも同じ
    ● チームの責任範囲と担当範囲が広がりすぎると、自分の仕事に熟達する余裕がなくなり、担当業務のコンテキストス
    イッチに悩まされる
    ● 我々は昔から伝統的な階層構造で認知負荷をコントロールしてきたとも考えられる
    ● 認知負荷を分割しないと組織としてパフォーマンスを発揮できなくなる
    13
    参考元:
    マシュー・スケルトン (著), マニュエル・パイス (著), 原田 騎郎 (翻訳), 永瀬 美穂 (翻訳), 吉羽 龍太郎 (翻訳) (2021)『チームトポロジー』日本能率協会マネジメントセンター
    

    View Slide

14. 認知負荷の種類
    ● 3種類に分類される
    ● 付加価値があるのは課題内在性負荷と学習関連負荷
    ○ 課題内在性負荷は最小限に抑える
    ○ 課題外在性負荷は取り除く
    ● あくまで「学習効果」についての話であり、組織設計として必要か不要かという話ではない
    14
    名前 説明 例
    課題内在性負荷 問題領域の本質的な複雑さ ユーザー課題や要件
    課題外在性負荷 その問題を解決することを妨げたり、間接的に複
    雑さを与えるもの
    どのようにデプロイを行うか
    学習関連負荷 対象を理解するために発生する負荷 ドメイン固有の知識や技術
    参考元:
    マシュー・スケルトン (著), マニュエル・パイス (著), 原田 騎郎 (翻訳), 永瀬 美穂 (翻訳), 吉羽 龍太郎 (翻訳) (2021)『チームトポロジー』日本能率協会マネジメントセンター
    

    View Slide

15. 認知負荷を下げるためのチームタイプ
    ● 4つのチームタイプが定義されている
    ○ 3つのインタラクションモードについては今回は割愛
    ● 今回のスライドでは下記の用語として定義する(太字がこのスライドで登場するチームタイプ)
    ○ 社内でも認識が揃っていないケースがある
    15
    タイプ名 役割 関連する認知負荷
    ストリームアラインド アプリケーションにおける価値を提供する
    (信頼性など、事業価値以外も含まれる)
    課題内在性
    プラットフォーム ストリームアラインドに直接関係ない領域をプラットフォームとして提
    供する
    課題外在性
    イネイブリング ストリームアラインドチームの能力ギャップを埋めるための支援をす
    る
    学習関連負荷
    コンプリケイテッド・サブシス
    テム
    複雑で専門性の高い領域を閉じることで外部から利用しやすくする 課題外在性
    参考元:
    マシュー・スケルトン (著), マニュエル・パイス (著), 原田 騎郎 (翻訳), 永瀬 美穂 (翻訳), 吉羽 龍太郎 (翻訳) (2021)『チームトポロジー』日本能率協会マネジメントセンター
    

    View Slide

16. どうやって認知負荷を下げる？
    3
    

    View Slide

17. これまでの体制
    ● 職能別チームは「全てのWebFrontendに関わる領域」を担当している
    ● 認知負荷がとても大きい
    ● 主戦場はChatworkアプリだが、普段は保守をしていない領域も暗黙的に担当している
    17
    WebFrontend
    チーム
    Chatwork
    アプリ
    ログイン
    管理画面
    …
    …
    

    View Slide

18. WebFrontendをプラットフォームチーム化する
    ● 「価値に直接貢献する」チームとそれを支援するチームに分割する
    ○ チームトポロジーの「ストリームアラインドチーム」と「プラットフォームチーム」を分割する
    18
    WebFrontend
    チーム
    Chatwork
    アプリチーム
    Chatwork
    アプリ
    ログイン
    管理画面
    …
    …
    Chatwork
    アプリ
    

    View Slide

19. Chatwork
    アプリチーム
    切り出せる領域は切り出す
    ● 他の領域をプラットフォームチームとして切り出す
    ● 基盤として切り出せる箇所はコードとしても分離しやすい
    19
    WebFrontend
    チーム
    認証基盤
    チーム
    Chatwork
    アプリ
    ログイン
    管理画面
    … …
    ログイン
    

    View Slide

20. Chatwork
    アプリチーム
    まだ大きな認知負荷を抱えるチームが残る
    ● 主戦場だったChatworkアプリ自体は巨大なまま分割されていない
    ● チームのサイズも大きくなるため、複数チームで開発できるようにしなくてはならない
    20
    WebFrontend
    チーム
    認証基盤
    チーム
    Chatwork
    アプリ
    管理画面
    … …
    ログイン
    

    View Slide

21. コンポーネントチームとフィーチャーチーム
    ● Chatworkアプリを複数チームで開発する方法として、コンポーネントチームとフィーチャーチームが考えられる
    ● コンポーネントチーム
    ○ 1つのチームが単一のコンポーネントを扱う
    ○ 施策によってはコンポーネントを横断する必要があり、他のチームと協力する必要がある
    ○ チーム単体でユーザー価値がデリバリーできるとは限らない
    ● フィーチャーチーム
    ○ ユーザー価値の提供を目的としたチーム
    ○ コンポーネントを持たず、複数のコンポーネントを横断して開発する
    ○ クロスファンクショナル & クロスコンポーネント
    ○ 難易度が高い
    ○ (https://featureteamprimer.org/jp/)
    ● 社内でも用語の認識が揃っていないケースがある
    21
    参考元:
    常松 祐一 (著), 川口 恭伸 (監修), 松元 健 (監修) (2023)『アジャイルプラクティスガイドブック 』翔泳社
    

    View Slide

22. コンポーネントチームとフィーチャーチーム
    コンポーネントチーム
    22
    フィーチャーチーム
    メッセージ
    ルーム
    検索
    チーム A
    チーム B
    チーム C
    機能開発 A
    機能開発 B
    機能開発 C
    メッセージ
    ルーム
    検索
    チーム A
    チーム B
    チーム C
    機能開発 A
    機能開発 B
    機能開発 C
    参考元:
    常松 祐一 (著), 川口 恭伸 (監修), 松元 健 (監修) (2023)『アジャイルプラクティスガイドブック 』翔泳社
    

    View Slide

23. コンポーネントチームとフィーチャーチーム、どちらがいいか
    ● 「巨大なワンアプリである」というところに難しさがある
    ○ 1つのチームが1つのコンポーネントに閉じて開発するのは現実的ではない
    ○ ストリームアラインドチームを分割してもコミュニケーションパスが増えるだけ
    ■ 課題内在性が減るわけではない
    ○ 少なくともチームとして適切な境界面は現時点で見つかっていない
    ● 課題外在性としての認知負荷はプラットフォームとして切り出しつつ、メインとなるチャットアプリ部分はフィーチャー
    チーム体制を敷く、というのが現時点ではよさそう
    ○ 今後、事業環境の変化やドメインへの分析が進むことで方針が変わる可能性がある
    23
    

    View Slide

24. 晴れて認知負荷を下げることができました、めでたしめでたし....?
    ● ではない
    ● ここまでは「現時点での理想のチーム境界」の話
    ● システムを運用・保守している以上、チームを分割するためには様々な考慮が必要になる
    ● 体制としては道半ばなものの、現時点で組織として向き合った課題や、フィーチャーチームを組織する上での考慮ポイン
    トをご紹介したい
    24
    

    View Slide

25. 職能別チームと
    フィーチャーチームの連携における考慮ポイント
    4
    

    View Slide

26. 現在の体制
    ● フィーチャーチームとしてPMと連携して施策を進めているのがChatworkアプリチーム
    ○ 現在は事業戦略上、グロースに注力したチームになっている
    ○ 運用・保守やリファクタリング系のタスクはまだWebFrontendチームが担っている状態
    ○ チームトポロジーのプラットフォームチームになれていない
    26
    Chatwork
    アプリチーム
    WebFrontend
    チーム
    Chatwork
    アプリ
    管理画面
    … …
    Chatwork
    アプリ
    フィーチャーチーム
    プラットフォームチーム
    

    View Slide

27. コードのオーナーシップの問題
    ● 一番問題になりやすいのが「コードレビューをどう行うか」
    ○ フィーチャーチームの人数が増えるほど、職能別チームにレビュー負荷がかかる構図になる
    ○ フィーチャーチーム内でレビューが完結する仕組みを作ることが重要
    ■ 既存のコードに精通したメンバーにフィーチャーチームへ参加してもらう
    ■ 難しい場合はメンターとしてフィーチャーチームを支援する
    ○ 現在はChatworkアプリチームに閉じてレビューが実現できている
    ● スケールした際に全体のアーキテクチャに対してどのように意思疎通を行うかは課題
    ○ チーム横断で課題感や情報共有ができるギルドを結成する、といった仕組みもセットで検討が必要
    27
    タスク
    ルーム
    検索
    リポジトリ
    Chatwork
    アプリ
    WebFrontend
    レビュー依頼
    

    View Slide

28. 施策と技術領域のバランス問題
    ● フィーチャーチームではWebFrontend以外にも、サーバーサイドやモバイルアプリも触る必要がある
    ○ フルスタックな志向性を持つメンバーがフィーチャーチームに向いている
    ● 一方で、事業として注力するべき施策が全ての領域をカバーしているとは限らない
    ○ 「モバイルの招待数を増やしたいので、iOS / Androidに注力します」はあり得る
    ● 職能別組織では経験しづらい他領域の開発ができる反面「慣れないうちに触る機会が減ってしまった」という状態にな
    ることも
    ○ 触れる機会が少ないと忘れてしまい、定着しづらい
    ● チーム内で希望する領域に関わるための仕組みや、自分の軸ではない領域を積極的にキャッチアップできる仕組みづく
    りが必要
    28
    

    View Slide

29. コンテキストスイッチの問題
    ● 自身が得意でない言語を触ったり、一つの施策で領域を横断して開発するとコンテキストスイッチが発生する
    ○ サーバーサイドはPHP、WebFrontendはTypeScript、モバイルはSwift, Kotlin
    ○ 現在は人数が増えたこともあり、自分の得意領域を軸にして余力があれば他の領域に関与していくスタイルに
    ● 最適な開発体制は模索中
    29
    

    View Slide

30. 安全にリリースするためにこれらが重要
    ● レビュー負荷をできるだけ下げつつ、複数チームで開発するためには安全性を担保する仕組みが重要
    ○ 複数チームで安全に触るための仕組み
    ○ エラーにすぐ気づくための仕組み
    ○ 万が一不具合がリリースされてもすぐに切り戻せる仕組み
    30
    https://speakerdeck.com/shibe23/ju-da-naspanoji-shu-de-fu-zhai-toxiang-kihe-isok-kerutekunituku
    

    View Slide

31. まとめ
    ● 巨大なワンプロダクトにおいては、境界を区切って認知負荷を下げる部分と、ある程度の認知負荷を抱えながらもデリバ
    リーを最大化するために方向性の模索が必要な領域がある
    ● 職能別組織からの移行は、コードのオーナーシップを委譲し、複数チームで共同して開発していくための仕組みづくりが
    重要
    ● 全てがきれいに分割できるわけではなく、一つ一つの改善を泥臭く積み重ねていくことが大事
    ○ スケールする組織を目指すには技術だけでなく、組織・文化と向き合う必要がある
    ○ コードを適切に分割できればすべてがうまくいくわけではない
    ● 組織体制の構築は、事業、システム、メンバーそれぞれの観点を持つことが大事
    ○ 地道にコツコツと改善しています
    31
    

    View Slide

32. 最後に
    ● Chatworkではフロントエンドエンジニア、フィーチャーチームで活躍いただける方を募集しています
    ● 一緒に組織の課題と向き合い、進み続けてくださる方、ぜひご応募ください
    32
    採用ページはこちら
    

    View Slide

33. 働くをもっと楽しく、創造的に
    

    View Slide