Slide 1
Slide 1 text
「品質管理ヨロ」
と言わせないために
努力している話
2025年10月8日
星野リゾート
情報システムグループ
寺田 厚
Slide 2
Slide 2 text
国内外70施設以上を運営する
ホテル・旅館の運営会社
北米進出
自然観光
通年採用
続く開業
Slide 3
Slide 3 text
全社イベント “Annual Message 2024”
● 既存のホテル運営 の仕組みに限界がある
● 異なるシステムの仕組みを、何とか繋いでいる
● 顧客の選択肢を狭めてしまっている
「思い描くことが、
思い描くように、
やろうと思えばできる」
この仕組みが何としても必要なのだ！
Slide 4
Slide 4 text
よし、内製開発しよう
Hoshino Resorts Operation
Platform 4
Slide 5
Slide 5 text
今回は、HOP4プロジェクトの中の、あるチームの話
ReCX
たびでこ
ACCO
たび予約
たびなか
たび
ざいむ
顧客向け予約
マーケティング
マーケティング
財務管理
サービスチーム
（現地スタッフ）
統合予約
（カスタマーサポート）
どのチームも、だいたい同じ
規模感:
PO: 1, 2名
DEV: 5名程度(パートナー多め)
SM: 1名弱
採用技術:
Java, SpringBoot, Vue3, Nuxt, PosgreSQL,
Rabbit MQ, AWS, DDD
スクラム実践: 伸び代しかない
Slide 6
Slide 6 text
弊社、ITが本業じゃない …
● 開発チーム以外、ほぼ全員が現場スタッフ経験者
● 全員がエンジニアリングを知っているわけではない
「品質管理？作ったエンジニアがやるものっしょ？よろしくー」
…とまでは言われないが、否定はできない現状
＊「なんで内製化を判断したの？」は、今回は時間の都合上、割愛いたします mm
もっと知りたい方は：
Slide 7
Slide 7 text
私たちは、やるしかないのだ
本日の発表では、
● PART1: ここまでにお伝えした背景を踏まえた、私たちの実践を紹介します
● PART2: Playwright MCPの実践を紹介します
Slide 8
Slide 8 text
私たちは、やるしかないのだ
私たちの実践を紹介します
Slide 9
Slide 9 text
・PBIの受け入れ条件には操作手順を書きましょう
Slide 10
Slide 10 text
・テストシナリオにも操作手順を書きましょう
Slide 11
Slide 11 text
・テストレポートを見ましょう
Slide 12
Slide 12 text
・リリース条件にしましょう
1スプリントに1回実施
Slide 13
Slide 13 text
もしかして「そんな時間 POにないぜ」って思いました？
● プロダクトの具体を知らずに、PBIの優先順位を付けられますか？
手順が違えば、”ハナシ”はだいぶ変わってくる
● 開発者に”依存”していませんか？
POは”ステークホルダーの御用聞き ”や、”開発チームの調整さん ”になっていませんか？
● お仕事の断捨離、できていますか？
「いま」「あなたが」真にやるべきことはなに？
スクラムマスターとして
頑張ってます
Slide 14
Slide 14 text
段取りまとめ
PBIに
操作手順を明記
テストシナリオに
操作手順を明記
シナリオを
e2eテストとして実装
（適宜、機能を改修）
「手順通りの実装で
テストしたこと」
を確認してリリース
私はPOとして
「お手本」を作っています
私はQAエンジニアとして
作っています
私はDEVとして
最初の導入やりました
私はSMとして
説得 / 整理しました
Slide 15
Slide 15 text
そうすれば、
● 仕様の解像度が上がります
○ 仕様のムリ・ムダに気づけます
○ 仕様の変化に対するコストに気づけます
● 操作手順の再利用で、効率が上がります
● 動画は仕様の確認にも使えます（マニュアルにも使う想定）
● e2eコードにスクリーンショットを仕込めばVRTもできます
Slide 16
Slide 16 text
この実践の基底にある、たび予約チームの考え方
Slide 17
Slide 17 text
POは、
・仕様を決める
・受け入れ条件、期待値を知っている
・テスト結果をもとに判断する
ならば、
・テストケースはPOが管理できるはず
・開発者はテスト結果をPOに届けるべき
＊「委任」しても、いいんだよ！（責任はとってね！）
品質管理は POのもの
Slide 18
Slide 18 text
POに届けたい！
だから、「カバレッジが足りん！あと20%！」
では伝わらんのです…
Slide 19
Slide 19 text
だから、「このソースをAIが書いてるっ！！」
では伝わらんのです…
POに届けたい！
Slide 20
Slide 20 text
PART1のおわりに :
チームが一体となって品質管理をしたい
● リスクやコストは”みんなで払う”
○ POの関心がないことを過度にテストしない
○ テストを開発チームに任せっきりにしない
● 様々なテストレベルを組み合わせて「メッシュ」を重ねる
○ UT, IT, e2e… それぞれのテストの「べき論」は大事にしたい …
でも、リスクとコストに落とし所と覚悟を持てれば良いのでは
● チームは「品質が伝わる」ための努力をする
● 開発者に、テスト実装の苦労をかけない
○ 開発に集中できるタスク作り
○ テストをきちんと評価する
Slide 21
Slide 21 text
● PART1を踏まえて、こんなチャレンジもしています
PART2: Playwright MCPの実践を紹介します
https://zenn.dev/hoshinoresorts/articles/89dae203ffab21
Slide 22
Slide 22 text
MicrosoftのPlaywright MCP…じゃないぞ！
Slide 23
Slide 23 text
こう使ってます
● テストケースをGhekinで書く
● AIにテストしてもらう
○ この時にEAのPlaywright MCPを使っている
● 動画も作ってもらう
Slide 24
Slide 24 text
MCP できること比べ
お世話になってます
Slide 25
Slide 25 text
工夫していること
● 英語で書いた方が、結果的にラク
○ 日本語は文字数が多い “nihonngohamojisuugaooi” + スペースキー押下
○ 拙い指示はAIが言い直してくれるので、それを元に改善できる
● CIで継続的に！とかは、あまり目指していない
○ 30分くらいで終わるテストなら、ローカルで実行すればいい
○ その頻度のレポートは期待されていない
● コンポーネントを指す言葉と、セレクタのマッピングを外部化しています。
○ Markdownで管理しやすく
■ 結局AIだけが使ってる
○ 「ドキュメントほしい」勢がいたら、渡しておけばいい
Slide 26
Slide 26 text
たとえばこんなプロンプト : “マッピング ”の外部化
画面を開いて、.featureファイルを読んで、実行に必要なコンポーネントを特定したら、セ
レクタとのマッピングをして.mdファイルに出力してください。
ただし、id属性とclass属性を使用しないでください*。
…を、英語で書く（と、修正しやすい）
*弊社オリジナルのUIコンポーネントライブラリ（これも内製）
”Fabric”の都合
https://tech.hoshinoresorts.com/design/fabric/
Slide 27
Slide 27 text
.featureファイル
Slide 28
Slide 28 text
.mdファイル
Slide 29
Slide 29 text
適宜、マッピングを更新しています。
例:「1番目」と生成させてから、「X番目」と書き換える
Slide 30
Slide 30 text
.mdファイルを参考に、.featureファイルを読み１行ずつ実行してください。
操作ごとに、スクリーンショットをとってください。
最後に、ffmpegを使って、スクリーンショットを動画にしてください*。
…を、英語で書く（と、修正しやすい）
*動画生成は面倒なので、 DatadogのRUMを使った方が良さそう（いつか検証したい）
たとえばこんなプロンプト : テストの実行
Slide 31
Slide 31 text
こんな未来を目指しています
POは、
・仕様を決める
・受け入れ条件、期待値を知っている
・テスト結果をもとに判断する
ならば、
・テストケースは POも書けますね！
・テスト結果は POご自身で確認できますよ！
＊「委任」しても、いいんだよ！（責任はとってね！）
Slide 32
Slide 32 text
「品質管理ヨロ」
と言わせないために
努力している話
2025年10月8日
星野リゾート
情報システムグループ
寺田 厚
ご清聴ありがとうございました
Slide 33
Slide 33 text
弊社POが、エンジニアリングへの思いをこめて書いています。
ぜひご一読ください！！！