



WithCodeMedia-1-pc
WithCodeMedia-2-pc
WithCodeMedia-3-pc
WithCodeMedia-4-pc




WithCodeMedia-1-sp
WithCodeMedia-2-sp
WithCodeMedia-3-sp
WithCodeMedia-4-sp










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



それなら、GitHub Projectsを使った工程管理がおすすめじゃ!コードとタスクを一元管理できるから、特にWeb制作との相性が抜群なんじゃぞ!今日は実際のコードやテンプレートも交えて、詳しく解説するぞい!
結論から言うと、GitHub ProjectsはGitHubでコード管理をしているチームに最適な工程管理ツールです。コードとタスクを同一プラットフォームで完結させることで、「誰が何のタスクをやっているか分からない」「修正依頼が埋もれる」「ツールが分散して管理が煩雑」といった課題をまとめて解決できます。
本記事では、GitHub Projectsの基本から実践的な7ステップの導入手順・活用シナリオ・トラブルシューティングまでを、実際のコード例とテンプレートを交えて徹底解説します。


GitHub Projectsは、GitHubが提供するコードリポジトリと完全に統合されたプロジェクト管理ツールです。2022年にリニューアルされ、カンバンボード・テーブル・ロードマップの複数ビュー、カスタムフィールド、GitHub Actionsとの連携など、より強力な機能が追加されました。
| 比較項目 | GitHub Projects | Trello / Notion | Jira / Asana |
|---|---|---|---|
| コード連携 | ◎ 完全統合 | △ 手動リンク | ○ API連携 |
| 料金 | 無料(基本機能) | 一部有料 | 有料プラン必須 |
| 学習コスト | ○ Git知識が必要 | ◎ 直感的 | △ 高機能で複雑 |
| 自動化 | ◎ GitHub Actions | △ 限定的 | ◎ 豊富 |
| エンジニア親和性 | ◎ 非常に高い | ○ 普通 | ○ 普通 |
1. タスクの整理(Sort tasks): 優先度、担当者、ラベル、カスタムフィールドで柔軟に並び替え
2. プロジェクト計画(Plan your projects): カンバンボード、テーブル、ロードマップなど複数のビューで可視化
3. 自動化(Automate your workflow): issueやPRのステータス変更、ラベル付与を自動化
4. 進捗追跡(Track progress): 完了率、バーンダウンチャート、マイルストーン進捗を可視化
5. ステータス共有(Share status): 個別タスクの詳細をチーム内外で共有、コメント機能
6. プロジェクト完了(Wrap up): 完了したプロジェクトをアーカイブし、テンプレート化





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



いや、万能なツールは存在しないんじゃ。メリット・デメリットの両面を理解して、自分のプロジェクトに合うかどうか、しっかり見極めることが大切じゃぞ!
GitHubでコード管理をしている場合、プロジェクト管理も同じプラットフォームで完結します。プルリクエストやコミットとタスクを直接リンクできるため、「このバグ修正は、どのissueに対応したものか?」が瞬時に分かります。
git commit -m "Fix: ヘッダーのレスポンシブ表示を修正 #45"コミットメッセージに#45と記載するだけで、issue #45に自動的にリンクされます。プルリクエストの説明欄にCloses #45と書けば、マージ時に自動的にissueがクローズされます。
| ツール | 無料プラン | 有料プラン |
|---|---|---|
| GitHub Projects | 全機能利用可能 | – |
| Trello | 1ボード10枚まで | $5/月〜 |
| Notion | 個人のみ | $8/月〜 |
| Jira | 10ユーザーまで | $7.75/月〜 |
GitHubを普段から使っているエンジニアにとって、issue・PR・label・milestoneといった概念は既知のため、学習コストがほぼゼロです。新しいツールの使い方を覚える必要がありません。
# 自分がアサインされた、バグ修正の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"クライアントにGitHubアカウントを作成してもらい、リポジトリへのアクセス権を付与する必要があります。技術に不慣れなクライアントには以下の代替策が有効です。





それでは、実際にGitHub Projectsを導入する手順を、7つのステップで詳しく解説していくぞい!実際のコマンドやテンプレートも紹介するから、そのままコピーして使えるんじゃ!
まずは、Web制作案件用のGitHubリポジトリを作成し、チーム開発に適した設定を行います。


