要件整理タスクへ展開する
ここまでは、Defaultエージェントを利用し、会議室予約システムの構想を自由形式で整理しました。続いて、この構想を要件、設計、実装タスクへ具体化します。今回は、Kiroの仕様駆動開発ワークフローであるQuick Specを利用します。Quick Specは、最初に確認事項へ回答すると、要件、設計、タスクを一括して生成するセッションモードです。
作成したシステム構想を参照するよう指示し、Quick Specを実行しました。
Quick Specを実行すると、構想をベースにrequirements.md、design.md、tasks.mdが生成されました。requirements.mdには、要件が記載されます。design.mdにはシステム構成や実装方針、tasks.mdには実装可能な単位へ分解されたタスクが記載されます。
Quick Specで生成された成果物は、Agent Focusの画面右側にも表示されました。表示内容は、.kiro/specs/配下に生成された各Markdownファイルと対応しており、要件、設計、タスクの概要を確認できます。
一方、今回生成された設計にはER図も含まれていましたが、筆者の環境では表示可能な範囲が限られており、図全体を確認しづらい場面がありました。成果物の概要を確認するには便利ですが、図や長い設計書を詳しく確認する場合は、IDEビューでMarkdownファイルを直接開く方が見やすいと感じました。
Analyze Requirementsで要件を分析する
Quick Specで生成した要件について、曖昧な表現や考慮漏れが残っている可能性があります。そこで、実装へ進む前にAnalyze Requirementsを実行しました。Analyze Requirementsは、要件を個別に確認するだけでなく、要件全体を横断して、論理的な矛盾、曖昧な表現、競合する制約、未定義の前提、境界条件などを分析する機能です。機能の詳細はこちらをご参照ください。
実行するためには、IDEビューで「Continue」をクリックし、「Analyze requirements」を選択します。
分析を実行すると、要件をさらに具体化するための確認事項が提示されます。今回のケースでは、「要件8.1では、同時利用者が100名以下の場合に主要操作へ2秒以内で応答すると定義されているが、ちょうど101名になった場合は同じ性能基準を維持するのか、それとも性能の劣化を許容するのか」といった指摘がありました（英語で表示されたため筆者訳）。
このように、要件として明確に定義されていない内容について確認ができました。
質問へ回答すると、その内容に応じてrequirements.mdが更新されます。
なお、本記事執筆時点の筆者の環境では、Analyze Requirementsによる確認事項はすべて英語で表示されました。KiroのGitHub Issueでも、requirements.mdの記述言語やSteeringの設定にかかわらず、Analyze Requirementsの質問や選択肢が英語で表示される事例が報告されています。
一方、Analyze Requirementsの結果が日本語で表示されている事例もWeb上では確認できます。バージョンや内部の処理によって挙動が異なる可能性がありますが、詳細な条件は分かりませんでした。
利用者やrequirements.mdの記述言語に合わせて確認事項が表示されることが望ましく、この点は今後の改善に期待したいところです。一方で、要件を実装前に改めて見直し、曖昧さや考慮漏れを洗い出せる機能自体は有用だと感じました。
仕様駆動開発では、明文化した要件をもとに、その後の設計やタスクが作成されます。そのため、要件に曖昧な点や考慮漏れが残っていると、後続の成果物にも影響し、設計や実装をやり直す原因になります。また、設計やコードの再生成を繰り返すと、その分だけKiroのクレジットも消費します。Analyze Requirementsはコスト削減を目的とした機能ではありませんが、早い段階で要件の問題を見つけることは、不要な再生成とクレジット消費を減らすことにもつながります。
そのため、Analyze Requirementsを実行して設計や実装へ進む前に要件を確認・精査する流れは、有効だと感じました。
