こんにちは、SmartHRの基本機能を担当しているプロダクトエンジニアの池田です。
現在SmartHRのプロダクトエンジニアでは「最短距離を行こう」というスローガンを掲げ、開発効率の向上に取り組んでいます。その活動の一環として開発のデリバリーを早めるためにサイクルタイムの改善に取り組んでおり、今回はその取り組み内容についてご紹介していきたいと思います。
サイクルタイムとは
一般的にサイクルタイムとは1つの製品の工程が開始してから完了までの1サイクルにかかる時間のことを指します。ここではソフトウェア開発プロセスにおけるサイクルタイムのことなので、ブランチに対して最初のコミットがされてからPull Requestがマージされるまでの工程にかかる時間のことをサイクルタイムの定義として説明していきます。
Findy Team+
私たちのチームではFindy Team+を活用し、サイクルタイムの向上に取り組んでいます。
このFindy Team+とは一言で説明すると、エンジニアの生産性を向上させることを目的として、GitHubやJiraと連携することで開発プロセスを可視化できるSaaSのことです。今回はFindy Team+の中でもサイクルタイム分析という機能を使ってサイクルタイムの向上に取り組んでいきます。
4つの開発プロセス
Findy Team+ではサイクルタイムを4つのプロセスに分けて分析することができます。
- コミットからPull Requestオープンまでの平均時間
- Pull Requestオープンからレビューまでの平均時間
- レビューからアプルーブまでの平均時間
- アプルーブからマージまでの平均時間
これらのプロセス毎にかかっている平均時間を分析することで、どこがボトルネックになっているかが明らかになります。
私たちのチームではこのサイクルタイム分析を元に「アプルーブからマージまでの平均時間」に取り組むことを決めました。このプロセスをチームの最初の取り組みとして選んだ理由は次のとおりです。
- 平均時間を見ると改善の余地がある
- 自分たちだけでコントロール可能で、初めての改善活動として取り組みやすい(プロジェクトの開発状況や打ち合わせが多い等の、自分たちでコントロール出来ない要因になりにくい)
サイクルタイムの改善活動
チームの紹介
まず最初に私たちのチーム構成についても簡単にご紹介していきます。
プロダクトエンジニアは以下の5名体制です。
- バックエンドエンジニア 4名
- フロントエンドエンジニア 1名
Pull Requestを出し、2名からアプルーブがついたらマージをするといった体制で開発を行っています。
また普段はモブプログラミングを導入して開発を行っています。チームのモブプログラミングの様子については、以前「モブプログラミングでの成長と学び」というブログを書いておりますのでそちらをご覧ください。
改善の流れ
ここからはどのように改善に取り組んだかを説明していきます。
「アプルーブからマージまでの平均時間」の改善に取り組むことに決まったので、以下の流れで実際に仮説検証を行なっていきます。
- 何に時間がかかっているのか作業の内訳を洗い出す
- なぜその作業に時間がかかっているのか原因を探る(仮説を立てる)
- 対策案を検討し検証する
- 振り返りをする
作業の内訳を洗い出す
まずはこのプロセスの中で何の作業をしているのか、何に時間がかかっているのかをチームで洗い出すことから始めました。
やり方はシンプルにブレインストーミング形式で意見を出しました。意見に詰まったらFindy Team+でPull Request単位でサイクルタイムを見ることができるため、時間のかかっているPull Requestを眺めながら記憶を掘り起こしました。
原因を探り仮説を立てる
作業を洗い出したら内訳に占める割合が大きそうなもの、もしくは気になったものをいくつかピックアップしました。
ピックアップしたら、なぜ時間がかかっているのか(所謂なぜなぜ分析)をして原因を探ります。ここではあくまで仮説を立てることに集中します。
対策案を検討する
仮説が立てられたら実際に対策案を考え、どうすれば今よりも時間を縮められるかという観点でアイディアを出し合いました。
ここまでは下図のようなワークボードを作成し、作業の洗い出しから対策検討までを検討しました。
詳細については省きますが、ざっくり要約すると以下のような意見となりました。
時間がかかっている原因
- 大部分はアプルーブに気づいていないことやマージ忘れの何もしていない時間
- アプルーブはついているが追加の作業をしていることが稀にある
対策とねらい
チームのアプルーブやマージ条件を整備する
- 曖昧になっていた開発ルールを明確にして正しい作業フローを作る
- 誰が何をするかを明確にすることでマージ忘れを減らす
振り返りをする
私たちはスクラム開発をしているため週に一度チームでのレトロスペクティブを行なっているので、その時間にサイクルタイムの観点で以下の振り返りをしました。
- 結果の確認と分析
- サイクルタイムの時間を確認する
- Pull Request単位で時間のかかっているもの、早かったものを分析する
- なぜ改善したか、または悪化したかを考える
- Next Actionの検討
- 必要に応じて対策案のチューニング、または新たな対策を検討する
2ヶ月間取り組んだ結果
改善に取り組む前の「アプルーブからマージ」の3ヶ月間の平均は4.4時間でしたが、取り組み後は平均を1.3時間まで削減することができました。また週平均で見ると、取り組み後はほとんどの期間で1時間未満を維持しており、再現性のある継続的な改善であることもわかります。
良かったこと
- 開発ルールを整備したことで正しい方法で開発を行える
- チームメンバーがサイクルタイムを意識した開発が行えるようになった
- その結果、アプルーブからマージまでの平均時間が短くなった
失敗したこと
失敗したこととしては、時間を早めることを意識し過ぎて、正しい開発方法からずれてしまったことがありました。
私たちは「アプルーブからマージ」までのサイクルタイム改善のために、マージ条件を満たしたら最後にアプルーブをつけた人がマージをするというルールを作りました。
一般的にはPull Requestは作成者がマージをすることが多いと思いますが、マージ条件を満たしているのであれば最後にアプルーブを出した人でもマージを出来るはず。そうすればマージを忘れることはなくなり、サイクルタイムを縮められるといった狙いでした。
実際に2週間実施をしてみると確かにサイクルタイムの時間は短くなってきたのですが、振り返りをするとPull Requestを作成者がマージをしないことによるネガティブな意見が多く出ました。
- 開発チケットのステータス変更を忘れがちになる
- マージして良いタイミングを間違えていつか問題が起きそう
- Pull Requestが知らない間にマージされていることに違和感がある
その結果、Pull Requestは作成者がマージをするといった自分たちにとって自然なルールに戻すこととなりました。
この経験からチームでは、サイクルタイムの改善のために何かを疎かにしたり、不自然なルールにするようなことはやめるといった学びを得られました。
最後に
チームでサイクルタイム改善に取り組んだことにより、全員がサイクルタイムを意識した開発が行えるようになりました。この意識ができるようになるだけで数値は目に見えて良くなることが多いため、改善に取り組む時はまずはチームの共通認識を作り、サイクルタイムに意識を向けるところから始めるのも効果的かと思います。
また今回は「アプルーブからマージ」の改善について紹介しましたが、チームでは引き続き他のプロセスの改善にも取り組み、サイクルタイム全体を改善することを目指していきたいと考えています。
We Are Hiring!
SmartHR では一緒に SmartHR を作りあげていく仲間を募集中です！
少しでも興味を持っていただけたら、カジュアル面談でざっくばらんにお話ししましょう！
