20201008_ファインディ_品質意識を育てる役目は人かAIか___2_.pdf

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