QAが障害対応フローを管理している話 / QA engineer is managing the incident response process

2026/7/13 QA Engineer at a Startup 登壇資料

Transcript

1. July 13, 2026 QAが障害対応フローを管理している話 QA engineer at a Startup vol.32
2. 自己紹介
3. 福富 はじめ（ふくとみ はじめ） • 1991年　静岡県生まれ • 2014.04 - 地元の制作会社で SWEになる • 2017.11 - 上京、赤い第三者検証会社で QAエンジニアになる • （なんやかんやあって） • 2024.02 - 株式会社マイベスト (現職) スポーツを TV観戦するのが好きです（海外サッカー、野球が中心です が、最近NBAにも目覚めてしまいました） @FukutomiQA 自己紹介 FukutomiQA FukutomiQA
4. マイベストの紹介
5. あなたは、何かを選択するときに 困ったことはありませんか？
6. 人生は選択の連続でできています。 マイベストは選択をよりよくすることで、ユーザーの生活を豊かにすることに貢献 したいと考えています。 最高の選択体験を 実現する。 私たちのミッション
7. 月間利用者数 3,000 ユーザーの “選択”を サポートするサービス 万人以 上 （2026年1月時点）
8. 選択に資するデータベースを作るために、 ユーザーニーズや利用シーンに合わせて 各領域で専門性を持ったメンバーが徹底検証 を行い、唯一無二のデータベースを制作しています。 商品を自社で購入し、専門性を持ったメンバーが徹底検証 雨傘の検証。送風機を使って「耐風性」を比較 防水カメラの検証。プールを貸し切り、実際に潜って撮影 縦型洗濯機の検証。主要メーカー 7社の中から人気18商品を購入して検証 ヘアアイロンの検証。全商品を実際に使用して違いを検証 チェーンソーの検証。片道 2時間ほどかけて、山奥にこもって検証 電子レンジの検証。実際の使い勝手などをリアルに検証
9. プロダクト組織の紹介
10. About us 開発体制 職種混成で構成され事業課題を扱うプロダクトチームと、専門領域毎の技術・組織課題を扱うイネーブリングチームがあります。 プロダクトチームは、PdM、デザイナーなどと職能横断なチームを構成し、機能開発を行っています。 新規事業 アプリ グロース Frontend Backend SRE QA 開発部 イネーブリングチーム 商品データ PdM デザイナー エンジニア EM プロダクトチーム PdM デザイナー エンジニア EM PdM デザイナー エンジニア EM PdM デザイナー エンジニア EM
11. About us 開発サイクル 定期リリース日を設けず、完成した機能から順次リリースする 継続的デリバリーを行う形で開発サイクルを回しています。開発案件の多くは事業部の要求ですが、出 てきた要求をPdMとエンジニアが一緒に具体化し、完成した変更から順次リリースする形で開発を進めています。 。 要求を具体化するフェーズ フィーチャーを届けるフェーズ 事業部要求 PdM・ エンジニアで 要求整理 要件定義/ 実装方針 すり合わせ フィーチャー 開発 Review環境で 検証 PdM受け入れ リリース 約 13 件 / 1日 💡 定期リリースではなく、完成したフィーチャーから順次リリース
12. About us 全社員を対象とした月額10万円のAIエージェント利用補助制度、エンジニア全員へのCursor / Claude Code / Codexの配布、Devinの利用、Claude Code Actionで のPRレビューなど、積極的に開発にAIを取り入れています。また、プロダクトやオペレーションにも生成AIを組み込んでおり、RAGを用いたAI接客機能のPoCや、 AI/LLMを用いたコンテンツ制作の効率化を進めています。 AI活用 モデル 開発 全社AI活用
13. ひとりめQAとしてやってきたこと
14. ひとりめQAとしてやってきたこと 日々のテスト活動を効率化したいねプロジェクト（仮） マイベストはコンテンツ数・種別が多く、構造が複雑なため網羅的なテストをするのが非常に難しい状態になっている エンジニアとQAで協力しながら、品質とスピードを両立させる仕組みを作る活動をしている E2E自動テストの構築と拡充 Playwrightを利用したE2Eテストを運用中 リリース前に必ず流れるもの、1日1回ステージング環境で流れるものなど、実行されるタイミングに応じてテストの粒度を変えながら複数のテ ストを管理している 障害対応フローの整備、運用管理 障害は起こしたくないけど起こってしまうもの 迅速に対応して影響を最小限にとどめるため障害発生時の対応フローを設け、保守、運用を行っている ミッションの QA活動ヘルプ 普段はプロダクト開発に関わることはないが、新規機能や規模の大きな施策ではミッションに加わってテストマネジメントやテスト設計、実行 を行ったりしている
15. ひとりめQAとしてやってきたこと 日々のテスト活動を効率化したいねプロジェクト（仮） マイベストはコンテンツ数・種別が多く、構造が複雑なため網羅的なテストをするのが非常に難しい状態になっている エンジニアとQAで協力しながら、品質とスピードを両立させる仕組みを作る活動をしている E2E自動テストの構築と拡充 Playwrightを利用したE2Eテストを運用中 リリース前に必ず流れるもの、1日1回ステージング環境で流れるものなど、実行されるタイミングに応じてテストの粒度を変えながら複数のテ ストを管理している 障害対応フローの整備、運用管理 障害は起こしたくないけど起こってしまうもの 迅速に対応して影響を最小限にとどめるため障害発生時の対応フローを設け、保守、運用を行っている ミッションの QA活動ヘルプ 普段はプロダクト開発に関わることはないが、新規機能や規模の大きな施策ではミッションに加わってテストマネジメントやテスト設計、実行 を行ったりしている 今日はこれについて話します
16. Before 障害対応フロー
17. • 障害に気づいたメンバーが連絡 ◦ 大きな障害であれば全社的に連絡するが、小さい障害だとごく一部の関係者にしか通知さ れないこともあり、基準が曖昧になっている • いつも同じメンバーが対応している • 障害履歴はNotionDBを利用してまとめているが、小さい障害だと記入されないこともある ◦ 再発防止策はエンジニアで議論されるが、その進捗は追われていない Before 障害対応フロー
18. Let's 障害対応フロー
19. 障害対応フロー全体図
20. 発生 重要度判断 (P0/P1/P2) Slackスタンプ で報告 〔自動〕連絡 Notion・JIRA コマンダー 指名 暫定対応 ＆リリース 振り返り→ 再発防止 （長すぎるので）障害対応フロー 要約
21. こまかく見ていきましょう
22. P0 緊急 サービス停止／サイト全体崩 れ／金銭・クライアント絡み P1 異常 一部が閲覧不可／主要機能 利用不能 P2 軽微 一部の表示崩れなど、想定 外の動作 障害重要度判断 判断基準に則って重要度を決定する 不具合に気づいたら、まず「即時対応が必要かどうか 」を判断する（マイベストでは即時対応の要否で障害かどうかを決める） 必要だと判断したら障害重要度判断基準を参照し、重要度を決定する 重要度はある程度ざっくりでよく、対応中や後の振り返りで変更することも可能
23. 障害に気づいたら Slackスタンプ 障害に気づいたら、その重要度に応じてSlackのリアクションを付与 する Zapierが重要度に応じて各所に連絡 Zapierを利用し、付与されたリアクションの重要度に応じて自動で各 所に連絡を行う リリース連絡を行うチャンネルにも通知 リリース連絡を行うチャンネルでも @channel をつけて周知し、障害が 解消されるまではリリースを避けてもらうようにしている [自動]各所への障害連絡
24. 参照：インシデントコマンダー業務解説～仕事の流れと必要な資質～ 障害対応の交通整理役を決める 障害対応はやることが非常に多く、また多岐に渡るため全体をコント ロールする司令塔が必要 最初にコマンダーを決めることで指揮命令系統を明確化し、指示をも らったメンバーが迷うことがなくなる コマンダー指名
25. コマンダーの指示に従い、調査！修正！リリース！ 暫定対応 & リリース （マイベストの公式キャラクター　ベスくん）
26. 振り返りは必ず実施する 障害振り返りは必ず実施する 影響範囲や原因をもとに再発防止策を決定 再発防止策は仕組み化できることを原則とし、重要度や原因によっ ては実装しないこともある 障害内容は相談会で共有する 障害の内容は隔週で実施しているエンジニア相談会で共有する 障害報告の内容をAIにまとめてもらって、それを話す感じ 再発防止策実装はトラッキングする 全ての再発防止策には実装期日を設けているので、月に1回程度の 頻度で実装状況を確認する（現状はQAエンジニアの人力で確認して いるので、なんかいい感じの運用にしたい） 振り返り & 再発防止
27. After 障害対応フロー
28. 障害発生数は減っていない 安定して月に5~10件程度の障害が発生している
29. リリースされた PR数が増えているので、相対的には減っている 月間のマージPR数が徐々に増加している
30. 障害対応フローを運用してよかったこと 障害データが蓄積されるので、分析や改善に繋げやすい すべての障害情報をひとつのデータベースに蓄積するようになったので分析が容易になった 月1程度で障害の分析を行い、障害の傾向やテコ入れの要否などを確認している 連絡が漏れない 重要度に応じて連絡を自動化したので、基本的に連絡が漏れることはない 障害が発生したことが全員に伝わるので、「知らないうちに障害があったの？」みたいなことにならない また、Slackにて連絡されるので対応スレも集約できる 若手が障害対応の経験を積める コマンダーから指名で作業依頼するようになっているので、調査 / 修正に若手エンジニアも参加しやすい状況になっている 修正対応だけでなく、原因調査や再発防止策の考案までひと通り経験できるので、現場のエンジニアとして成長しやすい
31. 障害対応フローのこれから 実装済み再発防止策の棚卸しをしたい 当時は最適だった防止策も、時間が経てば最適ではなくなっていくもの 後の負債にならないように定期的に棚卸しをする機会を作りたい 再発防止策の実装状況管理をイイ感じにしたい 現状はQAエンジニアによる人力リマインドがメインになっている 期日はNotionDBで管理しているので、カスタムエージェント等を利用して自動でSlackでリマインドをかけられるようにしたい 障害を減らすことで、メンバーが事業に向き合う時間が増える そうすれば会社のビジョン達成にも早く近づけるはず これからもイネーブリングチームの一員として障害に向き合っていく 障害を減らして、プロダクトに向き合う時間を増やしたい
32. おわりに
33. 2人目のQAエンジニアを募集しています！
34. Recruitment position QAエンジニア 担う役割 • マイベストの国内外プロダクト全体の品質向上をリード • QA業務の改善を通じて、開発組織全体の生産性向上に貢献 • 組織横断で開発チームに入り込み、品質改善を推進 • 品質と開発スピードを両立する仕組みづくりを担う 業務内容 • 開発プロセスの改善（テスト内容レビュー、受け入れ条件整理など） • 障害分析および再発防止のための改善施策立案 • QA支援ツールの開発・導入 • E2E自動テストの構築・運用（Playwright / Detox） • CI/CD環境（GitHub Actions）でのテスト運用 • インシデント対応フローの改善・運用 • AIなど新技術を活用したQA業務の効率化 必須経験 / スキル • WebサービスもしくはモバイルアプリのQA経験（3年以上） • テスト設計・実行・マネジメントの経験 JD URL｜https://open.talentio.com/r/1/c/my-best/pages/120730
35. Appendix
36. 障害重要度判断基準の詳細
37. 障害再発防止策実装優先度
38. 障害っぽい挙動を見つけた時の行動
39. 障害発生時の行動指針
40. 障害分析レポート（一部）
41. Thank you!