kk-web

Issue駆動開発ノススメ

2022-12-02

この 6 年間、さまざまなプロジェクトで働いてきましたが。

開発手法というのは会社やプロジェクトによって本当にさまざまで、それすなわち 100 人には 100 通りの考え方が存在するというわけです。

そんな中で、数年前に働いたとあるプロジェクトでの開発手法が Issue 駆動開発でして、これがまーシンプルでわかりやすく、開発初心者の方にもとっつきやすい良い方法だなと感銘を受けたことがあります。

そこから自身がテックリードを務める際は Issue 駆動開発を採用するようになり、そこにスクラムも乗っけた形にまで昇華させてきました。

もちろん、今自分が運用しているフロントエンド開発レッスンでもこの手法を導入しており、受講者の方からは非常に好評だったりします。

ということで、今回は自分流ではありますが Issue 駆動開発のやり方を書いていこうと思います。

前提

今回は以下のルールに沿って話を進めていきます。

  • GitHub Flow

Git Flow でもなんら問題ないです。

使用ツール

  • GitHub

Jira や Notion など他のサービスは NG です。

スクラムを導入する場合は Zenhub のようなツールの導入も必須となりますが、本記事では触れません。

類似サービスも多いため ZenHub にこだわる必要もないですが、ちゃんと GitHub と連携が可能なサービスを選択しましょう。

事前準備

Issue Templates を設定する

GitHub ではデフォルトで Bug report と Feature request の 2 つの Issue templates が準備されているので、この 2 つを Git の管理下に入れましょう。

Squash merge のみ許容する

GitHub では Pull Request を Merge する際、以下の 3 つの手段が存在します。

  • Merge commits
  • Squash merging
  • Rebase merging

個人的には Squash merge 派なので、他の 2 つは設定でできないようにしちゃいましょう。

Head branch は自動的に削除する

リモートブランチが乱立しているリポジトリは最悪です、誰も得をしません。

Automatically delete head branches の設定をオンにしましょう。

ブランチにルールを設定する

main ブランチに対して以下を設定しましょう。

  • PR を通してのみ merge を許容する
  • status check がすべて通った PR のみ merge を許容する
  • 1 人以上のレビューが通った PR のみ merge を許容する
  • ブランチをロックする
  • force push を許容しない
  • ブランチの delete を許容しない

上記に加え、以下の設定を入れるともっと強固になると思います。

  • Require conversation resolution before merging
  • Require deployments to succeed before merging

開発手順

ざくっと開発手順は以下のようになります。

  1. Issue を作成する
  2. main ブランチから Issue に紐づくブランチを切り出す
  3. 開発を行う
  4. commit を 1 本だけ打つ
  5. push しリモートブランチを作成する
  6. PR を作成し、コードレビューを依頼する
  7. レビューが通り次第、PR を merge する

いくつか注意すべきポイントがあるため、書き出します。

Issue の作成は Issue Template を必ず使用する

新しい機能を開発する際は Feature request を、バグの報告は Bug report を使用するようにしましょう。

その際、担当者やラベルなどは積極的に貼るようにしましょう。

ラベルについてはデフォルトのものだけで十分だと考えています。

ブランチ名はルールに沿って

たとえば Issue 番号が #1 の Issue に対応するブランチを切り出す場合、feature/#1-hogefuga のような名前で切り出すように統一しましょう。

ブランチ名がルールに沿っていない場合、レビュー時に指摘することも重要です。

PR に紐づく commit は 1 本のみ許容する（コードレビュー前）

もっとも賛否が割れる部分かもしれませんが、個人的に PR に紐づく commit は少なければ少ないほうが良いと思っています。

そもそも PR の粒度って細ければ細かいほうが絶対に良いと思っています、粒度が粗い PR から得られるメリットってなにもないですよね。

PR に紐づく commit が 1 本しか打てないということは、必然的に Issue の粒度もある程度細かくせざるを得ないわけで。

結果的にスクラムのスプリントバックログの粒度に沿ってくるんじゃないかな、というのが個人的な意見です。

粒度の粗い PR を上げてしまうと、コードレビューに時間がかかるわ修正範囲は広いわいつまでも merge されないわで最悪です。

PR なんて上げてなんぼなので、それすなわち Issue もそこそこ上げる必要があるということですね。

そもそも Issue を立てることがめんどくさいと思っているプログラマーは Issue 駆動開発に合っておらず、ひいてはスクラムにも合っていません。

なんでもかんでも細かくすることをしっかりと意識しましょう。

PR に紐づく commit のフォーマットは Conventional Commits に沿うようにする

PR に紐づく 1 本目の commit は GitHub で少し特殊な扱いをされます。

Conventional Commits では以下のフォーマットが定められていますが。

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

1 行目がそのまま PR のタイトルとなり、2 行目以降が PR の本文メッセージとして扱われます。

そのため、PR を立てる際にいちいちタイトルやメッセージを書く必要がなくなり、ぐっと開発速度が上がります。

また Issue に紐付かない PR の作成は禁止するため、必然的に PR の Template も不要となります。

PR に紐づく 1 本目の commit で必ず Issue 　を紐付ける

Conventional Commits のフォーマットのうち、optional footer で Issue を紐付けるようにしましょう。

たとえば close #1 と書くと PR に対し自動的に #1 の Issue が紐づくようになります。

そのため PR を作成する際に手動で Issue を紐付ける必要がなくなり、ミスが防げるようになります。

また PR が merge された場合、自動的に紐づく Issue も close してくれるようになるため、いちいちステータスを手動で変える必要もなくなります。

デメリット

ここまで読んでいただけると「Issue 駆動開発って最高じゃん！」って感じるかもしれませんが、実際最高です、個人的には導入しない理由がわからないレベルです。

とはいえいくつかデメリットもあります。

どんなに小さな開発や修正であっても Issue を立てる必要がある

誤字の修正を行おうとしても、まず Issue を立てて feature ブランチを切って修正して commit して PR を上げてコードレビューを依頼して通ったらようやく merge ができるという、なかなかどうしてめんどくさいフローが発生してしまいます。

Issue 駆動開発では基本的に例外を認めるべきではないと思っているので、この対応でなんら問題ないと思っていますが、イヤな人はイヤだろうなーと思います。

ただどんなに小さな修正であっても型にはめることができるわけですから、むしろメリットなんじゃないかとすら思っています。

そんな感じです、いかがでしょうか。

最近の日本では GitHub で Git は管理しているのに、なぜか Issue は Jira や Notion で管理しているプロジェクトが増えつつあって、個人的にはちょっと理解できません。

GitHub は世界でもっとも使用されているだけあって、GitHub 内で完結させるとかなりの部分が自動化可能なため、単純に開発速度とコードの質が上がってきます。

またスクラムを導入するのであれば ZenHub を入れることで複数のリポジトリの管理も容易となるため、良いことづく目です。

むしろ Jira や Notion を使うメリットってなんなんですかね？過去何度もそういうプロジェクトで働いてきましたが、GitHub で完結させないことによるデメリットがあまりにも大きすぎるよなーと個人的には。

Issue 駆動開発は仕事だけでなく、プライベートや個人開発でも絶大な効果を発揮してくれるため、ぜひぜひやってみて感想をいただけると嬉しいです。

© 2018 kk-web