2015.12.12

料理サプリにおけるスクラム開発フローの改善

naoty

この記事は RECRUIT MARKETING PARTNERS Advent Calendar 2015 の投稿記事です。

こんにちは。naotyです。入社2年目にして初ブログです。宜しくお願いします。

今回は僕が関わっている料理サプリでの開発フローをご紹介したいと思います。ここでの開発は主にサーバーサイドを想定していますが、スマートフォンアプリ開発にも部分的に導入可能です。本記事が対象としているのは以下のような開発者です（というか、かつての自分です）。

モダンな開発現場に憧れるものの、自分のチームにどう導入すべきかわからない開発者
他社の開発フローを参考にしたい開発者

開発フロー改善の進め方

料理サプリでは、スクラムを採用しています。2週間をスプリントとして、スプリント計画やレトロスペクティブ（ふりかえりの場）を実施しています。毎回、レトロスペクティブでは開発自体を改善するアイデアが出てきます。そうしたアイデアは通常の開発業務と同様にスプリントバックログに追加され実行されていきます。

開発フローのアイデアはQiita:Teamでドキュメント化されています。そこでチームメンバーから意見や合意を得て、実際に改善を進めていきます。また、Qiita:Teamで共有されているため、他のチームからも意見をもらうことがあり、他のチームでの知見を踏まえて開発フローをブラッシュアップすることができています。

現在の開発フロー

料理サプリでは、GitHubのprivateリポジトリを使って開発しています。以前はBitbucketを使っていたものの、部全体の方針によってGitHubに移行となりました。BitbucketにはApproveボタンなどGitHubにはない良いところがあるのですが、他社で行われている開発フローの知見や各種ツールを利用しやすいというのがGitHubの大きなメリットでした。

ブランチは大きくmaster、develop、各featureブランチ（以下、featureと表記）に分けて運用しています。各機能の実装ではfeatureからdevelopへのPull requestを作成し、リリース時にはdevelopからmasterへのPull requestを作成します。ここまではよくある開発フローだと思います。

Pull request

Pull requsetの作成はすべてコマンドから行っています。featureからdevelopへのPull requestは以下のようなgit-prというコマンドで作成しています。

#!/bin/sh
repo="ourapp"
current_branch=`git symbolic-ref --short HEAD`
base_branch=${1:-"develop"}
compare_branch=${2:-$current_branch}
body=`cat ./PULL_REQUEST/FEATURE.md`
open "https://github.com/recruit-mp/${repo}/compare/${base_branch}...${compare_branch}?expand=1&amp;body=$body"

このコマンドは./PULL_REQUEST/FEATURE.mdに記述したテンプレートをPull requestのページに展開しながら開きます。このテンプレートには以下のようなことを含めています。

概要や目的
リリース手順
よくあるミスをまとめたチェックリスト

一方、developからmasterへのPull requestの作成はmotemen/git-pr-releaseを使っています。git-pr-releaseコマンドはfeatureからdevelopにmergeされたPull requestをまとめて、リリースされる機能をまとめたPull requestを作成します。git-prと同様にテンプレートを指定できるため、ここに以下のようなことを含めて、リリース直前の最終確認を行っています。

リリースされるPull request
リリース手順
リリース前のチェックリスト

コードレビュー

かつての開発フローでは、コードレビューが特定のチームメンバーに偏ってしまう問題がありました。偏った結果として、コードレビューが開発フロー全体のボトルネックになってしまったり、コードの経緯やノウハウを伝える機会がなくなってしまいました。

料理サプリでは、これに対していくつかの施策を行い解決しました。まず、【レビュー待ち】【レビュー中】【レビュー完了】というラベルをPull requestに付加し、レビュー待ちになっているPull requestを分かりやすくしました。

次に、botに【レビュー待ち】ラベルが付加されているPull requestの一覧を14時と17時に通知するように設定しました。botはr7kamura/rubotyを使って作っており、r7kamura/ruboty-githubというプラグインで以下のようにしてPull requestの一覧を取得しています。ちなみに、この機能は僕が送ったPull requestによってr7kamura/ruboty-githubに追加されたものです。

@ruboty search issues repo:recruit-mp/myapp type:pr state:open label:レビュー待ち

このbotの設定のおかげで、毎日レビュー待ちのPull requestが通知されるようになり、コードレビューがたまってボトルネックとなってしまう問題が解決しました。また、コードレビューが特定のチームメンバーに偏ってしまう問題は、「コードレビューは最優先に行う」というルールをチーム内で合意することで対応しています。

まとめ

ここまで料理サプリで行われている開発フローの一部をご紹介しました。これらの改善は2、3ヶ月の間に行われました。まだまだ改善すべき問題があるのですが、冒頭で述べた進め方によって今後も開発フローをどんどん改善していきます。

Recruit Tech Blog

タグから見つける