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
SOC2取得の全体像
shonansurvivors
1
370
ACA でMAGI システムを社内で展開しようとした話
mappie_kochi
1
250
Exadata Database Service on Dedicated Infrastructure(ExaDB-D) UI スクリーン・キャプチャ集
oracle4engineer
PRO
2
5.4k
pprof vs runtime/trace (FlightRecorder)
task4233
0
160
PLaMo2シリーズのvLLM実装 / PFN LLM セミナー
pfn
PRO
2
970
Trust as Infrastructure
bcantrill
0
320
Goに育てられ開発者向けセキュリティ事業を立ち上げた僕が今向き合う、AI × セキュリティの最前線 / Go Conference 2025
flatt_security
0
350
AI駆動開発を推進するためにサービス開発チームで 取り組んでいること
noayaoshiro
0
150
いまさら聞けない ABテスト入門
skmr2348
1
200
SREとソフトウェア開発者の合同チームはどのようにS3のコストを削減したか?
muziyoshiz
1
100
SwiftUIのGeometryReaderとScrollViewを基礎から応用まで学び直す:設計と活用事例
fumiyasac0921
0
140
20250929_QaaS_vol20
mura_shin
0
110
Featured
See All Featured
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
2.6k
The Cult of Friendly URLs
andyhume
79
6.6k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
How GitHub (no longer) Works
holman
315
140k
Measuring & Analyzing Core Web Vitals
bluesmoon
9
610
Fireside Chat
paigeccino
40
3.7k
The Power of CSS Pseudo Elements
geoffreycrofte
79
6k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
Building an army of robots
kneath
306
46k
Build your cross-platform service in a week with App Engine
jlugia
232
18k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
A designer walks into a library…
pauljervisheath
209
24k
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が、エンジニアリングへの思いをこめて書いています。 ぜひご一読ください!!!