開発パフォーマンスを向上させるJira活用術

こんにちは！SmartHRで新機能開発を担当している、エンジニアのmuranoです。新機能開発チームでは、開発効率向上の取り組みとしてJiraの活用を進めています。今回はJiraのデプロイ管理とサイクル期間レポートの活用ついて紹介します🐶

この記事を読んで、ぜひJira力を高めていきましょう。

デプロイ管理

Jiraのデプロイ機能を利用してJiraのチケットとデプロイを紐づけることで、トレーサビリティを向上できます。チケット・スプリントごとにデプロイ状況が見えるようになり、「先週末にデプロイされていたのはここまでだね」などがすぐ分かったり、「あれ、このチケットはデプロイされましたっけ？」といった確認がなくなります。

DORA（*1）のバージョン管理（トレーサビリティ）をより厳密に満たせるようにもなります。

*1 DORAはDevOps Research and Assessmentの略で、DevOpsのパフォーマンスを測定するための指標を提供しています。詳しくは「DevOps の能力 | Cloud Architecture Center | Google Cloud」をご覧ください。

デプロイ管理の導入

デプロイを管理するにあたり、以下のような構成を設定することにしました。

この場合に必要な設定は次の通りです（参考記事）。

デプロイ機能を有効にする
デプロイツールをJiraに接続する
パイプラインをデプロイツールで設定する

1と2はJiraの設定を行うのみですでに設定済みだったため、3のデプロイツールの設定を行いました。

パイプラインをデプロイツールで設定する

GitHubで管理する方法としては以下の3通りの方法があります。

GitHub Actionsでenvironmentを指定する
GitHub Actionsでdeployment actionを使う
APIを使う（CircleCIから開始と終了をAPIで通知する）

今回は一番簡単そうな方法として、GitHub Actionsでenvironmentを指定することにしました。（GitHubのドキュメントに明記はされていませんが関連するドキュメントをみると、environmentを指定するとdeployとして管理されるようでした）

GitHub Actionsでenvironmentを指定する

GitHub Actionsの以下のような設定ファイルを作成しました。実際のデプロイにはCircleCIを使っているため、environmentを指定するだけの簡単なActionになっています。

# .github/workflows/deploy.yml

name: Deploy
on:
  push:
    branches:
      - staging
      - master
jobs:
  staging_deploy:
    runs-on: ubuntu-latest
    if: github.ref_name == 'staging'
    environment: staging
    steps:
      - name: deploy
        [...]
  production_deploy:
    runs-on: ubuntu-latest
    if: github.ref_name == 'master'
    environment: production
    steps:
      - name: deploy
        run: |
          echo "deploy to production for Jira integration"

ここまででの設定を行うと、GitHubのPull RequestをマージしたタイミングでJiraにデプロイ履歴が作成されるようになりました。

デプロイ管理の振り返り

デプロイ管理の運用を開始してみて、以下のようにチーム内でポジティブなフィードバックが多く挙がりました。

スプリントでチケットを見る時の手間・ストレスが減った
デプロイの状況が見えることで、チーム全体の進捗が見えるようになった

個人的には、設定はすぐ終わるのでやって損はないと思います。オススメです😊

サイクル期間レポート

Jiraのサイクル期間レポート機能で、簡易的にサイクルタイムとレビュータイムを計測することができます。サイクル期間レポートは、four keys の指標の変更リードタイムを測ることができ、以下のようなメリットがあります。

実装に時間がかかっているものやレビューに時間がかかっているものなどのボトルネックを調査することができる
開発パフォーマンスの低下をモニタリングできる

サイクル期間レポートの導入

参考記事を見ると以下の設定が必要となります。

ソースコード管理ツールと CI/CD ツールを接続する
十分な製品デプロイデータがあることを確認する（Jiraでデプロイ管理できている）
プロジェクトおよび課題レベルの権限を確認する（プロジェクトの設定でレポートを有効にする）

1と2は前述のデプロイ管理ができていれば満たせていて、3はプロジェクトの設定でレポートを有効にするだけで、すでに有効になっていました。設定がすぐに完了して、数週間分のデータがたまったところで、サイクル期間レポートの振り返りをしました

サイクル期間レポートの運用の工夫

サイクル期間レポートを実際に導入してみると、サイクルタイムとレビュータイムが見えるようになり、狙い通りにボトルネックを把握できるようになりました。ただしよく観察してみると、正しくサイクルタイムが計測できてないケースなどがあり、運用に工夫が必要なことがありましたので以下に説明します。

1チケット=1Pull Request

1チケットに複数のPull Requestを紐づけると、サイクルタイムが長くなってしまうため粒度がばらついてしまい、サイクルタイムの値が参考にならないことがありました。そこで、複数のPull Requestになる場合はサブチケットにPull Requestを紐づけるようにしました。

具体的には、スプリント開始前のプランニングの段階などからPull Requestの大きさを意識してサブチケットをきることにしました。結果的に、実装・レビューも進めやすくなったので、とても良かったです。

ブランチとチケットを紐づけ

これまでのGitHubの運用では、ブランチ名にチケットkeyをいれて紐づけていましたが、この運用だとPull Requestのマージ後にブランチを削除してしまうと、チケットとの紐づけが失われてしまい、正しくサイクルタイムを計測できていないようでした。

変更リードタイムを測定についての記事を読んだところ、ブランチでの作業開始時に空コミットをすることが推奨されていたので、この空コミットのコミットメッセージにチケットkeyを入れることで、チケットとの紐づけを保つことにしました。

また、空コミットをチームで運用するために、チームで運用しているhuskyを使って、post-checkoutで自動的に空コミットをするようにしました。

#.husky/post-checkout

#!/usr/bin/env sh

# コマンドライン引数を取得
before=$1
after=$2
switch=$3

# before と after が等しくない、または switch が 1 でない場合は終了
[ "$before" != "$after" ] && exit 0
[ "$switch" -ne 1 ] && exit 0

# 現在のブランチ名を取得
branch=$(git rev-parse --abbrev-ref HEAD)

# stagingブランチとmasterブランチを除外
if [ "$branch" = "staging" ] || [ "$branch" = "master" ]; then
  exit 0
fi

msg="start $branch"

# 空のコミットを作成
git commit --allow-empty -m "$msg"

この方法を採用することで、サイクルタイムのトラッキングが正しくできるようになり、また開始タイミングもより正確に計測できるようになりました。より堅牢な運用が自動でできるようになったため、とても良かったと思います。

サイクル期間レポートの振り返り

サイクル期間レポートを導入してみての振り返りをしたところ、以下のような意見がありました。

簡易的だが、変更リードタイムを見ることができるようになった
サイクルタイムが増加してしまったスプリントが直感的に分かるようになり、スプリントの進捗の異常に気づきやすくなった
サイクル期間レポートは簡易なものなので、Atlassian Analyticsを検討してもう少し詳細なデータが見れるようにしていきたい

最後に

デプロイ管理とサイクル期間レポートを導入することで、チーム全体の進捗が見えやすくなり、開発パフォーマンスの低下もモニタリングできるようになりました。以前に比べて、開発のボトルネックを早期に発見・対策することができて、開発のリスクを減らすことにつながっています。ぜひぜひ、読者の皆様も設定して頂き、より安全な開発ライフを送っていただければと思います。

We Are Hiring!

SmartHR では一緒に SmartHR を作りあげていく仲間を募集中です！

少しでも興味を持っていただけたら、カジュアル面談でざっくばらんにお話ししましょう！

hello-world.smarthr.co.jp

SmartHR Tech Blog

SmartHR 開発者ブログ