2. 「New repository」を選択


3. 以下の項目を入力:


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# 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を防ぎ、必ずプルリクエスト経由でマージするように設定します。
mainリポジトリができたら、次はプロジェクトボードを作成します。ボードは、タスクを視覚的に管理するためのカンバンボード形式のダッシュボードです。


| カラム名 | 説明 | 該当するissueの例 |
|---|---|---|
| 📋 Backlog | いつかやる予定だが、まだ着手していないタスク | SEO改善、パフォーマンス最適化 |
| 📝 Todo | 今週〜来週に着手予定のタスク | ヘッダー実装、お問い合わせフォーム作成 |
| 🚧 In Progress | 現在作業中のタスク | トップページデザイン調整中 |
| 👀 Review | コードレビュー・デザインレビュー待ち | プルリクエスト#23のレビュー待ち |
| 🧪 Testing | 動作確認・テスト中 | フォームのバリデーションテスト |
| ✅ Done | 完了したタスク | ヘッダーコンポーネント実装完了 |
| フィールド名 | タイプ | 選択肢 |
|---|---|---|
| Priority(優先度) | Single select | 🔴 Critical, 🟠 High, 🟡 Medium, 🟢 Low |
| 工程 | Single select | デザイン, フロントエンド, バックエンド, テスト, その他 |
| 見積工数 | Number | – |
| 期限 | Date | – |
| 担当領域 | Single select | UI/UX, ロジック, API, データベース |
issueテンプレートを用意しておくと、チームメンバーが統一された形式でissueを作成でき、情報の抜け漏れを防げます。リポジトリに.github/ISSUE_TEMPLATE/ディレクトリを作成し、テンプレートファイルを配置します。
# ディレクトリ構造
.github/
└── ISSUE_TEMPLATE/
├── bug_report.md # バグ報告用
├── feature_request.md # 機能追加リクエスト用
├── design_task.md # デザインタスク用
└── config.yml # テンプレート設定ファイル---
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で正常に動作する
- [ ] 関連する他のブラウザでも動作確認済み
- [ ] テストケースを追加済み---
name: ✨ 機能追加・改善
about: 新機能の追加や既存機能の改善を提案するテンプレート
title: '[Feature] '
labels: enhancement
assignees: ''
---
## ✨ 機能の概要
<!-- 追加・改善したい機能を簡潔に説明してください -->
## 🎯 目的・背景
<!-- なぜこの機能が必要なのか、どんな課題を解決するのかを記載してください -->
## 📝 詳細な要件
### 機能仕様
- 〇〇ページに〇〇ボタンを追加
- ボタンをクリックすると〇〇が発生
### UI/UX要件
- デザイン案: [Figmaリンク]
- レスポンシブ対応: 必要 / 不要
- アニメーション: 必要 / 不要
### 技術要件
- 使用するライブラリ:
- API連携: 必要 / 不要
- データベース変更: 必要 / 不要
## ✅ 完了条件
- [ ] 機能が実装され、動作確認済み
- [ ] デザインレビュー完了
- [ ] コードレビュー完了
- [ ] テストケース追加済み
- [ ] ドキュメント更新済み
## 📅 期限・優先度
- **期限:** 2024/02/15
- **優先度:** 🔴 Critical / 🟠 High / 🟡 Medium / 🟢 Low---
name: 🎨 デザインタスク
about: デザイン制作タスク用のテンプレート
title: '[Design] '
labels: design
assignees: ''
---
## 🎨 デザインタスクの概要
## 📋 デザイン要件
### 対象ページ・コンポーネント
- ページ名:
- セクション名:
### デザインの方向性
- テイスト: モダン / クラシック / ミニマル / ポップ
- カラー:
- 参考サイト:
## 📐 仕様
### 画面サイズ
- [ ] Desktop(1920px)
- [ ] Tablet(768px)
- [ ] Mobile(375px)
### 納品形式
- [ ] Figma
- [ ] Adobe XD
## ✅ 完了条件
- [ ] デザイン初稿完成
- [ ] クライアント/チームレビュー完了
- [ ] 修正対応完了
- [ ] デザインデータをFigmaにアップロード
- [ ] エンジニアに引き継ぎ完了
## 📅 期限
- **初稿提出:**
- **最終納品:** | 粒度 | 作業時間 | 例 |
|---|---|---|
| 大(Epic) | 2週間〜1ヶ月 | トップページ全体の実装 |
| 中 | 3-5日 | ヘッダーコンポーネントの実装 |
| 小(推奨) | 半日〜2日 | ヘッダーのロゴ配置とリンク設定 |
| 極小 | 1-2時間 | ロゴ画像のalt属性追加 |
コードの品質を保つには、プルリクエスト(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-componentGitHub Actionsを使えば、テスト実行、デプロイ、issueの自動管理など、あらゆる作業を自動化できます。
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}`
});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);
}
}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'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 }}"
}
}
]
}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);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で報告プロジェクト管理は、継続的な改善が重要です。定期的に振り返りを行い、運用方法をブラッシュアップしましょう。
| 項目 | 確認内容 |
|---|---|
| Keep(続けること) | うまくいっている運用方法 |
| Problem(課題) | 改善が必要な点 |
| Try(試すこと) | 次月に試したい新しい施策 |



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



いい質問じゃ!実際のプロジェクトを例に、具体的な活用方法を見ていくぞい!
| マイルストーン | 期間 | 主なタスク | 完了条件 |
|---|---|---|---|
| Phase 1: デザイン | Week 1-4 | ワイヤーフレーム、デザインカンプ作成 | クライアント承認取得 |
| Phase 2: フロント実装 | Week 5-10 | コンポーネント実装、ページ作成 | 全ページ表示可能 |
| Phase 3: CMS統合 | Week 11-12 | Contentful連携、動的コンテンツ | CMS更新が反映される |
| Phase 4: テスト&リリース | Week 13 | バグ修正、本番デプロイ | 本番公開完了 |
### 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タグ実装
...| Sprint | ゴール | issue数 |
|---|---|---|
| Sprint 1 | レビュー投稿機能の基本実装 | 8 |
| Sprint 2 | レビュー表示と星評価 | 6 |
| Sprint 3 | 管理画面とテスト | 5 |
#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


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



そうじゃな。ここでは、よくある課題と、その具体的な解決策を紹介するぞい!実際のコマンドやスクリプトも載せておくから、参考にするんじゃ!
原因: 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)"'解決策:
# 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にコメントでブロッカーを報告 |
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サイズとレビュー期限のルール:



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



その通りじゃ!最初は慣れるまで時間がかかるが、一度仕組みを作れば、プロジェクト管理の強力な武器になるぞい!コードと一緒に管理できるのが、GitHub Projectsの最大の強みなんじゃ!
はい、無料で使えます。個人アカウント・組織アカウントを問わず、Privateリポジトリでもカンバンボード・テーブル・ロードマップビュー・カスタムフィールドなどの基本機能はすべて無料で利用できます。大規模な組織向けの高度な権限管理などの一部機能はGitHub Teamプラン以上が必要ですが、フリーランスや小規模チームの用途には無料プランで十分です。
使えますが、学習コストがかかります。issueの作成・コメント・ラベル付けといった基本操作はGitのコマンド知識がなくても習得できます。ただし、プルリクエストやブランチといったGit特有の概念や、Markdown記法での文章作成は、最初の1〜2週間でオンボーディングが必要です。非エンジニアメンバーには「issues操作のみ担当」「コードベースの変更は触らない」などの役割分担を明確にすると、スムーズに導入できます。
既存のタスクを一括でインポートする公式機能はないため、移行時はGitHub CLIスクリプトでissueを一括作成するか、手動で移行する必要があります。移行のタイミングは「新しいプロジェクト開始時」が最もスムーズです。進行中のプロジェクトに途中から導入する場合は、Notionなどを並行運用しながら段階的に移行することをおすすめします。また、クライアントがNotionを見慣れている場合は、クライアント向けの進捗共有はNotionに残し、チーム内管理のみGitHub Projectsに移行する方法も有効です。
まずCIワークフロー(自動テスト・ビルド)から始めることをおすすめします。PRが作成されるたびにテストが自動実行される仕組みを最初に整えると、コード品質の底上げ効果が大きく、チームにも自動化の価値をすぐに実感してもらえます。次いで「PRマージ時のissue自動クローズ」、続いて「Slack通知」の順で追加すると、段階的に運用負荷を下げられます。
公式サイト より
今すぐ
無料カウンセリング
を予約!