https://qiita.com/ktoshiya/items/7da92159892eb4808cff?utm_campaign=popular_items&utm_medium=feed&utm_source=popular_items
現在の会社にテックリード（１人目の正社員エンジニア）として入社して、２年間やってきたことを書いています。 エンジニア二年目でテックリードとして試行錯誤してきて、自分の振り返りもしたいという思いから記事を書きました。 （前提として、シード期のスタートアップで実行してきたことです。）
入社当時は、２週間単位のスプリントでスクラムを回してましたが、全員が業務委託だったこともあり、完全な内製化を進める必要があり、主な課題は以下でした。
それまでは、GitHub Projectで進捗管理をしていたのですが、スクラムに特化されたZenHubを導入しました。 ユーザーストーリーの作成からリリースまでのタスクを、全社で可視化したことによって、リリースまでの流れがスムーズになりました。 プランニングポーカーもZenHubで完結できるので、オンラインで完結できます。
ただ導入するだけではなく、プロダクトバックログの作成からリリースまでの流れを整理しドキュメント化して、それを全社で共有することで、継続的なリリースが容易になったと思ってます。
プロダクトバックログは、１スプリントで完了できる粒度、スプリントバックログは１日単位で完了できる粒度に小さくするよう、チームで統一を図りました。 継続的にリリースし、仮説検証のサイクルを早くできるようにしたり、タスクを小さくすることで不確実性を極力なくして、心理的安全性を確保することが目的です。
各層のテストカバレッジの目標値を設定し、可視化するようにしました。 当初は、Slackで通知するようにしていたのですが、CodeCovを導入してプルリクレビュー時に見えるようにすることで、カバレッジ向上のモチベーションに繋がってます。 クリーンアーキテクチャであれば、domainやusecase層は80~100%に設定し、その他の層は50%くらい。フロントエンドであれば、80%くらいが良いかもしれませんが、現在も試行錯誤しながら調整してます。
コードレビューで何度も出てきたコーディング規約で、フォーマッターで設定できるものは都度設定していきました。 実装者が悪いのではなく、自動化できていない仕組みが悪いという解決方法です。 コードレビュー時の心理的安全性にも繋がります。