テックリードとして気づいた「あるべき姿」
トライバルメディアハウスというデジタルマーケティングの会社で新規事業のテックリードをしています。今の経験で気づいた事をメモの意味も込めて、この記事で共有させてください。
テックリードって何？
詳細はShimpei Takamatsuさんの「テックリードという役割」という記事が非常に参考になると思います。
簡単に責任範囲を箇条書きすると
・ソフトウェアの品質
・チームの生産性
・アーキテクチャ・設計
上記について具体的にどういう事を意識したら良いか書いていきます。
ソフトウェアの品質について
まずメンバーのコードをレビューする事。ただ、これは自分を品質の最後の砦とするためにやるのではなく、ティーチングプロセスと捉えレビューする事。永遠に自分が見続けないと品質をキープできないのはあるべき姿ではないように思います。
次に、品質を上げていく（もしくはキープする）ための仕組み・プロセスを積極的に導入していく事。例えば、Linter、ユニットテスト、型などを積極的に導入・精査し、それらをCI/CDで自動化するなど。永遠に口酸っぱく口頭 or チャットで同じ事を繰り返し注意するのはナンセンスだと思います。
チームの生産性について
まず、メンバーからめんどくさい雑務を取り払ってあげる事。例えば、PRが終わってissueを閉じるみたいな、必要だけどめんどくさい作業とかを自動でやる仕組みを入れてあげるとか（これはあくまで例、GitHubだと簡単な設定でできるはず）。これをやるとメンバーがソフトウェア開発自体に集中でき、コミット量が増えます。そして自分が役に立てているんだ、有能なんだという高揚感を得られる機会が増えます。この体験が増えた結果、本人のやる気になり更なる挑戦を自らするようになり、生産性も上がっていきます。大切なのは、「まず、本人のやる気に期待して待つ」のではなく、雑務を取り払うなど「やる気が上がっていくような仕組みを作っていく」という事が大切です。相手のやる気やお気持ちにまず期待して待つのはやめた方がいい気がします。
アーキテクチャ・設計
クリーンアーキテクチャなどアーキテクチャー論はいくつもあり、それを学び理解しておく事は必要ですが、テックリードの役割としてはプロダクトの状況・要求などを理解し、現実的な時間でどこまで追求するかを判断する事が大切だと思います。常に妥協するという話ではなく今後の時間軸を踏まえて今、どこまで、何を、守るべきか or 決めるべきかを最終判断する事がテックリードとしてすべき事だと思います。あとはアーキテクチャ・設計について未来のビジョンをメンバーに示し続けることも大切なように感じます。自然とメンバー内で議論も生まれやすくなると思います。
まとめ
色々書きましたが、仕組みやプロセスを入れた後は信頼して待つという事も大事かなって思ってます。これらは単なる一意見なので、逆にみなさんが普段どう意識してるか教えていただけると非常に嬉しいです。それでは