開発とQAが協力する「エラーを見る会」の取り組み

はじめに

自己紹介

はじめまして、株式会社グロービスの池邊と申します。QAエンジニアとして6年ほど、グロービスの GLOBIS学び放題 や グロービス経営大学院 ナノ単科 といったプロダクトのQAを担当しています。

グロービスでは、QAチームは開発プロセスに深く関わっており、各プロダクトチームと連携しながら品質向上に取り組んでいます。 日々の業務の中で、一部のエンジニアがエラー対応に苦慮していたり、個人で対応しているために根本的な対策についての議論が進んでいない場面が見受けられました。
そこで、開発とQAが協力してエラーを分析し、対応方針を決定する「エラーを見る会」を導入しました。 この取り組みにより、チームのエラー対応が円滑に進み、エンジニアの負担軽減にもつながるなど、期待以上の効果が得られています。 今回の記事では、この取り組みの経緯、具体的な内容、そして得られた成果について詳しくご紹介します。

「エラーを見る会」を導入した背景

エラー対応の仕方は、チームによってバラバラでした。例えば、チームAはエラーが発生したらすぐに修正されるが、チームBは一人のシニアエンジニアがひたすらエラー対応していて、新規開発と重なると対応が遅れがちでした。チームCはSentryの通知が多すぎて、どのエラーに注目すべきかの判断が難しい「オオカミ少年状態」になっていました。また、一部のエンジニアだけがエラー対応を担い、チーム全体での知見共有ができていないという問題もありました。
さらに、エラーが放置されることで、ユーザーへの影響が増してしまうリスクもあります。たとえば、あるチームでは「発生しているけど致命的ではないから後回しにしよう」と考えたエラーが、後々ユーザーからの問い合わせにつながり、結果的に緊急対応を強いられることもありました。このような課題を解決するために、エラーを見る会を導入することにしました。

• エラー通知が多すぎて、どれを対応すればいいのかわからない
• エラー対応が特定のエンジニアに集中し、他のメンバーが関われていない
• 技術的な判断で対応が決まることが多く、品質やユーザー影響の視点が抜けがち
• インシデント後の振り返りはするけど、未然に防ぐ仕組みがない

開発チームとQAが一緒にエラーを見れば、このあたりが改善できるのでは？ということで「エラーを見る会」を始めました。

「エラーを見る会」の運用方法

エラーを見る会をチームに定着させるには、実施方法を工夫する必要がありました。エンジニアもQAも負担を感じず、継続的にエラー対応ができるよう、以下のような方針で運用しました。

基本ルール

• 新しいツールは増やさない → 既存のSentryを活用し、運用の変更だけで対応する。
• チームごとに運用を調整する → エラーの発生頻度やチームの状況に応じ、週1回または隔週で実施する。また、自分事化するために、司会をローテーションにするなどチーム特性に合わせて運用を調整する。
• 短時間で進める → 30分以内に収まるよう、議論の焦点を絞る。

ミーティングの流れ

1. エラーの傾向を確認する
   直近1週間のエラー発生状況を整理し、頻発しているエラーや増減の傾向を把握する。これにより、今必要なエラー対応業務自体の温度感を共有する。
2. 誰が対応するか決める
   エラーの影響範囲を確認し、適切な開発チームにアサインする。
3. エラーの分析と対応方針を決める
   エラーの原因を調査し、再発防止のために必要な対策を決める。特に、ログの出力や監視ルールの見直しを重点的に議論する。
   このシンプルな流れのミーティングを各チームに導入して毎週少しずつ運用を調整しながら繰り返しました。チームによって違いましたが、1〜2ヶ月ほどで定着し、3ヶ月ほどでチームに最適な独自運用が始まりました。

「エラーを見る会」の導入による効果

実際にエラーを見る会を導入したことで、チームのエラー対応にはどんな変化があったのか。定着してきたタイミングで、チーム内のフィードバックを整理してみました。その結果、エラー対応の効率化や、エンジニアのスキル向上など、さまざまなメリットが見えてきました。

1. 不要なエラー通知が減り、対応すべきエラーが明確になった
   Sentryの通知を整理したことで、本当に対応が必要なエラーだけに絞れるようになり、エンジニアの負担が軽減された。
2. エンジニアのスキル向上につながった
   若手エンジニアやQAがエラー対応に関与し、エラー解析のスキルを学ぶ機会が増えた。
