前回まででspeckitの導入と、プロジェクト固有の原則ファイルまで作成しました
今回は導入したspeckitを利用して、実際にSDDの手法を用いて新機能を開発してみたいと思います
追加機能の概要
今回追加する機能は「地図上のマーカーに、吹き出しで投稿内容を表示する」改修になります
現在、地図上のマーカーをクリックしないと投稿内容が確認できませんが、マーカーに吹き出しを追加して開く前にある程度どのような投稿内容か把握できるようにするのとともに、見た目にも楽しくしたいという狙いがあります
SDDを用いた開発の流れ
/speckit-specifyで仕様書のドラフトを作成
antigravityのチャット欄で以下のコマンドを実行しました
この段階では詳細な技術スタックは記載せず、「何を作るか、なぜ作るか」に焦点を当てて要件を記載します
/speckit-specify 地図上に表示されているマーカーに、投稿内容の先頭8文字だけ表示する吹き出しを追加します。現在はマーカーをクリックしなければ投稿の内容は確認できませんが、投稿されたメッセージの先頭8文字だけを吹き出しとして表示することで、ユーザーに投稿内容の雰囲気を感じ取ってもらうほか、見た目的にも楽しくなるような効果を期待しています実行後、仕様書のドラフト、品質チェックリストが作成され、いくつか追加で質問が生成されました
質問に答えると、仕様が確定し次のステップに進むか促されます
ただ、触れられていなかった機能があり、その部分が気になって質問してみました
自分のWebアプリには「クラスター機能」が含まれており、地図が縮小されるとマーカーがまとまって表示される仕様になっていて、その場合の吹き出しの処理を聞いてみました
動作が確認できました
今回は自分の考えと、AIエージェントの考えが一致していることが確認できたので、仕様書に追記し次のステップに進むことにしました
speckit-planで技術スタックを指定する
ここでは「どうやって作成するか」に焦点を当てて指定します
ただ、今回は機能改修であり、技術スタックはすでに決まっているため、逆に「何も導入しないで」という指示にしました
/speckit-plan 今回の機能改修では既存の技術スタックのみで開発可能なため、新規のフレームワーク、ライブラリは追加しないでください
speckit-tasksでタスク分解を行う
speckit-tasksを実行すると、実装に向けたタスク分けが作成されます
/speckit-tasks 
生成されたファイルはフェーズ分けされて記載されていました
speckit-implementで機能を実装
※本来はimplement実行前にanalyzeを実行して、仕様の整合性を確認することが推奨されます
今回の実践編では、実行順序を間違えています
今まで作成した設計書を元に実装を行います
/speckit-implement
実際にテストしてみるとアイコンに吹き出しが表示されましたがマーカーと丸かぶりしていたため、少し調整して完成としました
speckit-analyzeでサマリーを作成する
※antigravityのモデルクォータを使い切ったので、ここからはローカルLLM + OpenCodeで作業しています
実装まで完了したのでアナライズを実行してサマリーを作成します
ちなみに、本来の順序ではtasks生成後に実行し、implementを実行する前に整合性を確認することが推奨されるとのことでした
/speckit-analyze
仕様書の重複表記や改善案が提示されています
Recomendationを参考に、生成されたドキュメント類を修正するのが良さそうですね
今回はNext Actionで表示された改善推奨、spec修正推奨だけ反映することにしました
↓
implement実行後の作業
implement実行まで完了すれば、実際に動作する状態になっているはずです
テスト環境を起動して、想定通りの動作になっているか確認します
ローカルで実行した結果、マーカー部分にきちんと吹き出しが表示されました！
E2Eテストを実施したところ、パスできない項目がありました
自分のアプリの場合、テスト側が間違えていたのでテストコードを修正する必要がありました
この用にimplement後は各種テストの実施や、実際の動作確認を行い仕様漏れやバグの修正を繰り返して、機能を仕上げていきます
付録：AIエージェントを切り替える場合
今回、antiigravityで開発していた環境から、OpenCodeを利用した環境に切り替えました
途中でAIエージェントを切り替える場合は、プロジェクトルートで以下のコマンドを使用して切り替えます
利用可能なエージェントの一覧
specify integration list切り替え
specify integration switch opencodeopencodeはマルチインストールに対応していなかったため、antigravity用の設定が削除され、新たにopencodeがインストールされる形になりました
以上
ということで、仕様駆動開発実践編として、アプリへの機能改修を例に実行してみました
仕様を事前にAIエージェントと決めることで、以下の利点なありました
・どのような実装が行われるのか明確になる
・仕様が文書として残る
・エージェントを途中で交代しても、作業を引き継げる
一方でこのような問題も感じています
・今回のような小規模の改修ではオーバースペック
・スキーマ駆動開発も取り入れているため、仕様書が散らばる可能性がある
・コードレビューを行わないと、仕様書は残るがコードレベルで実装がブラックボックス化される
・仕様書はGitで管理されるため、プロジェクト固有のドキュメントルールに沿わない可能性がある(例えば、仕様書をGoogle DocやNotionで管理している場合など)
個人としては、今後は仕様駆動開発を取り入れていくつもりですが、「銀の弾丸は無い」と言われるように、仕様駆動開発を取り入れれば、AIエージェントを利用した開発が全てうまくいくわけでもないということがわかりました
今後も新しい開発手法を試しつつ、品質の良いソフトウェア開発ができるように色々試していきたいですね
