はじめに
Kiroを使ってオセロゲームをつくってみました。
この作成は、ほぼオセロ作って。というだけで作成され問題なく動作しました。
実際のプロジェクトでは、機能の追加や変更も発生します。
継続して開発を続けられることも大切です。
オセロゲームを改良（2点）しながら、仕様書駆動開発による改善の工程を体験してみました。
UIの改善１
改善点
駒を置くときに、駒の色を次の手番の駒の色にする。
Kiroは仕様駆動開発を前提にしているので、何も言わなくても、仕様、デザイン、タスクを修正してくれるのかと思ったのですが、仕様、デザイン、タスクを大事にするのは最初だけで、このような修正を依頼すると、コード修正に走りました。
コードだけ修正していくと仕様とコードが乖離してしまい、困ったことになりそうです。
なので次のように依頼しました。
Desktop対応は保留にします。次の改良にうつります。こまを置くときのカーソルになっている〇の表示を、手番が黒の時は黒っぽい、白の時は白っぽいいろにしたい。まず仕様、デザイン、タスクを修正して
requirements.mdの変更箇所
妥当な内容になっています。
design.mdの変更箇所（追加）
駒の色を設計に落とし込んだ表現になっています。
task.mdの変更箇所（追加）
設計変更に対応するタスクが生成されました。
盤面にdata-current-player属性を追加する必要があることを設計の内容から判断してタスクが作られています。
## タスクの実行
タスクを実行しました。
テストする部分でブラウザーの起動を試みていましたが、WSLの環境でうまくいかず、テストプログラムで確認する方法に切り替えて進めていました。
実行結果
想定通りのUIに変更されました。
UIの改善２
改善点
駒をひっくり返す動作をアニメーション表示にする
次のように依頼しました。
駒をひっくり返す時に、一瞬で変えるのではなく、0.5秒に1枚で一枚づくひっくり返すようにして。
まず仕様、デザイン、タスクを修正して
アニメーションの処理がどのような実装されるのか、ちょっと興味がありますね。
requirements.mdの変更箇所
要求仕様の中に、アニメーションで表示する事だけではなく、4. 駒の反転アニメーション中、ゲームシステムはプレイヤーからの新しい入力を受け付けてはならない等、付随して必要になる要求が追加されていました。
このような考慮ができているのは、仕様作成にAIエージェントを集中させている効果だと思います。
この例は、単純なので、仕様駆動開発でなくても対処できるかもしれませんが、複雑な場合には、仕様作成に専念できることは仕様駆動開発のメリットだと思いました。
design.mdの変更箇所（追加）
アニメーション部分の設計がどうなったか見てみましょう。
animatingによってアニメーション中を区別し、Process.send_after/3で0.5秒間隔のイベントを送って、flipping_piecesの駒を順に処理していく。ということですね。
方針としてよさそう。
タスクの実行
task.mdにも適切にタスクが作成されました。これを実行してみます。
タスクの実行の様子を見ているとテストが失敗し修正する作業を繰り返していました。
最後まで解決できなかったのは、0.5秒ごとのアニメーションの処理でした。
LiveViewのテスト環境では、Process.send_after/3で送信される非同期メッセージが自動的には処理されず、Process.send_afterの動作も含めたテストがうまくテストできない点でした。
次のアドバイスを与えてみました。
テストでは、0.5秒の遅延を表現する必要はなく、0.5秒ごとに発生するイベントごとに正しい状態になっているかを確認する事でよいのではないか？
このアドバイスでテストプログラムが修正されテスト成功になったのですが、アニメーションの途中が正しいかどうかを検証していませんでした。
アニメーションの途中の過程をしらべるテストはあるか？
この問いに対して、急いで、何か作り始めたのですが、筋がよくありません。うまくいきそうになかったので、次のアドバイスをしました。関数型らしいテスト。
途中の状態については、全行程をすべてを検証する必要はなく、ステップｎとステップn+1の一段階を必要な条件について調べる方針でどうか？
このアドバイスで、私の意図をすべて理解しテストプログラムが完成しました。頼もしい。
ここまでできるんだったら、最初からやってよ。とも思いましたが、今のKiroの限界なんだとおもいました。
仕様書への反映
このテストプログラムのことは、Kiroとインターラクティブにやりとりしてソースコードを作成してしまいました。
このテストの方針を仕様書にフィードバックして
とお願いして、仕様書も修正しておきました。
まとめ
- 少ない指示で思ったような改修を行うことができた。
- 機能を追加する時に、仕様変更箇所に注力することで、影響を及ぼす機能をしっかり見直す事ができた
- Kiroは仕様書を最新に保ってはくれない。仕様書の修正は、Kiroに明示的に指示する必要があった
- 非同期な部分のテスト戦略にはアドバイスを与える必要があった。設計段階でこのようなアドバイスを盛り込んで置くとスムーズだったと思われる