3. ログ設計の改善が進んだ
   エラー調査を通じてログの出力項目を見直し、原因特定のスピードが向上した。
4. エラー調査が問い合わせ対応の迅速化につながった
   エラーを見る会で調査していたエラーについて、その直後にユーザーから問い合わせがあり、事前の調査のおかげで迅速に対応できた。
5. エラー対応の知見がチーム間で共有されるようになった
   エラーの傾向や対策がチーム内で共有されることで、過去の対応が活かされるようになった。

「エラーを見る会」は他の組織にも適用できるか？

この取り組みは、多くの組織で応用できる可能性があると考えています。特に、以下のような特徴を持つ組織やチームには、導入のメリットが大きいでしょう。

1. 複数の開発チームが存在する
   チーム間でエラー対応の進捗やナレッジを共有することで、組織全体の品質向上につながります。例えば、以前は各チームが独立してエラー対応を行っていたため、同じようなエラーが別のチームでも発生することがありましたが、「エラーを見る会」を導入してからは、チーム間で対策を共有することで、組織全体として効率的にエラーに対応できるようになりました。
2. QAチームが開発プロセスに関わっている
   QAが主体的にエラー分析に参加することで、より早期に品質課題を発見しやすくなります。グロービスでは、QAチームがスクラムの各開発チームに参加し、最新のプロダクト知識を持った状態でエラーを見る会に参加できたので、エラーの傾向分析や再発防止策の検討に積極的に参加できました。
3. Sentryなどのエラー監視ツールを導入している
   既存のツールを活用することで、新たな導入コストを抑えられます。多くの組織で既に導入されているSentryなどのツールをそのまま活用できるため、導入のハードルは低いと考えられます。
4. チーム内のコミュニケーションを活性化したい
   エラーの話は、時としてチーム内で避けられがちになることがあります。共通の課題ではあるものの、ネガティブな話をしなくてはいけなかったり責任の押し付け合いになることを懸念し避けてしまうためです。エラーを見る会のように枠組みとルールを決め定期的に議論することで、チーム内でネガティブな課題にも向き合う意識が生まれるとともに、品質に向き合うチームへの第一歩が踏み出せると思います。

ただし、導入にあたってはいくつかの注意点もあります。

1. 小規模なチームの場合
   エラーの発生頻度が少ない場合、定例のミーティングが形骸化する可能性があります。チームの状況に合わせて、開催頻度や議題を柔軟に調整する必要があります。例えば、週ごとの開催ではなく、エラーが一定数発生した場合に都度開催するなどの対策が考えられます。
2. 文化的な障壁
   エラーを個人の責任と捉える文化が強い組織では、エラーの共有や議論が活発にならない可能性があります。心理的安全性を確保し、失敗から学ぶ文化を醸成することが重要です。まずは一部のチームから試験的に導入し、成功事例を作ることで、他のチームへの導入をスムーズに進めることができるでしょう。
3. 参加者のモチベーション維持
   エラーを見る会の目的や効果が参加者に十分に伝わっていないと、モチベーションの低下につながる可能性があります。定期的に効果を共有したり、参加者の意見を取り入れたりする工夫が必要です。例えば、「エラーを見る会」によって削減できたエラーの数や、それによってどれだけ開発効率が向上したかを定量的に示すことで、参加者のモチベーションを高めることができます。

「エラーを見る会」は、特定の技術や開発手法に依存するものではありません。エラーという普遍的な課題に対して、チームで協力して向き合うための仕組みです。上記のポイントを踏まえれば、多くの組織でその効果を発揮できるのではないでしょうか。

まとめ

まとめます。今回ご紹介した「エラーを見る会」は、エラー対応の属人化、それによるモチベーションの低下、QAの品質改善への関与不足といった課題を解決し、エラー対応の効率化、エンジニアのスキル向上、そして最終的な品質向上につながります。
もしこれらの課題が開発組織にあるのであれば、まずは週に一度、30分程度の「エラーを見る会」を試験的に導入してみてはいかがでしょうか。きっと、チームの状況に変化が生まれるはずです。

宣伝

グロービスでは、エンジニア・QAを積極採用中です！個人的には、これまで転職で経験した会社の中で一番「ちゃんと課題解決の話ができる組織」「評価基準が明確な組織」だなと感じています。手前味噌ですが。
ご興味ある方は下記からご連絡お待ちしています！

グロービス エンジニア・デザイナー 採用情報