1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@kugiiiii
in

チーム開発におけるSpecKit利用の考察と提案

1
Last updated at Posted at 2026-06-30

1. 目的

本ドキュメントの目的は、チーム開発においてSpecKitをどのように活用できるかを整理することである。

2. 概要

本ドキュメントは、以下の情報をまとめたものになる｡

SpecKitは、仕様を起点としてAI主導開発を進めるための支援ツールである。要件定義、技術計画、タスク分解、実装支援といった流れを整理し、AIが作業しやすい状態を作ることに強みがある。

一方で、SpecKitはチーム開発に必要なルールや運用をすべて代替するものではない。ブランチ戦略、PRルール、レビュー基準、テスト方針、CI、セキュリティ方針などは、エンジニア側で準備する必要がある。

そのため、SpecKitを導入する際には、「SpecKitに任せる部分」と「エンジニアが責任を持つ部分」を明確に分けることが重要である。

3. 目次

  1. SpecKitについての説明

  2. SpecKitの作業フローで重要なこと

  3. エンジニアとSpecKitの担当領域

  4. チーム開発でSpecKitを利用するために必要な準備

  5. SpecKit導入時の注意点

  6. まとめ・提案

4. SpecKitについての説明

SpecKitは、仕様駆動開発をAIエージェントで進めやすくするためのツールである。
従来のように曖昧な指示から直接コードを生成するのではなく、要件定義、技術計画、タスク分解を段階的に行い、その成果物をもとに実装を進める。

主な流れは以下の通りである。

constitution
  ↓
specify
  ↓
clarify
  ↓
plan
  ↓
tasks
  ↓
analyze / checklist
  ↓
implement

それぞれの役割は以下のように整理できる。

工程 役割
constitution プロジェクトの原則や開発方針を定義する
specify 作りたい機能や要件を仕様として整理する
clarify 仕様の曖昧な点を質問によって明確化する
plan 技術スタックやアーキテクチャ方針を整理する
tasks 実装可能なタスクに分解する
analyze 仕様・計画・タスク間の矛盾や抜けを確認する
checklist 仕様や実装前の確認項目を整理する
implement タスクに沿って実装を支援する

5. SpecKitの作業フローで重要なこと

SpecKitを使ったチーム開発で重要なのは、いきなり実装に入らないことである。

AI主導開発では、仕様が曖昧な状態で実装を始めると、AIが不足している情報を推測で補完してしまう。その結果、意図しない機能追加、過剰な実装、設計方針のブレが発生しやすくなる。

そのため、SpecKitでは以下の流れを意識する必要がある。

何を作るかを決める
  ↓
曖昧な点を明確にする
  ↓
どう作るかを計画する
  ↓
実装タスクに分解する
  ↓
矛盾や不足を確認する
  ↓
実装する

具体的に意識したい点は2つある｡

  1. specify と plan を混同しないこと
  2. clarify, analyze, cheklistを飛ばさず実行する

spec.md(specifyコマンドの生成物) には作りたい機能や要件､plan.md(planコマンドの生成物)には技術スタックやアーキテクチャ方針を分けて記述する事が重要である｡要件定義の段階で技術選定まで混ぜすぎると、仕様の目的が曖昧になる可能性がある。

clarify, analyze, cheklistは仕様から漏れているものを見つけるのに重要な工程である｡そのため､妥協せず実行する｡また場合によってはspecifyやplanに戻って再度実行することもある｡

6. エンジニアとSpecKitの担当領域

SpecKitは開発作業を支援するが、最終的な判断や責任を持つのはエンジニアである。

領域 SpecKitの担当 エンジニアの担当
要件定義 仕様として整理する 目的・対象ユーザー・制約を決める
曖昧さ解消 質問を生成する 回答し、方針を判断する
技術計画 計画書として整理する 技術選定の妥当性を判断する
タスク分解 実装タスクに分解する 優先順位や粒度を調整する
実装 コード生成を支援する レビューし、採用可否を判断する
品質確認 チェック観点を提示する テスト方針や合否を決める
チーム運用 一部支援は可能 ブランチ戦略、PRルール、CIを設計する
セキュリティ 観点の整理は可能 認証、認可、秘密情報管理を判断する
リリース・運用 主担当ではない デプロイ、監視、保守を担う

このように、SpecKitは「作業を進める役」であり、エンジニアは「正しさを判断する役」である。

7. チーム開発でSpecKitを利用するために必要な準備

SpecKitをチーム開発で利用する場合、事前に以下を準備する必要がある。

7.1 要件定義

AIに実装を任せる前に、何を作るのかを明確にする必要がある。

必要な項目は以下である。

  • 目的

  • 対象ユーザー

  • 主要機能

  • 非対象範囲

  • 受け入れ条件

  • 制約

  • MVPの範囲

要件定義(specify)では WHAT と WHY に集中する｡技術計画(plan)ではHOW、つまり技術スタック・API・コード構造に集中する｡

7.2 ブランチ戦略

SpecKitで作成した仕様や実装を安全に管理するために、ブランチ戦略を決める必要がある。

例：

main
  └─ feature/001-requirement-chat
  └─ feature/002-markdown-export
  └─ feature/003-auth

