今日（昨日）の発表資料です
— リナ？ (@____rina____) 2024年10月24日
スライドだと何も伝わらないですが、お気持ちだけ感じ取ってください#JapanTestCommunityhttps://t.co/bnj0Y00CXN
japantestcommunity.connpass.com
これで発表してきました。 資料はこちら
今回のテーマ
今回のお話を受けた後で、「品質文化」がテーマってききました。 品質文化・・・って何？
そしてさらにイベントページを見ると、実践方法について発表すると書いてある。
なるほど（わからん）
ということで、リーディングクォリティを読みつつ そういえば、QAがインシデント対応について発表しているのを見かけたことがないかもなーって思ったので、それをテーマにしました。
実際、以前の職場で私は受託開発がメインだったこともあり、あまりインシデント対応に関わることがなく（会社はサービスも提供していたし、何かあったらエンジニアが対応をしていた） 今の会社ではQAも関わるし、サービスを提供している企業では当たり前かもしれないなぁと思っています。
実は翌月の登壇の方に気を取られてて、こちらはスライドなくてもいいかな・・・と思っていたんですが、それはそれでわからないよなと思って、生成AIにタイトルやアウトラインを出してもらって作りました。
インシデント対応におけるQAの役割
基本的には以下が主なタスクかなと思っています
- 再現手順の確認
- バグトラッキングの登録や更新
- 修正があった場合、そのテスト準備や実行など
他人たちは、思いつくものをあげるとこんな感じが役割になるかなと思っています
- PM: ビジネス観点をはじめとする意思決定や、関係者がインシデント対応者以外にもいる場合その調整、インシデントのファシリテート
- エンジニア：調査、技術的意思決定、修正対応、リリース
- QA：再現確認、テストに関する活動
- CS：お問い合わせ対応、お知らせ送信
今回はそれに、ファシリテートもQAがやってもいいんじゃない？って話をしました。 通常インシデント（本番障害）は、関わるみんな混乱したり慌てていたりやることがたくさんあるかもしれません。 それはQAも同じなんですが、ファシリテートはQAもできるよなって思っています。
関係者が混乱しないための仕組み
私たちの組織では、外部サービス（ツール）を入れることにより、うまくワークできているという話をしました。 もちろん最終的には人に依存するところもありますけど。
インシデント対応はいつどこまでするかが大事
インシデントって極めて優先度が高いものだと思います。 ただし、ここで大事なのは、すべてのインシデントが最優先かどうかはわからない。 その重要性を見極めることが大事です。
とくにエンジニアの場合は、できるうちに全部完了する必要があると思う方もいる印象があります。 これらをいつ、どこまでして、明日どこまでするといったことを状況整理することが大事かなと思います。 そのためのファシリテートをする人がいるのは大事です。
ポストモーテムをすることの大事さ
インシデントの台頭が落ち着いたあとにふりかえりをすることは大事です。
- 再びその状況をおこさせないための仕組み
- 再度同じことがおこってもいいための仕組み
- インシデント対応中の行動のふりかえり
とはいえ、こちらはすべてのインシデントが同じだけ時間をかけてふりかえりをする必要はないと思っています。
そこで、仕組み（外部ツール）を使いつつも、ある程度の下書きはQAが実施してもいいと思ってやっていますという話をしました。
結論。やれる人がやったらいいんだと思う
つまりこれで。インシデントのファシリもポストモーテムの下書きも、誰でもやったらいいんじゃないかな。って思います。
そして、QAとしても大事なのは、できるかぎりのハードルを下げる（システムをうまく使うことをめんどくさがらせない）とか、それにより、改善活動までスムーズにできることなんじゃないかなって思っています。
これは品質文化なのか？
今回の一例は、ただの事例紹介だと思うんですが、品質ってそういう行動をすることであげることができるし、これがあたりまえになってくると文化をつくったってことになるんだと思います。
今回のイベントに来てくださった方に期待値があったかちょっと不安ですが、 私以外の登壇者のはらしんさんとか、マークさんが色々お話ししてくださったしいいよね。 しかも示し合わせたように、セビリティの話や、実践事例は話せないという話だったので補完できているといいなぁ。
