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

2023年9月、ファインディ株式会社は「フロントエンドの開発生産性」と題したオンラインカンファレンスを開催。第一線で活躍しているエンジニアを招いて、フロントエンド領域における開発生産性を向上するための組織づくりや戦略について語っていただきました。

本稿では、Chatwork株式会社にてエンジニアリングマネージャーをしている澁谷哲也さんのセッション「認知負荷で考えるフロントエンドの組織体制」の内容をご紹介します。

2019年に上場を果たし、急成長を遂げている同社。それに伴い開発組織の拡大が急務となり、職能別組織から職能横断型組織への移行がスタートしました。しかし簡単に移行できるわけではなく、澁谷さんは「プロダクトの特性もあり、組織体制を移行するためにはいくつかの課題もある」と語ります。Chatworkが直面した課題とは、どのようなものだったのでしょうか。

■プロフィール
澁谷哲也（しぶたにてつや）/ @shibe_23
Chatwork株式会社　エンジニアリングマネージャー
2019年にChatwork株式会社へフロントエンドエンジニアとして入社。フロントエンド開発部のマネージャーを経て、現在はエンジニア組織全体のピープルマネジメントにも携わる。働く人がモチベーション高く事業を成長させるための仕組みに関心があり、社内でFour Keysの導入を推進中。

会社の成長に伴い、職能横断型組織への移行が決定

澁谷：Chatworkは、中小企業向けにクラウド型のビジネスチャット「Chatwork」を提供している会社です。2020年ごろから急成長していて、2019年に社員が100名ほどだったところから、現在は400名以上の規模にまで拡大しました。その中で、エンジニアとデザイナー、プロダクトマネージャーは約100名。エンジニアだけでいうと、約80名在籍しています。

次に、サービスについて紹介させてください。「Chatwork」はメインであるチャット以外に、タスクやファイルの管理、ビデオ/音声通話といった機能を備えています。Webフロントエンドとしては、巨大なSPAであり、利用中はほぼリロードされることのないアプリケーションである点が特徴ですね。1日に数回、もしくは数日間起動したまま利用されることもあります。ブラウザベースのアプリケーションでは珍しく、URL単位でアプリケーションとして分割していないのも特徴の一つ。単一の画面で複数の機能が動作する、GUIアプリケーションとしての複雑さもあります。

続けて、目指す開発体制と課題についてお話しします。これまで、主な機能開発については、職能による縦割りのチームが担当していました。具体的には、プロダクト開発で大きな案件が発生した際には、各部署からエンジニアを募ってプロジェクトチームを結成して開発を進める、といったスタイルですね。私たちは、このような開発体制を「プロジェクト体制」と呼んでいます。

ただ、組織規模の成長に伴い、開発チームの拡大が急務となり、職能別チームではスケールできる人数に限りがあるという課題と直面しました。チームで集まったとしても、それぞれが異なるプロジェクトを担当していることになりますし、チームというよりもリソース貸出所のようになってしまう可能性があるなと。職能ごとに運用・保守が分散していると、各部署に合意形成が必要となるため、非効率であるという点も否めません。どこかでボトルネックが発生すると、全施策に影響してしまう懸念もありました。

そこで私たちは、施策に対するコミュニケーションパスを減らし、運用・保守を含めてスケールするチーム体制にするために、職能横断型の組織に移行することにしました。

体制を移行するためのヒントは「認知負荷」

澁谷：体制移行を進める上で難しいのは、「Chatwork」は巨大なモノリスであり、事業としても単一のアプリケーションであるという点が関係しています。

Webフロントエンドの主戦場は、「Chatwork」のコア機能であるチャット画面です。2011年にリリースし、歴史あるプロダクトである分、技術的負債も大きくなっています。仮にモジュールを分割できたとしても、単一のモジュールとしてチームを運用する旨味は少ないでしょう。つまり、スケールするためには、単一のリポジトリを複数のチームで編集する必要があります。

それでは、巨大なワンプロダクトで職能横断型の組織に移行するにはどうすればいいのでしょうか？ヒントにしたのは「認知負荷」です。

認知負荷とは、ワーキングメモリーに対する負荷を意味しています。人間の脳はある瞬間に脳に留めておける情報量に限りがあり、それはチームにおいても同じことが言えます。チームの責任範囲や担当範囲が広がりすぎると、担当者はコンテキストスイッチに悩まされたり、自分のキャッチアップに集中できなくなったりするといった課題が派生してしまうでしょう。認知負荷を分割しなければ、組織としてパフォーマンスを発揮できなくなってしまう可能性があるのです。

