こんにちは！クラウド開発事業部エンジニアの岩間です。
今年も早いものでこの時期がやってきました！
ギークフィードメンバーがクリスマスまで毎日ブログを書いていきますので、ぜひ楽しみにしててください。
今年のアドベントカレンダーではとある企画をしました。
その名も【Kiro・Playwright】社内でフルAI開発バトル！！「1行も書かずに」Todoアプリを完成させよです。
今回の企画は、私も所属しているクラウド開発事業部メンバー全員で挑戦してみました。
明日から参加メンバーが実際の体験をブログ投稿していきますのでお楽しみに！
初日の今日はこの企画の目的、背景、ルールについてご紹介します。
目次
企画の背景
昨今生成AIの勢いは凄まじく、多くの企業で業務に活用されています。
ギークフィードでも、事業計画の目標にAIを使った業務効率化を掲げ、メンバー各自が様々なAIツールを使いながら開発に取り組んできました。
しかし、AIを使う中でいくつかの課題も見えてきました。
理解を超えたアウトプット
- AIの実装内容に対しての理解が追いつかない
- 結果、「AIがやったのでわかりません」のような状態になることも
- コードの意図を理解していないため、メンテナンスも困難に
コードの肥大化
- 冗長なコードが量産され、運用保守が大変に
- AIの提案を取捨選択できない
- コードレビューも大変
AIに丸投げ問題
- 目的や意図と理解しないままAIに丸投げした結果、一応動くが何の意味もない成果物ができる
こうした背景もあり、AIを使いこなすエンジニアを目指すべく今回の企画を立ち上げました。
企画の目的
企画を立ち上げるにあたり、AI時代のエンジニアに必要な力とは何か？を運営チームで考えました。
その結果、以下の 3 つの力が重要だという結論に至りました。
1. 隙間を埋める設計力
曖昧な要件（行間）を読み取り、ユーザーにとって最適な仕様を仮説検証する力。
実務では、設計書に書かれていないけれど必要な要件が存在することも多くあります。
思考停止せず、自分で考えるプロセスこそが大事。
2. AIマネジメント力
AIは指示通りに動きますが、指示が悪いと「動くゴミ」を作ってしまいます。
AIの提案を鵜呑みにせず、取捨選択・修正する力が必要です。
- AIのアウトプットを責任を持って説明できる
- 仕様書やテストケース自体が間違っていても気づける判断力
- 人間の役割は「コーダー」ではなく「ディレクター」
- AIは伴走者、助手として活用する
3. 品質への意識
作って終わりではなく、AIを活用してテストまで完結させ、品質を担保する力。
動いていても、保守性やセキュリティが不十分な場合もあります。AIをうまく使って、品質の高いものを作るスキルが求められます。
この企画を通じてAI開発に対しての向き合い方を考えるきっかけづくりや、何より参加者全員が楽しく学び合い、成長することを目的としました。
ルール
今回の企画では、以下のルールを設定しました。画像は実際の企画の説明資料です。
プログラミング禁止
エディタで直接コードを書く・修正することを禁止としました。
また、AIは自ら考えるきっかけを持ちません。問題設定は人間側の仕事であり、これこそがAI時代のエンジニアに必要なスキルだと考えました。
Spec 駆動開発のみ
vibe codingは禁止としました。
必須ツール
- Kiro
- Playwright MCP
普段メンバーは各自別々のツール（Claude Code、Gemini CLI など）を使っていますが、Kiro を使っているメンバーからの評判が良く、全員で一度触ってみる良い機会だと考えました。
お題
今回のお題は、意図的にふわっとした依頼にしました。
曖昧な要件で、とりあえず動くものを早く作って欲しい。実際の現場でありそうな状況を想定しています。
開発する中で「ここの前提がわからない」「このケースは想定しているか？」など、設計起点の問いが生まれることを期待し、あえて考える余白を残しました。
提示したお題は以下の画像の通りです。
例えば、これをAIに丸投げした場合、以下のような判断が必要になります。
- タスク完了時の挙動
完了したタスクはどうなるべきか？要件には書いていません。
線が引かれて残るのか？画面から消えるのか？「完了済みリスト」タブに移動するのか？など検討余地が生まれます。AIに任せると、単に削除してしまう実装や逆に複雑なアーカイブ機能を提案してくることがあります。 - 「今日やること」の定義
「今日やるべきこと」とありますが、期限が今日のものか？期限がまだ来ていないが今日中に片付けたいタスクすべてを指すのか？
また、要件には日付機能の記載がありません。
明日以降のタスクは登録できないようにするのか？日付が変わったら、前日の完了タスクはどうなる？ リセットされる？
ここを Local Storage で実装する場合、データ構造をどうするか（単なる配列か、日付キーを持つオブジェクトか）で、後々の拡張性が変わります。
ここで試されるのはまさに先述の隙間を埋める設計力、AIマネジメント力、品質への意識です。
なお、進め方の基本方針は以下としました。
- 必要最小限の要件を渡し、参加者は自由に解釈してアプリを作る
- UI のデザインやレイアウトは自由
- 必要と思った機能は各自で判断して実装可
追加要件
実際の現場では、後から要件変更が入ることもよくあります。
よりリアルな状況を体験してもらうため、開始1時間後に以下の追加要件をアナウンスしました！
- 間違ってタスク完了してしまったときのために、元に戻す機能
キタぞ…的な声もあり、会場（？）がざわざわしたのではないかと思います。
質問について
仕様についての質問は、Slackのワークフロー経由で個別に回答するルールとしました。
全員に回答を公開すると、全員が同じ仕様のアプリを作ってしまうのではという懸念がありました。
また、運営チームが質問に答える際の判断基準として、架空の現場リーダー「佐藤さん」のペルソナも設定しました。
佐藤さんのペルソナ
- 現場のリーダー 佐藤さん
- 面倒くさがり。細かい設定画面は嫌い。とにかくワンクリックで済ませたい
- 「シンプルでいいよ、シンプルで」が口癖
- 複雑な階層構造、ログイン必須化はNG
運営側のチェック観点
企画のアウトプットを、どういった観点でチェックべきか？運営チームで悩みました。
結論として、今回の企画ではあえて正解となる仕様を用意しませんでした。
正解を用意してしまうとAIの良さが活かせません。
もしAIが良い提案をしてきても、正解の仕様と違うため運営側では NG と判定せざるを得なくなります。
そのため今回の企画では、以下のポイントに注目することにしました。
- 必須機能が実装されているか
- 「行間」をどう解釈し、判断したか
- AIをどう活用したか（指示の出し方、対話のプロセス）
- UI の工夫や使いやすさへの配慮
- テストの充実度
事前準備
事前準備として、参加メンバーにはKiroのインストールとPlaywright MCPのセットアップをお願いしました。
運営側では質問受付用のSlack ワークフローを作成しました。
当日の様子
企画当日は3時間の枠を確保し、普段リモートワークのメンバーが多いのでオンラインMTG上に対象者全員集合してもらいました。
ただ、オンラインMTGだけだと盛り上がりにくそうだったため、ワイガヤ/雑談/進捗共有などはSlackに集約し、
オンラインMTGで黙々と作業しつつSlackでは盛り上がるという、ハッカソンっぽい雰囲気になるように工夫しました。
3時間の中では企画説明、アプリ開発、そして開発の過程をブログを書いてもらいました。
タイムスケジュール
- 14:00 説明開始
- 14:20 ゲーム開始
- 15:00 追加要件発表
- 16:00 質問締め切り
- 17:00 ゲーム終了
参加レポお楽しみに！
明日からのアドベントカレンダーでは、参加メンバーが実際の体験をブログを投稿していきます。
曖昧な要件から、どんな判断をし、AIにどんな指示を出し、最終的にどんなアプリを作ったのか、メンバーそれぞれの視点から語ってもらえます！
こんな方におすすめです。
- AIを使った開発に興味がある方
- AI時代のエンジニアスキルについて考えたい方
- Kiro の実践的な使い方を知りたい方
ぜひ、明日からのブログをお楽しみに！
- 【Kiro・Playwright】社内でフルAI開発バトルを企画した話〜ルール説明編〜 - 2025-12-01
- ロングネイル女子エンジニア、筋トレとピラティスで最強になった話 - 2025-08-26
- 取引先から最短距離にいる担当者へメール通知する仕組みをSalesforce Apexで実現してみた〜後編〜 - 2025-05-28
- 取引先から最短距離にいる担当者へメール通知する仕組みをSalesforce Apexで実現してみた〜前編〜 - 2025-05-23
- Amazon PollyのSSMLを使って日本語のイントネーションを自然にする - 2025-05-07
【採用情報】一緒に働く仲間を募集しています
