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
0
110
20201008_ファインディ_品質意識を育てる役目は人かAIか___2_.pdf
ファインディ株式会社(イベント資料アップ用)
October 08, 2025
Tweet
Share
More Decks by ファインディ株式会社(イベント資料アップ用)
See All by ファインディ株式会社(イベント資料アップ用)
E2Eテスト設計_自動化のリアル___Playwrightでの実践とMCPの試み__AIによるテスト観点作成_.pdf
findy_eventslides
0
110
コンテキストエンジニアリングとは? 考え方と応用方法
findy_eventslides
4
890
非エンジニアのあなたもできる&もうやってる!コンテキストエンジニアリング
findy_eventslides
3
910
大規模アジャイル開発のリアル!コミュニケーション×進捗管理×高品質
findy_eventslides
0
1.5k
アジャイル人材育成を現場業務と”シームレス”に直結 - DX銘柄に4年連続選定される 旭化成のDX人材育成戦略 -
findy_eventslides
0
110
デジタル時代における製造業の変革~ダイキン工業におけるデジタル人材育成の現状
findy_eventslides
0
150
HCP Terraformで品質を極める 自動化推進チームの実践ガイド
findy_eventslides
0
100
Other Decks in Technology
See All in Technology
LLMアプリケーション開発におけるセキュリティリスクと対策 / LLM Application Security
flatt_security
7
1.8k
Goに育てられ開発者向けセキュリティ事業を立ち上げた僕が今向き合う、AI × セキュリティの最前線 / Go Conference 2025
flatt_security
0
350
BirdCLEF+2025 Noir 5位解法紹介
myso
0
190
PLaMoの事後学習を支える技術 / PFN LLMセミナー
pfn
PRO
9
3.8k
"複雑なデータ処理 × 静的サイト" を両立させる、楽をするRails運用 / A low-effort Rails workflow that combines “Complex Data Processing × Static Sites”
hogelog
3
1.9k
Pure Goで体験するWasmの未来
askua
1
170
ACA でMAGI システムを社内で展開しようとした話
mappie_kochi
1
250
関係性が駆動するアジャイル──GPTに人格を与えたら、対話を通してふりかえりを習慣化できた話
mhlyc
0
130
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
11
77k
許しとアジャイル
jnuank
1
120
BtoBプロダクト開発の深層
16bitidol
0
260
AI時代だからこそ考える、僕らが本当につくりたいスクラムチーム / A Scrum Team we really want to create in this AI era
takaking22
6
3.3k
Featured
See All Featured
Building Better People: How to give real-time feedback that sticks.
wjessup
368
20k
VelocityConf: Rendering Performance Case Studies
addyosmani
332
24k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
358
30k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
132
19k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
30
2.9k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
12
1.2k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
285
14k
Fantastic passwords and where to find them - at NoRuKo
philnash
52
3.4k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
19
1.2k
Build your cross-platform service in a week with App Engine
jlugia
232
18k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
35
3.2k
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.2k
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が、エンジニアリングへの思いをこめて書いています。 ぜひご一読ください!!!