フロントエンドチームリーダーに就任して思ったこと

はじめに

こんにちは。KINTO Technologiesのグローバル開発部でフロントエンド開発をしているクリスです。以前はStorybookとVue.jsについて執筆させていただきましたが、今日は技術と少し離れ、マネジメントについて話したいと思います。

実は私は去年の7月からフロントエンドチームのリーダーになり、もうすぐ1年が経ちます。初めてのリーダー経験で、たくさんの出来事がありましたが、次の1年に向けてよりよいリーダーになるために何をすればいいか考え、この1年間リーダーとしてやってきたことの振り返りをテキストに起こしたいと思い、本記事を執筆しました。

チームについて

まず去年リーダーに就任した当時に遡ると、チームそのものが、部署の組織変更でフロントエンドに特化した部隊が欲しく作られたチームです。以前の記事でも少し触れましたが、多国籍なチームで、日本語がそこまで堪能ではないメンバーもいるので、チーム内では基本英語でコミュニケーションを取っています。

このチームの主な仕事はグローバル開発部が持つ各プロジェクトのフロントエンド開発を行うことですが、複数のプロダクトに対してメンバーの数も多くないので、一人が複数のプロダクトを担当するのは珍しくありません。また、保守期間になったプロダクトにおいてはずっとフロントエンドのタスクがあるわけでもないので、リファクタリングでコードを改善すると同時にローテーションでメンバーを他のプロダクトに回す時もあります。

チームリーダーとしての役割

私はチームリーダーになる前も、一人のメンバーとしてこのチームでフロントエンドの開発作業に専念し、デザインシステムの開発を行なっていましたが、リーダーになってからは主に以下の仕事に専念し、自ら開発するよりはメンバーに委ねることが多くなりました。

技術と実装方法の選定

一つ目の仕事はチーム全体の技術と実装方法を選定することです。フロントエンド開発においてはたくさんのフレームワークやライブラリーが選べます。実際、選択肢が多すぎて、何がいいか悩む方が多いと思いますが、私ももちろんその一人です。フレームワークの話だと、メンバーが慣れているか、機能面でプロダクトの要件を満たしているか、コミュニティーサポートが十分か、などの面で考慮しないといけないですが、なるべく話題になって、流行ってるフレームワークも使ってみたいという開発者のありがちの気持ちとどうバランスを取るかも重要です。

今グローバル開発部のフロントエンドチームは基本Vue.js/Nuxt.jsで統一していますが、かと言って今後もこのセットでやっていかないといけないというわけでもありません。チーム内には常に新しいことを試す雰囲気があるので、最近では社内の技術交流会で他のフロントエンドチームの影響を受けてSvelteKitやAstroなども試しながら評価しています。そして評価の結果を基に、何を利用するかを決めていきます。

PMとメンバーのコミュニケーションフォローとプロダクトのコードレビュー

二つ目の仕事はPdM/PjMとメンバーとのコミュニケーションが円滑に行えるようにすることです。フロントエンドチームは複数のプロダクトの開発タスクを行うことがあるため、それぞれのPdM/PjMとコミュニケーションを取って作業を進んでもらっています。仕様確認、提案やフィードバックなどをすることによって、プロダクト開発がスムーズに行えることを手伝っています。また、現行各プロダクトにアサインしているメンバーが一人の場合が多いので、リーダーとして品質と情報把握のために全プロダクトのレビューを行っています。

シニアマネージャーとメンバーの架け橋

三つ目はシニアマネージャーとメンバーの架け橋を担うことです。弊社では、マネージャー層になると、所属メンバーが10人以上増えることもあります。例えば私の場合ですと、自分の直上長は他のチームも管理していて、合計20人近くのメンバーを取りまとめています。そのため、多くの場合はリーダー経由でメンバーの管理を行います。

現在私がやっているのは、主に以下のことです：

