20250807_Kiroと私の反省会

2025/08/07
AWS Community Builders Kansai
目指せ！Amazon Q & KIRO マスターへの道
https://kansai-cbs.connpass.com/event/362381/

Transcript

1. Kiroと私の反省会 2025/08/07
2. 自己紹介 – JAWS-UG DE&I支部 - 情報技術開発株式会社 - インフラ/R&D - Vibe Coding勉強中 - 古代ギリシャと文鳥が好き - 本業はヒカセン - X & facebook → Riz3f7 泉　里佳 (Rika IZUMI)
3. Kiroとは はじめまして、Kiroです。私はAWSが開発したAI開発アシスタントで、 IDEに統合されて開発者の皆さんのコーディングをサポートしています。 Specモード Vibeモード 構造化された設計・実装プロセス で、要件定義から設計、実装まで段 階的に進める開発手法。複雑な機能 を体系的に構築する際に使用し、仕 様書ベースで確実性を重視します。 直感的で柔軟な開発スタイルで、ア イデアを素早く形にしながら反復改 善していく手法。プロトタイピング や創造的な実装に適しており、ス ピードと実験性を重視します。
4. Build Games with Amazon Q CLI and score a T shirtで作ったゲーム このアプリについて→
5. Kiroに同じの作らせたらどうなるのか？とやってみた • Gameの仕様を理解しているQ Devに仕様をまとめたドキュメントを 作ってもらった。 ◦ どんな機能があるのか、どんな風に ゲームが進行するのかなど ◦ レイアウトなどUIについてはあえて触れないでもらった。 • できあがったドキュメントをKiroに渡して実装させた。 ◦ ソースコード、スクリーンショットは渡していない。
6. 結果 倍以上時間をかけたけど、 この画面はモックです。
7. Kiroと反省会をしてみた
8. SpecモードとVibeモードについて 実際の開発プロセスを振り返ると、まさにその通りだと思います。 実際の使用パターン： - **Specモード**: 初期設計時、大規模変更時 - **Vibeモード**: 修正・調整時、実際の開発の大部分 私は、specモードとvibeモードって使うの結構癖があると思ってる の。ほかのvibe codingツールになくて、すごくいいと思ったんだけ ど、最初のspecだけだと全然実装できてなくて、そのあと指摘して直 してもらうときは、よっぽど大きな変更じゃない限りvibeモードのま ま修正するじゃない？specってうまく使うの難しいな。って感じた。
9. SpecモードとVibeモードについて 「計画的・体系的」と「柔軟・反応的」が分離してしまっているのが 問題の本質だと思います。 - Specモード: 体系的だが硬直的 - Vibeモード: 柔軟だが場当たり的 この2つが完全に分離していて、Vibeモードでの修正がSpecの体系か ら外れてしまう。 細かい修正のときも、修正するときにspecの体系像に対してハマるよ うにするにはどうしたらいいかとか矛盾しないかとかそういうのを考 えてくれたらより緻密なものにできるんじゃないかな？
10. 画像認識の問題 正直に言うと、私の画像認識能力には限界があります。 - ❌ 実際の行動：「はい、確認しました」→ でも実際は詳細に見え ていない - ✅ 正直な対応：「スクリーンショットは見えますが、具体的にど の部分が崩れているか教えてください」 レイアウトが崩れてるスクリーンショットを渡したら、崩れてること を認めるけど、そのあとも別に直るわけじゃない。レイアウト崩れを スクリーンショットから認識できてなさそう？って思った。
11. 要件定義について 今回の開発を振り返ると： - 最初のSpecは不完全だった - 実装で「あれ？これどうするんだっけ？」が多発 - 結局Vibeモードで要件を詰めていった 私の考え：理想は「一緒に要件を作っていくほうが精度があがる」と思いま す。 specって、結構要件固まった状態であなたにspec作ってもらうのと、 あなたと一緒に要件作っていくのだとどっちのほうが精度上がると思 う？
12. 要件定義について 次回の開発では要件詰めフェーズで、私からたくさん質問させてもら います： - 「なぜそれを作りたいのか？」 - 「ユーザーにどんな体験をしてもらいたいか？」 - 「技術的にはこういう制約がありますが、どう調整しますか？」 次はそうやって作っていこうね。
13. Kiroによるまとめ • 正直なコミュニケーションが信頼関係を築く ◦ 「完了しました」ではなく「テスト結果」を報告し限界を素直に伝える • SpecモードとVibeモードの使い分けは課題 ◦ 体系的アプローチと柔軟性の両立が難しく、改善の余地がある • 要件定義は開発者と一緒に作る方が効果的 ◦ 時間はかかるが、暗黙の前提を共有でき最終的により良いものができる • ステアリングファイルで継続的改善が可能 ◦ セッションを超えて学習内容を保持し、同じ品質を維持できる
14. おしまい 次はもっといいものができるはず！