スペック駆動開発でQAエンジニアの原点に戻る(QA×生成AI：現場のリアル、みんなで語る交流座談会 Vol.2)

https://zenkigen.connpass.com/event/367566/

1. スペック駆動開発で 

QAエンジニアの原点に戻る 

株式会社SODA 



岡内 佑樹


2. お詫び

・生成AI x QAの各社事例の発表ですが、構想段階で終わっています。 

・ただその中で出てきた副産物について今日は共有をさせてください。 

・それもまた「現場のリアル」ということで何卒お許しください。 


3. 自己紹介 


4. 岡内 佑樹(@okauchiwani)

・株式会社SODA（2023年10月~） 

・テスト自動化やスクラムチーム内のQAを担当 

・カーナビのプログラマーや、テストのSES、 

　事業会社の1人目QAエンジニアなどを経て現職 

・学生時代からゲームのテスターもテスト歴20年以上 

・最近はテックブログ書くようになりました 

　https://zenn.dev/okauchiwani

・最近の趣味は 

　ポケモンカード、散歩（週末10kmぐらい歩いてます） 


5. SNKRDUNKとは
「SNKRDUNK（スニーカーダンク）」は、スニーカーやアパレルを中⼼とするファッショ
ン領域やトレーディングカード‧フィギュアなどを中⼼に、個⼈間での売買を簡単に⾏え る
国内最⼤級のファッション‧コレクティブルマーケットプレイスです。
サービス開始：2018年7⽉
利⽤料：無料
※取引が成⽴すると、⼿数料および配送料がかかります
対応OS：Android、iOS
※Webブラウザからも利⽤可能
スニーカーダンク
取扱商品
フットウェア
スニーカー、シューズ、パンプスなど
トレカ‧ホビー
トレカ、フィギュア、ゲームなど
アパレル
Tシャツ、アウター、キャップなど
ファッション⼩物
時計、バッグ、アクセサリーなど
取引の過程で、運営がすべての商品を確認し、正規品を保証する「真贋鑑定」をおこなっ て
おり、お客さまに安⼼‧安全な取引環境を提供しています。

6. SNKRDUNKの特徴
取引の過程で運営が全ての商品を確認
出品者から届いた商品に問題がないことが確認でき
た時点で、出品者には売上⾦が振り込まれます。
万が⼀、購⼊者から返品希望があった場合にも、運
営と購⼊者でやり取りを⾏うため、出品者での対応
は必要ありません。
スニーカーダンク
スニダンの安⼼‧安全な取引システム
すべての取引が匿名配送
ユーザー同⼠のやりとりゼロ

7. AIプロダクト開発で起こっていること 


8. SODA開発部署で使える生成AIエディタ 


9. SWEの生産性にQAEが追いつけなくなる 

開発エンジニアの生産性は⤴⤴ 

QAエンジニアの生産性は ?????? ⤴

このギャップが 

課題


10. 業務の中でテストの割合が増え、木こりのジレンマに 

（将来的にそうなるかも・・の話です！！） 

テストが終わると、 

次のテストの準備がある 

テストが終わらないと、 

改善が出来ない 


11. QAエンジニアとしてはKIROに注目 ?????? 


12. なぜKIRO？


13. なぜKIRO?

・スペック（仕様）駆動開発のガイドがエディタに標準搭載 



・（スペック駆動開発が進むことで）スペックのドキュメント化が進む 



・受け入れ基準やテスト計画も明文化し、シフトレフトにもつながる 




14. なぜ、スペック駆動開発？ 

・仕様がすべての出発点 

- テストコードや実装よりも先に「どう動くべきか（仕様）」を明文化する。 

・仕様がコードになる 

- 自然言語で書かれた仕様から・実装・テストを一貫させる。 

・誤解を減らし、変更に強くする 

- 仕様ファーストになり、要件変更や新機能追加に強い開発体制を築く。 


15. KIROにおけるスペック駆動開発の流れ 

1. 要件定義(requirements)の作成とレビュー 

2. 設計書(design)の作成とレビュー 

3. タスク分解

4.タスクの実行 


16. KIROにおけるスペック駆動開発の流れ 

1. 要件定義(requirements)の作成とレビュー 

2. 設計書(design)の作成とレビュー 

3. タスク分解

4.タスクの実行 

1で要件とトレースした受け入れ基準が作られるが、 

テスト設計やテスト実装を含んでいない。 

steering（ルール、AIの行動指針）整備をして出力させるようにする。 


17. 日々時間を見つけてはsteeringの整備を進めています 


18. どうなりそう？ 


19. 進めて感じたこと 

・Steeringが整備されることで誰でもテスト設計が出来るように 

-開発者がまずは一歩、テストの領域に挑戦できる 

-Steeringとして残ることで、単純な出力だけでなく課程、頭の中も覗ける 

・組み合わせやパターンを記憶でなく記録に頼れる 

-1プロダクトが大きいものは他チーム開発機能は把握が難しい 

-知識共有は長期的投資、短期的な忙しさによって破壊されやすいプロセス 

・AIも半自動！全自動を夢見すぎない 

-テストケースの元となるCSV出力もカラムがズレること多い 

-E2Eテスト自動化で全自動は出来ないと学習したのにAIへ期待しすぎていた ?????? 


20. ギャップが小さくなれば良いサイクルになる 

開発エンジニアの生産性は⤴⤴ 

QAエンジニアの生産性も⤴⤴ 

ギャップも

小さくなる


21. まとめ

22. まとめ

・QAエンジニアとしてはやっぱりスペックに立ち返りたい 

-その手段としてスペック駆動開発 With KIROが良さそう 

-ただテスト設計やテスト実装に関しては整備が必要 



-スペックがしっかりすることで適切に進められたかも確認しやすい 

-誰でもsteeringを使うことで再現性のある出力が出来る 

-テストパターンを出す時も記録に頼ることが出来る 

・テスト設計の属人性削除 

-結果的に自分の分身を作れる 

-自分がいない時でもテスト設計タスクを開発者が進めることができる