この記事は「株式会社ログラス Productチーム Advent Calendar 2024」シリーズ1、2日めの記事になります。

こんにちは、ログラスでエンジニアをしております、あさマック こと 浅井です（@mixplace）。

私事になりますが、昨日12/1(日)に、シンガポールの市街地で行われた「Singapore Marathon 2024」に、ハーフマラソンの部で出場し、完走してきました。 ゴールに向かって走り続ける中で、体力、コンディション、道路の起伏、天候など、複数の変動要素からその時の最適解をもってペース配分するのは難しいものですね。プロダクト開発においても不確実性をつぶしながらスプリントを回していくメタファーとどこか似ているように感じながら走っておりました。

本題に戻りまして、ログラスでは2024年夏からフロントエンド領域に造詣のあるメンバーが独立して「フロントエンドチーム」を組成して活動しています。 今回、私自身が一メンバーとしてチーム組成を推進したのですが、その背景やチーム組成して取り組んだこと、その先の将来像について紹介したいと思います。

ことの背景

Loglassのプロダクトはリリースして5年目に入り、おかげさまでこの4年間でプロダクトの機能も、組織メンバーも成長してまいりました。 2024年春時点では複数のチームがそれぞれでスクラムでプロダクト開発を行う体制でした。（現在はFASTというアジャイルフレームワークでプロダクト開発を行っています。興味ある方は、記事「今こそ変化対応力を向上させるとき ログラスが FAST に挑戦する理由」もぜひご参照ください）

当時、私を含めフロントエンドに知見を持ったメンバーが特定のチームに偏っていたことで、 1つのスクラムチームの中でフロントエンド基盤や、別スクラムチームが管轄している領域におけるWebブラウザパフォーマンスの最適化など、横断で活動したり、技術相談いただく場面が、徐々に増えてまいりました。 当然、所属しているチーム内の開発量は減ってしまいます。

Webブラウザパフォーマンスの最適化の相談や改修依頼が、複数のチームから来ることもあり、フロントエンド基盤の投資をしていくべき状況となっていました。

チーム組成化に向けて

複数のチームからフロントエンドの改善を行ってほしい相談を受けるものの、「いまこのタイミングでチーム化することが最適解なのか？」は、私の中では腹落ちしきれていませんでした。

一時的にチームから離れて改善活動を行い、フロントエンドのナレッジを他エンジニアメンバーにシェアしつつも、プロダクトの開発活動に寄与した方が、プロダクト組織としてはROIが良いのではないかという思いがあったからです。

どのような組織編成が最適なのか、エンジニアリングマネージャー（EM）のよしださんと何度か壁打ちをしながら、あるべき形を模索していきました。まるでコーチングを受けているかのような、未来志向の問いかけをたくさんいただきました。（EMよしださんの記事もぜひご覧ください）

「フロントエンドチーム組成に向けて」というドキュメントを作り（通称: 原典）、チームが存在すべき理由、チームが持つ役割を言語化し、このドキュメントをチームの“原典”とすることにしました。

“原典”で記したこと

• 現状のチーム編成（フロントエンドチーム組成前）によって起こっている課題はなにか？

• このまま行くとどんな問題が顕在化するか

• そのための最適な打ち手はなにか？

フロントエンドチーム組成後の取り組み

2024年夏に正式にフロントエンドチームを組成し、まずはフロントエンド領域に造詣のあるメンバー2名（＋副業メンバー1名）の構成で組成しました。
プロダクトに関わるメンバーやチームと信頼関係を構築しながら、フロントエンド基盤に関わる改善を行うことでした。

プロダクト組織の現況と変化を知る、敏感になる

フロントエンドメンバーがチーム化したことで、プロダクト開発のスピードや生産性が下がってしまっては元も子もありません。チーム組成直後は、開発生産性が大きく変わらないように意識しました。

ちょうどプロダクト開発においては、FASTというアジャイルフレームワークを導入するタイミングでした。バリューサイクル（スクラムでいうスプリントに相当するもの）ごとに、「フロントエンド領域で開発に貢献できる部分はないか？」「ナレッジシェアできることはないか？」を想像し、画面の大きな改修が控えているグループに入り込む動きをしました。

