現在の会社にテックリード（１人目の正社員エンジニア）として入社して、２年間やってきたことを書いています。
エンジニア二年目でテックリードとして試行錯誤してきて、自分の振り返りもしたいという思いから記事を書きました。
（前提として、シード期のスタートアップで実行してきたことです。）
入社時のチーム課題
入社当時は、２週間単位のスプリントでスクラムを回してましたが、全員が業務委託だったこともあり、完全な内製化を進める必要があり、主な課題は以下でした。
- 継続的リリースが困難な状態になっており、それを解消することが急務
- 社内にエンジニアがいなかったので、開発組織体制づくりが必要だった。
- ウォーターフォール寄りのリリースが多く、継続的にリリースする文化がなかった。
- リファクタリングやテストコードが不十分だった。
改善したこと
Zenhubを導入
それまでは、GitHub Projectで進捗管理をしていたのですが、スクラムに特化されたZenHubを導入しました。
ユーザーストーリーの作成からリリースまでのタスクを、全社で可視化したことによって、リリースまでの流れがスムーズになりました。
プランニングポーカーもZenHubで完結できるので、オンラインで完結できます。
ただ導入するだけではなく、プロダクトバックログの作成からリリースまでの流れを整理しドキュメント化して、それを全社で共有することで、継続的なリリースが容易になったと思ってます。
バックログの粒度を極限まで小さくする。（分割統治法）
プロダクトバックログは、１スプリントで完了できる粒度、スプリントバックログは１日単位で完了できる粒度に小さくするよう、チームで統一を図りました。
継続的にリリースし、仮説検証のサイクルを早くできるようにしたり、タスクを小さくすることで不確実性を極力なくして、心理的安全性を確保することが目的です。
テストカバレッジの可視化
各層のテストカバレッジの目標値を設定し、可視化するようにしました。
当初は、Slackで通知するようにしていたのですが、CodeCovを導入してプルリクレビュー時に見えるようにすることで、カバレッジ向上のモチベーションに繋がってます。
クリーンアーキテクチャであれば、domainやusecase層は80~100%に設定し、その他の層は50%くらい。フロントエンドであれば、80%くらいが良いかもしれませんが、現在も試行錯誤しながら調整してます。
Lint、フォーマッターを導入
コードレビューで何度も出てきたコーディング規約で、フォーマッターで設定できるものは都度設定していきました。
実装者が悪いのではなく、自動化できていない仕組みが悪いという解決方法です。
コードレビュー時の心理的安全性にも繋がります。
Tailwind CSSの導入とTailwind UIの購入
コンポーネントの統一をするため、Tailwind CSSを導入しました。
また、公式で用意されているTailwind UIを購入して、FigmaデータをUIデザイナーに共有し、統一のコンポーネントで実装するようにFigma,フロントエンドともに意識あわせしました。UIの議論って不毛になりやすいので、用意されたコンポーネントで設計・実装するよう統一しました。
ユビキタス言語の設定
コードや画面上の表示がバラバラだったりしたので、言語を統一しました。
ドメインエキスパートと開発チームで議論の上、日本語と英語を設定し、コーディング時はユビキタス言語を使うようにチームで統一
ドメイン名やオブジェクト名はもちろんのこと、CRUDの動作名なども設定したことで、定数の見通しも良くなりました。
メール配信サービスを疎結合化
メール配信周りで障害が発生した際に、障害点を探すのに工数がかかっていたので、モノリシックサービスからメール送信を切り分け、SQS→Lambda→SendGridを使用し、疎結合化。耐久性が向上し、障害点が明確になりました。
ファイル配信サービスをセキュリティ要件に合うように実装
ファイル配信サービスにおいて、セキュリティの要件を満たす必要がありましたが、残課題として放置されていたので、S3に直接アクセスするのではなく、CloudFrontを使用し署名を発行することでセキュリティの要件を満たすように構築しました。
インフラのコード定義化
AWSコンソールで実装すると、差分がわからない、属人化しやすいといった課題があったので、
Terraformを使って実装することで、差分管理、属人化の解消ができました。
Makefile, シェルスクリプトの活用
必要なドキュメントは作成するようにしていましたが、よく使うコマンドや操作はmakefileやシェルスクリプトにして自動化するようにしています。
メンバーが増えると同じ動作を何度もすることになるので、開発体験を向上させる上ではやっておいたほうが良いと思ってます。
開発組織づくり
心理的安全性の確保を重視し、以下のことを意識してます。
- メンバー間で発言しやすい環境づくり
- ある程度の失敗は許容され、チャレンジがしやすい文化
- デプロイ時に不安にならない(CICD必須)
- 繰り返すことは、GitHub Actionsで自動化
- IssueやPull Requesのテンプレート作成し工数削減
- 必要なドキュメントは作成
- 十分なテストコード(カバレッジ測定)
- 勉強会、合宿の定期的な開催（技術以外にもサービスやドメイン知識の共有も行う）
ドメインを意識した設計・実装（特定の層に依存しないように意識）
ドメインを意識した開発チームにしたかったので、DDDまではしないけど、ドメインに焦点をあてるという文化づくりはしました。はじめからUMLやモデリングは工数が高いと思ったので、ラフスケッチくらいをドメインエキスパートとエンジニアが集まってやって、業務を分析して落とし込んで実装という流れまでは実践しています。
ドキュメントの整備
VSCodeのsettingとdebugを統一化
プロジェクトに.vscodeを使って共有
・settings.json
・launch.json
使用してる技術（AWS）
フロントエンド
- React
- Next.js
- Cypress
バックエンド
- Golang
- Gin
- クリーンアーキテクチャ
- Ruby on Rails（管理画面）
その他
- GitHub
- GitHub Actions
- Terraform
- Codecov
- ZenHub
- Sentry
AWS
- Amplify：GitHub連携、自動デプロイの設定が簡単ですぐに使える。リソースが少ないスタートアップならおすすめ。
- ECR/ECS: 現在ならApp Runner使っても良さそうですが、実装当時はあまり使い勝手がよくなさそうだったので、ECSで自動デプロイできるように設定しました。
- Aurora
- メール配信
- SQS
- Lambda
- SendGrid
- メール配信されない障害の際に、障害点を探すのに工数がかかっていた。のでメール配信サービスは既存アプリケーションと切り離して実装
- ストレージ
- CloudFront
- S3
- ファイル配信サービスを構築するにあたり、CloudFrontを使用し署名を発行することでセキュリティの要件を満たすように構築
GitHub Actions
便利なので使用しているもの。
Add Issue Links
https://github.com/tkt-actions/add-issue-links
PR Labeler
https://github.com/TimonVS/pr-labeler-action
Review Assign Action
https://github.com/hkusu/review-assign-action
おわりに
ユーザーの課題解決という目的のために、開発速度、開発体験、技術的負債をバランス良く管理しながら、開発体制を強化していきたいと思ってます。
まだまだ、課題ややりたいことがあるので、試行錯誤しながら挑戦していきます。
（一緒に働けるエンジニアをいつも募集しているので、興味があれば連絡欲しいです。）