どうもこんにちは、Infrabbitです。
しばらく前にkiroが発表され、速い方はさっさと試していて、あちらこちらからKiroすごいよ、とかいいよ、なんて話が聞こえてきていました。
まあうちも少し前にJoinリクエストを送って、Kiroを入れて、いろいろいじくり倒していたわけです。
ただ、Kiro Proだとあっという間にViveを使い切ってしまうので、とりあえずQ Developer Proで使用してみている感じですね。
まずKiroとは何か、という話ですが、要するにVSCodeです。VSCodeのCopilotの部分が、ごっそりAWSさんのKiroエージェントに置き換わっている、VSCodeのフォークプロジェクトですね。
なので、これまでVSCode使用していた方なら、なんの違和感もなく乗り換えられます。
Copilotなんかとおしゃべりしながらコードを作成し、プロダクトを作っていくのをViveコーディング、なんて言います。日本語だと雰囲気コーディングとかいうことになるらしいですが、要するにふわっとしたイメージを伝えて、それをコードに落とし込んでもらう、みたいなものです。
もちろん、できたコードは完全とはいいがたいし、そのまま使えるとも限らないわけですが、そのデバッグもまたふんわりコーディングしながらデバッグしていける、とあって趣味プログラミングではいかんなくパワーを発揮します。
さてそんなCopilotさんですが、ChatGPTだと結構アホ、というかコード全体をあまり見ません。まあこれはIssueをもとに駆動するイメージなので、コード全体を作る、というのは実は結構苦手なんだろうな、と思っています。
一方でLLMのモデルをClaude 4とかにすると、結構コード全体やドキュメントをさらって、仕様に合わせて作ろうとしたりします。とはいえ、あくまでViveなので雰囲気に流されやすく、仕様をちゃんと見てくれる時もあれば、さらりと無視されることもあったりするので、明示的に～～を見て書いて、とか言わないといけないことも多いです。
さあ、じゃあKiroはどうなんだ、という話です。
ここで持ち出されてきたのが、「仕様駆動型開発」などというわけのわからん言葉です。いや、言葉はわかります。仕様をもとに開発する、というウォーターフォール経験者ならば何を当たり前のことを大げさに言ってるんだ、という内容だからですね。
いや逆に当然すぎてなんで言葉としてこんな言葉が出てくるのか、というところがわけわからんわけです。
しかし、CopilotなどがViveコーディングで行っているのは仕様を見たり見なかったり、無視したり無視されたり守られたり、というふわっとした結果が得られるコーディングでした。
それでもそこそこ動くんだからすごいんですが、Kiroがやったことは異質でした。というか、我々インフラ屋やウォーターフォールにどっぷり漬かってきたオンプレ界隈の住人にとって、LLMが一気にステージを引き上げてきた、と実感できるものでした。
と、いうのも、KiroにはViveコーディングだけでなく、Specコーディング、という機構を備えているからです。
これは何か、という話です。
まず、その前にウォーターフォールでの開発を知っておきましょう。クライアントからくっそふわっとした要求が示され、それに基づいて我々は少し抽象度を下げて、でもクライアントの理解が得られる程度のふわっとさの要件整理をしていきます。さらにそれを推し進めて、最終的には要件定義に行きつき、その要件定義から全体設計に進み、詳細設計に入り、開発に入ります。
Kiroに、このくっそふわっとした要求を食わせると、何が起きるか。
詳細設計と最終的な実行計画が現実的な実装タスク単位で分割された実装計画が出てきます。何言ってんだって感じですが、ふわっとした要求をもとに、要件を定めていき、作るべきものの設計が行われ、その結果の実装計画が定められます。
アジャイルなどがもてはやされたのは、短期間のスパンで小さい単位で実装を繰り返していくことで、短い開発サイクルをたくさん回し、小さい変化を起こし続ける、という思想でした。もちろんこれには良し悪しもあり、短期間での実装でバグも生じやすいですし、その取り組みとして、SREなんて考え方やBizDevOpsといった思想も生まれてきました。
これらは、開発サイクルを大幅に短縮させるためには、開発に責任をおっかぶせて見ないふりしていた連中も巻き込んで、チームビルドとして開発だけの責任から、プロジェクトの責任、という形に拡充してきたという良い側面もありますが、同時に巻き込まれるメンバーは増え、この思想を共有できないチームは破綻しやすくもなります。そもそもこれをちゃんと理解できているBizなんてあまりいない。Opsだって結構怪しいんです。
でも、ショートサイクルでの開発、というのはもう世の中の潮流であり、クラウドというインフラレイヤがショートサイクルで提供される以上、Devがショートサイクルを実現できない、というのは致命的、ともいえる問題でもありました。
このようにアジャイル、という仕掛けはよくウォーターフォールとの対比で語られることが多いですが、実際には別にウォーターフォールの対となる概念でもなんでもありません。単にショートサイクルでイテレーションを回し続けるための方法論と思想です。
では一方でウォーターフォールってどうなのかっていうと、そもそもウォーターフォールの開発期間って数年とかいうレベルが当たり前です。アジャイルが対比されやすいのは単にこの期間の違いに主点が置かれていて、もちろんスタイルも違うのだけど、そもそもスタイルというか思想が違うから期間が違うのであって、開発期間が長い短い、みたいな比較ってなんか違うとは思うんですよね。それは結果であって。個人的にはキリスト教と仏教どっちが優れていますか、みたいな会話にしか聞こえない。
正直バカバカしいとさえ思う。いいとか悪いじゃなくて、このプロジェクトにはどちらが適しているか、であろうと思う。だから全部アジャイルでやろうとするのはバカだと思うし、じゃあなんでもウォーターフォールでやりゃいいって話でもない。
というかたまにウォーターフォールで開発された成果物をアジャイルでひっかきまわしてるケースもあって、何やってんだと思うこともある。もちろんその逆もあり得るんだけど、そもそもアジャイルで作ってきたものをウォーターフォールで改修とかしようとしたらたぶん要件定義の時点で客が逃げるだろｗ ウォーターフォールが介入する時点でスクラップ＆ビルド前提だろうしね。
これは、Webの世界ではまったく相手にもなりませんが、基幹システムなんかの開発ではウォーターフォールでなければならない、といった理由が多々あります。そもそも基幹系にアジャイルで突っ込んでいく、なんて自殺行為とも言えます。
基幹系、とは要するに各企業でもこれが死んだら仕事が止まる、とか、売り上げが全部飛ぶ、とかそういう場所でお仕事するシステムです。
つまり、これらのシステムに求められるのは「短期間での超速開発」などではなく、重厚で長大で、幾人ものエキスパートが毎週毎週顔を突き合わせて、「本当にこの仕様で作れるか、本当にこの内容の設計で大丈夫か」を何度も何度も議論して、ようやく開発をスタートする、みたいな代物です。
バグが発生することをゼロにはできませんが、「作ってみたけど想定と違ったわー」とかいうことはそれだけでウォーターフォールでは数か月、へたすりゃ年単位でのロールバックを巻き起こします。普通に賠償責任要求されます。アジャイルではちょっとやってみようか、で済むことが、ウォーターフォールでは必然的に、事前に仮組みしてみたり、ドキュメントを重箱の隅レベルで読み込んだり、ともすれば採用するライブラリのコードを調べてたりします。
よく、安定系のOSディストリビューションであるLTS版のOSのミドルウェアやライブラリのバージョンが古い、とかで開発とは結構やりあったりしますが、そりゃそうです。こういうLTS系のOSというのが長期のサポート期間を持つのは、こういうウォーターフォールシステムのために設計されているからで、アジャイルでショートサイクル回すような環境で、常に最新ライブラリ使いたいんですよ！とかの開発環境とはそもそも設計思想が異なるからです。
そういう環境ならそもそもOSだってショートサイクルでリプレースしたり、ローリングでアップデートしてくれるべきなのに、なんか知らんけどOSだけ別枠扱いされます。それは開発としてずるくない？とも思うので、さっさとそんな環境はコンテナに閉じ込めてコンテナで最新化してね、ということになりますね。というかホスト側に開発のあれこれ要求するのはもう現在ではダサいレベルといってもいいかもしれないですね。責任分離が進んでいます。
さて。
つまり、ウォーターフォールって重厚長大であるがゆえに、変化への対応が非常に鈍い反面、その設計は非常に重厚です。Viveコーディングなどはわりとアジャイル的な雰囲気を醸していて、ふんわりとこれ作ってーみたいな感じで作って、お気軽に構成に手を入れていきます。
じゃあ、Kiroの仕様駆動開発、とは何か。
要するに、このウォーターフォール開発のサイクルを、ウォーターフォール開発のスタイルのまま、アジャイルほどは短縮できないにしても「数年」だったものを「数か月」まで短縮しうる。というのがこのKiroのもたらしたものです。
そして、クライアントの「ふわっとした要求」をより具体的に書ければ書けるほど、Kiroがそこから生み出す設計仕様書は精度が高まっていきます。
えげつないことに、この仕様駆動開発の合間にViveコーディングを挟み込むことだってできるし、途中で仕様変更をかけてしまうこともできます。ウォーターフォールの人間にとって仕様変更、なんて悪夢以外の言葉ではないのですが、それが「ある程度前後の実行計画の中で整合性をもって」要件に組み込みなおされ、仕様が再定義され、計画に修正が入ります。
ここでいう「仕様」とはじゃあ何か、って話なんですが、要するにこれは我々ウォーターフォールにどっぷり漬かってきた人間の今まで見てきた仕様書、とか要件定義、というものと完全にイコールではないものです。
これは、じゃあなんだ、って話ですがViveコーディングのエージェントにこのプロンプトを渡したらこの仕様に沿ったコードが生み出される、というガイドプロンプトにあたるもの、が生み出されていると言えます。
それが、人間にも十分に可読性があり、前後整合性を読み解けるレベルで提供されてくる。これによって、このプロンプトセットは実装をViveコーディングにやらせつつ、一定の「同じような結果」をもたらすプロンプトセットとして提供されるわけです。
そして、我々はそのプロンプトセットに記述された内容を確認し、問題ない、と判断したら実行計画のタスクをViveコーディングに放り込むことで、Kiroがそれを作ってくれる、という仕掛けになります。
もちろん、成果物はレビューされてしかるべきですし、あちこちに人の手を入れるべきところはあります。しかし、それもある程度Viveコーディングでカバーできるし、Viveの中で仕様への追記改変を一定の水準で行うこともできる、というわけです。
これ、結構インパクトが大きくて、ちょっと個人的にLLMを使用した結構複雑なサービスを作ってみてはいるんですが、この規模の開発を個人で容易にカバーしうる、というのがかなりの衝撃です。とはいえ、私はコード読むの嫌いなので、コード品質まではまったく気にしてないですが。
それでも、コード内で効率的ではない動作なんかは実行計画で書かれるテストの中でさくっと判明して、こんなクラス作ったら？とかの相談もしながら計画修正したりできます。
なので、超速開発できるClaudeCodeとかがWeb界隈では結構人気っぽいですが、個人的にKiroはウォーターフォール界隈の方々に触ってほしい。結構な衝撃をうけるんじゃないかと思います。目からうろこ落ちます。
あ、使い方？ 馬鹿みたいに簡単。
KiroにRFPでも食わせときゃ、勝手にrequirement書くから、それ見て修正してdesign作らせる。ここで基本的な設計が書かれてる。RFPの代わりにちょっと真面目に書いた仕様だとか要件だとか作って食わせれば、より精度の高いものが出来る。
あとはtask、と呼ばれる実行計画を作ってもらえば、taskにはStart Taskってボタンがあるからそれを押せばいい。
で、このTaskの実行の際は基本的にKiro（というかバックのClaude）はrequirementもdesignもちゃんと読んで、Taskの定義に従って作ってくれる。別のドキュメントもちゃんと読んでやってほしけりゃTaskに書けば読んだうえでやる。Taskの実行そのものはViveなんだけどプロンプトが仕様ベースでしっかり書かれたものが放り込まれる、というのが人の手でViveしていくのとの大きな違いですね。
この結果、ウォーターフォールでよく見る仕様に基づいた開発、というものが、きわめて短時間で実行され、それによって「その仕様書の持っている問題点」を短期間で明らかにできる。
一発目のrequirementsで完全に成功なんかしないけど、ウォーターフォール的開発スタイルが数週間とかでワンサイクル回せる。そして、その失敗をもとにスクラップ＆ビルドできる。
仕様書の精度高めて、次のサイクルが回せる。重厚長大な仕様設計駆動スタイルで。仕様の欠陥や問題を短期サイクルで回しながら明らかにし、仕様書を大きく精度を上げていき、最終的にアウトプットできる仕様書を作り上げる、というスタイルなのだろうと思います。
思い付きを形にするViveと明確に作りたいものを定めて、そのうえでがっつり作るのをショートサイクルで行えるSpecコーディング。
これは結構なインパクトがありましたね。ぜひ、皆様もいまのうちにKiro触り倒してみてはいかがでしょうか。Copilotにこんな風に指示出せばいいんだ、みたいな発見も多いと思います。
