「Spec-Driven Development」「スペック駆動開発」という言葉を耳にする機会が急激に増えました。GitHub が2025年9月に Spec Kit をオープンソースで公開し、AWS が2026年に仕様駆動を前提とした IDE「Kiro」をリリースしたことで、AIコーディングの現場で新しい標準になりつつあります。
一方で、実際にプロジェクトを動かしている立場からすると素直に喜べない気持ちも残ります。これまで工数をかけて磨いてきた要件定義書のフォーマットやレビュープロセスは、これから不要になるのでしょうか。それとも別物として並走させるのでしょうか。「用語は分かったけれど、結局うちの案件で何をどう変えればよいのか」という疑問に答えてくれる記事はまだ多くありません。
さらに難しいのは、仕様駆動開発を紹介する記事の多くが「エンジニアが AI に何を指示するか」という視点に寄っていることです。発注者・開発マネージャー・情シスの立場から見ると、「要件定義との違い」「既存プロセスに組み込む順序」「検収基準の作り方」という論点を整理した情報が不足しています。
本記事では、仕様駆動開発（SDD）の定義から始め、従来の要件定義プロセスとの違いを目的・粒度・成果物・更新プロセスの4軸で整理します。そのうえで、GitHub Spec Kit が提唱する Specify → Plan → Tasks → Implement の4ステップワークフロー、主要ツール（Spec Kit / Amazon Kiro / Claude Code）の選び方、導入時に失敗しないための実務ポイントを、発注側の意思決定に寄せた形で解説します。
読み終える頃には、「要件定義書は捨てるのではなく、AI に接続する仕様レイヤーを追加することで再設計する」という基本方針と、そのための具体的な一歩が見えている状態を目指します。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
仕様駆動開発（Spec-Driven Development）とは何か
仕様駆動開発（Spec-Driven Development、以下 SDD）は、AI コーディングエージェントに実装を任せる前提で、「仕様書」を開発プロセスの中心に据える開発手法です。「スペック駆動開発」と呼ばれることもあり、両者は同じ概念を指します。
仕様駆動開発の定義とコア概念
SDD の中核にあるのは、「Source of Truth（唯一の情報源）」の転換です。従来の開発では、動いているソースコードこそが「実際に何が動くか」を決定する最終的な真実でした。仕様書や設計書はあくまで補助資料であり、実装が進むにつれて内容が古くなり、コードと乖離していくのが常でした。
SDD では、この関係を逆転させます。人間が書く「仕様（Spec）」が唯一の情報源であり、コードは仕様から AI が生成する成果物として位置づけられます。仕様が変われば実装も更新される、という一方向の依存関係にすることで、「仕様書と実装の乖離」という長年の課題を構造的に解消しようとする考え方です。
@IT の用語解説では、この点を「コードではなく人間の意図（intent）が Source of Truth になる」と表現しています（出典: @IT AI・機械学習の用語辞典「仕様駆動開発」）。従来のドキュメント駆動開発と似ているように見えますが、決定的に違うのは「仕様書を書けば、AI が実装まで進めてくれる」という実行可能性が前提になっている点です。
つまり SDD は単なるドキュメント文化の再興ではなく、「AI に読ませて実装させる前提で仕様を書く」ことで、これまで理想論だった「仕様書中心の開発」を現実的な選択肢に変えたアプローチです。
なぜ今、仕様駆動開発が注目されているのか
SDD がここ1年ほどで急速に注目された背景には、AI コーディングツールの実力向上とその副作用があります。Claude Code、GitHub Copilot、Cursor などのツールが実用レベルに達したことで、「プロンプトを投げれば動くコードが返ってくる」時代が到来しました。しかし、その反面「思いつきのプロンプトで場当たり的にコードを積み上げる」いわゆる Vibe Coding（バイブコーディング）の弊害も顕在化しました。
思いつきベースの生成は短期的には速いのですが、要件が曖昧なままなので、生成された機能同士が矛盾したり、後から仕様追加した際に整合性が取れなくなったりします。開発者は「AI が書いたコードのレビューと修正」に大量の時間を奪われる状況が生まれました。
この課題への回答として、GitHub が2025年9月2日に Spec Kit をオープンソース公開し、「AI に実装させる前に、仕様・技術計画・タスク分解を人間がしっかり書く」というフローを提唱しました（出典: Visual Studio Magazine「GitHub Open Sources Kit for Spec-Driven AI Development」）。さらに2026年5月には AWS が Kiro を国際的にリリースし、仕様駆動を前提とした IDE として大きな注目を集めました（出典: AWS Kiro Developer Guide 2026）。
つまり SDD は、AI コーディングを本格導入する現場で「思いつきコーディング」を卒業するための共通言語として広がっています。単なる流行語ではなく、AI エージェントを組み込んだ開発プロセスを持続可能な形に整えるための実務的な要請から生まれた考え方だといえます。
仕様駆動開発と従来の要件定義の違い
ここが本記事の主戦場です。「Spec-Driven Development」の翻訳として「仕様駆動開発」という言葉が広まる中、多くの現場で「これは従来の要件定義書と何が違うのか」という混乱が起きています。まず前提として、両者は「置き換え」ではなく「役割分担」の関係にあります。
要件定義書と仕様書は何が違うのか
日本の受託開発・SI 業界で長年使われてきた「要件定義書」と、SDD で言うところの「仕様書（Spec）」は、目的も読者も粒度も異なります。混同したまま議論を進めると、「要件定義書は不要」という極端な結論に飛びついてしまうため、まず整理します。
観点 | 要件定義書 | 仕様書（Spec） |
|---|---|---|
目的 | 発注者と受注者の合意形成、契約の根拠 | AI エージェントに実装させるための実行可能な指示 |
主な読者 | 発注者・PM・アーキテクト・レビュワー | AI エージェント（＋人間のレビュワー） |
粒度 | 業務要件・機能要件・非機能要件（What レベル中心） | 入出力・データ構造・受け入れ基準まで含む実行粒度 |
更新プロセス | フェーズ移行時に確定、変更管理表で更新 | 継続的に更新され、変更が即座に実装に反映される |
成果物としての位置 | プロジェクトの節目に納品される「静的文書」 | 開発中ずっと更新され続ける「生きている文書」 |
要件定義書は「合意形成のための文書」であり、発注者と受注者の間で「何を作るか」を握るための契約基盤としての性格が強いものです。一方 SDD の仕様書は、AI が読み取って実装に落とし込める粒度まで踏み込んだ「実行可能な指示書」であり、粒度も更新頻度もまったく異なります。
両者は代替関係ではなく、上流の要件定義書が「なぜそれを作るか（Why）」「何を作るか（What）」を扱い、下流の仕様書が「どのように実装するか（How の一歩手前）」を扱う、レイヤーの違う存在だと整理するのが実務的です。
"唯一の情報源"がコードから仕様に移ることで変わる意思決定
Source of Truth が仕様に移ると、日々の意思決定の場所が変わります。これは仕様書のフォーマットが変わる以上のインパクトを持つ変化です。
従来は、要件が曖昧なまま実装が進み、コーディング中に発生した細かい判断（バリデーションルール、エラー時の挙動、境界条件の扱いなど）がコードに直接埋め込まれていました。レビューはコードで行い、変更が必要になればコードを直接修正します。仕様書は「実装後に整合性を取る」対象として、常に後回しになりがちでした。
SDD では、これらの細かい判断もすべて仕様書側に記述します。バリデーションルールを変えたければ、まず仕様書を書き換え、その差分を AI が実装に反映します。レビューの対象は「コード」ではなく「仕様の変更差分」に移ります。つまり、コードレビューよりも「仕様レビュー」のほうが重要になるということです。
この変化は、レビュワーに求められるスキルセットにも影響します。コードの実装品質を見る役割から、「仕様として矛盾がないか」「エッジケースまで網羅されているか」を確認する役割に軸足が移ります。従来の要件定義レビューに近い頭の使い方が、より高頻度で必要になるイメージです。
AI が実装する前提で要件定義書に求められる粒度の変化
「要件定義書は残す」と決めたとしても、粒度に対する要求は確実に変わります。従来は「あとは実装者の解釈でよしなに」で許されていた曖昧な記述が、AI 実装を前提にすると通用しなくなるためです。
人間の開発者は経験と暗黙知で「文脈から察して埋める」ことができました。「エラー時はユーザーに分かりやすくメッセージを出す」と書けば、経験のあるエンジニアは適切なメッセージ・ロギング・監視への通知まで自然に組み立てます。しかし AI エージェントは書かれた通りにしか動きません。曖昧なまま渡すと、平気で不整合な実装を生成します。
つまり要件定義書は「捨てる」のではなく、「AI に接続する下流工程を意識して、より明示的に書く」方向に進化させる必要があります。特に、以下のような論点を要件定義段階で明確化しておくと、下流の仕様書作成が滑らかになります。
- 業務ルールの境界条件（例外・エラー時の扱い）
- データの制約（必須／任意、桁数、フォーマット）
- 非機能要件（性能・セキュリティ・運用監視）の受け入れ基準
- 画面遷移・状態遷移の網羅
これらは従来も「書くべき」とされていた項目ですが、AI 実装を前提にすると「書いていないと動かない」項目に格上げされる、と考えると分かりやすいかもしれません。
仕様駆動開発のワークフロー（Specify → Plan → Tasks → Implement）
SDD の代表的な実装として、GitHub Spec Kit が提唱する4フェーズのワークフローを見ていきましょう。Spec Kit は MIT ライセンスで公開されているオープンソースのツールキットで、30以上の AI コーディングエージェント（GitHub Copilot、Claude Code、Gemini CLI など）と連携できます（出典: Visual Studio Magazine「GitHub Spec Kit Takes Off」2026年5月）。
このワークフローは、Spec Kit を使わない場合でも「仕様駆動開発の考え方の基本骨格」として参考になります。まずは全体像を押さえたうえで、各フェーズを従来の V 字モデルと対応づけて整理します。
Specify（仕様定義）— 何を作るかを言語化するフェーズ
最初のフェーズは Specify です。ここでは「何を、誰のために、なぜ作るのか」を人間が言語化します。ユーザーストーリー、業務フロー、画面イメージ、受け入れ基準など、いわゆる「機能仕様」に相当する内容を書き出します。
このフェーズで重要なのは、実装方法（How）に踏み込まず、あくまで「作るもの（What）」に集中することです。技術選定や設計方針はまだ扱いません。従来の要件定義プロセスの「業務要件」「機能要件」の言語化に近い作業ですが、より詳細に、AI が読み取れる形で明示します。
発注者・PM が主体的に関わるフェーズであり、SDD の中で最も「人間らしい判断」が求められる工程です。ここが曖昧だと、後続すべての工程が瓦解するため、時間を惜しまず精度を高めるべきステップになります。
Plan（技術計画）— 仕様からアーキテクチャを導出するフェーズ
次に Plan フェーズでは、Specify で固めた仕様を元に、技術スタック・アーキテクチャ・データベース設計・API 設計などを立案します。従来の「基本設計」に相当するフェーズです。
このフェーズは開発者・アーキテクトが主体になりますが、発注者にとっては「非機能要件（性能・セキュリティ・可用性）が仕様と整合しているか」を確認する場になります。AI エージェントは基本設計案を提案できますが、システム全体の整合性・既存資産との接続・運用体制との適合性は人間の判断が必要です。
Plan の成果物は、次の Tasks フェーズで細かい実装単位に分解される前提の設計書になります。従来の基本設計書のように「完成された成果物」というより、「分解の材料」として使われることを意識した粒度で書きます。
Tasks（タスク分解）— AIエージェントに渡せる粒度に分けるフェーズ
Tasks フェーズでは、Plan の内容を AI エージェントに渡せるサイズのタスク単位に分解します。1つのタスクは「AI が1回のセッションで確実に完了できる」規模が目安です。多くの現場では、1タスクあたり数時間〜1日の作業量程度に切り分けています。
このフェーズは従来の詳細設計に近い性格を持ちますが、「人間が実装するための設計書」ではなく「AI が実装するためのタスク定義」なので、記述の切り口が変わります。具体的には、以下の要素を明示します。
- 入力（前提条件、依存するデータ・API）
- 出力（生成されるファイル、関数、テストケース）
- 受け入れ基準（テストが通る条件、レビュー観点）
- 想定される依存関係（他タスクとの前後関係）
Spec Kit ではこれらを Markdown ベースのテンプレートで管理し、AI が読める形で構造化します。人間側から見ると「タスク管理ツールで管理していたチケットの記述」を、より AI 向けに厳密化したものと考えると近いです。
Implement（実装）— AI による生成と人間によるレビュー
最後の Implement フェーズで、AI エージェントが実際にコードを生成します。人間の役割は、生成されたコードのレビューと、想定通りに動くかの検証です。ここまでのフェーズをしっかり進めていれば、AI の生成品質は大幅に向上し、レビュー負荷も下がります。
一方で、Implement フェーズで発見された問題（仕様の曖昧さ・矛盾・考慮漏れ）は、コードを直接修正するのではなく Specify / Plan / Tasks に戻って修正します。これが SDD の「Source of Truth を仕様に置く」原則を守る運用ルールです。
コードだけを直接修正すると、仕様書との乖離が発生し、次回の生成時に矛盾を引き起こします。この規律を組織に定着させることが、SDD 導入で最も重要かつ最も難しい部分だといえます。
従来の V 字モデルとの対応関係
ここまでの4フェーズを、従来の V 字モデルと対応づけて整理します。
従来の工程 | SDD のフェーズ | 主体 |
|---|---|---|
業務要件定義・機能要件定義 | Specify（＋従来の要件定義書は上流に残す） | 発注者・PM |
基本設計 | Plan | アーキテクト・PM |
詳細設計 | Tasks | 開発者（AI 補助） |
実装・単体テスト | Implement | AI エージェント＋レビュワー |
結合テスト・受入テスト | 各フェーズの受け入れ基準に組み込み | QA・発注者 |
重要なのは「要件定義書」自体がなくなるのではなく、上流に位置づけたまま、Specify フェーズと接続することです。要件定義書は「発注者と受注者の合意基盤」として残し、Specify は「AI に渡すための実行可能な仕様」として新設する、と役割分担を明確にするのが実務的な運用になります。
主要ツールの位置づけと選び方
SDD の考え方を実現するツールは複数出ています。ここでは代表的な3つを、アプローチと向いている状況の観点で整理します。
GitHub Spec Kit — エージェント非依存の Markdown ワークフロー
Spec Kit の最大の特徴は、特定の AI コーディングエージェントに依存しないことです。GitHub Copilot、Claude Code、Cursor、Gemini CLI など、30以上の AI エージェントと組み合わせて使えます。CLI コマンドとスラッシュコマンドで動作し、仕様・計画・タスクを Markdown ファイルで管理する軽量なワークフローが提供されます（出典: Cryptobriefing「GitHub unveils Spec Kit」）。
向いているのは、以下のような状況です。
- 既に社内で使っている AI コーディングエージェントを変えずに、仕様駆動プロセスだけを導入したい
- 複数の AI エージェントを併用しており、ツールごとに違うワークフローを持ちたくない
- 仕様書を Markdown で管理し、Git で差分管理・レビューしたい
一方で、Spec Kit はあくまでワークフローの「型」を提供するだけであり、IDE の中で完結する体験は得られません。エディタ・CLI・AI エージェントを別々に開いて連携させる形になります。
Amazon Kiro — 仕様ネイティブの IDE
Kiro は、AWS が2026年に国際リリースした仕様駆動ネイティブの IDE です。プロンプトを入力すると、EARS 記法（Easy Approach to Requirements Syntax）でユーザーストーリーと受け入れ基準を自動生成し、アーキテクチャ設計と実装タスクまで一貫して IDE 内で管理できます。ファイル保存時のリント自動実行、PR マージ時のテスト自動再生成など、エージェントフックと呼ばれるバックグラウンド自動化も特徴です（出典: Toolbrain Kiro AI Review 2026）。
向いているのは、以下のような状況です。
- 新しく AI コーディング環境をゼロから整備するチーム
- AWS 上でシステムを構築しており、既存 AWS サービス（Q Developer）との移行を検討している
- IDE 内で仕様〜実装〜テストまで完結させたい
Kiro は AWS が旧 Amazon Q Developer を段階的に置き換える意図で投入したツールでもあり、Q Developer を使っている組織にとっては移行検討が実務的な選択肢になります（Q Developer IDE プラグインのサポート終了予定: 2027年4月30日）。
Claude Code — 軽量な CLI エージェント
Claude Code は、Anthropic が提供する CLI ベースの AI コーディングエージェントです。厳密には Claude Code 自体が SDD 専用ツールではありませんが、Spec Kit と組み合わせることで SDD ワークフローを実現できます。「Markdown で仕様を書き、CLI で実装を依頼する」という軽量な運用に向いています。
向いているのは、以下のような状況です。
- 既存の開発フロー（エディタ・Git・CI/CD）を変えずに SDD を試したい
- IDE を切り替えるコストを避け、まずは小さく始めたい
- CLI 中心の開発文化があるチーム
Claude Code 単体では「仕様書のテンプレート」「4フェーズのワークフロー管理」までは提供されないため、Spec Kit と併用するか、社内独自のテンプレートを整備する必要があります。
ツール選定は「プロセス設計」の後に行う
3ツールを紹介しましたが、SDD 導入で最も避けるべき失敗は「ツールから入る」ことです。「Kiro を導入しよう」「Spec Kit を使おう」が先に来ると、既存の要件定義プロセスとの接続が曖昧なまま、ツールの流儀に振り回されがちです。
順序としては、次の順に検討することをおすすめします。
- 既存の要件定義プロセスの中で、どこまで人間が書き、どこから AI に渡すかを決める
- 仕様書のテンプレート・粒度・レビュー基準を先に整理する
- その運用に合うツールを選ぶ（既存 IDE との親和性・チームの成熟度・エージェント選択自由度を軸に判断）
プロセスが整えば、ツールは後から交換できます。逆に、ツール先行だとプロセスが「そのツールでしか回らない」形になり、他ツールへの移行やハイブリッド運用が難しくなります。
仕様駆動開発で失敗しないための実務ポイント
SDD を実際に導入する際、多くの現場で似たような失敗パターンが観察されます。ここでは、それらを避けるための実務ポイントを3つの観点で整理します。
"良い仕様"の3条件（明示性・網羅性・検証可能性）
SDD の成否は「仕様の質」で7割方決まります。良い仕様の条件は次の3つです。
明示性: 曖昧な表現を避け、AI が判断に迷わない粒度で書きます。「ユーザーに分かりやすいメッセージ」ではなく、「メッセージ表示は最大2文、40文字以内、日本語、丁寧語」のように具体化します。設定値・境界値・許容範囲を数値で示すことがポイントです。
網羅性: 正常系だけでなく、異常系・境界条件・エラー時の挙動まで含めて記述します。「入力が空だったら」「ネットワーク断のとき」「同時に複数リクエストが来たら」といったケースを、仕様書に明記します。ここを漏らすと AI が勝手に補完し、要件外の実装を生成することがあります。
検証可能性: 「その仕様が満たされたかどうか」を機械的にチェックできる形で書きます。可能なら受け入れテストの形式（Given / When / Then など）で記述し、自動テストとして検証できるようにします。Kiro が採用している EARS 記法は、この検証可能性を高めるための表現形式です。
3条件のうち、日本の受託開発現場で特に不足しがちなのが「明示性」です。長年の慣習で「あとは実装者の判断で」という曖昧さが許容されてきたため、SDD への切り替えで最初に躓きやすいポイントになります。
発注者が関与すべきフェーズと開発者に任せるべきフェーズ
SDD では、フェーズごとに求められる関与の深さが変わります。発注者・PM の立場では、以下の使い分けを意識すると効果的です。
発注者が主体的に関わるフェーズ:
- Specify（仕様定義）: 業務要件・受け入れ基準・優先順位を決める
- Plan の非機能要件レビュー: 性能・セキュリティ・可用性の妥当性を確認
- Implement 完了後の受入検証: 仕様通りに動くかを確認
開発者・AI に任せるフェーズ:
- Plan の技術選定・アーキテクチャ設計（発注者はレビューのみ）
- Tasks のタスク分解（発注者は成果物のマイルストーンだけ確認）
- Implement のコード生成・単体テスト
従来の受託開発では「要件定義は発注者、以降は受注者」という切り分けが多かったのですが、SDD では発注者が Specify フェーズにより深く関わる必要があります。理由は、AI が実装する前提だと「仕様の曖昧さ＝実装の品質低下」に直結するためです。
逆に、Tasks や Implement で発注者が細かく口を出すと、AI と開発者の作業リズムを乱します。「上流で深く関わり、下流は受け入れ基準の確認に絞る」という関与モデルへの切り替えが求められます。
AI が生成したコードの品質保証を検収にどう組み込むか
AI が生成したコードを検収するにあたっては、従来の目視レビューだけでは不十分です。生成量が多く、人間が全行を読み切ることは現実的でないためです。以下の3層で検収基準を組み立てることをおすすめします。
1層目: 自動テストで検証 仕様書に受け入れ基準を明記し、それを自動テストとして実装します。テストコード自体は AI が生成できますが、テスト設計の妥当性は人間がレビューします。「仕様に書かれた振る舞いをすべてカバーしているか」を確認するのが検収の第一関門です。
2層目: 静的解析・セキュリティスキャン リンター、型チェック、セキュリティスキャナー（SAST）を CI に組み込みます。AI が生成したコードでも脆弱性を含むケースはあるため、機械的なチェックで最低ラインを担保します。
3層目: 人間による重要ポイントレビュー すべてのコードを目視レビューするのではなく、「AI が判断に迷った箇所」「複雑な業務ロジック」「セキュリティ・認証に関わる箇所」に絞ってレビューします。Spec Kit や Kiro は、AI の判断ログや生成理由を残す機能があるため、それを手がかりにレビュー対象を絞り込めます。
検収基準として重要なのは、「コードの美しさ」ではなく「仕様との整合性」に評価軸を寄せることです。AI が生成したコードのスタイルにこだわりすぎると、レビューが不毛になります。仕様通り動き、テストが通り、セキュリティ要件を満たしていれば、まずは合格とする運用が現実的です。
まとめ — 従来の要件定義プロセスをどう再設計するか
ここまで、仕様駆動開発の定義から、従来の要件定義との違い、4ステップのワークフロー、主要ツール、実務ポイントまでを見てきました。最後に、既存の要件定義プロセスをどう再設計するかを「捨てる／残す／組み替える」の3軸で整理します。
捨てるもの:
- 「あとは実装者の解釈で」という曖昧な記述の余地
- 実装後にコードを直接修正して仕様書を放置する運用
- コーディング詳細に踏み込まない前提の「静的な設計書」
残すもの:
- 発注者と受注者の合意基盤としての要件定義書
- 業務要件・非機能要件のレビュープロセス
- V 字モデル的な受入検証・段階的な品質担保
組み替えるもの:
- 詳細設計の位置づけを「人間向け」から「AI 向けタスク定義」へ
- レビューの主戦場を「コード」から「仕様の変更差分」へ
- 検収基準を「動くか」から「仕様と整合するか＋自動テストで検証可能か」へ
つまり、SDD の導入は「要件定義プロセスの全面刷新」ではなく、「AI に接続する仕様レイヤーを既存プロセスの下流に追加する」再設計です。この視点で見ると、これまで積み上げてきた要件定義の資産は決して無駄になりません。むしろ、上流で丁寧に業務要件を握れるチームほど、下流の仕様書作成・AI 実装への接続がスムーズに進みます。
明日からの一歩としておすすめしたいのは、「今動いているプロジェクトの中で、1つの機能追加案件だけ SDD 的に進めてみる」ことです。既存の要件定義書はそのまま活用しつつ、下流工程を Specify → Plan → Tasks → Implement の形に切り分け、Markdown で仕様を管理してみる。この小さな実験を通じて、自社に合った粒度・レビュー基準・ツール選択が見えてきます。
仕様駆動開発は流行の一過性ではなく、AI コーディングを本格活用するうえで避けて通れないパラダイムになりつつあります。要件定義プロセスの再設計を、既存資産を活かしながら段階的に進めていくのが、成功への近道です。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
よくある質問
- 仕様駆動開発を導入したら、既存の要件定義書はもう不要になりますか？
不要にはなりません。実務では「どちらが先に直るか」という更新の主従関係を最初に決めておくことが重要です。要件定義書に矛盾する記述が見つかった場合は、まず発注者・PMが要件定義書側を修正し、その内容をエンジニアがSpecify文書に反映する、という順序を固定しておくと、2つの文書が食い違ったまま放置される事態を防げます。要件定義書は合意基盤として残し、Specify以降はそこから派生する実行可能な指示書として位置づける「役割分担」で運用します。
- 仕様駆動開発を試すとき、最初に何から手をつければいいですか？
いきなり複数案件に広げず、対象を選ぶ基準を先に決めることがポイントです。影響範囲が閉じていて、受け入れ基準を数値で書きやすい機能追加（例: バリデーションルールの追加や表示条件の変更など、境界条件を言語化しやすいタスク）を1つだけ選び、他の進行中案件には広げません。要件定義書自体は変更せず、下流の実装指示だけをSpecify以降に切り出す形にすると、既存の契約・合意プロセスに影響を与えずに小さく試せます。
- Spec Kit・Kiro・Claude Codeはどう選び分ければいいですか？
迷ったら「今の開発フローを変えずに始められるか」を優先軸にするのがおすすめです。Spec KitとClaude Codeは併用が前提の組み合わせで、CLI中心の運用のまま小さく試せます。AWS資産を多く使っており将来的にIDE統合型へ移行したい場合は、Spec Kit運用で仕様の書き方・レビュー基準を固めてからKiroへ段階移行する順番が無理がありません。逆に、複数のAIエージェントを併用しているチームがいきなりKiroのようなIDE一体型を導入すると、ツール切り替えのコストが仕様駆動開発そのものの定着を妨げやすい点に注意が必要です。
- 発注者はどこまで仕様書の作成に関与すべきですか？
関与すべきフェーズを覚えるだけでなく、関与の「質」が変わる点が重要です。従来の要件定義レビューでは細部の解釈を開発者に委ねられましたが、SDDでは発注者が使った曖昧な表現がそのままAIの誤実装に直結するため、Specifyフェーズでの言葉の精度がこれまで以上に成果を左右します。目安として、判断コストの多くをSpecifyに前倒しで割き、Planの非機能要件レビューは「性能・セキュリティの数値目標が明記されているか」の確認に絞れば十分です。逆にTasksやImplementの細部にまで口を出すと、AIと開発者の作業リズムを乱すため避けてください。
- 良い仕様と悪い仕様を見分けるポイントは何ですか？
明示性・網羅性・検証可能性という3条件を覚えるだけでなく、迷ったときの簡易チェック法を持っておくと実務で役立ちます。書いた仕様文を読み返し、「これを読んだAIが2通り以上の実装方法を選べてしまう箇所はないか」を自問すると、明示性・網羅性の不足に気づきやすくなります。検証可能性については、受け入れ基準をGiven/When/Then形式で書けるかどうかを試すのが手軽な判定法で、うまく書けない場合はまだ仕様が曖昧である証拠だと考えてください。
