このページは何?
2025年3月5日に行われたDeNA QA Nightについて書いたメモです。
トピックや内容、それを受けての所感などを徒然なるままに書いていきます。
Session1:リアルタイム品質モニタリング導入
- DeNA QAの変遷:
- 事実を把握する → 統計的な予想を立てる → 品質の判定をする(いまここ)
- 品質を判定する上での課題:
- データ(根拠)がないため判定しづらい
- 判定には経験が必要だが、シニアなQAがいない状況もある
- 解決策:
- 全プロダクト共通の品質指数の定義とリアルタイムモニタリングを導入
- 各verのリリース前に品質指数を算出しリスクを判定
- リリース前に、品質的なリスクが高いか低いかを可視化する - 指数と本番障害の実績データを比較して根拠を裏付ける
- 高リスク(=品質指数が低い)→本番障害が起きやすい など
- 全プロダクト共通の品質指数の定義とリアルタイムモニタリングを導入
- 良かった点:
- リソースの最適化ができる
- 指標が悪ければ追加テストの実施、良ければ一部のテストを省略
- リスクが高い場合はリリース時に障害対応リソースを厚くする など
- 他プロダクトと比べられるのが(プロダクト責任者など上位レイヤーから)好意的に受け取られた
- リソースの最適化ができる
- 筆者感想など:
- まずはデータの取り方を各部署で統一することが重要だなぁ
- あとで登壇者さんに話を聞いたこと
- 共通の指標を各プロダクトに導入~データ蓄積するまで2年程かかったそうな...。
- AIにオールインする(参考)ので、今まで貯めたデータが不要になるかも、と震えていらっしゃいましたw
Session2: ガチャのパトロールの話
- プレサートチームについて
- QAチームとは別に、ガチャに関するリスクを管理する専門チーム
- 主にCESAやDeNA独自のガチャガイドラインへの準拠確認が業務内容
- 具体的な活動:
- 実際の本番アカウントを使用してのパトロール
- 実態(データ)と訴求(仕様書や想定)の比較チェック
- AIを用いた、過去の不具合レポート全体のサマリーおよび、それによるテスト観点設計
- 筆者感想:
- 自社独自のガチャガイドラインがあるのが新しい発見
- 職種を超えたリスク管理チームも有効かもしれない
- 過去の不具合データをAIに食わせて分析させ、プロダクトの弱点を探るのはやってみたいかも
- 昨今はネットで炎上したときの火力が上がっており、以前より厳しいリスク管理が必要であることに強く共感した
Session3: ニコニコじゃない方の品質保証の話(From:ドワンゴさん)
- ニコニコじゃない方...とは?
- 教育事業のQA組織に関する話でした
(品質保証の闇 的な側面の話かとてっきりw)
- 教育事業のQA組織に関する話でした
- 教育事業(N校など)のサービス開発における課題:
- 各サービスの影響範囲が把握できない
- 「様々なサービスから成り立っている」かつ「サービス間を連携するマイクロサービスが多い」ため
- サービスAに入れた機能改修が思わぬサービスに影響を与えていることが
- 情報共有の問題(関心の薄さ、認識の相違)
- 各担当者が他サービスへの関心が薄いため、情報連携がなされていない
- 各サービスの影響範囲が把握できない
- 課題への解決策:
- サービス間横断の情報共有ミーティング開催
- 連携の大切さを実感した社員が多かったことは成果といえる
- サービス間横断の情報共有ミーティング開催