Vibe Codingと仕様駆動開発、単純比較ではなくユースケースや特性を意識した議論をしようね・・・という話を５分ではなく３分で喋ってきました。

登壇資料

Kiroの Vibe と Spec

Kiro、個人的には課金を継続してもいいかもと思える程度にはよいAIコーディングツールだなと思っています。なによりも仕様駆動開発という名前を、レトロニウムではないかとも言われていますが定義し、それの実践を目指したエディタであるだけあって、Spec（仕様）を作る力はかなり強力だなと思います。

個人開発などが中心の方やジュニアエンジニアの方で「仕様とか要件定義ってどうやるの？」と気になった方はとりあえず無料プランで試してみると、読み物としても面白いかなと思います。「100%これが要件定義や仕様を決めて進める一般的なSDLCだ！」・・・とは言いませんが、それでも未知の世界を「なんとなく見たことがある」レベルにまで引き上げてくれるかなと。

一方で「そんな大袈裟なspec作成は不要。とはいえ変なことをやろうとしていないかチェックはさせろ」と感じることも開発を進めるとかんじることが少なくありません。個人的には、「Vibes / ( Cursor Plan mode) / Spec」のように中間の存在が欲しいかなと思います。今のところは「まずは調査と計画を立てなさい」のような指示をだし、コード生成を行おうとしたら中断させるというワークアラウンドをとっていますが、Vibes / Specの間にある存在が欲しい気がします。

わからないものは作れないし教えられない

t-wadaさんのスライドにも引用があるのですが、生成AIは基本的に知識の増幅器です。そのため自分が知らないことについてAIへ指示を出すことは困難ですし、マージや指摘すらとてもリスキーで負担のかかる作業となります。

ちょっと強引なこじつけかもしれませんが、「既知か未知か」を整理する意味で「ジョハリの窓」という物差しを借りてくることは悪くない選択だと思っています。幸い懇親会でも「あの例えはわかりやすかった」と評価いただくことができていました。

人間が理解していてAIが理解していないなら、MCP / Agent Skillsなどでコンテキストを共有するか、 CI / CD などでルールとして制約を設ける。AIが理解していて人間が理解できていない場合は、とりあえず作らせてみるなり説明させてみることで理解を深めることができる。そしてAIも人間もやるべきことを理解している状態になっているかは、Kiroの Spec などでドキュメントにすることができる。

今の所生成AIを実践投入する際の使い方は、このような「どの窓に位置付けできるか？」を考えながらタスクや役割を委譲することがストレス少なめです。ちなみに一番しんどいのは「言語化できないけど、なんとなくわかっているつもり」という状態で、ほぼ100%生成AIが出すものに満足できません。個人的な意見としては、「言語化できてない時点でジョハリの窓における盲点か未知へ分類せよ」と思っていますので、まずは壁打ちなり言語化のアシストからさせましょう。

変化が激しいからこそ、変わらないものを見定める

LTでジェフ・ベゾス氏の言葉を引用しましたが、「10年経っても変わらないもの」を見定めるのはかなり重要だと思っています。オライリーやそれこそドラッガーから老子まで長く読まれている書籍を読むと、何年前の内容だろうと「これは今でも使えるな」と感じるものが少なくありません。

AIコーディングについても、SDLCやアジャイル・DevOpsやリーンなど様々な考えや概念が根底や前提条件・あるいは基準点として利用されていると思っています。

ツールの使い方に習熟することも大切ですが、どこかで鳥の目虫の目魚の目のように視点や視座を動かして見定めていきたいところです。

余談

タイマーなしで５分間ジャスト喋るの、マジで難しいです。