こんにちは、フロントエンドエンジニアの峯です。
私はテックリードやリーダーとして、チームを牽引することが求められる立場で普段働いています。
今回は、そんな私が今年リーダーとして行った取り組みと、日々業務を進める上で心がけていることについて紹介します。 これからチームをリードしていく立場を目指す方の参考になれば幸いです。
目次
1. 開発プロセスの整備
新規開発プロジェクトで技術選定からジョインしているプロダクトがローンチされ、これから運用フェーズに入っていくというタイミングで、開発プロセスの整備を行いました。
新規開発フェーズは、ゴリゴリコードを書いてmainブランチに取り込んでいくという進め方でした。なぜなら、ローンチ前に手厚いテストフェーズが待ち構えているため、まずはスケジュールに遅れを取らないようにとりあえず動く機能の開発を行いました。
しかし、運用フェーズはそれではいけません。新規開発フェーズと違って、すでにリリースされている機能に不具合の無いように新しい機能を追加していく必要があるからです。
mainブランチから開発ブランチ（featureブランチなど）を切ってマージしてデプロイする…という一連の開発プロセスはフェーズによって最適化していかなければ、サービスとして安全性を維持することができません。サービスの地盤として最も大切な開発プロセスの整備をまず行う必要がありました。
開発プロセス整備の詳細な話は、それで一本記事が書けてしまうくらいのボリュームになってしまうため、ここでは整備が完了するまでの流れを紹介します。（別の機会に書かせていただきます！是非、反響をお待ちしています。笑）
1-1 状態の定義
Gitのブランチ運用では、深く検討されることなく定番な？ブランチ運用が採用されがちだと思いますが、今回大切にしたのはそのフローが事業やサービスの状態にマッチしているかどうかという点です。
そのため、まずサービスが今後歩もうとしている方向性のキャッチアップや理解を進めました。PMとコミュニケーションと取ったり、事業資料に目を通しました。
事業の方向性に関する解像度が上がってから、開発プロセスの理想の状態を定義しました。
わたしは「機能改善やバグ、次期メジャーバージョンに向けた機能の並行開発が可能な状態」と定義しました。なぜなら、この時、私たちのサービスはコア機能のひとつを造り切っただけの状態だったため、このコア機能の改善や次の機能追加などが行われていくという状況だったからです。
1-2 手段の検討
フロントエンド、バックエンドそれぞれ4名ほどの開発体制ということで、複数の機能開発が並行して進んでいくことは想像できますし、複数スプリントを見据えた進行を可能にしておく必要もあります。イレギュラーなバグ対応等ももちろん入ってくるため、このような理想の環境を満たす開発プロセスを構築するべく、ここからようやく手段の検討をスタートしました。
ツールの制約などは事前に押さえておき※1、ブランチ運用やCI/CDについて過去経験があるものを振り返り、バックエンドチームのリーダーと相談しながら最適な状態を検討しました。
検討するにあたって重視した理想の状態や、検討した他の手段のメリデメをまとめたドキュメントを基に共有し、意見を仰ぎながら最終的な開発プロセスの整備が完了しました。
2. 利用ツールの活用改善
ツール利用にはお金がかかります。
ツールを導入することで、開発効率が上がったり、大きなメリットを得られると思いますが、コストがかかるため、コストに見合った活用ができているかというのはしっかり定期的に観察していく必要があります。
2-1 現状把握
今回はあるツールの課金額の割合が、導入している他プロジェクトに比べて明らかに多くの割合を占めているという状況がありました。
これまでの開発でメリットを感じていたため、コスト削減を目的に利用停止するという判断は避けたく、まずは利用状況の把握を行いました。
ツールは最初の段階から導入しており、その時に利用目的をドキュメント（技術選定フェーズで、ツールやライブラリのメリデリの調査、目的を記したドキュメント）に記していたので、そのドキュメントを振り返りながら、どのような目的で導入を決めたのか、その目的に対して適切に活用されているのかを確認しました。
振り返りの結果、目的通りの活用が行えていることは分かりましたが、利用されていない大きな無駄があることもわかりました。
2-2 活用方法の見直し
無駄を削減し、活用方法に見合ったコスト感に合わせていくために、ツールの設定や運用フローの見直しを行いました。
現状把握から活用方法の見直しは、チーム全体で話し合いをしながら進めました。アジェンダを用意し、メンバーがどこにメリットを感じているのか、どこを使われていて、どこが使われていないのかをドキュメントにまとめながら進行しました。
利用タイミングと運用フローを改善し、新たな活用方針をスタートさせることで、約30~40%程度のコスト削減が見られました。このコスト削減はそれだけ無駄のある状態で導入されていたという裏返しでもあるので、導入当初の見積もりの甘さを受け止めながら、今後の知見としてプロダクトチーム全体へ振り返り共有を実施しました。
なかなかコスト意識を持つ機会は多く無いので、こうした機会にチーム全員で会話をするということの重要性も感じています。ツールに限らず、運用フローなどは日々ベストを求めていくものです。定期的に見直しを行いながらそのポイント、ポイントで最適な状態であるかは今後も継続的に見直していきたいと思っています。
3. ドキュメントを書く
最後に、チームをリードする上で意識していることについて紹介します。
先に述べた2つの取り組みの中にもしつこく登場してきてお気づきの方もいらっしゃるかもしれませんが、私はチームの意思決定を行う際にはドキュメントを書くということを意識しています。
単純に非同期コミュニケーションツールとして有効性にメリットを感じているだけではなく、チームの決定や方針を齟齬なく伝えるための手段として有効だと考えているからです。
どのようなことを重視し、どこからどんな情報を集め、何を検討し最終的に決定したのか。この一連のプロセスをドキュメント無しに伝えるというのは非常に難しいと思いますし、メンバーの納得感も得られないと考えています。
口頭コミュニケーションでは、伝わりづらい部分やニュアンスが邪魔をしてメンバーの理解に差が生まれてしまうこともありますし、情報を可視化して残しておくことで、チームの拡張性もアップすると考えています。
3-1 言語化スキルを養う
仕様書でもマニュアルでも、コードのコメントでも、伝えるというシチュエーションはさまざまなところで必要です。
我々の仕事は全てが伝えるという要素を持っていると言っても過言ではないと思っています。私自身、このブログを読んでいただいてわかるように、文章が決して上手ではありませんし、実はドキュメントを書くという機会を利用して少しでも伝える力、言語化能力を身につけていきたいという思いもあります。
向き不向きがある領域なのだとは思いますが、チームを牽引する役割を持つ者としては決して避けられないスキルなのでは無いかと感じています。
3-2 チームへのインストール
ひとりのエンジニアとして言語化スキルを身につけることで、得られるメリットも非常に多いと感じるところがあります。
ひとつに、コードコメントやプルリクエストの内容です。自分が書いたコードや行った変更に関する情報を正しく伝えることで、その後の開発効率は大きく変わります。
エンジニアとしてドキュメントを書く癖をつける最初の一歩目として、有力だと感じているのがプルリクエストです。
私がジョインするプロジェクトでは、プルリクエストテンプレートを用意してプルリク作成時にしっかりとプルリクエストコメントを記入する仕組みをとっていることが多いです。仕様書を書いてもらうようなこともあったりしますが、仕様書の内容がエンジニア向けの内容過ぎるという状況がよくあります。まずはプルリクエストを非エンジニアでも理解できる内容で書くというとこからスタートしてもらうとドキュメントのハードルを下げる施策として良い気がしています。
また、テックブログも最近では多くの企業で導入されていると思います。社内の情報を社外へ届けるソリューションとして有効だと思います。
まとめ
自分の成果よりチームの成果。
私が、リーダーやテックリードというロールを得たことで変化した一番のマインドはこれです。
これまでは「自分がサービスのコア機能を作るんだ…」や「他のメンバーが抱えている不具合の解消に努めるんだ…」というメンバーの一員としての役割を重視してきましたが、チームのバランスをとるポジションで仕事を進める機会が増えてきたことで徐々にマインドが変化してきました。
メンバーが気持ちよく動けているか、パフォーマンスを発揮できているか。こうした観点を常に持ち、躓きやすそうな石は事前に取り除く。
以上のようなことを考えながら今年は働いてきました。課題はいくつも転がっていますし、次から次へと降ってきます。引き続き今後もチームのパフォーマンス向上に努めて邁進していきます。
注釈
- ※1：全社的に推奨されているツールやルールは変更することができない、変更コストが高いのでここでは優先度を下げて変更可能なもの、チームで検討可能な部分に絞って検討を行いました。