SpecKitでは､指示がない場合001-***というような一つのブランチで全ての実装を行おうとする｡そのため､どのようにブランチを切りPRを出すのかを定義する必要がある｡

7.3 PRテンプレート

AIが生成したコードをレビューするために、PRテンプレートを整備する必要がある。

以下はPRテンプレートの一例である。

  • どの仕様に対応しているか

  • どのタスクを実装したか

  • 仕様外の変更が含まれていないか

  • テストや動作確認を行ったか

  • AI生成部分と人間が修正した部分はどこか

7.4 テスト方針

AIが生成したコードの正しさを確認するために、テスト方針を決める必要がある。

  • 単体テスト

  • 結合テスト

  • E2Eテスト

  • 手動確認

  • 受け入れ条件に基づく確認

AI主導開発では、テストは「品質確認」だけでなく、「AIの出力を検証する仕組み」として重要である。

7.5 CI・自動チェック

チーム開発では、人間のレビュー前に最低限の品質チェックを自動化する必要がある。

例：

  • lint

  • format check

  • type check

  • test

  • build

CIを用意することで、AIが生成したコードに含まれる基本的なエラーを早期に検出できる。

7.6 レビュー基準

AI生成コードをレビューする際の基準を明確にする必要がある。

確認すべき点は以下である。

  • 仕様と実装が一致しているか

  • 不要な機能が追加されていないか

  • 既存機能を壊していないか

  • セキュリティ上の問題がないか

  • テストや確認手順があるか

  • チームのコーディング規約に従っているか

このPRが何を行い､レビュワーに何を求めているのかを明確にすることが重要だと考えられる｡

8. タスク分解と並列作業の判断

SpecKitの tasks コマンドは、仕様書と技術計画をもとに、実装に必要な作業をタスクリストとして生成する。
タスクはユーザーストーリーごとに整理され、Setup、Foundational、User Story、Polish のようなフェーズに分けられる。

また、SpecKitは [P] マーカーを用いて、並列実行できる可能性があるタスクを示す。
ただし、[P]マーカーは主に「別ファイルであること」「未完了タスクに依存していないこと」を基準にしたものである。

実際のチーム開発では、並列化の可否はファイル依存だけでは判断できない。
メンバーのスキル、担当技術､仕様理解、API設計の確定状況、PRの粒度、マージ競合、リリース優先度などを総合的に考慮する必要がある。

そのため、SpecKitが生成した tasks.md はそのまま作業割り当て表として使うのではなく、エンジニアがチーム状況に合わせて実行計画へ変換する必要がある。

9. SpecKit導入時の注意点

SpecKitを導入する際には、以下の点に注意する必要がある。

9.1 SpecKitにすべてを任せない

SpecKitは、仕様の整理や実装支援には有効である。
しかし、仕様の正しさ、技術選定の妥当性、品質保証、運用設計を判断する必要がある。

9.2 仕様を更新し続ける

実装が進む中で仕様が変わる場合、コードだけでなく仕様書も更新する必要がある。
SpecKitはドキュメントを参照して実行し成果物を生成する｡そのため､仕様とコードがずれると、SpecKitを使う意味が弱くなる。

9.3 AIの推測を前提にしない

AIは不足している情報を推測で補完することがある。
そのため、曖昧な点は clarify などを用いて事前に明確化する必要がある。

9.4 チームの運用ルールを先に決める

SpecKitを導入しても、ブランチ戦略やPRルール、レビュー基準がなければ、チーム開発は混乱する可能性がある。

SpecKitの導入前に、最低限以下を決めるべきである。

  • ブランチ戦略

  • PRテンプレート

  • レビュー基準

  • テスト方針

  • CI

  • セキュリティ方針

10. まとめ・提案

SpecKitは、要件定義を基に技術計画、タスク分解、コード実装を支援するツールである。
特に、仕様を起点としてAI主導開発を進める場合に有効である。

しかし、SpecKitはチーム開発に必要なすべての仕組みを代替するものではない。
円滑なチーム開発を行うためには、SpecKitの担当領域を理解し、それ以外の領域をエンジニア側で整備する必要がある。

本ドキュメントでは、SpecKitをチーム開発に導入する際、以下の方針を提案する。

  1. SpecKitは仕様作成から実装支援までの補助ツールとして利用する

  2. 仕様の正しさや技術判断はエンジニアが責任を持つ

  3. ブランチ戦略、PRテンプレート、レビュー基準、テスト方針、CIを事前に用意する

  4. SpecKitの成果物とGit運用を結びつけ、仕様と実装の対応関係を明確にする

  5. AI生成コードは必ずレビュー対象として扱う

最終的に、SpecKitを有効に使うためには、AIに作業を任せるのではなく、AIが迷わず作業できる環境を設計することが重要である。

10. 終わりに

最後までご覧いただきありがとうございます｡
この記事はチームでSpecKitを利用した際の問題点を改善する方法について考察した結果をまとめた内容です｡

そのため、本記事の内容には不足している視点や、実際のチーム開発では考慮すべき点が含まれていない可能性があります。
もし「この観点も必要ではないか」「実際にはこのような運用が重要になる」といったご意見がありましたら、ぜひ教えていただけると嬉しいです。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?