Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
20201008_ファインディ_品質意識を育てる役目は人かAIか___2_.pdf
Search
ファインディ株式会社(イベント資料アップ用)
October 08, 2025
Technology
3
710
20201008_ファインディ_品質意識を育てる役目は人かAIか___2_.pdf
ファインディ株式会社(イベント資料アップ用)
October 08, 2025
Tweet
Share
More Decks by ファインディ株式会社(イベント資料アップ用)
See All by ファインディ株式会社(イベント資料アップ用)
Findy Team+ QAチーム これからのチャレンジ!
findy_eventslides
0
530
E2Eテスト設計_自動化のリアル___Playwrightでの実践とMCPの試み__AIによるテスト観点作成_.pdf
findy_eventslides
3
710
コンテキストエンジニアリングとは? 考え方と応用方法
findy_eventslides
4
1k
非エンジニアのあなたもできる&もうやってる!コンテキストエンジニアリング
findy_eventslides
4
1k
大規模アジャイル開発のリアル!コミュニケーション×進捗管理×高品質
findy_eventslides
0
1.6k
アジャイル人材育成を現場業務と”シームレス”に直結 - DX銘柄に4年連続選定される 旭化成のDX人材育成戦略 -
findy_eventslides
0
110
デジタル時代における製造業の変革~ダイキン工業におけるデジタル人材育成の現状
findy_eventslides
0
170
HCP Terraformで品質を極める 自動化推進チームの実践ガイド
findy_eventslides
0
110
Other Decks in Technology
See All in Technology
RemoteFunctionを使ったコロケーション
mkazutaka
1
110
ローカルLLMとLINE Botの組み合わせ その2(EVO-X2でgpt-oss-120bを利用) / LINE DC Generative AI Meetup #7
you
PRO
1
160
20251027_マルチエージェントとは
almondo_event
1
420
初めてのDatabricks Apps開発
taka_aki
1
400
だいたい分かった気になる 『SREの知識地図』 / introduction-to-sre-knowledge-map-book
katsuhisa91
PRO
3
1.4k
AI駆動で進める依存ライブラリ更新 ─ Vue プロジェクトの品質向上と開発スピード改善の実践録
sayn0
1
300
Azure Well-Architected Framework入門
tomokusaba
1
130
OCIjp_Oracle AI World_Recap
shinpy
1
180
現場の壁を乗り越えて、 「計装注入」が拓く オブザーバビリティ / Beyond the Field Barriers: Instrumentation Injection and the Future of Observability
aoto
PRO
1
590
組織全員で向き合うAI Readyなデータ利活用
gappy50
0
280
AI-Readyを目指した非構造化データのメダリオンアーキテクチャ
r_miura
1
320
Dify on AWS 環境構築手順
yosse95ai
0
130
Featured
See All Featured
XXLCSS - How to scale CSS and keep your sanity
sugarenia
249
1.3M
Measuring & Analyzing Core Web Vitals
bluesmoon
9
640
We Have a Design System, Now What?
morganepeng
53
7.8k
What’s in a name? Adding method to the madness
productmarketing
PRO
24
3.7k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
52
5.7k
Side Projects
sachag
455
43k
Music & Morning Musume
bryan
46
6.9k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
9
1k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
48
9.7k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
190
55k
Product Roadmaps are Hard
iamctodd
PRO
55
11k
Agile that works and the tools we love
rasmusluckow
331
21k
Transcript
「品質管理ヨロ」 と言わせないために 努力している話 2025年10月8日 星野リゾート 情報システムグループ 寺田 厚
国内外70施設以上を運営する ホテル・旅館の運営会社 北米進出 自然観光 通年採用 続く開業
全社イベント “Annual Message 2024” • 既存のホテル運営 の仕組みに限界がある • 異なるシステムの仕組みを、何とか繋いでいる •
顧客の選択肢を狭めてしまっている 「思い描くことが、 思い描くように、 やろうと思えばできる」 この仕組みが何としても必要なのだ!
よし、内製開発しよう Hoshino Resorts Operation Platform 4
今回は、HOP4プロジェクトの中の、あるチームの話 ReCX たびでこ ACCO たび予約 たびなか たび ざいむ 顧客向け予約 マーケティング
マーケティング 財務管理 サービスチーム (現地スタッフ) 統合予約 (カスタマーサポート) どのチームも、だいたい同じ 規模感: PO: 1, 2名 DEV: 5名程度(パートナー多め) SM: 1名弱 採用技術: Java, SpringBoot, Vue3, Nuxt, PosgreSQL, Rabbit MQ, AWS, DDD スクラム実践: 伸び代しかない
弊社、ITが本業じゃない … • 開発チーム以外、ほぼ全員が現場スタッフ経験者 • 全員がエンジニアリングを知っているわけではない 「品質管理?作ったエンジニアがやるものっしょ?よろしくー」 …とまでは言われないが、否定はできない現状 *「なんで内製化を判断したの?」は、今回は時間の都合上、割愛いたします mm
もっと知りたい方は:
私たちは、やるしかないのだ 本日の発表では、 • PART1: ここまでにお伝えした背景を踏まえた、私たちの実践を紹介します • PART2: Playwright MCPの実践を紹介します
私たちは、やるしかないのだ 私たちの実践を紹介します
・PBIの受け入れ条件には操作手順を書きましょう
・テストシナリオにも操作手順を書きましょう
・テストレポートを見ましょう
・リリース条件にしましょう 1スプリントに1回実施
もしかして「そんな時間 POにないぜ」って思いました? • プロダクトの具体を知らずに、PBIの優先順位を付けられますか? 手順が違えば、”ハナシ”はだいぶ変わってくる • 開発者に”依存”していませんか? POは”ステークホルダーの御用聞き ”や、”開発チームの調整さん ”になっていませんか?
• お仕事の断捨離、できていますか? 「いま」「あなたが」真にやるべきことはなに? スクラムマスターとして 頑張ってます
段取りまとめ PBIに 操作手順を明記 テストシナリオに 操作手順を明記 シナリオを e2eテストとして実装 (適宜、機能を改修) 「手順通りの実装で テストしたこと」
を確認してリリース 私はPOとして 「お手本」を作っています 私はQAエンジニアとして 作っています 私はDEVとして 最初の導入やりました 私はSMとして 説得 / 整理しました
そうすれば、 • 仕様の解像度が上がります ◦ 仕様のムリ・ムダに気づけます ◦ 仕様の変化に対するコストに気づけます • 操作手順の再利用で、効率が上がります •
動画は仕様の確認にも使えます(マニュアルにも使う想定) • e2eコードにスクリーンショットを仕込めばVRTもできます
この実践の基底にある、たび予約チームの考え方
POは、 ・仕様を決める ・受け入れ条件、期待値を知っている ・テスト結果をもとに判断する ならば、 ・テストケースはPOが管理できるはず ・開発者はテスト結果をPOに届けるべき *「委任」しても、いいんだよ!(責任はとってね!) 品質管理は POのもの
POに届けたい! だから、「カバレッジが足りん!あと20%!」 では伝わらんのです…
だから、「このソースをAIが書いてるっ!!」 では伝わらんのです… POに届けたい!
PART1のおわりに : チームが一体となって品質管理をしたい • リスクやコストは”みんなで払う” ◦ POの関心がないことを過度にテストしない ◦ テストを開発チームに任せっきりにしない •
様々なテストレベルを組み合わせて「メッシュ」を重ねる ◦ UT, IT, e2e… それぞれのテストの「べき論」は大事にしたい … でも、リスクとコストに落とし所と覚悟を持てれば良いのでは • チームは「品質が伝わる」ための努力をする • 開発者に、テスト実装の苦労をかけない ◦ 開発に集中できるタスク作り ◦ テストをきちんと評価する
• PART1を踏まえて、こんなチャレンジもしています PART2: Playwright MCPの実践を紹介します https://zenn.dev/hoshinoresorts/articles/89dae203ffab21
MicrosoftのPlaywright MCP…じゃないぞ!
こう使ってます • テストケースをGhekinで書く • AIにテストしてもらう ◦ この時にEAのPlaywright MCPを使っている • 動画も作ってもらう
MCP できること比べ お世話になってます
工夫していること • 英語で書いた方が、結果的にラク ◦ 日本語は文字数が多い “nihonngohamojisuugaooi” + スペースキー押下 ◦ 拙い指示はAIが言い直してくれるので、それを元に改善できる
• CIで継続的に!とかは、あまり目指していない ◦ 30分くらいで終わるテストなら、ローカルで実行すればいい ◦ その頻度のレポートは期待されていない • コンポーネントを指す言葉と、セレクタのマッピングを外部化しています。 ◦ Markdownで管理しやすく ▪ 結局AIだけが使ってる ◦ 「ドキュメントほしい」勢がいたら、渡しておけばいい
たとえばこんなプロンプト : “マッピング ”の外部化 画面を開いて、.featureファイルを読んで、実行に必要なコンポーネントを特定したら、セ レクタとのマッピングをして.mdファイルに出力してください。 ただし、id属性とclass属性を使用しないでください*。 …を、英語で書く(と、修正しやすい) *弊社オリジナルのUIコンポーネントライブラリ(これも内製) ”Fabric”の都合
https://tech.hoshinoresorts.com/design/fabric/
.featureファイル
.mdファイル
適宜、マッピングを更新しています。 例:「1番目」と生成させてから、「X番目」と書き換える
.mdファイルを参考に、.featureファイルを読み1行ずつ実行してください。 操作ごとに、スクリーンショットをとってください。 最後に、ffmpegを使って、スクリーンショットを動画にしてください*。 …を、英語で書く(と、修正しやすい) *動画生成は面倒なので、 DatadogのRUMを使った方が良さそう(いつか検証したい) たとえばこんなプロンプト : テストの実行
こんな未来を目指しています POは、 ・仕様を決める ・受け入れ条件、期待値を知っている ・テスト結果をもとに判断する ならば、 ・テストケースは POも書けますね! ・テスト結果は POご自身で確認できますよ!
*「委任」しても、いいんだよ!(責任はとってね!)
「品質管理ヨロ」 と言わせないために 努力している話 2025年10月8日 星野リゾート 情報システムグループ 寺田 厚 ご清聴ありがとうございました
弊社POが、エンジニアリングへの思いをこめて書いています。 ぜひご一読ください!!!