テックリードを目指して3ヶ月働いてみて

自己紹介

こんにちは、請求管理ロボ開発メンバーの花塚です。ポエムっぽい記事を書きます！現在入社してから1年程度経ちますが、嬉しいことに開発業務以外にも様々なタスクを担当しています。将来的に遠い目で振り返れるように、テックリードを目指して取り組んだことの振り返りを書き残しておきたいと思います。

経緯

弊社ではエンジニアリングマネージャー（以下、EM）が複数の開発チームのチームリーダーを兼務している、という状況がありました。
そこで、EMから「今後チームをリードしていってほしい」と言われました。が、嬉しい思いはあったものの、自分なんかができるのか、、？という思いが大きかったのが正直なところです。悩みながら読んだ書籍にこんな一文があり、背中を押されました。

テックリードの役を任されたというのは祝福されてしかるべきことです。チームを代表する連絡窓口であるテックリードにふさわしい人物だ、と誰かが認めてくれた証拠なのです。これを機に、新たなスキルを学び、身につけていってください。
引用元：『エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド』- Camille Fournier -（オライリージャパン：2018）第3章

いい言葉ですね。どこか評価に値するところがあったのだろう、ということで軽い気持ちで受けてみて、私のテックリード候補ライフが始まりました。

目指した状態

以下ができている状態を目指しました。

タスク分割をしてメンバーにタスクを割り振ること
進捗を守ること
チーム内で議論が停滞した時に意思決定を行うこと
コードレビューにおいてリファクタリングの提案を行うこと

結果

大雑把ではありますが、◯、△、× で評価します

タスク分割をしてメンバーにタスクを割り振ること
- → △
進捗を守ること
- → ◯
チーム内で議論が停滞した時に意思決定を行うこと
- → ×
コードレビューにおいてリファクタリングの提案を行うこと
- → ×

工夫したこと、心がけたこと

タスク分割をしてメンバーにタスクを割り振ること

要件を担当した案件を小さい単位に分割して、各メンバーにタスクを割り振りました。また、タスク内容に認識齟齬がないように、タスクごとに細かい粒度でTODOリストを作成しました。

進捗を守ること

スプリントの進め方で気になる細かいところの改善に取り組みました。
例えば、スプリント単位でのストーリーポイント消化を可視化して、ストーリーポイント達成/未達の要因をスプリントごとに振り返るようにしました。活かせる点があれば次スプリントに振り返り内容を盛り込んでいきます。細かいところではありますが、ストーリーポイント消化に対するメンバーの意識は高められたと感じています。

できていないこと、学び

この3ヶ月間を通してできなかったこととして、以下の2点を自覚しています。

チーム内で議論が停滞した時に意思決定を行うこと

技術の細かい話になってくると適切な意思決定ができていない（つまり議論をリードできていない）、という実感があります。

コードレビューにおいてリファクタリングの提案を行うこと

私の今までの経験で、そもそも良いコードとは、良い設計とは、というところに対する意識が低かったので、レビュー観点においてもリファクタリングの提案があまりできていないと考えています。

テックリードを目指して、開発業務以外にも様々なタスクを担当することで、テックリードをやる上で足りていない技術力があるというところを自覚することができました。

これから

1つのPull Request（以下、PR）でリファクタリングを実施する
→ まずは小さく実践していく、ということで日々のPRでリファクタリングを実践していきます。（ボーイスカウトの原則を実践していく、ということですね）
EMとの相互コードレビュー
→ 影響範囲が大きい修正や、インシデントにつながる可能性のある修正に関してはEMがコードレビューに入っているのが現状です。この一次レビューに私が入って、どこでEMと差分が生じているか、どこで観点漏れが生じているかを明らかにして、コードレビューの改善に取り組んでいきます。
設計周りのインプット
→ コードレビューの際に知識不足を感じたので、特に足りていないと感じている設計周りの知識を引き続きインプットしていこうと思っています。（現在、弊社ではコード品質を高めるために品質向上MTGというものを行なっており、この辺も上手く活用していきたいです。細かい内容に関しては機会があれば記載します、、！）

総じて、技術力向上のために何をするか、というところですね。上述した内容を日々繰り返して技術力向上に取り組んでいきたいと思います。

3ヶ月ほどテックリードを目指して働いてみた感想

引き受けてよかったな、と思っています。
仮にもチームをまとめる立場になり、振ってもらえる仕事が増えたことで、自分の得意なところ、苦手なところが明らかになったと感じています。メンバーのタスク管理や議論をリードするのは比較的できるが、テックリードとしてはコードレビューする上で設計周りの知識が不足している、ということを再認識できました。

また、どうすればチームが良くなるか、という仮説を立てて成功・失敗するという経験ができるようになったのは良い点だと思っています。主体的に仮説を立てて失敗して、振り返り改善するというサイクルを回す機会が以前より明らかに増えました。