個人開発こそ、GitHub × AI × スクラムで回したほうがいい

はじめに

個人開発で意外と難しいのは、コードを書くことそのものより、何を先にやるかを決め続けることです。
一人で進めていると、自由に動けるぶん、別のアイデアに引っ張られやすくなります。少し触るつもりだった作業が、そのまま別の作業に広がることも珍しくありません。

最近はAIの支援で、

• アイデア出し
• 要件整理
• 実装
• レビュー
• 文書化

まで一気に進められます。
ただ、速く作れるようになったぶん、崩れ方も分かりやすくなりました。

• 思いついたことを、その場で作り始めてしまう
• AI が速いので、必要以上に機能を足してしまう
• タスクが散らかって、優先順位が見えなくなる
• 忙しいのに、完成物だけがなかなか増えない

そこで、GitHub を中心にした軽いスクラム運用 が個人開発と相性がいいと考えています。
ここでは、個人開発でも無理なく回せる形に絞って、GitHub × スクラム × AI の組み合わせを整理します。

背景

個人開発で詰まりやすいのは、技術そのものより、進め方がぶれやすいことです。
崩れるときのパターンは、ある程度共通しています。

• 新機能を思いついて、そのまま着手する
• UI が気になって横道に入る
• バックエンドを作っていたのに設計見直しへ広がる
• AI の提案を見て、予定外の改善まで始める

こうなると、手は動いているのに、完成したものが増えません。
スクラムが有効なのは、この散らかり方に歯止めをかけやすいからです。

1. 今やることを絞れる

スクラムでは、「全部少しずつ進める」のではなく、今週のスプリントで何を完成させるかを決めます。
あれもこれも同時に進めてしまう状態を止めるには、ここがかなり効きます。

2. 大きい話を、小さい完了単位に分けられる

個人開発では、最初の構想が大きくなりがちです。
スクラムの考え方を使うと、機能を「今週完了できる単位」に落としやすくなります。

3. 継続しやすくなる

本業や私生活があると、毎週使える時間はぶれます。
それでも1週間単位で回していれば、進みが悪い週でも立て直しやすいです。
個人開発では、長い計画をきれいに守るより、短い周期で修正していくほうが現実的です。

全体像

この流れでいちばん大事なのは、思いついたことはバックログに置き、今週やることだけスプリントに入れることです。
個人開発では、この線引きがあるだけでも進めやすくなります。

役割より視点を分ける

標準的なスクラムには、プロダクトオーナ（何を作るか決める役）、スクラムマスター（進め方を整える役）、エンジニア（実装を進める役）があります。
個人開発では、当然これを一人で担います。
ただし、役職名そのものを気にする必要はありません。

必要なのは、視点を切り替えることです。

プロダクト責任者の視点

• 何を作るべきか
• 今の優先順位は何か
• 今は何を捨てるべきか

進め方を整える視点

• 今週の目標は明確か
• タスクを積みすぎていないか
• 作業の流れに無駄がないか
• ふりかえりができているか

開発者の視点

• 実装を進める
• 不具合を直す
• 動く状態まで持っていく
• リリース可能な形に近づける

個人でやる場合は、

一人で全部やるからこそ、役割よりも視点を分ける

この切り替えができるだけでも、進め方はかなり安定します。

なぜ GitHub が向いているのか

個人開発では、道具を増やしすぎると続きません。
GitHub は、もともとコードを置く場所になっていることが多いため、そこに少し運用を足すだけで回しやすいのが強みです。

使える要素は十分あります。

• Issues（イシュー）: タスク、機能、調査、バグの管理
• Projects（プロジェクトボード）: カンバンでの見える化
• Milestones（マイルストーン）: スプリントの区切り
• Pull Requests（プルリクエスト）: 変更単位の整理
• README / docs: 方針や記録用の文書
• Actions: テストや確認の自動化

個人開発で地味に大きいのは、コードとタスクが離れにくいことです。
「何をやるつもりだったか」と「どこまで触ったか」が、同じ場所で追えます。

まずはここから始める

最初からきっちり作り込む必要はありません。
まずは、このくらいの構成で十分です。

my-product/
├── README.md
├── docs/
│   ├── vision.md
│   ├── roadmap.md
│   ├── backlog.md
│   └── sprint-review/
├── src/
└── .github/

最低限あると便利な文書は、次の四つです。

• vision.md: 何を解決するプロダクトか
• roadmap.md: 中期の方向性
• backlog.md: 今後やりたいこと
• sprint-review/: スプリントごとの記録

Issuesの分類

最初から分類を増やしすぎなくて大丈夫です。
最低限、種類 と 優先度 が見えれば回せます。

よく使う分類は次の通りです。

• feature: 機能追加
• bug: 不具合修正
• task: 雑務や設定
• refactor: 構成改善
• research: 調査や検証
• idea: 将来案の保管

Projectsの列

列もシンプルで十分です。