認知負荷は「課題内在性負荷」「課題外在性負荷」「学習関連負荷」に分類できます。課題内在性負荷は問題領域の本質的な複雑さで、開発に例えるとユーザー課題を解決するための本質的な問題だと考えています。

課題外在性負荷については、その問題を解決することを妨いだり、間接的に複雑さを与えたりするものであると言えるのではないかと。どのようにデプロイを行うか、あるいはシステムとして必要な認証といった部分に関わってくるものですね。

学習関連負荷は、対象を理解するために発生する負荷のことで、言い換えるとドメイン知識や技術について理解することだと言えると思います。

組織設計として必要か不要かという話ではなく、学習効果において付加価値があるのは、課題内在性負荷と学習関連負荷ですね。課題内在性負荷は最小限に押さえつつ、課題外在性負荷など直接的な課題解決にならないものを取り除いていくのが望ましいと考えています。

また、組織設計についてまとめられている書籍『チームトポロジー』では、認知負荷を下げるために4つのチームタイプが定義されています。

その中でも今回は「ストリームアラインドチーム」と「プラットフォームチーム」についてお話ししたいと思います。ストリームアラインドチームは、アプリケーションにおける価値を提供するチームです。本来は信頼性のように直接的な事業価値以外のものも含まれるのですが、今回は事業価値だと定義しています。

プラットフォームチームは、ストリームアラインドチームと直接は関係のない領域をプラットフォームとして提供することで認知負荷を下げ、課題外在性を切り出すチームです。

ちなみに、チームの呼称や役割の定義については組織変更などによって変更することがあり、他のメンバーがイベントなどでお話しする内容とは異なる可能性があります。あくまで、今回お話しする上ではこのような定義をしていると思っていただけますと幸いです。

認知負荷を下げるために誕生した、二つのチーム

澁谷：認知負荷を下げるための具体的な施策についてもご紹介します。職能別チームで開発を進めていた際は、WebフロントエンドチームがWebフロントエンドに関わる全ての領域を担当しており、認知負荷が非常に大きい状態でした。

そこで、Webフロントエンドをプラットフォームチーム化し、事業価値に直接貢献するチームとそれを支援するチームに分割しました。チームトポロジーでいうと、上の図の右側がストリームアラインドチームです。Chatworkアプリチームという形でストリームアラインドチームを切り出し、プラットフォームチームとしてWebフロントエンドチームを置くスタイルですね。

次に、ストリームアラインドの領域でなくとも、他の領域に切り出せるところをプラットフォームチームとして切り出しました。わかりやすいのは認証基盤チームです。認証基盤はログインにも関係する部分であるため、ログインの責務は認証基盤チームに持ってもらう。そういった形でチームを分割し、認知負荷を切り出して分けていくということを進めています。

ちなみに、主戦場だった「Chatwork」は、まだ巨大なままで分割していません。チームのサイズが大きくなるのを防ぐために、複数チームで開発できるようにする必要があると考えています。

では、巨大な「Chatwork」を複数チームで開発するにはどうするべきか。そのためには、コンポーネントチームとフィーチャーチームといった考え方ができると思います。

コンポーネントチームは一つのチームが単一のコンポーネントを扱います。施策に関してはコンポーネントを横断して他のチームと協力する必要があり、チーム単体でユーザー価値がデリバリーできるとは限りません。

フィーチャーチームは、ユーザー価値の提供を目的としており、コンポーネントを持たずに複数のコンポーネントを横断して開発します。クロスファンクショナルかつクロスコンポーネントのチームですね。コンポーネントを全チームでシェアするとイメージしていただくとわかりやすいかもしれません。非常に難易度が高いものではありますが、提供したい価値の単位でチームを構成できます。

なお、これらのチームについても用語の使い方が社内で揃っていないケースがあるため、今回お話しする上での定義としてご理解ください。

話を戻すと、コンポーネントチームとフィーチャーチームのどちらがいいのかについては、まだ明確な答えが出ていません。繰り返しますが、「Chatwork」は巨大なワンプロダクトです。一つのチームが一つのコンポーネントに閉じて開発するのは現実的ではなく、ストリームアラインドチームを分割してもコミュニケーションパスが増えるだけ。課題内在性が減るわけでもありません。

最適解は見つかっていませんが、課題外在性としての認知負荷はプラットフォームチームとして切り出しつつ、メインとなるチャット画面はフィーチャーチーム体制を敷くのが、現状のベストだと考えています。ただ、今後の事業環境の変化やドメインの分析が進むことで、方針が変わる可能性はあるのかなと。あくまで現状では、このフォーメーションを目標に施策を進めています。

フィーチャーチームと連携する上での問題・考えるべきポイントとは？

