WithCodeMedia-1-pc
previous arrowprevious arrow
next arrownext arrow

WithCodeMedia-1-sp
previous arrowprevious arrow
next arrownext arrow

【完全保存版】GitHub ProjectsでWeb制作の工程管理を効率化!実践的な使い方を徹底解説

目次

この記事でわかること

  • GitHub Projectsの基本概念と、他のプロジェクト管理ツールとの違い
  • Web制作現場でGitHub Projectsを使う具体的なメリット・デメリット
  • リポジトリ作成からボード設定・issue管理・自動化まで7ステップの導入手順
  • issueテンプレート・PRテンプレート・CONTRIBUTING.mdの実用コード一覧
  • コーポレートサイトリニューアル・ECサイト機能追加の実践シナリオ
生徒

Web制作の案件が増えてきたんですけど、タスク管理がごちゃごちゃになって大変です…。誰が何をやっているのか全然わからなくて…

ペン博士

それなら、GitHub Projectsを使った工程管理がおすすめじゃ!コードとタスクを一元管理できるから、特にWeb制作との相性が抜群なんじゃぞ!今日は実際のコードやテンプレートも交えて、詳しく解説するぞい!

結論から言うと、GitHub ProjectsはGitHubでコード管理をしているチームに最適な工程管理ツールです。コードとタスクを同一プラットフォームで完結させることで、「誰が何のタスクをやっているか分からない」「修正依頼が埋もれる」「ツールが分散して管理が煩雑」といった課題をまとめて解決できます。

本記事では、GitHub Projectsの基本から実践的な7ステップの導入手順・活用シナリオ・トラブルシューティングまでを、実際のコード例とテンプレートを交えて徹底解説します。


GitHub Projectsとは?

GitHub Projectsは、GitHubが提供するコードリポジトリと完全に統合されたプロジェクト管理ツールです。2022年にリニューアルされ、カンバンボード・テーブル・ロードマップの複数ビュー、カスタムフィールド、GitHub Actionsとの連携など、より強力な機能が追加されました。

他のプロジェクト管理ツールとの比較

比較項目GitHub ProjectsTrello / NotionJira / Asana
コード連携◎ 完全統合△ 手動リンク○ API連携
料金無料(基本機能)一部有料有料プラン必須
学習コスト○ Git知識が必要◎ 直感的△ 高機能で複雑
自動化◎ GitHub Actions△ 限定的◎ 豊富
エンジニア親和性◎ 非常に高い○ 普通○ 普通

GitHub Projectsの6つの主要機能

1. タスクの整理(Sort tasks): 優先度、担当者、ラベル、カスタムフィールドで柔軟に並び替え
2. プロジェクト計画(Plan your projects): カンバンボード、テーブル、ロードマップなど複数のビューで可視化
3. 自動化(Automate your workflow): issueやPRのステータス変更、ラベル付与を自動化
4. 進捗追跡(Track progress): 完了率、バーンダウンチャート、マイルストーン進捗を可視化
5. ステータス共有(Share status): 個別タスクの詳細をチーム内外で共有、コメント機能
6. プロジェクト完了(Wrap up): 完了したプロジェクトをアーカイブし、テンプレート化

Web制作でGitHub Projectsが選ばれる理由

  • コードとタスクの完全な追跡: プルリクエスト#123が、どのissue#45を解決するのか一目瞭然
  • 修正履歴の永続的な記録: 「なぜこの修正をしたのか」がissueに残る
  • レビュープロセスの可視化: コードレビューの状態がボード上で確認可能
  • チーム全体の透明性: 誰が何に取り組んでいるか、リアルタイムで把握
  • 追加コストゼロ: GitHubアカウントだけで全機能を利用可能

GitHub Projectsのメリット・デメリット

生徒

GitHub Projectsって完璧なツールなんですか?デメリットはないんですか?

ペン博士

いや、万能なツールは存在しないんじゃ。メリット・デメリットの両面を理解して、自分のプロジェクトに合うかどうか、しっかり見極めることが大切じゃぞ!

メリット

1. コードとタスクの一元管理ができる

GitHubでコード管理をしている場合、プロジェクト管理も同じプラットフォームで完結します。プルリクエストやコミットとタスクを直接リンクできるため、「このバグ修正は、どのissueに対応したものか?」が瞬時に分かります。

git commit -m "Fix: ヘッダーのレスポンシブ表示を修正 #45"

コミットメッセージに#45と記載するだけで、issue #45に自動的にリンクされます。プルリクエストの説明欄にCloses #45と書けば、マージ時に自動的にissueがクローズされます。

2. 完全無料で使える(Privateリポジトリでも)

ツール無料プラン有料プラン
GitHub Projects全機能利用可能
Trello1ボード10枚まで$5/月〜
Notion個人のみ$8/月〜
Jira10ユーザーまで$7.75/月〜

