【GitHub】Issue ドリブン開発を個人開発に取り入れてみた話

こんにちは、けいこんぐらです！

今回は、Issue（イシュー）ドリブン開発という開発手法を見つけて、実践してみた話ができればと思います 🙆‍♂️

これは、私が過去に個人開発で実践した開発手法の体験談になりますので、参考程度に読んでいただければと思います！

いざ実践してみて、「いいな！」と感じたので、私目線での Issue ドリブン開発を紹介できればと思います ✨

Issue ドリブン開発とは？

Issue ドリブン開発とは、

Issue つまり、実装における課題をタスクとして管理・運用する開発手法です。
新規機能の追加やバグ修正などを Issue として立て、それを解決するためのブランチを切り、コミットやプルリクエストで適宜 Issue を参照しながら開発を進めるというフローを取ります。

開発で行うべきタスクを Issue として管理し、Issue ごとにブランチを作成して開発を進め、コミット、プルリクエスト、マージを行っていく手法です 📝

こちら Issue に関しての公式ドキュメントですが、

リポジトリに問題を作成して、作業の計画、議論、追跡を行うことができます。

とありますね！

Issueについて - GitHub Docs

GitHub Issues を使用してアイデア、フィードバック、タスク、バグを追跡する方法を学びます。

https://docs.github.com

手順

簡単に説明すると以下のような手順で開発を進めていきます 🔎

1. Issue の作成（タスクの作成）
2. main ブランチ、もしくは develop ブランチなどの開発用ブランチから Issue に基づいたブランチを作成
3. 2 で作成したブランチで開発を行い、コミット + プルリクエスト
4. プルリクエストを確認し、問題なければマージする
5. 手順 1 に戻る

個人開発で実践した

「個人開発だしいいかな」という考えのもと、そんなにガチガチな運用はしませんでしたが、上記でも説明した「手順」に沿って開発を行いました！

※ 過去遊びで作っていたタイピングゲームで、今はリポジトリをアーカイブしています 🙇‍♂️

grazie-a-k-a-keita/jojo-typing-v1

『ジョジョの奇妙な冒険』モチーフにした、タイピングゲーム. Contribute to grazie-a-k-a-keita/jojo-typing-v1 development by creatin

https://github.com

とりあえずこんな感じで機能追加や、バグ修正のタスクごとに Issue を作成するところから始めてみました！

Issue の粒度はそれぞれの考え方やプロジェクトで統一すれば良いと思いますが、私は結構雑に切り出しています 🗡️

Issue ごとに Labels なども設定しておくと、後で見返した際にわかりやすいかと思います！

これは別リポジトリですが、Labels を使用すると見栄えが良くなる！

Tips

Issue とプルリクエストを紐づけて、プルリクエストがクローズされると、Issue も自動的にクローズされるようにしておくと便利です 💡

Closes #10

Pull RequestをIssueにリンクする - GitHub Docs

pull request またはブランチを issue にリンクして、修正が進行中であることを示し、pull request またはブランチがマージされるときに issue を自動的にクローズすること

https://docs.github.com

また、個人的に、作成した Issue は自動的に番号が振られるので、ブランチ名はその番号を使い、統一して管理してあげると非常にわかりやすかったです。

私は、ブランチ名を issues-69 のように管理していました。

ただ、ブランチ名は個人やチームの命名規則のルールによって異なると思うので、そのルールに従えば問題ないと思います！

feature/issues-69
bugfix/issues-42
hotfix/issues-100
などなど

ちなみに私は今回の「Issue ドリブン開発」を行う際、以下の記事を参考にさせていただきました 🧐

【メモ】Issueドリブン開発とブランチ命名規則ついて【Git】 - Qiita

こんにちわ=) 初学者の皆さんは「Issueドリブン開発」や、Gitのブランチ名にも命名規則があるのを知ってますでしょうか？ 自分は「聞いたことあるな」くらいにしか考えていませんでしたが、最近は開発設

https://qiita.com

取り入れた感想

今回「Issue ドリブン開発」を実践したことによって感じたメリット、デメリットを紹介できればと思います。

メリット

私が感じたメリットは以下の 4 つです ✅

1. その日やるべきタスクを容易に把握できる。
2. Issue ごとの開発規模の大小にもよりますが、コミットする範囲が大きくなりすぎず、ブランチ、プルリクエストなどの管理も煩雑になりにくくなった。
3. プルリクエストほど、Issue は気軽に作成できるので、思いついたことをすぐにタスク化できる。
   • 結局やらなかったら Issue をクローズすればよいだけなので、気軽に作成できる。
4. 後で Issue を見直した時に、どういう変更を行ったのかなどわかりやすい。

要するに、やるべきことを書き出して、それをこなしていくということの繰り返しなので、そのやるべきことの管理が GitHub の同じリポジトリ上でシンプルで容易になったという感じです！

デメリット

逆にデメリットに感じた部分もありました、、💦

1. 小さい規模の変更などを Issue にする場合、めんどくさい！

   • 「ちょっとこの一部分だけ変更したいなぁ」（小規模の修正など）みたいな場合に、いちいち Issue を作成して、Issue に紐づくブランチを作成して、・・・っていう作業が、ちょっとめんどくさいなぁと私は感じました、、

マメな人じゃないと、Issue の作成を忘れたりしてしまうかもしれませんね、、

でも、一般的な開発フローに取り込む分には、特に大きなデメリットはないと思います！

おわりに

今回は、Issue ドリブン開発を個人開発に取り入れてみた話をさせていただきました 🚀

デメリットなんかも上げましたが、なんだかんだやってよかったなーと感じています！

今回は個人で取り入れた話ですが、チーム開発となると誰が何をやってみたいなことが GitHub 上で可視化できるので、手軽に大きな恩恵を受けられる開発手法だと感じました！

私自身、今後の開発なんかでも、「Issue ドリブン開発」は取り入れていく予定です。

この記事を読んでいただき、いいなと感じていただいた皆様にもぜひ実践していただければと思います！！