© Chatwork 組織フェーズを見据えた Webフロントエンドの アーキテクチャと変遷 フロントエンド開発部　澁谷　哲也 2021年11月27日

自己紹介 2 Chatwork株式会社 澁谷　哲也 Tetsuya Shibutani フロントエンド開発部　マネージャー ビジネスチャットツールを作っています @shibe_23

Chatworkの歴史と組織規模の変遷 (登録ID数:各年12月末時点、2021年のみ9月末時点。従業員数: 各年10月末時点) 登録ID数 フロントエンド チームメンバー数 従業員数 + DDD 🔔 2019/09/24 東証マザーズ上場 81名 87名 109名 154名 247名 3 3名 4名 6名 178.2万ID 241.6万ID 308.0万ID 395.2万ID 458.2万ID 約2.3倍

Chatworkのフロントエンドの特徴について 4 Chatworkは歴史のあるプロダクト ○ リリースから10年 ○ フロントエンド部分のコードベースで約15万行

Chatworkのフロントエンドの特徴について 5 例: メッセージが表示される、タイムライン上の未読ライン ● ウィンドウがアクティブかどうか ● 表示してから◯秒経過した ● メッセージを送信したときは全て既読にする etc... クライアントサイドもビジネスロジックがてんこ盛り ● あらゆる状態が1つのページで複雑に絡まり合っている ○ メッセージ、ルーム、タスク、権限... ● ルーティングで特定エンドポイントごとに区切ってリファクタリング、ができない ページという概念がない

Chatworkのフロントエンドの特徴について 6 「安全に」「段階的に」リファクタリングをする仕組みが必要 既に社会インフラに近い存在になっている ● DAU 96.6万 (2021/9月末時点・最大) ● 重篤な不具合 = ユーザーの業務が止まる

フロントエンドのアーキテクチャの変遷(1) 7 ● 巨大なjQueryベースのSPA ● Reactを導入し、ViewとModelの分離を試みた ● 段階的にjQueryからReactへ置き換えるため、jQuery部分を明確に分離する必要がある ○ DDDを元にしたDomain Modelの作成 ○ ACL(腐敗防止層)によりアーキテクチャを分離し、jQuery部分への依存を制御 複雑化するjQueryからの脱却を目指し、ReactとDDDベースのモデリングを採用 + DDD

React + DDD：構成図 8 詳しくは下記blogをご覧ください https://creators-note.chatwork.com/entry/2020/11/04/111353 https://creators-note.chatwork.com/entry/2020/11/09/102425

React + DDD：サンプルコード 9 Render (propsの再生成)

フロントエンドのアーキテクチャの変遷(2) 10 ● Propsを更新する仕組みが自前 ● 常に最上位コンポーネントからのレンダリングをするため、レンダリングコストが高い ● mutableに状態を管理するため差分比較コストが高い 技術面、組織面の課題からReduxを採用 + DDD 技術的課題 ● 組織全体を拡大させていくフェーズに突入したが、実装に独自性が強くオンボーディングコストが高い 組織的課題 ⇒ Redux導入で再レンダリングの範囲を狭める 　 immutableにして差分比較コストを下げる ⇒ デファクトスタンダードである状態管理ライブラリの採用により 　 最初から共通言語で会話できるように

Redux採用の効果(1): 再レンダリングの範囲を狭める 11 ● react-reduxのuseSelectorを利用 ● Storeをsubscribeして、dispatchされる度に差分比 較してくれる ● Stateの差分検知・キャッシュ機構により、再レンダ リングの範囲を狭めることができた

Redux採用の効果(2): immutableにして差分比較コストを下げる 12 ● Redux Toolkitを活用 ○ immerによってimmutableな実装が可能 ● ClassベースのEntityをどうReduxに移行するか ○ 値はcreateEntityAdapterを使ってStoreに格納 ○ メソッドはreducerなど種類ごとに分けて関数として定義

DDDベースのモデルとReduxの関係 13 ● EntityやValue ObjectがStoreに再現しやすい ● Application Serviceを見ればRedux化に必要なreducerやselectorが分かる DDDベースのモデルがあることでReduxの導入がスムーズだった クライアントサイドでもビジネスロジックの整理は重要 ● 戦術的な考え方を取り入れることはメリットがある ● もちろんモデル分析をする姿勢も重要

Redux 処理フロー概要図 14

Redux ディレクトリ構成(抜粋) 15 ● Reduxを導入したコードは application 以下へ ● feature単位でreducerやselector、Container Componentをまとめる ● 各featureのactionをactions以下にまとめる

これから：機能別組織への挑戦とモジュラモノリスを意識した構成へ 16 ● Reduxの導入を進めながら、feature単位での分割を行う ● モジュラモノリス化を目指して、モノレポ構成への移行を段階的に進める 組織全体で機能型組織への移行を検討 ● 採用計画が順調に進み、人数のスケールに関する課題感がより切実なものに ● 職能型組織のため、機能開発はプロジェクトごとにメンバーをアサインする形式 ○ リポジトリのメンテナンスが職能型組織に紐づく ○ 一つの機能開発で複数のチームに合意をとらなくてはならない ○ 組織がスケールするほど調整コストがかかり、デリバリーをスケールさせづらい 組織をスケールさせるために、モノリシックなSPAを分割していかなくてはいけない

まとめ 17 ● 適切なモデリングへの探求 ● コードを疎結合に保ち、変更容易性を確保する ● 新しいコードと古いコードの境界を設け、依存関係を制御する ● 「アーキテクチャで解決すべき課題」は常に変わり続ける アーキテクチャの決定はプロダクトだけでなく、組織フェーズにも影響をうける ● 過去のアーキテクチャもプロダクトや組織に貢献していれば負債ではない 環境の変化は激しい。技術的負債を返却しながら新しい環境に適応する必要がある どんなアーキテクチャにするとしても、大事なことは変わらない

最後に 18 JSConf 2021アフターイベントとしてLTに収まらなかった話をします https://chatwork.connpass.com/event/230070/ 12/1(水) 20:00 ~ 21:00 フロントエンド・アーキテクチャの今までとこれから Chatwork Tech Talk #6 󰳒 󰳏 しぶたに たかせ

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