3. エンジニアに馴染みやすいUI/UX

GitHubを普段から使っているエンジニアにとって、issue・PR・label・milestoneといった概念は既知のため、学習コストがほぼゼロです。新しいツールの使い方を覚える必要がありません。

4. GitHub Actionsによる自動化ができる

  • PRマージ時に関連issueを自動クローズ
  • 特定ラベルが付いたissueを自動的に担当者へアサイン
  • 定期的にリマインダーをSlackに送信
  • テストが通過したら自動的にステータスを「Review」に変更
  • 古いissueを自動的にクローズまたはアーカイブ

5. 高度な検索とフィルタリングができる

# 自分がアサインされた、バグ修正のissueで、まだオープンなもの
is:issue is:open assignee:@me label:bug

# 先週作成された、優先度が高いissue
is:issue created:>=2024-01-01 label:priority-high

# 特定のマイルストーンに含まれる、未完了のissue
is:issue is:open milestone:"Phase 1"

デメリット

1. 高度なプロジェクト管理機能は限定的

  • ガントチャート: タイムライン表示は限定的(ロードマップビューで代替可能)
  • タスクの親子関係: Epicやサブタスクの階層管理は手動
  • 依存関係の設定: 「タスクAが完了したらタスクBを開始」といった設定は不可
  • 工数管理: 時間トラッキング機能がない(外部ツールと連携が必要)
  • 予算管理: コスト計算機能がない

