なぜ個人開発で？ GitHub ActionsとIssue駆動開発で実現する「未来の自分」を助ける開発プロセス

なぜ個人開発で？ GitHub ActionsとIssue駆動開発で実現する「未来の自分」を助ける開発プロセス

はじめに：個人開発の「あの課題」

個人開発をしていると、こんな経験はありませんか？

• 「このコード、なんで書いたんだっけ…？」
• 思いつきでブランチを切り、気づけば feature/new-idea のような謎ブランチが乱立。
• 半年後の自分が見ても、変更の意図が全くわからない。

私自身も、この「未来の自分が困る問題」に直面していました。そこで、現在進行中のポートフォリオプロジェクト「ハンニバルのアルプス越えルートアプリケーション」で、あえて徹底したIssue駆動開発の仕組みを導入することにしました。

これは、単に技術力を示すだけでなく、「再現性のある開発プロセスを構築し、チーム全体の生産性を向上させる力」を証明するための挑戦です。

構築した開発フローの全体像

すべての作業はGitHub Issueから始まります。フローは次の手順で回します。

1. Issueを作成する（gh issue create）。
2. ブランチを作成する（feature/#XX-description）。
3. 実装してConventional Commitsでコミットする。
4. Pull Requestを作成し、本文に「Closes #XX」を記載する。
5. Lint・Test・Security Scanなどの自動チェックが走る。
6. チェック通過後にマージし、mainを更新する（gh done XX）。
7. 次のIssueに戻り、サイクルを繰り返す。

この一見すると「面倒くさそう」なフローを、いかにスムーズに、かつ開発体験を損なわずに実現するかが鍵でした。そのために活用したのが、GitHub Actionsによる徹底的な自動化と、各種テンプレートによる標準化です。

開発プロセスを支える3つの仕組み

1. 「何をすべきか」を明確にするIssue/PRテンプレート

すべてのタスクは、まずIssueを作成することから始まります。CLIからでも、Web UIからでも同じ内容を記述できるよう、テンプレートを整備しました。

【Issueテンプレートの主な項目】

• 背景・目的: なぜこの変更が必要なのか
• 要件定義 / スコープ: 何を達成すれば完了とみなすか
• 受け入れ条件: 完了の具体的な基準
• 設計方針: どのように実装するか
• 変更予定ファイル: 影響が及ぶ可能性のあるファイル
• テスト計画: どのようにテストを実施するか
• ダウンタイム: 本番環境での停止時間が発生するか
• リスクレベル: 変更に伴うリスクの度合い (low, medium, high)
• コスト影響: AWSコストに影響があるか (none, small, medium, large)

【必須ラベル】
Issue作成時には、以下の体系に沿ったラベル付けも必須となっています。

• type:*（例: type:feature）
• area:*（例: area:backend）
• risk:*（例: risk:low）
• cost:*（例: cost:none）

これにより、実装前に「何を・なぜ・どう作るか」を言語化する癖がつき、手戻りが劇的に減少しました。PRテンプレートも同様に、変更内容や影響範囲をレビュワー（この場合は未来の自分）に明確に伝える工夫をしています。

2. プロセスを強制し、品質を守るGitHub Actions

ルールを作っても、守られなければ意味がありません。そこでGitHub Actionsを使い、開発プロセスを自動化・強制しました。

• PRチェック (pr-check.yml): PRが作成されると、自動でLint、ビルド、テストを実行。品質基準を満たさないコードはマージできません。
• セキュリティスキャン (security-scan.yml): Trivyによる脆弱性スキャンやGitleaksによるシークレット検出を自動化。セキュリティのベースラインを維持します。
• ラベル同期 (labels.yml): Issue/PRに付けるラベルをコードで管理。type:featureやarea:infraといったラベルがリポジトリに自動で同期され、誰でも同じ基準でタスクを分類できます。

3. 面倒な作業をなくす開発者体験（DX）の向上

厳格なルールは、開発の足かせになることもあります。そこで、GitHub CLIのエイリアス機能を活用し、定型作業をワンコマンドで実行できるようにしました。

【PRマージからmainブランチ更新までを1コマンドで実行するエイリアス】

# gh done {PR番号} と打つだけでOK

gh alias set done '!f() { gh pr merge "$1" --merge && git checkout main && git pull origin main; }; f'

このgh doneコマンドにより、PRをマージした後の「mainに移動して、pullして…」という面倒な作業から解放され、すぐに次のタスクに取り掛かれます。

なぜここまでやるのか？

個人開発でこの仕組みを導入したメリットは、計り知れません。

1. 思考の整理とドキュメント化: Issueを作成する過程で、要件や設計が自然と整理され、それがそのまま仕様書として機能します。
2. 変更の追跡性: 半年後でも、IssueとPRを辿れば「なぜこのコードが変更されたのか」が一目瞭然です。
3. 品質とセキュリティの担保: 自動化されたCI/CDパイプラインが、常にコードの品質とセキュリティをチェックしてくれます。
4. チーム開発への貢献力の証明: このポートフォリオは、単なる「動くアプリ」ではなく、「スケール可能で保守性の高い開発プロセスを構築・運用できる能力」を示すものになりました。

まとめ

Issue駆動開発は、チームだけでなく個人開発においても、プロジェクトの品質と生産性を劇的に向上させる強力な武器となります。

もしあなたが「未来の自分」を助け、より構造化された開発プロセスに挑戦したいなら、まずはIssueテンプレートを一つ作るところから始めてみてはいかがでしょうか。きっと、あなたの開発体験はもっと良いものになるはずです。