【GitHub】Issueドリブン開発を個人開発に取り入れてみた話
こんにちは、ぐらじえ（＠grazie_Engineer）です。
今回は個人開発をするにあたって、「Issue ドリブン開発」とかいう開発手法を見つけて、実践してみたので、その話ができればと思います。
私は、IT 経験 1 年にも満たない初学者、且つ現場でもソース管理に SVN 等を使用しているため、Git の操作もままならないようなスペックです。
そんな私でもなんとなく「Issue ドリブン開発」についてなんとなく理解し、いいなと思ったので、私目線での「Issue ドリブン開発」を紹介していこうと思います！
Issue ドリブン開発とは
Issue ドリブン開発とは？
色々調べた結果以下のような説明を見つけました！
つまり、私の解釈では、開発で行うべきタスクを「issue」として管理し、「issue」ごとにブランチを作成して開発を進め、コミット、プルリクエスト、マージを行っていく手法だという認識です。
以下公式ドキュメントに、Issue についての解説がたくさん載っているので、こちらもぜひお読みください！！
手順
ざっと、以下のような手順です。非常にシンプル！
- Issue の作成。（タスクの作成）
- main ブランチから Issue に基づいたブランチを作成。
- 作成したブランチで開発を行い、コミットする。
- プルリクエストを作成し、マージする。
- 手順１．に戻る。
個人開発で実践した
「個人開発だしいいやー」という考えのもと、そんなに凝った運用はしませんでしたが、、上記の「手順」に沿って開発を行いました！
とりあえずこんな感じで機能追加や、バグ修正のタスクごとに Issue を作成してみました。
それぞれタイトルは自分でわかればと思い、結構雑かもです、、
Issues 画面
Issue 作成後のブランチ作成時、便利なことに、「Development」の中に"Create a branch"という箇所があるので、そこを押下すればブランチの作成まで一気に行えてしまいます！
"Create a branch"からブランチを作る
私はめんどくさかったので使わなかったのですが、Issue ごとに「Labels」なども設定しておくと、後で見返した際にわかりやすいかと思います！
また、作成した Issue は自動的に番号が振られるので、ブランチ名はその番号を使い、統一して管理してあげると非常にわかりやすかったです。
私は、ブランチ名を「issues-69」のように管理していました。
ただもっと絶対にいい命名規則はあるので、そのあたりは別の方の記事なども参考にしてみてください！
ちなみに私は今回の「Issue ドリブン開発」を行う際、以下の記事を参考にさせていただきました。
開発フローに取り入れた感想
今回「Issue ドリブン開発」を実践したことによって感じたメリット、デメリットを紹介できればと思います。
メリット
私が感じたメリットは以下の 3 つです！（どれも似たような意見ですが、、）
- その日やるべきタスクを容易に把握できる。
- Issue ごとの開発規模の大小にもよりますが、コミットする範囲が大きくなりすぎず、ブランチ、プルリクエストなどの管理も煩雑になりにくくなった。
- 後で Issue を見直した時に、どういう変更を行ったのかなどわかりやすい。
まあ、要するに"やるべきこと"を書き出して、それをこなしていくということの繰り返しなので、その"やるべきこと"の管理がシンプルで容易になったという感じです。
デメリット
逆にデメリットに感じた部分もありました、、
- 小さい規模の変更などを Issue にする場合、ちょっとめんどくさい！（いや、結構面倒、、）
ちょっとこの 1 部分だけ変更したいな～（小規模の修正など）みたいな場合に、いちいち Issue を作成して、Issue に紐づくブランチを作成して、・・・っていう作業が、ちょっとめんどくさいなぁと私は感じました、、
ただ、こんな小さな箇所までも管理できるこの開発フローは素晴らしいなと思いました！
（ただただ、めんどくさい、、）
まとめ
今回は、Issue ドリブン開発を個人開発に取り入れてみた話をさせていただきました！
まあ、デメリットなんかも上げましたが、なんだかんだやってよかったなーと思います！
個人的には、かなりいい開発フローだと感じたので、今後の開発なんかでも、「Issue ドリブン開発」は取り入れていく予定です。
ぜひこの記事を読んでいただいた皆様にも実践していただければと思います！！
Discussion