2. 非エンジニアには操作が複雑

  • Git特有の用語(PR、merge、branch、commitなど)の理解が必要
  • Markdown記法を使った文章作成
  • issue番号での参照(#123のような記法)
  • UIがエンジニア向けに最適化されている

3. 日本語サポートが不十分

  • 公式ドキュメントの多くは英語のみ
  • GitHub Actionsのマーケットプレイスは英語が中心
  • サポートフォーラムやコミュニティも英語が主流
  • エラーメッセージが英語

4. クライアントとの直接共有が難しい

クライアントにGitHubアカウントを作成してもらい、リポジトリへのアクセス権を付与する必要があります。技術に不慣れなクライアントには以下の代替策が有効です。

  • NotionやGoogleドキュメントで進捗レポートを作成
  • プロジェクトボードのスクリーンショットを定期共有
  • 週次ミーティングで口頭報告
  • 専用のクライアント向けダッシュボードを別途構築

実践!GitHub Projects導入の7ステップ

ペン博士

それでは、実際にGitHub Projectsを導入する手順を、7つのステップで詳しく解説していくぞい!実際のコマンドやテンプレートも紹介するから、そのままコピーして使えるんじゃ!


ステップ1:リポジトリの作成と初期設定

まずは、Web制作案件用のGitHubリポジトリを作成し、チーム開発に適した設定を行います。

準備するもの

  • GitHubアカウント(無料で作成可能:https://github.com/signup)
  • プロジェクト名の決定(命名規則:クライアント名-プロジェクト種類)
  • 公開・非公開の方針(クライアント案件は通常Private)
  • 使用する技術スタック(README.mdに記載)

リポジトリ作成手順(画面で操作)

  1. GitHubにログイン後、右上の「+」アイコンをクリック

2. 「New repository」を選択

3. 以下の項目を入力:

  • Repository name: abc-company-corporate-site
  • Description: ABC株式会社コーポレートサイトリニューアルプロジェクト
  • Public/Private: Private(クライアント案件のため)
  • Initialize with README: ✓ チェック
  • .gitignore template: Node(使用する技術に応じて選択)
  • License: No license(クライアント案件の場合は通常No licenseを選択)

4.「Create repository」をクリック

コマンドラインでの作成(上級者向け)

# GitHub CLIのインストール(Mac)
brew install gh

# GitHubにログイン
gh auth login

# 新規リポジトリを作成
gh repo create abc-company-corporate-site \
  --private \
  --description "ABC株式会社コーポレートサイトリニューアルプロジェクト" \
  --gitignore Node \
  --clone

# リポジトリに移動
cd abc-company-corporate-site

README.mdの初期テンプレート

# ABC株式会社 コーポレートサイトリニューアル

## プロジェクト概要

- **クライアント:** ABC株式会社
- **プロジェクト期間:** 2024年1月〜2024年3月
- **納期:** 2024年3月31日
- **担当チーム:** デザイナー1名、フロントエンド1名、バックエンド1名

## 技術スタック

- **フロントエンド:** Next.js 14, TypeScript, Tailwind CSS
- **バックエンド:** Node.js, Express
- **CMS:** Contentful
- **ホスティング:** Vercel
- **デザインツール:** Figma

## 開発環境のセットアップ

```bash
# 依存関係のインストール
npm install

# 環境変数の設定
cp .env.example .env.local
# .env.localを編集して、必要なAPIキーを設定

# 開発サーバーの起動
npm run dev
```

## ブランチ戦略

- `main`: 本番環境にデプロイされるブランチ
- `develop`: 開発用の統合ブランチ
- `feature/*`: 機能追加用ブランチ
- `bugfix/*`: バグ修正用ブランチ
- `hotfix/*`: 緊急修正用ブランチ

## コミットメッセージ規約

```
feat: 新機能
fix: バグ修正
docs: ドキュメント変更
style: コードフォーマット
refactor: リファクタリング
test: テスト追加・修正
chore: ビルド設定など

例:feat: ヘッダーコンポーネントを実装 #12
```

## プロジェクト管理

- **GitHub Projects:** [プロジェクトボードリンク]
- **デザイン:** [Figmaリンク]
- **ドキュメント:** [Notionリンク]

## チーム連絡先

- **プロジェクトマネージャー:** 山田太郎 (yamada@example.com)
- **デザイナー:** 佐藤花子 (sato@example.com)
- **フロントエンドエンジニア:** 鈴木一郎 (suzuki@example.com)

ブランチ保護ルールの設定

mainブランチへの直接pushを防ぎ、必ずプルリクエスト経由でマージするように設定します。

  1. Settings → Branches → Add ruleをクリック
  2. Branch name pattern: main
  3. 以下にチェックを入れる:✓ Require a pull request before merging / ✓ Require approvals / ✓ Require status checks to pass before merging / ✓ Require conversation resolution before merging
  4. 「Create」をクリック

ステップ2:プロジェクトボードの作成とカスタマイズ

リポジトリができたら、次はプロジェクトボードを作成します。ボードは、タスクを視覚的に管理するためのカンバンボード形式のダッシュボードです。

プロジェクト作成手順

  1. リポジトリ内の「Projects」タブをクリック
  2. 「New project」を選択
  3. テンプレートから「Board」(カンバンボード形式・推奨)を選択
  4. プロジェクト名を入力(例:ABC Corp. Website Renewal 2026)
  5. 「CreateProject」をクリック

Web制作に最適なカラム構成

カラム名説明該当するissueの例
📋 Backlogいつかやる予定だが、まだ着手していないタスクSEO改善、パフォーマンス最適化
📝 Todo今週〜来週に着手予定のタスクヘッダー実装、お問い合わせフォーム作成
🚧 In Progress現在作業中のタスクトップページデザイン調整中
👀 Reviewコードレビュー・デザインレビュー待ちプルリクエスト#23のレビュー待ち
🧪 Testing動作確認・テスト中フォームのバリデーションテスト
✅ Done完了したタスクヘッダーコンポーネント実装完了

カスタムフィールドの追加

フィールド名タイプ選択肢
Priority(優先度)Single select🔴 Critical, 🟠 High, 🟡 Medium, 🟢 Low
工程Single selectデザイン, フロントエンド, バックエンド, テスト, その他
見積工数Number
期限Date
担当領域Single selectUI/UX, ロジック, API, データベース

ステップ3:issueテンプレートの作成と管理

issueテンプレートを用意しておくと、チームメンバーが統一された形式でissueを作成でき、情報の抜け漏れを防げます。リポジトリに.github/ISSUE_TEMPLATE/ディレクトリを作成し、テンプレートファイルを配置します。

# ディレクトリ構造
.github/
└── ISSUE_TEMPLATE/
    ├── bug_report.md        # バグ報告用
    ├── feature_request.md   # 機能追加リクエスト用
    ├── design_task.md       # デザインタスク用
    └── config.yml           # テンプレート設定ファイル

1. バグ報告テンプレート(bug_report.md)

---
name: 🐛 バグ報告
about: バグや不具合を報告するためのテンプレート
title: '[Bug] '
labels: bug, needs-triage
assignees: ''
---

## 🐛 バグの概要
<!-- バグの内容を簡潔に説明してください -->


## 📝 再現手順
<!-- バグを再現するための手順を記載してください -->

1. 〇〇ページにアクセス
2. 〇〇ボタンをクリック
3. 〇〇を入力
4. エラーが発生

## 🎯 期待される動作
<!-- 本来どのように動作すべきかを記載してください -->


## 😵 実際の動作
<!-- 実際にどのような動作をしたかを記載してください -->


## 📸 スクリーンショット
<!-- 可能であれば、スクリーンショットや動画を添付してください -->


## 🌐 環境情報
- **ブラウザ:** Chrome 120.0 / Safari 17.0 / Firefox 121.0
- **OS:** macOS 14.0 / Windows 11 / iOS 17.0
- **デバイス:** Desktop / Mobile / Tablet
- **画面サイズ:** 1920x1080 / 375x667

## ✅ 完了条件
<!-- このissueをクローズするための条件を明記してください -->
- [ ] バグが修正され、手順1-4で正常に動作する
- [ ] 関連する他のブラウザでも動作確認済み
- [ ] テストケースを追加済み

2. 機能追加テンプレート(feature_request.md)

---
name: ✨ 機能追加・改善
about: 新機能の追加や既存機能の改善を提案するテンプレート
title: '[Feature] '
labels: enhancement
assignees: ''
---

## ✨ 機能の概要
<!-- 追加・改善したい機能を簡潔に説明してください -->


## 🎯 目的・背景
<!-- なぜこの機能が必要なのか、どんな課題を解決するのかを記載してください -->


## 📝 詳細な要件

### 機能仕様
- 〇〇ページに〇〇ボタンを追加
- ボタンをクリックすると〇〇が発生

### UI/UX要件
- デザイン案: [Figmaリンク]
- レスポンシブ対応: 必要 / 不要
- アニメーション: 必要 / 不要

### 技術要件
- 使用するライブラリ:
- API連携: 必要 / 不要
- データベース変更: 必要 / 不要

## ✅ 完了条件
- [ ] 機能が実装され、動作確認済み
- [ ] デザインレビュー完了
- [ ] コードレビュー完了
- [ ] テストケース追加済み
- [ ] ドキュメント更新済み

## 📅 期限・優先度
- **期限:** 2024/02/15
- **優先度:** 🔴 Critical / 🟠 High / 🟡 Medium / 🟢 Low

3. デザインタスクテンプレート(design_task.md)

---
name: 🎨 デザインタスク
about: デザイン制作タスク用のテンプレート
title: '[Design] '
labels: design
assignees: ''
---

## 🎨 デザインタスクの概要


## 📋 デザイン要件
### 対象ページ・コンポーネント
- ページ名:
- セクション名:

### デザインの方向性
- テイスト: モダン / クラシック / ミニマル / ポップ
- カラー:
- 参考サイト:

## 📐 仕様
### 画面サイズ
- [ ] Desktop(1920px)
- [ ] Tablet(768px)
- [ ] Mobile(375px)

### 納品形式
- [ ] Figma
- [ ] Adobe XD

## ✅ 完了条件
- [ ] デザイン初稿完成
- [ ] クライアント/チームレビュー完了
- [ ] 修正対応完了
- [ ] デザインデータをFigmaにアップロード
- [ ] エンジニアに引き継ぎ完了

## 📅 期限
- **初稿提出:**
- **最終納品:** 

issueの粒度の目安

粒度作業時間
大(Epic)2週間〜1ヶ月トップページ全体の実装
3-5日ヘッダーコンポーネントの実装
小(推奨)半日〜2日ヘッダーのロゴ配置とリンク設定
極小1-2時間ロゴ画像のalt属性追加

ステップ4:プルリクエストテンプレートとレビューフロー

コードの品質を保つには、プルリクエスト(PR)を通じたコードレビューのフローが不可欠です。.github/pull_request_template.mdファイルを作成します。

## 📝 変更内容の概要
<!-- このPRで何を変更したのかを簡潔に説明してください -->


## 🎯 関連issue
Closes #
Related to #

## 🔧 変更の種類
- [ ] 🐛 バグ修正 (Bug fix)
- [ ] ✨ 新機能 (New feature)
- [ ] 💄 UI/スタイル変更 (UI/Style)
- [ ] ♻️  リファクタリング (Refactoring)
- [ ] 📝 ドキュメント変更 (Documentation)
- [ ] 🧪 テスト追加・修正 (Test)
- [ ] ⚡️ パフォーマンス改善 (Performance)
- [ ] 🔒 セキュリティ修正 (Security)

## 🧪 テスト方法

1. このブランチをチェックアウト
```bash
git fetch origin
git checkout feature/123-header-component
```

2. 依存関係をインストール
```bash
npm install
```

3. 開発サーバーを起動
```bash
npm run dev
```

4. ブラウザで http://localhost:3000 にアクセス
5. ヘッダーが正しく表示されることを確認
6. レスポンシブ表示を確認(DevToolsで375px、768px、1920px)

### テスト結果
- [ ] Desktop(Chrome)で動作確認済み
- [ ] Mobile(Safari)で動作確認済み
- [ ] Tablet(Chrome)で動作確認済み

## 📸 スクリーンショット / 動画

### Before

### After

## 📋 レビュアーへのチェックリスト
- [ ] コードの可読性・保守性
- [ ] パフォーマンスへの影響
- [ ] セキュリティリスク
- [ ] アクセシビリティ(WAI-ARIA、キーボード操作)
- [ ] エラーハンドリング
- [ ] テストカバレッジ

## 🚀 デプロイ前の確認事項
- [ ] 環境変数の追加が必要な場合、.env.exampleを更新済み
- [ ] データベースマイグレーションが必要な場合、マイグレーションファイルを追加済み

プルリクエストの作成手順

# 1. ブランチを作成
git checkout -b feature/45-header-component

# 2. 変更をコミット
git add src/components/Header.tsx
git commit -m "feat: ヘッダーコンポーネントを実装 #45"

# 3. リモートにpush
git push origin feature/45-header-component

ステップ5:GitHub Actionsでワークフローを自動化

GitHub Actionsを使えば、テスト実行、デプロイ、issueの自動管理など、あらゆる作業を自動化できます。

1. 自動テスト&ビルド(.github/workflows/ci.yml)

name: CI - Test & Build

on:
  pull_request:
    branches: [main, develop]
  push:
    branches: [main, develop]

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - name: チェックアウト
        uses: actions/checkout@v4

      - name: Node.jsセットアップ
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'

      - name: 依存関係のインストール
        run: npm ci

      - name: リントチェック
        run: npm run lint

      - name: タイプチェック
        run: npm run type-check

      - name: テスト実行
        run: npm run test:ci

      - name: ビルド
        run: npm run build

      - name: テスト結果をコメント
        if: always()
        uses: actions/github-script@v7
        with:
          script: |
            const testResult = '${{ job.status }}' === 'success' ? '✅ テスト成功' : '❌ テスト失敗';
            github.rest.issues.createComment({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: context.issue.number,
              body: `## CI結果\n\n${testResult}\n\n詳細: ${context.serverUrl}/${context.repo.owner}/${context.repo.repo}/actions/runs/${context.runId}`
            });

2. PRマージ時にissueを自動クローズ

name: PR関連issueの自動クローズ

on:
  pull_request:
    types: [closed]

jobs:
  close-issues:
    if: github.event.pull_request.merged == true
    runs-on: ubuntu-latest

    steps:
      - name: PR説明文からissue番号を抽出してクローズ
        uses: actions/github-script@v7
        with:
          script: |
            const prBody = context.payload.pull_request.body || '';

            // "Closes #123" "Fixes #456" などのパターンを抽出
            const issueNumbers = [...prBody.matchAll(/(?:close[sd]?|fix(?:e[sd])?|resolve[sd]?)\s+#(\d+)/gi)]
              .map(match => parseInt(match[1]));

            for (const issueNumber of issueNumbers) {
              try {
                await github.rest.issues.update({
                  owner: context.repo.owner,
                  repo: context.repo.repo,
                  issue_number: issueNumber,
                  state: 'closed'
                });

                await github.rest.issues.createComment({
                  owner: context.repo.owner,
                  repo: context.repo.repo,
                  issue_number: issueNumber,
                  body: `✅ PR #${context.payload.pull_request.number} がマージされたため、このissueをクローズしました。`
                });

                console.log(`Closed issue #${issueNumber}`);
              } catch (error) {
                console.error(`Failed to close issue #${issueNumber}:`, error);
              }
            }

3. 古いissueの自動クローズ(.github/workflows/stale.yml)

name: 古いissueの管理

on:
  schedule:
    - cron: '0 0 * * *'  # 毎日午前0時に実行

jobs:
  stale:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/stale@v9
        with:
          repo-token: ${{ secrets.GITHUB_TOKEN }}
          stale-issue-message: '🔔 このissueは30日間更新がありません。7日以内に更新がない場合、自動的にクローズされます。'
          close-issue-message: '🔒 このissueは37日間更新がなかったため、自動的にクローズされました。'
          days-before-stale: 30
          days-before-close: 7
          exempt-issue-labels: 'priority-high,in-progress,blocked'

4. Slack通知の自動化

name: Slack通知

on:
  issues:
    types: [opened, closed]
  pull_request:
    types: [opened, closed, ready_for_review]

jobs:
  notify:
    runs-on: ubuntu-latest
    steps:
      - name: Slackに通知
        uses: slackapi/slack-github-action@v1.24.0
        with:
          webhook-url: ${{ secrets.SLACK_WEBHOOK_URL }}
          payload: |
            {
              "text": "${{ github.event_name == 'issues' && 'Issue' || 'PR' }} ${{ github.event.action }}",
              "blocks": [
                {
                  "type": "section",
                  "text": {
                    "type": "mrkdwn",
                    "text": "*${{ github.event.issue.title || github.event.pull_request.title }}*\n${{ github.event.issue.html_url || github.event.pull_request.html_url }}"
                  }
                }
              ]
            }

5. 週次進捗レポート生成

name: 週次進捗レポート

on:
  schedule:
    - cron: '0 9 * * 1'  # 毎週月曜日9時

jobs:
  report:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/github-script@v7
        with:
          script: |
            const { data: openIssues } = await github.rest.issues.listForRepo({
              owner: context.repo.owner,
              repo: context.repo.repo,
              state: 'open',
              per_page: 100
            });

            const { data: closedIssues } = await github.rest.issues.listForRepo({
              owner: context.repo.owner,
              repo: context.repo.repo,
              state: 'closed',
              since: new Date(Date.now() - 7 * 24 * 60 * 60 * 1000).toISOString()
            });

            const report = `
            ## 📊 週次進捗レポート

            - **オープン中のissue:** ${openIssues.length}件
            - **今週クローズしたissue:** ${closedIssues.length}件
            - **進捗率:** ${Math.round((closedIssues.length / (openIssues.length + closedIssues.length)) * 100)}%

            ### 🚧 オープン中の優先度高いissue
            ${openIssues.filter(i => i.labels.some(l => l.name === 'priority-high'))
              .map(i => `- [#${i.number}](${i.html_url}) ${i.title}`)
              .slice(0, 5)
              .join('\n')}
            `;

            // Slack通知やGitHub Discussionsに投稿
            console.log(report);

ステップ6:チーム運用ルールの策定とドキュメント化

GitHub Projectsを効果的に使うには、チーム全体で運用ルールを決めて、文書化することが重要です。リポジトリのルートにCONTRIBUTING.mdを配置します。

# プロジェクト運用ガイド
## 📋 目次
1. [開発フロー](#開発フロー)
2. [ブランチ戦略](#ブランチ戦略)
3. [issue作成ルール](#issue作成ルール)
4. [プルリクエストルール](#プルリクエストルール)
5. [コミットメッセージ規約](#コミットメッセージ規約)
6. [コードレビュー](#コードレビュー)
## 🔄 開発フロー
1. **issueを作成**: タスクはすべてissueとして登録
2. **ブランチを作成**: feature/issue番号-機能名
3. **開発**: コードを書く
4. **プッシュ**: リモートブランチにpush
5. **PRを作成**: テンプレートに沿って作成
6. **レビュー**: 最低1名の承認が必要
7. **マージ**: mainブランチにマージ
8. **ブランチ削除**: マージ後はブランチを削除
## 🌿 ブランチ戦略
### ブランチの種類
- `main`: 本番環境にデプロイされるブランチ(保護されている)
- `develop`: 開発用の統合ブランチ
- `feature/*`: 機能追加用
- `bugfix/*`: バグ修正用
- `hotfix/*`: 緊急修正用
### 命名規則
```
feature/issue番号-機能の簡潔な説明
```
**例:**
- `feature/45-header-component`
- `bugfix/78-form-validation`
- `hotfix/99-security-patch`
## 📝 issue作成ルール
### issueタイトル
```
[カテゴリ] 具体的な作業内容
```
**カテゴリ:**
- `[Feature]`: 新機能
- `[Bug]`: バグ修正
- `[Design]`: デザイン作業
- `[Refactor]`: リファクタリング
- `[Docs]`: ドキュメント
### issueの粒度
- **目安**: 1-3日で完了できるサイズ
- 大きなタスクは複数のissueに分割
- 親issueに子issueをリンク
## 💬 コミットメッセージ規約
### フォーマット
```
<type>: <subject> #issue番号
```
### Type
- `feat`: 新機能
- `fix`: バグ修正
- `docs`: ドキュメント変更
- `style`: コードフォーマット
- `refactor`: リファクタリング
- `test`: テスト追加・修正
- `chore`: ビルド設定など
## 📞 連絡ルール
- **技術的な質問**: issueコメント or GitHub Discussions
- **緊急の連絡**: Slack
- **進捗報告**: 毎日夕方にissueコメント
- **ブロッカー**: 即座にSlackで報告

ステップ7:定期的なブラッシュアップ

プロジェクト管理は、継続的な改善が重要です。定期的に振り返りを行い、運用方法をブラッシュアップしましょう。

週次スプリントレビューの確認項目

  • 完了したissue数: 目標に対する達成率
  • 長期間「In Progress」のissue: ブロッカーがないか確認
  • 優先度高のissue: 対応状況を確認
  • マイルストーン進捗: 期限に間に合うか確認

月次レトロスペクティブ

項目確認内容
Keep(続けること)うまくいっている運用方法
Problem(課題)改善が必要な点
Try(試すこと)次月に試したい新しい施策

Web制作での実践的な活用シナリオ

生徒

実際のWeb制作の現場では、どんな風にGitHub Projectsを活用するんですか?

ペン博士

いい質問じゃ!実際のプロジェクトを例に、具体的な活用方法を見ていくぞい!

シナリオ1:コーポレートサイトリニューアル(3ヶ月プロジェクト)

  • 期間: 2024年1月〜3月(3ヶ月)
  • チーム: デザイナー1名、フロントエンド1名、バックエンド1名、PM1名
  • 技術: Next.js 14, TypeScript, Tailwind CSS, Contentful(Headless CMS)
  • ページ数: 10ページ

マイルストーンの設定

マイルストーン期間主なタスク完了条件
Phase 1: デザインWeek 1-4ワイヤーフレーム、デザインカンプ作成クライアント承認取得
Phase 2: フロント実装Week 5-10コンポーネント実装、ページ作成全ページ表示可能
Phase 3: CMS統合Week 11-12Contentful連携、動的コンテンツCMS更新が反映される
Phase 4: テスト&リリースWeek 13バグ修正、本番デプロイ本番公開完了

実際のissue構成例

### Phase 1: デザイン(16 issues)
#1  [Design] トップページワイヤーフレーム作成
#2  [Design] 会社概要ページワイヤーフレーム作成
#3  [Design] サービス紹介ページワイヤーフレーム作成
#4  [Design] お知らせ一覧ページワイヤーフレーム作成
#5  [Design] お問い合わせページワイヤーフレーム作成
#6  [Design] トップページデザインカンプ作成
#7  [Design] 会社概要ページデザインカンプ作成
...

### Phase 2: フロントエンド(30 issues)
#17 [Feature] プロジェクト初期設定(Next.js, TypeScript)
#18 [Feature] ヘッダーコンポーネント実装
#19 [Feature] フッターコンポーネント実装
#20 [Feature] ナビゲーションコンポーネント実装
#21 [Feature] ボタンコンポーネント実装
#22 [Feature] カードコンポーネント実装
#23 [Feature] トップページ - ヒーローセクション実装
#24 [Feature] トップページ - サービス紹介セクション実装
#25 [Feature] トップページ - 会社概要セクション実装
...

### Phase 3: CMS統合(8 issues)
#48 [Feature] Contentfulアカウント設定
#49 [Feature] コンテンツモデル設計
#50 [Feature] お知らせ記事のCMS連携
#51 [Feature] サービス情報のCMS連携
...

### Phase 4: テスト&リリース(10 issues)
#57 [Test] クロスブラウザテスト(Chrome, Safari, Firefox)
#58 [Test] レスポンシブテスト(Mobile, Tablet, Desktop)
#59 [Bug] IEでのレイアウト崩れ修正
#60 [Feature] Google Analyticsタグ実装
...

シナリオ2:ECサイトの機能追加(アジャイル開発)

  • 開発方式: 2週間スプリント
  • 追加機能: 商品レビュー機能
  • チーム: フルスタックエンジニア2名

スプリント計画

Sprintゴールissue数
Sprint 1レビュー投稿機能の基本実装8
Sprint 2レビュー表示と星評価6
Sprint 3管理画面とテスト5

Sprint 1のissue例

#101 [Feature] レビューデータのDBスキーマ設計
  見積: 0.5日 | Priority: High | Sprint 1

#102 [Feature] レビュー投稿APIの実装
  見積: 1日 | Priority: High | Sprint 1

#103 [Feature] レビュー投稿フォームのUI実装
  見積: 1.5日 | Priority: High | Sprint 1

#104 [Feature] バリデーション処理の実装
  見積: 0.5日 | Priority: Medium | Sprint 1

#105 [Test] レビュー投稿機能のテスト作成
  見積: 1日 | Priority: Medium | Sprint 1

トラブルシューティング:よくある課題と解決策

生徒

実際に運用していると、いろいろな問題が出てきそうですね…

ペン博士

そうじゃな。ここでは、よくある課題と、その具体的な解決策を紹介するぞい!実際のコマンドやスクリプトも載せておくから、参考にするんじゃ!

課題1:issueが増えすぎて管理できない

原因: issueの粒度が不適切、完了したissueをクローズしていない、優先度が設定されていない

# 古いissue一覧を取得(30日以上更新なし)
gh issue list \
  --state open \
  --json number,title,updatedAt \
  --jq '.[] | select((.updatedAt | fromdateiso8601) < (now - 2592000)) | "#\(.number) \(.title)"'
# ラベルが付いていないissueを抽出
gh issue list \
  --state open \
  --json number,title,labels \
  --jq '.[] | select(.labels | length == 0) | "#\(.number) \(.title)"'
# 担当者が未設定のissueを抽出
gh issue list \
  --state open \
  --json number,title,assignees \
  --jq '.[] | select(.assignees | length == 0) | "#\(.number) \(.title)"'

解決策:

  • 月1回の棚卸しミーティングで全オープンissueをレビュー
  • 「今週やるべきタスク」ビュー(Priority=High AND Status=Todo)を活用
  • 不要なissueはクローズし、大きなissueは分割する

課題2:チームメンバーがステータスを更新しない

# GitHub Actionsで毎日17時にSlack通知
name: Daily Status Reminder

on:
  schedule:
    - cron: '0 8 * * 1-5'  # 平日17時(JST)

jobs:
  remind:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/github-script@v7
        with:
          script: |
            const { data: issues } = await github.rest.issues.listForRepo({
              owner: context.repo.owner,
              repo: context.repo.repo,
              state: 'open',
              assignee: '*'
            });

            const inProgressIssues = issues.filter(i =>
              i.labels.some(l => l.name === 'in-progress')
            );

            if (inProgressIssues.length > 0) {
              const message = `🔔 ステータス更新リマインダー\n\n` +
                `現在「In Progress」のissue: ${inProgressIssues.length}件\n` +
                `今日の作業終了時に、ステータスを更新してください!`;

              // Slack通知(Webhook URLをSecretsに設定)
              await fetch(process.env.SLACK_WEBHOOK_URL, {
                method: 'POST',
                body: JSON.stringify({ text: message })
              });
            }

ステータス更新ルール:

タイミングアクション
作業開始時「Todo」→「In Progress」に移動
レビュー依頼時「In Progress」→「Review」に移動
PRマージ時「Review」→「Done」に移動(自動化推奨)
作業が止まった時issueにコメントでブロッカーを報告

課題3:PRのレビューが遅い

name: PR Review Request Notification

on:
  pull_request:
    types: [review_requested]

jobs:
  notify:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/github-script@v7
        with:
          script: |
            const reviewers = context.payload.pull_request.requested_reviewers;
            const prUrl = context.payload.pull_request.html_url;
            const prTitle = context.payload.pull_request.title;

            for (const reviewer of reviewers) {
              // Slack DMで通知(または@メンション)
              const message = `@${reviewer.login} レビュー依頼が届いています\n${prTitle}\n${prUrl}`;
              console.log(message);
            }

PRサイズとレビュー期限のルール:

  • 変更行数は300行以内が目安。大きなPRは複数に分割する
  • 24時間以内にレビュー開始、48時間以内にレビュー完了を目標にする
  • Draft PRを活用して、早めにフィードバックをもらう

生徒

GitHub Projectsって、思ったよりも奥が深いんですね!でもこれだけ理解すれば、チームでのWeb制作が本当にスムーズになりそうです!

ペン博士

その通りじゃ!最初は慣れるまで時間がかかるが、一度仕組みを作れば、プロジェクト管理の強力な武器になるぞい!コードと一緒に管理できるのが、GitHub Projectsの最大の強みなんじゃ!


よくある質問

GitHub ProjectsはPrivateリポジトリでも無料で使えますか?

はい、無料で使えます。個人アカウント・組織アカウントを問わず、Privateリポジトリでもカンバンボード・テーブル・ロードマップビュー・カスタムフィールドなどの基本機能はすべて無料で利用できます。大規模な組織向けの高度な権限管理などの一部機能はGitHub Teamプラン以上が必要ですが、フリーランスや小規模チームの用途には無料プランで十分です。

デザイナーやディレクターなど非エンジニアもGitHub Projectsを使えますか?

使えますが、学習コストがかかります。issueの作成・コメント・ラベル付けといった基本操作はGitのコマンド知識がなくても習得できます。ただし、プルリクエストやブランチといったGit特有の概念や、Markdown記法での文章作成は、最初の1〜2週間でオンボーディングが必要です。非エンジニアメンバーには「issues操作のみ担当」「コードベースの変更は触らない」などの役割分担を明確にすると、スムーズに導入できます。

TrelloやNotionからGitHub Projectsに移行するときの注意点は?

既存のタスクを一括でインポートする公式機能はないため、移行時はGitHub CLIスクリプトでissueを一括作成するか、手動で移行する必要があります。移行のタイミングは「新しいプロジェクト開始時」が最もスムーズです。進行中のプロジェクトに途中から導入する場合は、Notionなどを並行運用しながら段階的に移行することをおすすめします。また、クライアントがNotionを見慣れている場合は、クライアント向けの進捗共有はNotionに残し、チーム内管理のみGitHub Projectsに移行する方法も有効です。

GitHub Actionsの自動化はどこから始めるべきですか?

まずCIワークフロー(自動テスト・ビルド)から始めることをおすすめします。PRが作成されるたびにテストが自動実行される仕組みを最初に整えると、コード品質の底上げ効果が大きく、チームにも自動化の価値をすぐに実感してもらえます。次いで「PRマージ時のissue自動クローズ」、続いて「Slack通知」の順で追加すると、段階的に運用負荷を下げられます。

– service –WithGroupの運営サービス

  • WithCode
    - ウィズコード -

    スクール

    「未経験」から
    現場で通用する
    スキルを身に付けよう!

    詳細はこちら
  • WithFree
    - ウィズフリ -

    実案件サポート

    制作会社のサポート下で
    実務経験を積んでいこう!

    詳細はこちら
  • WithCareer
    - ウィズキャリ -

    就転職サポート

    大手エージェントのサポート下で
    キャリアアップを目指そう!

    詳細はこちら

公式サイト より
今すぐ
無料カウンセリング
予約!

目次