エッジケースエラーをチームで低減させた話

f:id:shuhei_kaneko:20201218174005p:plain

こんにちは、技術部でバックエンドエンジニアをしている金子です。
この記事はロコガイド Advent Calendar 2020の22日目となります。
前日の小川から続きまして、私はエッジケースなエラーを低減した活動の話をご紹介します。

なぜ、やったか？

日々の業務の中で、優先度の高い不具合や、ユーザー影響の大きいものは即時対応しています。
しかし、上記に当てはまらない主にエッジケースのみで発生するもの、発生頻度が低いものなどは対応が先送りにされ、解消できていないものが存在しました。

また、社内のエンジニアからも以下のような声があがっており

例外棚卸しやりたいな…… 無視できるやつが多いんだけど合意がないから目grep -vしているという状況になっている気がする

このような課題を少しでも解決するために、「エラーの流れをゆるくする会」と称した活動を始めました。

どうやったの？

会は隔週1時間の定期開催とし、バックエンドメンバーは全員参加の形で行いました。

弊社では、エラー監視ツールにSentryを利用しています。アプリケーション内でエラーが発生すると、Sentryに送信され、以下のようにエラー内容を確認できます。

f:id:shuhei_kaneko:20201218174245p:plain

このエラー情報を元に、以下のような流れで進めていきました。

まずは、全員で

前回作業の進捗確認
エラーの概要把握と修正方針の確認
１回の会で取り扱える範囲のエラーを選定
選定したエラーの担当割り振り

を行い、残りの時間をそれぞれが

エラー内容の原因調査
エラー内容に応じた対処
時間内に終わらなかったものは、次回に持ち越し

を行いました。

やってみて、より良い活動の形に

上記のように活動を進めてきたのですが、初めからこの形だったわけではなくメンバーの意見や進捗状況を鑑みて形を変えてきました。

1. 宿題方式で開始

はじめは、全メンバーが揃う場として、隔週のKPTを利用しました。KPTが終わった後にエラー内容の棚卸しと担当決めまでを行い、解消は各自、次回のKPTまでに進めてくるという宿題方式にしました。しかし、本来の開発業務と比べて優先度が低くなってしまうため、各自でエラーの原因調査や対処するにはまとまった時間の確保が難しく、なかなか進捗がでませんでした。

2. 定例方式に変更

あるときのKPTでの振り返りにて、このままの宿題方式では進捗がでないため、メンバー全員で隔週１時間集まって、同時に作業する定例方式でトライしてみようとなりました。エラーを解消するには十分な時間ではありませんでしたが、時間内になんとか解決したいという思いや、全員で同時に作業することで生まれた適度な緊張感もあり、宿題方式に比べて作業効率をあげることができました。また、この時間内に終わらなかったものは１での反省を活かし、次回に持ち越すようにゆるいルールとしました。

3. エラーの低減だけでなく、広範囲の課題解決へ変更

定例方式に変更したこともあり順調にエラーの解消が進み、Sentryでのエッジケースエラー解消も終わりが見えてきました。そんなとき振り返りにて、CIでたまに発生する自動テストのfailケース(Flaky Test)や使われなくなったコードが、開発生産性を下げているという意見が出てきました。残りのエッジケースのエラーを解消していくよりも、これらを解消する方が全体としての開発生産性をあげられるので、会の活動を拡張しこちらについても取り扱うことにしました。

この取り組みをしてよかったこと

１つ目はこの活動を通じて、実際にエラーの解消が進んだことです。
エラーの中には特定機種でのみ稀に発生するものもあり、原因調査に時間がかかるため、なかなか手が付けることができませんでしたが、そのようなエラーに対して解消まで行うことができました。また、ユーザーには正常動作で返していますが、内部の確認用としてエラーを収集していたものは、特に対処の必要がないため、エラーレベルをErrorからWarningに落とすなどの適切な処置を行いました。これによりエラー確認時の視認性が向上しました。

２つ目はバックエンドメンバー全員で取り組んだことです。
作業自体は個人で進めていましたが、エラー内容の確認や進捗確認を全員で行うことで、自然と実装についての会話に繋がり、知見を共有できました。また定例方式として全員が集まり作業することで、自分の担当分で分からないことも、誰かしら知っていたり相談に乗ってもらったりと、チームとしてエラーを解消するという動きに繋がりました。この活動を通じてチームとしても一歩成長できたと感じています。

そして、３つ目は姿形を変えながら継続できたことです。
始めてみたものの勢いが続かず、途中で終わってしまうことがあると思います。「エラーの流れをゆるくする会」も、始めた当初はなかなか進捗が出せませんでしたがコツコツと改善を加えたこと、全員で一丸となってやったことで諦めずに進めることができました。現在、「エラーの流れをゆるくする会」としては役割を終え、作業時間を確保し進めるのではなく各自のタスクとして各スプリントに組み込む形で、上記のようなエラーやクリーニングに対応するように変化しています。