• メンバーの能力や志向を踏まえて、それぞれの役割とミッションを設定すること（もちろん最終的にマネージャーにもすり合わせること）
• 決めたミッションを基づいて、定期的に1on1をセットアップし、フィードバックをしたり、彼らの相談や悩みを聞いたりして、必要に応じて現場の声をマネージャーにもフィードバックすること

動機づけとメンターリング

最後はもちろんメンバーの管理です。前述したように、1on1でのコミュニケーションはもちろん、それぞれの強みを発見し、なるべくそれを活かすというのも重要な役割です。私のチームメンバーは国籍だけでなく、スキルレベルもバラバラですが、共通点としては向上心が高いのが挙げられます。中には細部に気を配って、気づきにくいところまで発見くれるメンバーもいれば、プライベートで勉強して、取得したスキルや知識を業務で活かすメンバーもいます。あとはやる気を維持するのも必要で、なるべくメンバーのやりたいことを実現させてあげたいですが、そうならない時もモチベーションを持たせるコミュニケーションは必要です。

また、メンバーがまだ使ったことがない技術を使う必要がある場合は私がレクチャーしたり、もし私も使ったことがないなら一緒に勉強したりします。

リーダーとして気をつけていきたいこと

適切なコミュニケーションとフォロー

コロナ禍以降、リモートワークが増える傾向にありますが、弊社もフルフレックス制度やリモートワーク制度を導入しています。そうするとオンラインでのミーティングが多くなります。対面と比べて相手の表情やジェスチャーからの情報が察知しづらくなり、コミュニケーションミスが発生するリスクがあるので、特に自分がリーダーとして主に話したい時と、メンバーから相談がある時の1on1はなるべくお互いオフィスにいる時に行っています（もちろんミーティング自体は最小限にしています）。

また、私自身は去年部署内で開催されたハッカソンで優勝し、作品を製品化に向けて別のチームで進めているので、兼務の中で素早くメンバーのフォローに回せないという反省もありますので、今は両立できるように手探りしています。

うまく任せて育てること

私のチームは複数のプロダクトを担当しているので、プロダクトへのアサインはメンバーのスキルレベル、好みなどとプロダクトの難易度、課題などを掛け合わせて考慮するようにしています。

そして、アサインした後も定期的に状況をヒアリングしたり、サポートしたりします。たまにメンバーのタスクを見て、自分もやりたい気持ちが強くなる時もありますが、そこは頑張って自分の気持ちを抑えてメンバーにやってもらっています（笑）。

一方、任せた後もどんなことをしたらメンバーが成長するかも考えなくてはいけません。私の一つの答えとしては、なるべく自分で考えてもらうことです。例えばジュニアレベルのメンバーだと、0から何もかも教えるのでなく、レビューで指摘したい時はまず質問して、「何で」という部分を意識してもらって考えさせています。

終わりに

1年リーダーをやってみて、たくさんのことを経験し、今年度のグローバルGフロントエンドチームの展望について述べてこの記事の終わりに迎えたいと思います。

FE分野のスキルアップデート

前述したように、チームにはまだジュニアレベルのメンバーがいるということに加え、技術も日々変わってきます。フロントエンドだけでもここ数年たくさんの新しい話題となるフレームワークが生まれました。例えば他の部署で使っているSvelteや、AstroやQwikなどがあります。

新しいフレームワークやライブラリーを導入するには技術以外の要素も考えないといけませんが、勉強しておくと将来役に立つし、視野が広がるので、メンバーに対して影の年間目標として設定し、チームとしてスキルのアップデートをしていきたいと思います。

BE分野への理解

「フロントエンドだけ特化して、バックエンドへの理解が少ないと、API連携の話で噛み合わない部分がある」というのは自分の経験上でよくある話なので、自社では職種的にフロントエンドとバックエンドで分かれていても、なるべく担当でない領域の基礎知識も身についてもらいたいと考えます。例えば、今の一つやっている施策としては、メンバーをプロジェクトにアサインした後、バックエンドにも迷惑かけないレベルで簡単なタスクを経験させてもらえるようにプロジェクトリーダーと調整したりしています。