• Backlog（バックログ）
• This Sprint（今週やること）
• In Progress（進行中）
• Review（確認中）
• Done（完了）

見た目を整えることより、今どの仕事がどこにあるかすぐ分かることのほうが大事です。

Milestonesをスプリントにする

たとえば1週間ごとに、次のようなマイルストーンを作ります。

• スプリント 1（2026/03/09 - 2026/03/15）
• スプリント 2（2026/03/16 - 2026/03/22）

その週にやるIssueをひも付けておくと、週末に「何をやるつもりで、実際どうだったか」を見返しやすくなります。

スプリント期間

個人開発では、スプリントは1 週間くらいがいちばん扱いやすいはずです。

理由はシンプルです。

• 本業や私生活の影響を受けやすい
• 優先順位が変わりやすい
• 方向修正を早めに入れたい
• 長いと中だるみしやすい

スプリントゴールの書き方

良いスプリントゴールは、完成状態が見えます。

• ユーザーが初回登録を完了できる状態にする
• 基本画面を一通り操作できる状態にする
• 最小実用版（MVP）の最小フローを最後までつなぐ

あまり良くないスプリントゴールは、広すぎます。

• UIもAPIも通知も全部進める
• できるだけ多く進める
• 思いついた改善を全部入れる

スプリントでは、たくさん入れることより、焦点が合っていることのほうが大事です。

注意点

AIを使うと、個人開発のスピードはかなり上がります。
その一方で、放っておくと横にも広がります。だからこそ、何をやらないかを決めることが前より重要になります。

使いどころとして多いのは、たとえばこのあたりです。

• バックログの整理
• Issueの分解
• 実装のたたき台づくり
• プルリクエストのレビュー補助
• スプリントレビューとふりかえりの文章化

ここで大事なのは、AIに全部まかせないことです。
AIは便利ですが、「今なにを優先するか」までは決めてくれません。
普段から守ってほしいルールと、必要なときだけ使う進め方を分けておくと、扱いやすくなります。

そのときに役立つのが、Instructions（常設の指示）と Skills（作業手順）です。
このあたりは、以下の記事がかなり分かりやすく整理しています。

特に、copilot-instructions.md に何でもかんでも詰め込むのではなく、必要な場面でだけ読む SKILL.md に分けていく、という整理は実務でもかなり使いやすいです。

個人開発のAI基準

Skills はよくやる作業を、毎回ゼロから考えず進めるための型と考えると分かりやすいです。
大きな copilot-instructions.md に全部を書き続けるとノイズになりやすいので、テスト、設計、画面実装、レビューなどの単位で分けるほうが扱いやすくなります。

Instructions に書くもの

• ほぼ毎回必要
• 短く書ける
• プロジェクト全体の前提
• 守ってほしいルール
• 開発スタイルや制約

Skills に書くもの

• 特定タスクだけで使う
• 手順が複数ある
• 出力形式をそろえたい
• レビュー観点を固定したい
• 調査や要約の型を再利用したい

ここを分けておくと、AIが余計な方向に広がりにくくなります。
慣れないうちは特に、この差を意識しておくと扱いやすくなります。

おすすめの置き方

ファイル構成の一例です。

.github/
├── copilot-instructions.md
└── skills/
    ├── sprint-planning/
    │   └── SKILL.md
    ├── issue-breakdown/
    │   └── SKILL.md
    ├── pr-review/
    │   └── SKILL.md
    └── retrospective-summary/
        └── SKILL.md

置き方の考え方はシンプルです。

• copilot-instructions.md には、毎回効かせたい前提を書く
• skills/ には、必要なときだけ呼ぶ作業手順を書く

こうしておくと、AI の返し方にぶれが出にくくなります。

実際にどう回した

個人開発なら、体験した後に、このくらいの軽さがちょうどいいと思います。

週のはじめ

• バックログを見直す
• スプリントゴールを 1 つ決める
• イシューを 3〜5 件選ぶ
• 「今週やらないこと」を決める

毎日

• デイリーログ を 3 分だけ書く
• その日に触るイシューを 1 件決める
• 実装、確認、プルリクエストまでをできるだけ一続きで進める

週のおわり

• スプリントゴールに対して何が完了したか確認する
• 良かったこと / うまくいかなかったこと / 次に試すことで ふりかえる
• 次に試すことを次のバックログへ戻す

まとめ

個人開発でスクラムを取り入れるとき、教科書どおりに全部そろえる必要はありません。
押さえたいのは、次の点です。

• 今週の目標を明確にする
• 今やることと、いつかやることを分ける
• GitHub で見える化する
• AIを整理、分解、レビューに使う
• 毎週ふりかえる

個人開発では、全部を一気に進めようとしないことが大事です。
GitHubで見えるようにして、今週やることだけに絞る。AIはその補助に回す。
そのくらいの軽さのほうが、結果として続けやすくなります。