はじめに
現在、私は東京のとあるフィンテック企業で働いています。2023年8月にソフトウェアエンジニアとして入社し、それ以来 Go を用いたクレジットカード決済システムの開発に従事してきました。2024年3月からは前任者から テックリード の役割を引き継ぎ、5人のエンジニアが所属するチームを率いています。
Dodaさんの記事では、テックリードは「技術面でのチーム牽引役に加えて、他のチームや部署との連携を担う窓口役」と説明されています。他多くの記事でも似たような説明がされていますが、実際にどのような業務を行っているのか、具体的に語られることは少ないように感じます。
そこでこの記事では、この1年間私がテックリードとして行ってきた業務の内容について紹介していきます。
この記事が読者のキャリア形成の一助となれば幸いです。
本記事では、テックリード と リードエンジニア を同義として扱います。企業によっては別の役職として扱う場合もありますが、本稿では違いについては触れていません。
また、本文の内容はあくまで私の経験に基づくものです。一般論として受け取らないようお願いします。
テックリードの責務
業務内容の紹介の前にまずはテックリードの責務について解説します。
私が所属する会社におけるテックリードの責務は、**「所属チームにおける開発プロジェクトの成功」**を実現することであるとされています。
ここでいう「開発プロジェクト」とは、新機能の開発や既存機能の改善などのチームが取り組むあらゆる業務を指し、「成功」は期限内に品質を維持しながらプロジェクトを完遂することを意味します。
つまり、テックリードとはチームの成功を支えるために必要な業務全般に取り組みながら、文字通りリーダーとしてチームを牽引していく役割を担うことになります。
テックリードとしての具体的な業務内容
以下に、私がテックリードとしての1年間に行ってきた業務内容を紹介します。
これらの業務は、前述のテックリードの責務を果たすための手段として行ってきたものとなります。
開発チームの窓口業務
開発チームの窓口業務では、CS、マーケティング、デザイン、PdMなど他のチームと連携を図ります。
特にPdMとのコミュニケーションは頻繁に発生します。
PdMとは中長期的な開発ロードマップの整理や目下のタスクの優先順位調整や要件のすり合わせを行います。
また、CSからは緊急度の高い突発的な問い合わせが飛んでくることが多いです。
この際の一次受けも基本的にはテックリードが対応し、不具合の有無や原因の特定などを行います。
また、外部ベンダーなどの社外のパートナーとの連絡もテックリードが引き受ける事が多いです。
PRD（Product Requirements Document）の作成
PRDの作成自体は基本的にはPdMの担当領域であるイメージですが、タスクのスコープが比較的小さい場合やPdMのキャパが逼迫している場合にはテックリードがPRDの作成を行います。
PRDとは開発要件をまとめたドキュメントで、実装担当者はこのドキュメントを元に実装を行います。
UIの変更が絡む際には、デザイナーを巻き込んでPRDの作成に取り組むこともあります。
設計
設計業務においては、開発タスクの要件定義や基本設計を行い、開発の方向性を示します。
この時にコードレベルなどの過度に詳細な設計を行ってしまうとメンバーが開発に取り掛かる際の創造性が抑制されるため、適度な粒度でのを意識しています。
タスクアサイン
タスクの割り振りの際には、各メンバーのスキルや志向、タスク間の依存関係や優先度を考慮して行います。
たとえば、複雑なドメイン知識が必要なタスクは、その分野に経験のあるメンバーに任せることで、リードタイムの短縮や知識の深化を狙います。逆にスケジュールに余裕がある時には、メンバーのできることの幅を広げるためにあえて経験が浅い分野のタスクを割り振ることもあります。
メンバーごとの嗜好やスキルを考慮しながらアサインを行うのは何とも言えない地味な難しさがありますが、『このタスクを通して実装担当する人がこんな学びを得てくれたら嬉しいな』と思いを巡らせられるのが個人的には楽しいところでもあります。
コーディング
テックリードでありながら私自身もコーディングに取り組んでおり、業務時間の30%前後をこの作業に充てています。
テックリードとしての業務に時間を割くべきだという意見もあるかもしれませんが、これは私自身のキャリア形成と技術力の維持のための重要な活動だと考えています。
監査対応
現職ではISMSなどの監査を定期的に行っています。現職では情シスチームが主導して諸々の準備も含めて対応してくれているのでやることは多くないのですが、監査時には私がリードしているチームの開発フローについて監査官に説明しセキュリティー面での問題がないことを伝えました。
1on1ミーティング
以下を目的にチームメンバーとの1on1を行います。
- 信頼関係の構築（と言いつつ雑談するだけのことも）
- チームや会社についての情報の共有（今後の開発計画や制度変更などの頭出し）
- 今後挑戦したいタスクのヒアリング
- フィードバックを通じたパフォーマンスの向上や期待値の調整
メンバーの特性によって、1on1の時間内にどこを深堀りするべきかは異なると考えています。
そのため、1on1の開催頻度や話す内容はメンバーごとに調整しています。
まとめ
以上が、私がテックリードとしての1年間に行ってきた業務内容の一部です。ちなみに今後は採用面接官としての業務も加わる予定です。
1年テックリードをやってもまだまだ新しい業務が増えているので、これからも日々の業務に取り組む中で新たなスキルや知識を身につけていきたいと考えています。
この記事が、皆さんのキャリア形成において参考となる情報を提供できればと思います.