開発リーダーとしてチームビルディングのためにやったことを振り返る

はじめまして、フロントエンドエンジニアの田中です。 2月にリリースした Synergy! フォーム機能リプレースのβ版のフロントエンドチームリーダーを任されました。リーダーという役割は初ということもあり悪戦苦闘した日々を振り返りたいと思います。

本記事はプロダクトマネージメントの手法などの話ではなく、リーダーとしてどんな気持ちで何に注力し、どんな行動を取っていたかという話です。

田中　賢樹（タナカ　マサキ）

2019年6月入社のフロントエンジニア。
職場環境改善が大好物。
漫画/ゲーム/酒が好きです。

コロナで飲食店がすぐ閉まるのでつらい日々を送ってます...クラフトビール飲みたい🍺

このプロジェクトは

Synergy!リリース当初から稼働していたフォーム機能を現在のモダンな技術でリプレースするというプロジェクトです。

フォーム機能は、フォームを作成し公開/非公開などの設定をする管理機能、作成されたフォームを実際に利用するコンシューマ機能に分かれています。私は管理機能のチームに所属し、フロントエンドエンジニアは私を含め5人体制でした。

Synergy!のフロントエンドは機能毎にリポジトリが分かれており、その多くはAngularが使われていますが、今回技術選定をするにあたってReact（Next.js）を選択しました。
様々な理由がありますが、大きなものは以下の２点です。

Angularは約半年に一度メジャーアップデートされるため、これに対応し続けることが苦しかった
私含めメンバー全員が別の技術に触れたかった

過去の資産が使えないデメリットはありますが、それ以上にメンバーのモチベーションを高め、生産性を上げることを選択しました。

チームとして目指したこと

今回特に目指したことは、メンバー全員が実装に集中でき成長できる環境作りです。

リーダーとしてフロントエンドメンバーの窓口になること以外、開発の進め方などは私個人に任されていました。そこで、自分が開発者として働きたくなるような環境を作ることを目指しました。それは、開発者が実装に集中できて、かつチーム全体で技術的に成長しあえる環境です。実装のことだけに集中して思った通りの実装ができた時の快感はたまらないですよね？

リーダーとして心がけていたこと

今回私が心がけていたことは常にオープンであることです。

具体的にはいつどこで声をかけられても即レスすること、声をかけやすいように忙しさや疲れ、苛立ちなどを極力見せないことを心がけました。

私はチームで一番良くないことは、「一人で悶々と考え、時間を浪費してしまうこと」や「不満や疑問を言い出せずにため込んでしまうこと」だと考えています。些細なことでもとりあえず田中にぶつけてみれば話が前に進む、という印象を持ってもらうように努めました。

実際に何をしたのか

開発前1on1

メンバーはそれぞれ得意分野も違うし目指しているものも少しずつ違います。開発前に1on1をし、どこでバリューを出したいか、何にチャレンジしたいかなどをヒアリングして、チームとして共通認識を持つように努めました。

事前学習期間を設ける

今回はReactで開発することになりましたが、私以外のメンバー全員ほとんど未経験なので、約1週間の学習期間を設けました。やってもらったことは利用する技術のマニュアルやチュートリアルの確認です。意図は実装力をつけることではなく、どんなことができてどこに情報があるのかということを知ってもらうことです。

ライブラリ更新の自動化

開発中はライブラリの更新をいつするのかという課題があります。Synergy!のこれまでの開発でもこの課題に悩まされてきました。時間が経ってからいざ更新しようと考えても、色々なところが壊れてしまってサッと対応できず、想定外のリソースを取られてしまいます。

こういった課題を解決するために、ライブラリの更新を自動化するRenovateを導入しました。毎日自動的に更新の有無がチェックされ、自動的に更新、テストが行われます。テストに通らない場合でも、差分が少ないので小さな工数で対応することができました。これにより環境がどんどん古くなっていくという不安がなくなりました。

ページや機能毎の担当制を廃止

Synergy!のこれまでの開発では、ページやその中の大きめの機能毎に担当を分けて開発を進めていました。これは担当者がページや機能全体の責任を持ち、自分のやり易いように作るように考えられたもので、チーム内のコミュニケーションコストも低く着手までは早いです。

ただ、この方法はコードが属人化し易く、仕様の把握も自分の担当箇所のみで他の仕様に興味を持ちづらいという欠点があります。また、チーム内のコミュニケーションコストは低いものの、他チームまで含めると関係人数が多くなり全体的なコミュニケーションコストは高くなります。

上記理由から担当制は廃止しました。その代わり

issue作成時に変更の詳細まで記述する
１週間毎にmilestoneを設けて、issueを整理する
メンバー全員でissueを消化する

という方針にしました。

担当制を廃止しても、自分が実装した内容に近しいissueばかり拾われて結局属人化するかも、という懸念がありました。多少そのような傾向はありましたが、メンバーは未経験なものも含め、様々な領域のissueを消化していました。

リーダーはissue作成やコードレビューに徹底して、コードを書くことを諦める

せっかくマージリクエストを出してもレビューが遅いと次のissueに集中しづらい状況になってしまいます。普段からフロントエンドチームは担当プロジェクトに関係なく全員でコードレビューを行っていますが、各々がタスクを抱えているためレビューするまでに時間がかかる事も多いです。

そのためリーダーは即レビューを徹底しました。

これは開発メンバーの生産性を上げることにもつながりますが私自身、プロジェクトのコードがどうなっているかを完全に把握することができました。

しかし、リーダーとしてissue作成に加え、即レビューを徹底すると、それだけでいっぱいになってしまうことが予想できたため、自分自身はコードを書くことを諦めました。

結果として中途半端な対応にならずにサポートに回れ、メンバーの生産性、品質に貢献できました。

Slack通話の活用

コロナの影響で完全リモートの環境になり、基本的にチャットベースでコミュニケーションを取りますが、画面を共有しながら話した方が圧倒的に早い場面はとても多いです。しかし、その度にわざわざスケジュールを確認してWebミーティングを設定するのも手間がかかります。そこで活用したのがSlack通話です。

プロジェクトチャンネルやメンバーの分報などでちょっと話せますか？など一言いれた後にそこで通話を開始、画面を共有しながらペン機能を活用し、時に別のメンバーがフラッと入って来て別の視点から意見を出してくれたりと同じオフィスにいる場合とあまり変わらないシームレスなコミュニケーションをとることができました。