Jira における仕様駆動の開発
仕様駆動の開発とは、エージェントがビルドを行う前に構造化された仕様を作成し、もっともらしい推測ではなく正しいものをビルドできるようにすることを意味します。Jira では、実際の意図 (成果、スコープ、制約、承認基準) を確定した後、すでに取り組んでいる作業項目にその仕様を含めます。1 つの作業項目には、1 つのタスクの完全な仕様を含めることも、複数の作業項目に分割されたより大きな機能仕様の一部を含めることもできます。
このガイドでは、仕様をエージェント対応にする要素、作業項目が仕様を含める適切な場所である理由、および最初の仕様の書き方について説明します。簡単に言えば、Jira での仕様駆動の開発によって、以下の 3 つが実現します。
エージェントがビルドの基盤とし、レビュアーが確認の基準とする、信頼できる唯一の情報源
エージェントと担当者の両方に対して完了を定義する受け入れ基準
意図が確定してからエージェントがコーディングを開始するため、手戻りを削減
仕様駆動の開発とは
仕様駆動の開発は、何をビルドし、成功をどのように測定するかを定義した構造化された仕様を作成しておき、エージェントが 1 行のプロンプトから推測するのではなく、その仕様を実装できるという手法です。
仕様が信頼できる情報源になります。仕様を中心として計画、ビルド、チェックが進められますが、Jira ではこれら 3 つすべてが同じ作業項目で行われます。このアイデアは、ビルド前に動作を定義する API 設計や形式手法の実践から生まれたものであり、AI よりも前から存在しています。
ツールの成熟に合わせて、定義も変化し続けるため、固定された仕様フォーマットとしてではなく、あくまで実践的な指針として捉えましょう。変わらないのは、その中核となるアプローチ、つまりエージェントがそれを構築する前に、その作業内容を定義しておくということです。
違いは、曖昧さを解決するタイミングです。バイブ コーディングはコードの記述後に解決しますが、仕様駆動型の開発は事前に解決します。
バイブ コーディング: プロンプトでエージェントを導き、返されたものを受け入れます。そのため、エージェントが想定するスコープ、制約、エッジ ケースは、コードの作成後に明らかになります。
仕様駆動型: 最初に意図、制約、受け入れ基準を決定します。これにより、エージェントは直感ではなく定義に基づいて構築を行います。また、レビューでは、その定義が含まれる作業項目上で、同じ定義と照らし合わせて確認を行います。
実際のコードベースで機能し続ける必要があるコードの場合、確立されたコンテキストを持たないエージェントは、チケットを文字通りに修正することで、重要な制約を見落とす可能性があります。そこから手直しが始まります。
プロンプトでは、2 つのことが曖昧になりがちです。それは、仕様とは構築するものであること、そして計画とはそれをどう構築するかということです。仕様駆動型の開発では、まず「何を」を決定し、それに基づいて「どのように」を構築します。それが、AI コーディング ツールの計画モードでよくスキップされるステップです。多くの場合、合意された仕様がないまま、プロンプトから直接実装方法が作成されます。
計画モードは簡易的な仕様の代わりとして機能しますが、作業に継続して適用される合意済みの仕様からではなく、その場でのプロンプトに基づいて「方法」を策定します。
AI コーディングで仕様が重要である理由
コード生成のコストが下がると、難しいのはもはやコードの記述ではなく、構築しているものを正しく定義するというステップです。したがって、最もレバレッジの高い成果物とは、プロンプトではなく仕様となります。
ワンショット プロンプトでは、不足している情報がエージェントに委ねられます。エージェントはそれを推測で補い、一見正しそうでも間違った問題を解決するコードを生成します。このようなギャップを埋めるのが仕様です。これにより、エージェントは推測ではなく定義に基づいて構築を行います。Jira においては、チームがすでに計画、割り当て、レビューを行っている作業項目が仕様となります。
エージェントが構築の基準にできる仕様に含まれるもの
エージェント対応の仕様書は、優秀なエンジニアが作業を開始する前に尋ねるであろう質問に答えるものです。Jira では、作業項目の要約、説明、リンクされた要件、受け入れ基準にこれらが含まれます。重要な 6 つの要素は次のとおりです。
成果: レビュアーが確認できる形で、変更によって達成すべきこと。
スコープ: 何がスコープ内であるかはもちろん、それと同じくらい重要なのが、何がスコープ外であるかということです。
制約: 遵守すべきアーキテクチャ、セキュリティ、パフォーマンスの制限。
過去の決定事項: コンテキストはすでに確定しているため、エージェントが再議論することはありません。
タスクの細分化: 検証できるほど十分に小さなステップに分割された作業。
受け入れ基準: エージェントが達成に向けて構築し、レビューの基準となる、テスト可能な完了の定義。Jira では、これらは作業項目に存在し、AI コード レビューによって、人の手に渡る前に変更を基準と照らし合わせてチェックされます。
Jira で作業項目が仕様になる仕組み
適切に作成された作業項目は、エージェントが構築の基盤とし、レビューの基準とする仕様として機能します。仕様はリンクされたドキュメントにも配置できます。これは多くの SDD ツールが機能する方法ですが、Jira では作業がすでに実行されている場所に仕様を配置できます。上記の 6 つの要素を備えている場合は、スペックグレードとなります。1 行の "ログインのバグの修正" というような作業項目は、スペックグレードにはなりません。
作業項目に仕様を保持することには、構造上の利点が 1 つあります。それは、作業がすでに存在している場所にあるため、誰も再び開くことのないリポジトリ内のマークダウン ファイルよりも放置されにくくなる点です。だからといって、仕様が自動でメンテナンスされるわけではありません。これは、仕様と作業が乖離することがないということを意味します。
要約、説明、リンクされた Confluence 要件、受け入れ基準のすべてが連動し、エージェントとレビュアーの両方が確認できるように一元化されます。
対照的に、リポジトリ ファイルは作業の追跡、レビュー、クローズを行う場所から離れているため、計画が変更された瞬間に古くなります。
エージェントの作業が完了すると、同じ作業項目がレビュー画面となり、チームが要件や未解決の質問について認識を合わせる場所になります。
Jira によって、明確な要件、タスク、見積もりが組み込まれた計画が定義されます。
Jira Planner が構造化された仕様を生成する仕組み
前のセクションでは、ベースライン、つまり 1 つの作業項目をご自身で仕様に変換する方法についてご説明しました。Jira Planner は、すべての仕様書を手作業で作成するといった方法が現実的ではない、複数のチームにまたがる複雑な取り組みのために設計されています。これは取り組みから開始して、それぞれ独自の仕様を持つ、構造化された作業項目に分割されます。
Jira Planner はアクセラレーターであり、ベースラインではありません。ベースラインの SDD 手法は、適切に構成された作業項目に受け入れ基準を加えたものであり、現在ではどのチームでも実行できます。Jira Planner は、その作業の最も困難な部分である、複雑で曖昧なリクエスト数を構造化された仕様に変換するプロセスを迅速化します。
複雑なプロジェクトである場合、Jira Planner は、コードベース、Jira や Confluence の履歴、チームのコンテキストを含む Teamwork Graph を活用して要件を定義し、開発者やコーディング エージェントが構築できる状態の構造化された技術仕様を Confluence で生成します。1 つの計画が多くの対象者で活用でき、人間にとって読みやすく、エージェントにとって役立ちます。
仕組み:
お客様とチームがコラボレーションを行い、エージェントが実行する前に事前に認識を合わせるための共有スペースを提供します。
作業全体からコンテキストを抽出するため、仕様書は空のプロンプトからではなく、チームがすでに把握している情報に基づいて作成を開始できます。
人間にとって読みやすく、エージェントが問題なく解析できる仕様を生成するため、同じ成果物をレビューと実行に使用できます。
Confluence に仕様を保持して、作業にリンクさせることで、意図や決定事項が記録に残るようにします。
Jira Planner は、大まかなアイデアを構造化されたエージェント対応の仕様に変換します。
Jira Planner はアーリー アクセス版です — 待機リストにご登録ください。
Jira で初めてのエージェント対応の仕様を作成する方法
1 つの作業項目を取り上げ、6 つの要素をチェックリストとして使用し、手作業でエージェント対応の仕様を作成しましょう。
作業項目から開始します。タイトルだけでなく、成果、スコープの境界、制約事項を説明に記載します。
意図を構造化された仕様に変換します。これは実際の SDD 作業です。事前のコンテキストを作業項目の成果、スコープ、制約としてまとめ、エージェントが定義を継承できるようにします。
テスト可能な受け入れ基準を作成します。これらは、エージェントが構築の目標とし、レビュアーがチェックする際の基準とする契約書のようなものです。ほとんどの基準は、テスト可能になるまでに何度か見直す必要があります。
コーディング エージェントに割り当てます。スペックグレードの作業項目は、エージェントが実装を行い、その項目に紐づくプル リクエストを作成するのに十分な情報を提供します。
基準に照らしてプル リクエストをレビューし、調整します。エージェントが推測した箇所の仕様を厳格化して、次の作業項目でそのパターンを再利用します。
仕様駆動型の開発に関するよくある質問
仕様駆動開発を行うには Jira Planner が必要ですか?
いいえ。ベースラインは、受け入れ基準を備えた適切に構成された作業項目であり、現在どのチームでも作成できます。複雑な作業の場合、Jira Planner は最上位の計画である取り組みから開始し、それを構造化された Jira 作業項目に分割することで作業を加速させます。各項目には仕様が入力されているため、すべてを手作業で記述する必要はありません。
仕様と受け入れ基準の違いは何ですか?
仕様とは、成果、スコープ、制約、コンテキストといった変更全体を定義します。受け入れ基準はその一部であり、エージェントが目標として構築し、レビュアーが照合して確認する、テスト可能な「完了」の定義です。
本当に優れたプロンプトだけで十分でしょうか?
小規模で元に戻せる作業であれば、多くの場合で十分です。複雑な操作や元に戻すのが難しい操作の場合、プロンプトは省略された内容をエージェントに推測させます。仕様があると、推測が不要になります。
仕様はリポジトリ ファイルと Jira 作業項目のどちらに置くべきでしょうか?
作業項目は、作業の追跡、レビュー、クローズを行う場所に仕様を保持します。これにより、誰も開かないリポジトリ内のマークダウン ファイルよりも、内容が乖離しにくくなります。
仕様駆動型の開発はチームのスピードを低下させますか?
事前の労力は増えますが、後々の手直しが不要になります。複雑な作業においては、そのトレードオフは全体としてプラスになります。軽度な修正については、仕様をスキップして直接プロンプトを実行しましょう。
仕様を作成すべきタイミングと、スキップすべきタイミングとは?
複雑で影響が大きい作業や元に戻すのが困難な作業、または実際のアーキテクチャやセキュリティ上の制約があるものについては、仕様を作成します。簡単なプロンプトのほうが早い場合や、軽微で元に戻せる修正の場合は、仕様をスキップします。