こちらは バイセルテクノロジーズ Advent Calendar 2023 の12日目の記事です。 昨日の記事は、福田さんのモノレポを導入して開発効率を上げるでした。
はじめに
開発一部の伊与田です。
私はAXISという在庫・販売管理システムのチームでバックエンドエンジニアとして開発、運用を担当しています。
今回は直近取り組んでいる開発生産性の改善について、お話ししていきたいと思います。 AXISでは今までそういった取り組みをしたことが無かったので0からのスタートでしたが、 何も仕組みの無いところからどのように開発生産性の改善をするまでに至ったのか、 具体的にどのような取り組みをしたのかをチームの事例としてご紹介できればと思います！
前提
- 開発手法はアジャイルのスクラム開発を採用しています。
- タスク管理はJIRAというツールを使用しています。
- プルリクエストをPRと表記します。
- Findy Team+というツールを利用して生産性の可視化を行なっています。
改善前のチームの状態
改善前のチームは以下のような状態でした。
- 開発の生産性って何？
- デプロイは週に1回くらい
- よくPRのレビューが滞留していることがある
- スクラム開発の理解度も低い
開発が遅くてリリースに支障が出るなどの問題は起こってはおらず、目の前の課題に実直に取り組み、ユーザーの課題を解決し、システムに反映するということはできていたと思います。 しかしチームとしてどの程度のアウトプットが出せているのか、そもそもどのような指標を生産性のアウトプットとして考えればいいのか分からない。 生産性という観点ではチームのことを把握できていない透明性の低い状態だったと思います。
また漠然と生産性が高くないだろうという定性的な実感はあったのですが、どういったことを改善すべきかを明確にできていない状態でした。
そもそも開発生産性って何？
まず開発生産性とはなんぞや？ という状態だったので、そこを明らかにするステップを踏みました。 エンジニアには一般的なツールになりましたが、ChatGPTに「IT企業でアプリケーション開発に従事するチームにとって、生産性とはなんですか？」という質問をしてみました。
ざっくりした情報ではありますが、どうやら開発リードタイムや、コードの品質などを指標にできそうだということと、 改善のためにアプローチできることは色々ありそうだということが分かりました。
見えてきた課題
そして上記の情報や社内の有識者からのアドバイスを踏まえて、AXISチームでは以下のようなことに取り組むことで生産性を上げることができると判断しました。
- PR作成数を増やす
- デプロイ頻度を増やす（Prodリリース）
デプロイ頻度はそもそもリリースする改修を増やす必要がある為、順番的にはまずPR作成数を増やすことが重要であると考えました。 PR作成数を増やしていくために、何をすべきか考えたところ以下のような具体的な課題が見えてきました。
- PRレビューの滞留
- タスクの粒度が大きすぎる
また最終的にデプロイ頻度を増やすには、以下の課題解決が必要であることが分かりました。
- デプロイが1回/週で固定される運用になっている（＝MAX1回/週デプロイになる）
取り組んだ事
事例1：PRレビューの滞留
問題発生理由
そもそも何故PRレビューの滞留が起きているのか分析した時に、以下のような理由があることが分かりました。
PRレビューを優先する意識がない
これは今回の取り組みの中でも一番最初に対処した内容で、意外と致命的な問題は意識的な所でした。 PRをオープンしてもレビューするまでに時間がかかるので直接的に滞留する一因になります。 早く見ればいい話なのですが、何も言わずにできていれば問題になっていないので解決すべき課題でした。
どれだけ早く開発を進めてもレビューが通らないとデプロイができないので、デリバリの観点でもここがボトルネックになっている状態でした。
PRの変更行数、ファイル数が多すぎる
チームにヒアリングしたところ、PRの内容が肥大化していることも原因であることが分かりました。 確かに1つのPRでFile Changedが20個だったり、変更行数が1000行を超えていたりするとレビューに二の足を踏んでしまうのは頷ける状況でした。
改善方法
PRレビューを優先する意識がない
もちろん意識的にレビューをしましょうという投げかけはしましたが、それ以外に仕組み解決するために以下のようなことを取り入れてみました。
1日に1回、PRのApproveを出すルール
地味ですが意外と効果がありました。 自分の作業に没頭しすぎるとレビューをしないという事も散見されたため、1日1回でもレビューをしてもらうことでメンバーのレビューを習慣化できたと思います。
Githubのレビューリマインダー
「そもそもレビュー依頼に気づかなかった」、「後でレビューをしようと思っていて忘れてしまった」ということがありました。 そこはGithubのリマインダー機能を活用しました。 自分がレビュアにアサインされたPRにApproveしていない場合、Slack通知されるようにしたことで、レビューの見落としを防ぐことができるようになりました。
PRの変更行数、ファイル数が多すぎる
明確に1PRあたりの変更行数やファイル数の上限を決めてもいいのですが、PRどう分割するか迷うという意見もあったので、以下のような仕組みで取り組みをしました。
機能や作業単位でPRを区切るようにした
検索ロジック、マスタデータ修正、フロントエンド、テストコードなど意味のある単位でPRを作成してもらうようにしました。 割とざっくりした運用でしたが効果は大きく、変更にもよりますがファイル数は大体5ファイル前後、変更行数も多くても300行くらいには収まるようになったので、レビュー着手のハードルが下がり改善に繋がりました。 その効果かレビュー依頼からレビューまでの時間も改善が見られました。
結果
今回8月からこれらの取り組みを始めたのですが、 半年間のレビュー数の推移を見てみると取り組み開始翌月からの2ヶ月は半年の平均値を超え改善傾向にあることが分かりました。
またPRオープンからレビュー着手までの推移を見たところ、取り組み開始付きから顕著に改善が見られ、後半2ヶ月について1時間以内にレビューが着手されていることが確認できました。
事例2：タスク粒度が大きすぎる
問題発生理由
こちらは上述した「PRの変更行数、ファイル数が多すぎる」といった問題にも関連するのですが、 そもそもプランニング時点でアサインしているタスクの粒度が大きいために、開発者もその粒度のまま1つのPRに作業を詰め込んでしまう、ということが根本的な原因であると分かりました。 またタスクの粒度が大きくなる背景としては、プランニング時に要件や完了基準を詰めきれないままアサインをしてしまっている、ということがありました。
改善方法
リファイメントの採用
本来プランニングでは開発チームのリソースを使って次のスプリントのゴール達成に向けてどのようにタスクアサインするか戦略を考える作業をメインにしたいのですが、 プランニングの時間を使って要件や完了基準の確認の作業も合わせてしているような状況でした。 今までチームではリファイメントというタスクの精査をするためのスクラムイベントを実施していなかったので、改めてチームで実施するようにして、 そちらに作業を切り出して時間を確保することで、チケットの精度を高めることができました。
粒度の大きいタスクを分割
そしてここからがタスク粒度の肥大に対しての具体的な対策なのですが、開発者の作業単位にチケットを分割するようにしました。 基本的にこのチケットの粒度でPRを作成してもらうことによって、タスクアサインの段階でPRの粒度を小さくするようコントロールすることが可能になりました。
結果
思うように結果の出ていない月もありますが、傾向としては増える方向になっているかと思います。
事例3：デプロイが1回/週で固定される運用になっている
問題発生理由
AXISチームではスプリントレビューを毎週固定の曜日に決めており、そこまでに溜まった変更をまとめてスプリントレビュー、結合テスト、デプロイするような運用を行なっていました。 この運用だとどれだけ早く開発が完了してもスプリントレビューまで待機させないといけません。
改善方法
スプリントレビューを毎週固定の曜日ではなく、実装完了したタイミングでPdMと開発者が二人で行うことにしました。 開発者間の成果物の共有については、PRで動作確認の動画を貼るなどしているのでそれで充足すると判断しました。
結果
まだ取り組み中の段階ではありますが、デプロイ頻度がどのように改善されたのかを確認してみます。
半年前と比べるとこちらも上昇傾向にあり0.3件程度の改善が見られることが分かりました。 まだPRの作成数が思うように伸ばせていない中で、デプロイ頻度が改善しているのはスプリントレビューを適宜行うように変更したことが大きいと思われます。 スクラムのフローを改善することで、デプロイ頻度を上げられたという点と必要な機能や改修をユーザーに最速でデリバリーできるようになったところが成果だと考えています。
まとめ
「PRのレビュー滞留」の改善では、レビューをするための意識付けや仕組みの構築の甲斐もあってレビュー速度が大幅に改善し、今では自発的にメンバーがレビューに取り組む文化を作ることができました。
「タスクの粒度が大きすぎる」の改善では、既存のスクラムイベントにリファイメントを追加するという大きな変更をしました。 粒度を下げること、そもそもの要件をしっかり詰めることを徹底することで、作成されるPRの粒度を小さくコントロールし、 レビュー速度の改善、要件漏れ防止、進捗管理コストを抑えるなど様々な効果を得ることができました。
そして「デプロイが1回/週で固定される運用になっている」の改善では、デプロイに制限がかかっていたフローを変更して、 オンデマンドにスプリントレビューやデプロイを行うことで、デプロイ頻度の改善ができました。
まだ改善が浸透しきっていないこともあってか、PRの作成数が思うように伸びないという課題はあるものの、 色々な数値が改善傾向にあるのでこれからも調整をしながら取り組みを続けていきたいと考えています。
最後に
今回は開発生産性をどのように改善するのか、AXISチームが0からスタートして取り組んだことをご紹介させて頂きました！ 最終的な目的としてはデリバリの速度や量の向上をすることで、ユーザーの課題解決を素早く行い、事業の目標に寄与することにあるので、 その点は忘れずにこれらの取り組みを通して、開発生産性の高いチーム作りができたらいいなと考えています。 指標の決め方や改善の取り組み方はチームによって様々あると思いますので、一例として参考にしていただければ幸いです。
BuySell Technologiesではエンジニアを募集しています。こういった取り組みに興味がある方はぜひご応募をお願いします！
