はじめに
こんにちは、株式会社バニッシュ・スタンダードでエンジニアをやっているhidechaeです。
弊社ではスクラムを導入しています（どれだけちゃんとやっているかはチームによってバラつきありますが）。毎週レトロスペクティブを行っており、面倒くさかった作業などはできるだけ仕組み化しようと心がけています。
今回は、僕の所属するチームが直近数ヶ月でやったことを紹介します。
レビューの効率化
Storybookの導入
フロントエンドのレビューをするとき、デザインを確認する場合はローカルで起動して確認していました。
ローカルの変更をstashしてpullしてきて起動するだけでも面倒くさいのに、コンポーネントのPropsにパターンが多いときなどは確認作業が大変で結構な工数がかかってしまっていました。（面倒くさいのでまぁ大丈夫っしょって感じで承認しちゃうことも多々…）
StorybookをPRごとにAmplifyでホスティングすることで、デザインに関してはStorybook上で確認出来るようになってかなり楽になりました。
OpenAPIのプレビュー
APIのドキュメントはOpenAPIに書いています。
これはフロントエンドのレビューに比べるとyamlファイルなので見やすいのですが、古いAPIだとパラメータ数やレスポンスのサイズが異常に大きくて、yamlで見るのが苦痛でした。
これもPRごとにAmplifyでホスティングすることで、見ようというモチベーションを上げることに成功しました。
ドキュメントのビルドにはRedocly CLIを使いました。
Redocly CLIを使ったのは、デザインがきれいだったのと、npxでビルドできて楽だったからです。
動作確認作業の効率化
APIリクエストの共有
システムの特性上APIを直接叩いて動作確認を行いたいケースがあります。エンジニアだけでなくCSでもAPIを直接叩くことがあります。
今までは各自が都度リクエストを作ったり、PostmanやInsomniaでリクエスト管理をしたりしていました。
各自で管理するのも非効率なので、Insomniaで共有するようにしました。
PostmanではなくInsomniaにした理由は、認証系のAPIからCookieを引き継いで使えたりといった点が便利だったのと、チーム内でリクエスト管理を最もちゃんとしていたメンバーがInsomniaユーザーだったからです。
パフォーマンス測定
弊社では、パフォーマンス測定に「Findy Team+」を使っており、サイクルタイム分析を見ることが多いです。
サイクルタイム分析では、以下の4つのプロセス別のリードタイムを可視化してくれます。
- コミットからオープンまでの平均時間
- オープンからレビューまでの平均時間
- レビューからアプルーブまでの平均時間
- アプルーブからマージまでの平均時間
この計測をできるだけ正確に行えるように以下の仕組み化を行いました。
ブランチ作成時のfirst commit設定
「コミットからオープンまでの平均時間」は、最初のコミットのタイミング次第で大きくぶれてしまいます。細かくコミットする人と、ある程度開発してからコミットする人がいると、集計しても全く意味のある数字になりません。
「開発開始からオープンまでの平均時間」になるように、タスク開始時に空コミットをするようにしていました。
しかし空コミットを忘れてしまうことが何度かあったので、Gitフックを導入してブランチを切ったタイミングで空コミットを自動で行うようにすることで解決しました。
以下のようなフックを.git/hooks/post-checkoutに設定しました。
#!/bin/sh
previous_head=$1
new_head=$2
branch_flag=$3
# ブランチが新規作成された場合に実行
if [ "$branch_flag" = "1" ] && [ "$previous_head" = "$new_head" ]; then
git commit --allow-empty -m "first commit"
fi
PRへのラベル付けの自動化
リリースのPRや、リバートのPRなど、計算対象外にしたいものがありました。Findy Team+では、ラベルをつけることで計算対象から外すように設定することができます。
リリースのPRにはreleaseラベル、 リバートのPRにはignoreラベルを付けています。
これも手動でラベルをつけていたのですが忘れることが頻発したので、ブランチ名でルールが決まっているものに関しては、Gtihub Actionsで自動でラベル付与するようにしました。
具体的には、以下のような設定をしています。
name: pr label
on:
pull_request:
branches:
- main
- develop
jobs:
pr-label:
runs-on: ubuntu-latest
permissions:
pull-requests: write
steps:
- uses: agaroot-technologies/action-restrict-pr-label@v1.0.0
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
with:
rules: |
main <- develop [release]
main <- revert-* [ignore]
develop <- main [ignore]
develop <- revert-* [ignore]
まとめ
振り返ってみると、ちょっとずつではありますが効率化が進んできたなぁと思います。
チームとして改善していこうという意識がちゃんと根付いてきており、仕組み化のアイデアが出てきて、ある程度工数使ってちゃんと仕組み化しようという流れができているのはとても良い状態だと思います。
実際、サイクルタイムの改善やベロシティの向上など、数値にも良い結果が出てきています。（僕個人としてはあまりそういった数値を重視してはいませんが。）
こんなチームに興味を持っていただけた方は、ご応募お待ちしています。
Discussion