$30 off During Our Annual Pro Sale. View Details »

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

shibe23
September 21, 2023

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

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

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

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

shibe23

September 21, 2023
Tweet

More Decks by shibe23

Other Decks in Programming

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