Kiroを実案件で評価してみた②

Kiroの中核要素　Specs/Steering
Specsとは：Requirements(要件) → Design(設計) → Tasks(実行計画) の3点セット

Kiroの仕様駆動開発ではSpecsが実装の前提であり、開発が進んでも仕様と実装が乖離しないように更新していく考え方が重視されています。Specsは最初に作成したら終わりではなく、継続的に管理し、要件が変わったらSpecsを更新してからコードを修正することで、常に仕様と実装を同期させることが推奨されています。

Specsは次の3つから構成されています。

Requirements：何を実現したいか

ユーザーはまず、KiroとのチャットでSpecモードを選択し、要件をプロンプトとして入力します。

すると入力したプロンプトをKiroが分析し、ユーザーストーリーと受け入れ基準を中心に要件を構造化した以下のようなRequirementsを作成します。
要件の数はプロンプトの内容にもよりますが、10~15要件程度にまとめられます。

※以降のKiroの作成物に関する画像について、一部マスキング、抜粋をしており実際のものとは異なる箇所があります。

受入基準はEARS記法を用いて記述されており、認識のズレや要件の追加があればチャットでKiroに修正を指示することでRequirementsを更新します。

Design：どう実現するか

Designは、要件(Requirements)を満たすための技術設計（ファイル構成やAPI/データ、処理フローなど）になります。

KiroはRequirementsをインプットとして、以下のように具体的な技術観点での設計内容を整理します。

Tasks：どの順番で作るか

要件(Requirements)と設計(Design)が完了すると、Kiroは以下のような依存関係に基づいて順序付けされた開発タスク一覧を整理します。
ユーザーはKiroに対して上から順番にタスクの実行を指示することで開発を進めます。

また、コードの実装だけでなく、以下のようにテストの実施や設計書等のドキュメント作成もタスクに含めることでシステム開発プロジェクトにおけるタスクを一通りKiroにて実施することができます。

これらのSpecsは一度で完成させるのではなく、人による確認を挟みながらKiroに修正を指示して精度を上げる使い方が前提になります。
また前述の通り、実装後に要件変更が出た場合はSpecsを更新して仕様と実装を同期させることが推奨されています。

Steeringとは：Kiroが参照するプロジェクトのルールブック

Kiroのもう一つの中核要素が Steeringです。
SteeringはSpecsとは異なり、必要なファイルや記載要項は決まっておらず、自由な内容を記載することができます。
今回の検証ではSteeringに次のような内容を整理しており、Kiroは推論時に常にこれらを参照しています。
これにより、Steeringに記載されているルールや前提事項を遵守しながら開発タスクを実行できます。

リポジトリ構造

このようにリポジトリ構造をSteeringとしてKiroにインプットすることで、アプリケーションの構造を常に把握し適切な箇所のコード修正等を実現します。

アプリケーションが利用しているフレームワーク(今回の検証の場合Django)観点での開発規約も整理しています。

技術スタック

このように、利用しているライブラリの一覧をSteeringに整理することで、そのライブラリを利用することを前提としてベストプラクティスに従った実装を実現します。

また開発ルール以外にも、高品質な各種ドキュメントを作成するための手順について整理した以下のSteeringも作成しています。

画面設計書の作成・更新手順

画面設計書のテンプレートファイルを参照し、要件を基に画面設計書を作成するための手順を整理したSteeringファイルを作成しました。
社内には各種設計書の標準テンプレートおよび設計書作成のポイントが整備されており、通常のシステム開発プロジェクトではこれらの標準に則ることで設計書の品質を担保しています。
今回の検証では、標準テンプレートをKiroにインプットし、どのような観点で設計書の各項目を記載するのかというポイントを以下のようにSteeringに整理しました。

イメージとしては、プロジェクトに新規参画した新人に対して設計書の作成手順を教えるような感覚に近いです。
また、仕様が変更された際の設計書更新手順や変更履歴の書き方も以下のようにSteeringに含めることで、実際のプロジェクトでありがちな設計書と実装の乖離を防ぐことを実現しました。

テスト仕様書の作成・更新手順

テスト仕様書のテンプレートファイルを参照し、設計書通りに実装されていることを担保するテストケースの作成手順を整理したSteeringファイルを作成しました。
テストに関しても設計書と同様に、テスト仕様書の標準テンプレートやAPIテスト/画面テストといったテスト工程ごとにチェックするべき観点が社内の標準として整備されています。
そのため今回の検証では設計書と同様に、テストに関する標準を満たすテスト仕様書の作成手順およびテストケース作成時のポイントを以下のようにSteeringに整理しました。

また、テスト実行時に利用するテストデータも作成するようにSteeringに記載することで、テストケースと合わせてテストデータが自動で作成されテストの効率化および品質の向上を実現しました。

これらのようにドキュメントの標準を満たすためのSteeringを作成することで、実際のプロジェクトで作成した成果物と同等の品質の高いドキュメントアウトプットを実現しました。
実際にKiroにより作成されたドキュメントについては次回の記事でご紹介します。


Steeringが効果的なのは、「AIは一般論に引っ張られやすい」という性質への対策です。
プロジェクト固有のルールややり方がある場合、Steeringに明示しないと一般的なベストプラクティスを基に成果物を作ってしまい、手直しが必要になる可能性があります。
Steeringは、いわばKiroと人との間の「共通言語」であり、開発を開始する前に整備するのが望ましいと考えています。

まとめ

SpecsとSteeringを中心にKiro開発の具体的な流れについてご紹介しました。
これらの機能を使いこなすことで、品質を保ちつつ生産性を大きく向上させることが可能になります。
次回の記事では、実際にKiroで作成したドキュメントのご紹介、さらにKiroの有用性および課題について深掘りします。