実はDay6くらいから熱を出していて、進捗が芳しくないので今実装しながらAIの記事を書いていきます。
📘Spec駆動開発は便利だがそれ一本にはならなかった
Auth機能実装からSpec駆動開発を使っているが、一言で言うとかなり便利で自分好みだった。UIも含めて体験が良かったのでこの段階でのメリットとそれでもClaudeを使うClaude固有のメリットについて話していきます。
🧪Spec駆動開発のメリット:進みの進捗が可視化される気持ちよさ
taskをリスト化してくれることでこのリストが終わったら目標の実装ができる。「OO個あるフェーズのxまで終わったので残りの所要時間は△です」と明確にストーリを話せる。これがSpec駆動開発の気持ちよさであり、１番のメリットなのかなと思いました。
🪡Spec駆動開発のメリット: やってることが細かく丁寧に書かれている
RooCodeのサブタスクもそうなのですが、一番細かいレベルの指示がdesign.mdとtask.mdを合わせると入っているところがかなり嬉しく思っています。特にKiroの場合人間がやるべきE2Eテストの観点がCorrectness Propertiesに記載されており、隙間時間に動作確認するかーという時のチェックリストにも役立ちます。
次やるタスクが明確に言葉になっているとタスクの進みが体感早いので、実装を進める良い補助輪になってるのではないかなと思います。
🤖Vibeのメリット: 何も考えずにエラーメッセージを投げて自律的に解決するのに便利
今回陥ったErrorがロジックというよりフォーマットに依存するエラーが多く、CI回してるフォーマットのエラーを細かい実装方法で投げても仕方ありません。治し方実質フォーマッターのエラーログに書いてあるし。こういう時にエラーログだけ投げて自律的にCIを見に行ったりrulesをさんこうにしてローカルで再現してくれたりするのはVibeでやってもらうことが多いです。
📊kiro固有の良さ: Spec駆動で動かすための体験が良い
「spec駆動のOOやるために何をすればいいんだっけ」と考える必要がないUIでありながら、VSCodeと同じPlaginをいれられるところがかなりKiroやるなぁと思うところです。この、体験の間に「OOするためには」が差し込まれないのは初見のAIだと難しいと思っていて（個人的にClaudeのスラッシュコマンドがとっつきにくいのはこの辺りもあります。）そこをできるだけ少なくする「デザインどこだっけ？」とtask見てる時に思わせなくするさりげない誘導のデザインも込みでかなり体験が良いなと思っています。
🔍Claude固有の良さ: 自律的にGithubを見てくれるようになる
GithubのCIが落ちている系だとどうしてもKiroはそこまで見てくれるほど育ってない(やらないがちなのかも）に比べてClaudeはghコマンドを駆使して自律的にGithubのCI処理やCIログを見に行ってくれるところがストレスフリーで体験がいいなと思います。
🍀終わりに 結局咲くところでそれぞれのAIが咲けばいい
コスト面は高くついてしまいますが、ClaudeCodeとKiroをそれぞれ使いやすいところで使っていく、特にCIのエラーに関してはスポットでClaudeCodeの自立力が役に立ち、ペアプロをやらせるとか開発のタスク分解はSpec駆動開発のKiroが使いやすいなと思いました。
明日こそは、実装を進めていくぞ！
「やだ私のテストカバレッジ....低すぎ！？」ということでテストカバレッジを上げるための記事が書けたら...いいな