澁谷：ここまで、現時点での理想のチーム境界についてお話ししました。ここからは、体制を移行する中で組織として向き合った三つの課題やフィーチャーチームを組織する上での考慮ポイントについて触れていきます。

おさらいとして、現在の体制についてご紹介します。

フィーチャーチームとして、PMと連携して施策を進めているのがChatworkアプリチームで、事業戦略上、グロースに注力したチームとなっています。ただ、運用・保守やリファクタリング系のタスクは今もWebフロントチームがメインで担っており、『チームトポロジー』のプラットフォームチームにはなれていません。運用・保守も含めて、どのように移譲していくのか、どういったフォーメーションで担っていくかについては、これから改善していかなくてはいけない部分です。

それらを踏まえた上で、私たちが向き合ってきた課題の中で最もわかりやすいのが、一つ目の課題である「コードレビューをどのように行うか」ですね。職能別チームがワンリポジトリで管理をしていたので、コードレビューは職能別チームが担うことになります。そうなると、フィーチャーチームの人数が増えるほど、職能別チームにレビュー負荷がかかってしまう。フィーチャーチーム内でレビューが完結するための仕組みを作ることが重要です。

私たちの場合は、既存のコードに精通したメンバーにフィーチャーチームへ参加してもらっています。それにより、現在はChatworkアプリチームに閉じてコードレビューをすることができるようになりました。難しい場合はメンターとしてフィーチャーチームを支援してもらうのも有効だと思います。ただ、スケールした時に全体のアーキテクチャに対してどのように意思疎通を行っていくか、といった点についてはまだ課題が残っています。その点については、チーム横断で課題感や情報共有ができるギルドをつくり、アーキテクチャに関するディスカッションができるような仕組みをつくることも必要だと考えています。

二つ目は「施策と技術領域のバランス」です。フィーチャーチームは、Webフロントエンド以外にサーバーサイドやモバイルアプリケーションにも触れる必要があります。つまり、フィーチャーチームに向いてるのは、フルスタックの指向性を持つメンバーです。一方で、事業として注力すべき施策が全ての領域をカバーしているとは限りません。例えば「モバイルの招待数を増やしたいので、iOS/Androidに注力します。Webフロントエンドはしばらく触りません」といったことも起こり得ます。そうなると、メンバーにとっては特定領域の技術が定着しづらくなるかもしれません。そういった事態を避けるためには、希望する領域に関わるための仕組みや、自分の軸ではない領域を積極的にキャッチアップできる仕組みづくりが必要になってくると考えています。

三つ目は「コンテキストスイッチ」です。一つの施策で領域を横断して開発するとなると、コンテキストスイッチが発生しやすくなってしまいます。サーバーサイドはPHPメイン、WebフロントエンドはTypeScript、モバイルはSwift/Kotlinとなると、四つの言語を操ることになります。それではコードを書くメンバーの負荷が非常に大きくなってしまう。最適な開発体制については模索中ですが、Chatworkでは自分の得意領域を軸にして、余力があれば他の領域を関与してキャッチアップするといったスタイルにしています。

また、レビュー負荷をできるだけ下げつつ、複数チームで安全に開発するためには、安全性を担保する仕組みが重要です。具体的には、複数チームで安全に触るための仕組み、エラーにすぐ気がつくための仕組み、不具合がリリースされてもすぐに切り戻せる仕組み、などですね。これらの点については、以前登壇した際にお話ししているので、よろしければ資料をご確認ください。

コツコツと地道に、泥くさく改善を積み重ねていくことが大切

ここまでの話をまとめますと、「Chatwork」をはじめとした巨大なワンプロダクトにおいては境界を区切って認知負荷を下げる必要があると考えています。同時に、ある程度の認知負荷を抱えつつ、デリバリーを最大化するための方向性を模索するのが必要な領域もあると思います。職能別組織から移行する際は、コードのオーナーシップを移譲して、複数チームで共同して開発していくための仕組み作りが重要になってくるのではないでしょうか。

これら全ては綺麗に分割できるものではなく、一つひとつの改善を泥くさく積み重ねていくことが大切です。コードを適切に分割できれば全てがうまくいく、なんてことはなく、スケールする組織を目指すためには、技術だけではなく組織やカルチャーといった部分にも向き合う必要があるでしょう。ちなみに、Chatworkでは、開発生産性の重要性を広めるために「Findy Team+」を導入したり、外部の方を招いて講演会を開催したりと、さまざまな取り組みを行っています。

私たちも走りながら改善を進めている最中ですし、今後も地道に改善を進めていきたいと思います。

本日は、ご清聴ありがとうございました。