Appearance
6. 変更を実装する
概要
Issue の完了条件に基づいて、先に失敗するテストを追加し、その後に実装を変更します。実装後は、テスト結果、ビルド結果、差分を根拠にセルフレビューします。
GitHub Copilot の Agent Skill を利用する方法と、コードを手動で変更する方法から選べます。どちらの方法でも、変更内容の最終判断は自分で行います。
手順
1. Issue の変更を実装する
Agent モードで以下の指示を与えます。1 は、記事4で作成した実際の Issue 番号へ置き換えてください。
text
/implement-issue 1次を確認します。
- 対象ブランチと Issue の対応が確認されている
- テストを先に追加し、既存実装では失敗することが確認されている
- 提案されたファイル変更とコマンドを確認してから承認している
- テスト、実装、検証の順に作業が進められている
src/availability.test.js に次のテストを追加します。
javascript
it('残席が3席の場合は残席わずかと表示する', () => {
expect(formatAvailability(10, 7)).toBe('残席わずか（残り 3 席）')
})
it('残席が4席の場合は通常表示にする', () => {
expect(formatAvailability(10, 6)).toBe('残り 4 席')
})テストが失敗することを確認してから、src/availability.js の満席判定の後へ追加します。
javascript
if (remainingSeats <= 3) {
return `残席わずか（残り ${remainingSeats} 席）`
}補足: Agent Skill とは
Agent Skill は、特定の作業手順を SKILL.md にまとめて再利用する仕組みです。プロジェクト固有の Skill は .github/skills/<Skill名>/SKILL.md に配置します。GitHub Copilot は作業内容に応じて Skill を読み込めるほか、Chat ビューで /Skill名 を入力して明示的に指示を与えられます。
AGENTS.md はリポジトリで常に守る方針や制約を定義し、Skill は Issue の実装やセルフレビューなど、目的ごとの手順を定義します。この記事では、スターターに含まれる Skill のうち、Issue 番号を引数で受け取る /implement-issue 1 と、現在の Git 差分を入力なしで確認する /review-changes を使用します。
implement-issue Skill は、ブランチと Issue の対応を確認し、必要な場合だけ askQuestions で要件を明確にしてから、テスト、実装、検証を順に進めます。回答を Issue コメントへ残すことで、実装判断の経緯を Pull Request のレビュー担当者も確認できます。
詳しくは、Visual Studio Code の Agent Skills を使うを参照してください。
2. 差分をセルフレビューする
この時点ではまだコミットしていないため、Visual Studio Code の Source Control ビューに変更差分が表示されます。
Agent モードで以下の指示を与えます。
text
/review-changes次を確認します。
- ステージ済みと未ステージの差分が確認されている
- Issue の完了条件、境界値、回帰、可読性の観点で指摘が示されている
- 指摘を差分とコードに照らして判断している
- コミットや push が行われていない
Source Control ビューで2ファイルの差分を開き、次を確認します。
- Issue の5つの完了条件を満たしている
- 残席数0、1、3、4の境界値をテストしている
- 変更対象が
src/availability.jsとsrc/availability.test.jsに限られている - 条件分岐が満席判定の後にあり、既存の通常表示を壊していない
- 変数名とテスト名から意図を読み取れる
review-changes Skill は、ステージ済みと未ステージの git diff を読み、現在のブランチから取得できる Issue の完了条件、境界値、回帰、可読性の観点でレビューします。GitHub Copilot の指摘は、人へレビューを依頼する前のセルフレビューとして使用します。人によるレビューの代わりにはしません。
テスト、ビルド、差分確認を実行し、実装が完了条件を満たし、無関係な変更を含まないことを確かめます。
Agent モードで以下の指示を与えます。
text
/review-changes
現在の差分について npm test と npm run build を実行し、5件のテスト成功、Vite のビルド成功、Issue と無関係な変更がないことを確認してください。
実行したコマンド、結果、未ステージを含む差分の要約を報告し、コミット、push、ファイルの追加変更は行わないでください。次を確認します。
- Vitest の5件のテストと Vite のビルドが成功している
- Issue と無関係な変更が含まれていない
- 実行したコマンド、結果、未ステージを含む差分が報告されている
- コミット、push、ファイルの追加変更が行われていない
powershell
# Vitest のテストを実行します
npm test
# Vite アプリを本番用にビルドします
npm run build
# コミット前の変更差分を表示します
git diffbash
# Vitest のテストを実行します
npm test
# Vite アプリを本番用にビルドします
npm run build
# コミット前の変更差分を表示します
git diff確認事項
- 5件のテストが成功する
- Vite のビルドが成功する
- 変更対象が
src/availability.jsとsrc/availability.test.jsの2ファイルだけである - Issue の完了条件、境界値、回帰、可読性の観点で差分をセルフレビューしている
まとめ
Issue の完了条件をテストとコードへ反映し、対象ブランチ、Issue、実装、テストの関係を確認しました。GitHub Copilot を利用する場合は、implement-issue Skill に Issue 番号を渡すことで、曖昧な要件を実装前に確認し、決定事項を Issue コメントへ残せます。
今回は、先に境界値3席と4席のテストを追加して失敗を確認し、その後に最小限の実装を加えました。テストを先に用意すると、期待する振る舞いを具体的な入力と出力で表現でき、実装が完了条件を満たしたことを自動的に確認できます。
最後に Git 差分をセルフレビューし、Issue と無関係な変更、テストの不足、既存動作への影響がないかを確認しました。review-changes Skill を利用した場合も提案はそのまま採用せず、Issue、差分、テスト結果、ビルド結果を根拠に判断することが重要です。
レビューでは、経験豊富な開発者が自然に確認している境界値、回帰、変更範囲、可読性などの観点が、個人の暗黙知になりがちです。これらを Skill に明文化すると、経験の浅い開発者も必要なときに同じ観点で事前レビューを受け、指摘と根拠を繰り返し学べます。また、チーム内でレビュー品質のばらつきを減らし、シニア開発者は設計判断や業務上の影響など、人にしか判断しにくい論点へ集中できます。
補足: 実務で役立つ GitHub Copilot との進め方
- 依頼には、参照する Issue、変更してよい範囲、検証方法、実行してはいけない操作を含めます。
- Agent がファイルを変更する前に、理解した要件と作業対象を要約させると、認識違いを早い段階で見つけられます。
- 曖昧な要件は推測させず、実装結果やテストケースが変わる点だけを質問して明確にします。
- テストの失敗を先に確認すると、追加したテストが既存実装でも成功してしまう誤りを防げます。
- 大きな変更を一度に承認せず、テスト、実装、検証の単位で差分とコマンドを確認します。
- セルフレビュー用の Skill へチームのレビュー観点を蓄積すると、暗黙知を共有可能なチェック手順に変え、経験にかかわらず一貫した事前レビューを行えます。
- GitHub Copilot のレビューは人によるレビューの代替ではありません。Pull Request では、変更理由や運用への影響も含めてチームで確認します。
次は、実装した変更をコミットして feature ブランチへ push し、develop に取り込むための Pull Request を作成します。