この「グループに入り込む動き」は、FASTにおいては重要なポイントとなっており、いわゆるOST（オープンスペーステクノロジー）における“蜂”や“蝶”に近しい動き方を積極的に行っています。我々フロントエンドチームメンバーが、各々のグループの様子を観察しつつ、プロダクト開発活動の中で最も価値貢献できるグループに入り込むことで、開発を加速強化できるのではないかと考えたのでした。

具体的には、コンポーネント設計や複雑になりそうな実装の箇所は、フロントエンドチームがリードし、ペアプロやプルリクエストレビューでナレッジを伝承できるよう心がけました。
また、新たにジョインしてくれたデザイナーやエンジニアに対して、フロントエンド領域の今をオリエンテーションしました。 新メンバーのみならず既存メンバーにも、フロントエンドメンバーに「相談しやすい・声を掛けやすい状態」を作ることを意識しました。

具体的には、1on1を複数名とさせていただき、困りごとや今後協力したい場面をヒアリングしました。タスク的にフロントエンドチームで改善できるものはチームのバックログアイテムとして追加することにしました。フロントエンドメンバーが持っているナレッジをもっとシェアしていく余地があることがわかり、今後ペアプロを通したナレッジシェア、ドキュメントの拡充、勉強会等での発表等を予定しています。

近い将来に起こり得ることを想像する

「Loglass 経営管理」プロダクトは、多くのお客様がご利用いただけるようになり、長く使ってくださっているお客様、新しくご契約いただいた規模の大きなお客様となりますと、データ量が必然的に増えてまいります。

プロダクト開発当初には想像しえなかったデータ量をフロントエンドのコンポーネントで扱う場面も増えてきており、各お客様のデータ量も鑑みながら、「いま最大データ量を持っているお客様の2～3倍規模であっても、でも快適にご利用いただけるのか？」「性能の低いPCでもご利用いただけるのか？」と問い続け、環境の準備、計測、異常値があれば気付くことができるように活動を行いました。

Enabling & Platform としてのフロントエンドチームへ

プロダクト組織内のほぼすべてのチームから相談される、相談できる関係性を構築していきました。

この秋からは、インフラ領域やアプリケーションの基盤部分を担う「Enabling & Platform」の部署に合流することとなり、明確にフロントエンドの基盤部分を担うチームとして確立することとなりました。

マルチプロダクトに向けた取り組みを進めており、フロントエンド部分についても考えなければならない時期となったのもあります。

エンタープライズ フロントエンドのナレッジを持ったチームへ進化させるために

ログラスは経営管理、予実管理を担うBtoB SaaSプロダクトを運営・提供している中で、さらに規模の大きなお客様、大量データを表示して分析するプロダクトとして進化させていくこととなります。

大量データと聞くとどうしてもバックエンドやインフラ領域に負荷やパフォーマンスの最適化になるイメージがありますが、フロントエンド領域においてもWebブラウザパフォーマンス、具体的にはDOMの量、ブラウザメモリ使用量にはより一層注意を払う必要があります。

また、「ログラスはこれから2年で10個の事業を立ち上げます」を大きく進めていくにあたっても、プロダクト個別の最適化はもちろんのこと、「フロントエンド基盤」「デザインシステムにおける共通UIコンポーネント群」それぞれの進化と最適化が求められていくフェーズにもなるでしょう。

エンタープライズ領域におけるフロントエンドエンジニアリングとしてナレッジを持ち、品質も高めていく、このような活動を精力的に行うためにも、フロントエンドチームを組成したことが生きてくると考えています。また、マルチプロダクトとして一貫のあるユーザー体験を担保するためにも、デザインシステム・共通UIコンポーネント群に対してもより良いものを、より強いものを作っていく必要があります。

そんなエンタープライズ領域のフロントエンド開発を一緒に推し進めていくメンバーも募集しています。話を聞いてみたい、ちょっと興味あるという方は、ぜひお話しさせてください。

2025年・来年のアドベントカレンダーでは、エンタープライズ フロントエンドならではの取り組みをご紹介できたらと思います。

最後までお読みくださり、ありがとうございました。 明日3日目のアドベントカレンダーは @EichiSanden さんによる記事になります、こちらもぜひお楽しみに。