Upgrade to Pro — share decks privately, control downloads, hide ads and more …

標準テストプロセスへの AIエージェント活用の現在地

Sponsored · Your Podcast. Everywhere. Effortlessly. Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
Avatar for Shin Harada Shin Harada
May 21, 2025
760

標準テストプロセスへの AIエージェント活用の現在地

Avatar for Shin Harada

Shin Harada

May 21, 2025
Tweet

Transcript

  1.   2 ◆経歴: • 2021年6⽉〜:freee • 〜22年9⽉:モバイル • 22年10⽉~23年7⽉:会計(インボイス担当) •

    23年7⽉〜24年6⽉:SEQ(Software Enginner in Quality) • 23年10⽉〜24年12⽉:権限基盤管理 • 24年 7⽉〜:統合モジュール(マスタや申請承認基盤な どを担当) ◦ ⾃称社内ジョブホッパー🤙 宣伝の写真、僕だけピザを⾷べてる写真でした...笑 原⽥晋 / harashin QAE Shin Harada プロフィール画像の トリミング⽅法
  2.   3 AIエージェントの状況 • フリーでは現在AIエージェントのcline が全社導⼊されています • AIエージェントCline、freeeはどうやって全社導⼊した? 「標準テストプロセス」とは •

    フリーでは、爆速で⼈材を⽴ち上げたい‧⼈材の流動性を担保するために プロダクトが違っていても横断的にQAプロセスの進め⽅が同じになるように、 アウトプットを標準化した「標準テストプロセス」を導⼊しています。 はじめに AIエージェントCline、freeeは どうやって全社導⼊した? QAのスキルアセスメントシー トを作って適⽤してみた
  3.   4 • AI駆動QAとは ◦ 理想:すべての⼈がAIエージェントを⽤いてテストプロセスを実践することができる ◦ 現状:チーム‧個⼈によってAI活⽤度合いが異なる。 • AI駆動QAチームとは

    ◦ 理想に近づけるために横断的にAI活⽤を推し進めるため横断的な仕組みを作っていく チーム。各チームへのenabling を含む。今のところみんな兼務。 • AI駆動QAの進め⽅ ◦ 理想:すべてのテストプロセスを対象としていきたい。 ◦ 現状:テスト分析とテスト実⾏に関して積極的に進めている。 ▪ なぜ:テスト実⾏‧テスト分析が⼯数がかかっていたため AI駆動QAとは
  4.   5 • 開発プロセスがAIエージェントによって早くなっている。 • 従来通りの標準テストプロセスを当てはめるだけでは、 開発がスケールアウトした場合に品質が追いつかなくなる可能性がある。 • 解決策の⼀つとして、AIエージェントによるQAプロセスを実践することで並列数を担保する。 •

    スキルによってばらつきのあるアウトプットの質を⾼く揃えたい。 ◦ テスト分析やテスト設計などのアウトプットは、担当するQAEのスキルセットに依存する ◦ AIエージェントを活⽤することで、だれがやっても同様に質の⾼いアウトプットになるようにしていきたい。 ▪ AI駆動QAの理想にあった「すべての⼈がAIエージェントを⽤いてテストプロセスを実践することができる」とい うのは、質の⾼いアウトプットが出てくる前提で実現できる。 ▪ ⚠AIエージェントのアウトプットの正確さを理解できるように、組織としてもスキルアップをしていかないとい けない。AI駆動とセットで育成プランも必要。 なぜテストプロセスにAIエージェントの活⽤を進めるのか
  5.   6 • AIエージェントのアウトプット ◦ いきなりDesign Docからテストケースの作成ではなく、 テストプロセスごとに中間⽣成物をアウトプットさせて、ヒトがレビューする⽅針。 ▪ 中間⽣成物は、テストプロセスのある⼯程のinput/output

    になる。 各テストプロセスのinterface の設計にも合わせて取り組んでいる。 ◦ これまでの標準テストプロセスとの違い ▪ freeeにおけるQA業務を改めて⾔語化して、⼈が良い感じにやってる⾏為を精緻にタスク分解しようとしている • AIエージェントのルール ◦ プロダクト横断的なルールとプロダクトごとのルールをそれぞれ指定 ▪ [AI駆動QAチームが担当]ドメインの寄らないテスト分析やテスト設計などの考え⽅を横断的なルールとして指定。 (ドメインに寄らないテストモデリングの考え⽅など) ▪ [それぞれのプロダクトチームが担当]プロダクト個別のテストに必要な情報‧考え⽅は個別で定義。 全体を通した取り組みの⽅針
  6.   8 • レビューが⼤変 ◦ Design Doc を丸ごと読み込ませたりすると、アウトプットの量が多くレビューがしづらくなる。 ◦ アウトプットのフォーマットが複雑だと、利⽤者は考え⽅の違いからレビューに⼿間取る。

    • エージェントに渡すコンテキストの管理が難しい ◦ どこまでAIエージェントにコンテキストを渡すべきか悩ましい ◦ ドメインの知識は必要だけれど、全部インプットするとコンテキストが⼤きい。 • コンテキストがドキュメント化されていない ◦ 現状の仕様がなく、誰かの頭の中に⼊っているといったケースがある。 ◦ そういった暗黙知を⾔語化していく必要性をかなり感じた。 ▪ プロダクトの知識だけではなく、プロセスなどの⾔語化も同様。 実際にやってみて、どう?
  7.   9 • 既存の枠にとらわれない ◦ 現状は、標準テストプロセスの各プロセスをAIエージェントによって置き換えている。 ただAIの進化によって標準テストプロセスそのもののあり⽅も柔軟に変えていく必要がある。 • より上流へのアプローチをする ◦

    標準テストプロセスの中でのAIエージェントのインプットとなる製品要求仕様書、設計書などの情報がより⼤事に なった。 ▪ AI活⽤のためにも根底にある要求‧要件の正確性はより必要になってくる 今度どうしていくか