【QA Test Talk Vol.8】AI-DLC による Whole Team Approach の加速

Transcript

1. AI-DLC による Whole Team Approach の加速 QA Test Talk Vol.8 株式会社PKSHA Technology AI BackOffice 開発部, QAエンジニア ⾦⼦ 昌永 鵜飼 貴広 2026年8⽉5⽇ © PKSHA Technology Inc. 1
2. はじめに • あらまし ◦ 2023年から QA 活動を開発チーム全体で進める Whole Team Approach を推進 ▪ 分業の QA から協働の QA へ https://voice.pkshatech.com/n/nb9d8c1a7bd15 ◦ AI-DLC によって Whole Team Approach が加速された ◦ 本講演では、その加速を QAE (Quality Assurance Engineer) の視点でお伝えします • プロダクト：PKSHA AI バックオフィス ◦ 社内⽤ヘルプデスク、依頼管理、タスク実⾏からなる SaaS ◦ AI 機能を多数搭載 ◦ 2020年に提供開始し、多数の企業に採⽤され成⻑中 • チーム ◦ PdM, SWE, QAE, SRE によるクロスファンクショナルチーム x 2 ▪ 登壇者2名はこれらのチームそれぞれの QAE ◦ 実験的な機能開発チーム x 2 PdM (Product Manager), SWE (Software Engineer), SRE (Site Reliability Engineer) © PKSHA Technology Inc. 2
3. AI-DLC (AI-Driven Development Life Cycle) とは？ • 開発チームが同期的に AI と対話しながら進める、要求分析‧仕様化‧設計‧テストを 含む⼀連の開発プロセス。モブプログラミングに分類できる。 • Amazon Web Services 提唱, https://github.com/awslabs/aidlc-workflows ◦ 本事例では Claude Code (Opus) から /aidlc コマンドで起動 • 3 フェーズに分かれる。決めたことの変更は可能(例：仕様変更、設計変更)。 Inception Construction Operation ‧要求の仕様化 ‧ユーザーストーリー化 ‧リバースエンジニアリング ‧基本設計 ‧作業(ユニット)順番決定 ユニット毎に ‧詳細設計 ‧コード⽣成 ‧レビュー ‧テスト ‧リリース ‧監視 U1 U2 ‧‧‧ Un 本事例では未実施 © PKSHA Technology Inc. 3
4. Whole Team Approach とは？ • チームメンバー全員が各々の専⾨性を活かしてプロダクトの品質に責任を持つこと • XP(エクストリームプログラミング)に由来し、近年の⽂献でも扱われている プロジェクトの成功に必要なスキルや視点を持った⼈たちをチームに集めること。 これは昔からある「クロスファンクショナルチーム」の考えだ。 エクストリームプログラミング, 2004, 7.2 チーム全体 (Whole Team) アジャイルにおける品質保証は、特定の段階で特定の⼈々のみが取り組むというより も、専⾨家を交えつつ、ロードマップ策定から⽇々のモニタリングに⾄るあらゆる段 階でチーム全体となって取り組む活動となります。 アジャイル品質パターン QA to AQ, 2022, 第1章 QA to AQ の全体像 • サッカーチームが { FW, MF, DF, GK } で構成されるように 開発チームも { PdM, SWE, QAE, SRE … } で構成される © PKSHA Technology Inc. 4
5. AI-DLC の採⽤理由 • チームに知識を貯め、継続的に開発できるようにするため ◦ 問題：最⾼速で初回リリースするだけなら、1プロジェクト1名 + AI でよいが… ▪ 他のエンジニアに知識が貯まらない ▪ 1名では気づけない⼿戻りが終盤に起きうる ◦ 参考：AI-DLCで「ベテランしか分からない」を減らす, PKSHA テックブログ, 2026 ▪ https://zenn.dev/pksha/articles/5c9772c8716803 • 既存の開発プロセスを AI で加速させるのではなく、 抜本的な AI 前提の開発プロセスを志向しているため ◦ 2025年、AIツールが普及した時期では、既存のプロセスをAIで加速させていた ◦ プロセスモデルを変えないと限界があることに気づいた © PKSHA Technology Inc. 5
6. AI-DLC の採⽤基準は⾒込み変更規模(⼤) & プロダクト成熟度(⾼) • ⾒込み変更規模の代表的な特徴 ◦ (⼤)：多数のシステム構成要素、複雑なシステム構成要素を変更 UX‧性能‧信頼性‧可観測性など多様な品質特性の考慮 ユーザーズマニュアルの複数ページを変更 ◦ (⼩)：1⼈、開発チケット1つにおさまる • プロダクト成熟度の代表的な特徴 ◦ (⾼)：1年以上利⽤している顧客が多数、SLA(Service Level Agreement) の範囲内 ◦ (低)：マーケットフィット以前、実験的なプロダクト/機能、SLA の範囲外 • AI-DLC ⼯数割合は 10% ◦ PKSHA AI バックオフィス 開発組織の全⼯数のうち AI-DLC の割合 ◦ AI-DLC 以外の全ての開発業務にも AI は活⽤されている ◦ プロダクト成熟度(低)では、よりアグレッシブなAI活⽤ © PKSHA Technology Inc. 6
7. AI-DLC 採⽤事例 (2026年3⽉〜7⽉) 着手日順 A B C D 変更種別 新機能 新機能 UI リアーキ & 性能向上 新機能 営業日数 (着手～リリース) 26 うち inception 4 81 うち inception 7 51 うち inception 6 36 うち inception 3 人数 5 2-5 3 2-4 ユニット数 6 10 8 8 コード量 +16005 / -489 +37769 / -1484 +83640 / -6138 ※ +15301 / -139 ドキュメント量 +9579 / -0 +76334 / -294 +60384 / -2280 +20130 / -424 ※現時点では旧コードも併⽤しているため 増加量に対して削除量が少ない • 実験ではなく本番リリース済 • PdM, SWE, QAE による協業 • 要求(何をなぜ作りたいか？)は明確だが仕様は未定の状態から着⼿ • ドキュメントの9割は Markdown 形式、Git 管理 • 毎⽇計3時間、オンライン会議 (まれにオフライン) で⼤画⾯を共有 © PKSHA Technology Inc. 7
8. 開発スピード 年あたり⼤規模変更リリース数は 前年⽐倍増の⾒込み • AI-DLC 採⽤開始時期は 2026年3⽉ のため、採⽤前後でも⽐較した ◦ ⽉あたり⼤規模変更数 ：前 0.5 → 後 0.8 ◦ 平均サイクルタイム(営業⽇) ：前 132 → 後 48 (⼤幅短縮) • AI-DLC 単独効果とまでは断定できないが効果⼤と評価 ◦ 4事例のみ、難易度の差、⼈員の差、AI-DLC 以外での AI 活⽤ © PKSHA Technology Inc. 8
9. Inception：要求の仕様化における Whole Team Approach • ✅ [結果] 要求 (何をなぜ作るか？) を全員(PdM, SWE, QAE)で共有した上で開始できた • ✅ [結果] 全員が AI の仕様案に対する意⾒を出し、PdM が決定権を持つようにできた • ✅ [結果] 詳しい⼈が仕様の問題を指摘できた ◦ AI 単独で⾃⼰検出できなかった問題を、⼈間が各事例10件以上指摘 ◦ 特に⾮機能の仕様未定義をリリース直前に埋める修正が事例Aで13件あり 同チーム担当事例Dでは2件に抑えられた • 💡 [発⾒] AI は仕様の問題に気づきづらく、ベテランSWE, PdM, QAEは気づきやすい ◦ 明⽰できなかった要求に対する仕様 ◦ 要求は明⽰されていたが導出されなかった仕様 ◦ ⾮機能 (UX, 性能, 互換性, 信頼性, 可観測性…) の仕様 ◦ 採⽤している技術スタックによる制限 © PKSHA Technology Inc. 9
10. Inception：要求→仕様化の議論例 • PdM : 曖昧な質問には聞き返し、同じ⽂脈で続けて質問できるようにしたい 要求 • AI : 案：回答後に「続ける」ボタンを表⽰し、押されたら会話を継続する 仕様案 根拠：プロトタイプ画⾯、および既存アンケート機能の状態遷移に沿う • QAE : 「続ける」を押さず、そのまま次の質問を打つ⼈が必ずいます。 ⽋陥指摘 その場合も継続にしないと会話が切れます 修正 • AI : 妥当です。任意テキスト⼊⼒でも継続する仕様に改めます ⽋陥指摘 • SWE : ならボタン⾃体が不要では？他チームが管理する中継サーバーと Web フロントが、どちらも変更不要になります 修正 • AI : 確認しました。既存のメッセージ型に載せるだけなので両⽅とも変更不要で ボタンを後から⾜す場合も、当リポジトリ内の作業で完結します • QAE : 継続と終了を、回答⽂のテキスト⼀致で判定していませんか？ ⽋陥指摘 それだとボタンの押下⽂⾔がそのまま検索クエリに流れます 修正 • AI : ご指摘どおりです。⼊⼒種別からサーバー側で判定するよう修正します 決定 • PdM : では「継続促し⽂＋任意テキスト」で決定。ボタンは将来の選択肢に残す 更新 • QAE : 状態遷移表とテスト設計も更新しましょう © PKSHA Technology Inc. 10
11. Inception：開発計画における Whole Team Approach (事例A,B,D) • ⚠[従来] システム構成要素毎に開発して終盤に結合しがち ◦ SWE のみで開発計画を決めがち ◦ QAE が有名な右図を周知してきたが うまくユーザーストーリーを⾒出せなかった • ✅[結果] AI-DLC によりインクリメンタル & イテレーティブに ◦ AI がユーザーストーリー⽣成 (ほぼそのまま採⽤) ◦ PdM, QAE も開発計画に参加したことにより… https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense -of-mvp ▪ 1ユニットに1つ以上のユーザーストーリーを割り当てた (ユニット：AI-DLC における作業単位) ▪ 先にやるユニットは何か？なぜか？を図をもとに決めた ▪ スクラムの1スプリントに1つ以上のユニットを割り当て ユニットの順番図 毎週のプランニングで決めた ▪ ユニット毎にシステムテストするようにした ◦ スプリントレビューにてユーザー視点での価値を確認できることが増えた © PKSHA Technology Inc. 11
12. Inception：開発計画における Whole Team Approach (事例C) • ❌[結果] 1スプリント(1週間)に1ユニットを収めようとしなかった ◦ イテレーティブの意義理解‧習慣づけが浅く、スクラムとの整合を未考慮 ◦ Inceptionで決定したユニットのうち、3ユニットが1スプリントに収まらなかった ▪ 特に画⾯の⼤半を占める2つの主要ユニットは、3〜4スプリントかかった ◦ ユニットが⼤きいため、 AI による⽣成物も増えた ◦ レビューの解像度が下がってしまった ▪ 「⽅針があっているか」、「⼤きく外れていないか」までは⾒られた ▪ 「AIが⾔及していないが必要な仕様」、「エッジケース」はすり抜けた ◦ リリース直前のシステムテストで仕様誤りによるバグが多く検知された • 💡[発⾒]⼤きくても1ユニットが1スプリントに収まるように ▪ AI の⽣成物をレビューで丁寧に読み切れるように ▪ システムテストを完了し、スプリントレビューで報告できるように © PKSHA Technology Inc. 12
13. Construction：設計における Whole Team Approach • ✅AI に設計案を図⽰してもらうことにより、⽇の浅い SWE, 設計機会の少ない QAE も理解→指摘しやすいように ◦ クラス図‧ステートマシン図‧シーケンス図‧ER図… • ✅いずれの事例においても QAE が設計に貢献 ◦ API, 状態遷移, データ構造…について⼀定の知識があり、 AI の補助があれば貢献可能 ▪ 事例B：AI-DLC で⽤いている AI と別モデルを⽤いバグ予測、 その中から確度が⾼いものを指摘 (13件中5件修正) • 例：画⾯はガード有りだが API はガード無し • 例：ログに個⼈情報が残りうる ▪ 事例C：リアーキ前後の状態遷移の違いによる 画⾯更新レスポンスへの影響を指摘 ▪ 事例D：変更必要な他チーム管理コンポーネントの抜けを指摘 • ⼊社3か⽉ SWE では気づかないところをサポート © PKSHA Technology Inc. 13
14. Construction：システムテストにおける Whole Team Approach • ⚠[従来] ⼤規模変更のシステムテストを QAE のみで担当するのは限界なので SWE も担当するように2026年1⽉から推進途中 • 事例 A, B, D ◦ ✅SWE 複数名がテスト実⾏、QAE 1名がテスト設計とテストマネジメント ▪ AI-DLC キットにはシステムテスト⽤のプロンプトがなく QAE が独⾃に追加 ▪ テストベース検索、品質特性考慮、検証/妥当性確認、テスト技法…といった システムテストの重要概念を QAE が SWE に説明し、SWE もテスト設計レビュー ◦ ✅機能仕様の検証なら SWE のみでテスト設計、QAE は⾮機能/妥当性確認 • 事例 C ◦ ✅ A, B, D と同じプロンプトを使い網羅的なテスト設計 → SWEレビューで洗練 ◦ ❌テスト設計するまでもなく簡単に⾒つかるバグが多発 ▪ QAE がテスト、SWE が修正という従来の役割分担をせざるをえなくなった ▪ 仕様や品質特性を網羅するテストが後回しになり、さらにバグ発⾒→修正の遅れ ◦ 💡当該コンポーネントの変更失敗率が⾼いことはわかっていたので(リアーキの理由) それを考慮してテストまで含めた開発計画を⽴てるべきだった © PKSHA Technology Inc. 14
15. おわりに：AI-DLC によって Whole Team Approach が加速された • ❌Whole Team Approach は肯定的に捉えられていたが、習慣化できていなかった • ✅AI-DLC に PdM, QAE, SWE が参加する、と決めたことで急速に解決した • 💡AI-DLC はアジャイル開発の原則‧プラクティスと整合する PdM SWE QAE 得意領域を 適時に発揮 ・要求と仕様の整合性をレ ビューし、仕様の決定 ・Inception, Construction そ れぞれの設計 ・未定義/曖昧仕様の早期指摘 ・イテレーティブ計画による 早期のシステムテスト 新たな プロセスへの 貢献 ・開発計画に参加し、市場要 求とのずれを早期に修正 ・要求の仕様化 ・システムテスト設計/実行 ・AI による図示をもとに設計にも 参加、早期バグ修正に貢献 • 本事例はいずれも PdM, SWE, QAE による協業だが、 今後は SRE, UX Designer, Product Support など他の職種を AI-DLC に加える有効性を模索する © PKSHA Technology Inc. 15