「データの負債は高利子である」バグの修正別リードタイム分析

この記事は Wantedly Advent Calendar 2023 4日目の記事です。

また、2023年 11月 23日に行われた「技術的負債に向き合う Online Conference」の LT 選手権で行った発表したものになります。その際の発表資料は以下です。

Engineering Manager 兼 Quality Control Squad リーダーの鴛海です。Quality Control Squad は内部品質を向上させるためのチームです。Quality Control Squad の詳細や発足の経緯は以下の記事にて紹介しています。

Quality Control Squad が発足して 1年経ち、その中で多くのバグ修正をしました。それらのバグの傾向を分析して、バグが生まれたり、負債化しやすい箇所はどこかを調査しました。

バグの分析

1年間の優先度が高い 86 件バグ修正を対象に何を修正したかを App/System/Data の 3つで分類し、報告されてから対応完了するまでのリードタイムを計測しました。System はバックエンドのコード修正で直るもの、App はフロントエンドのコード修正で直るもの、Data はRDB やログ等のデータ修正が必要なものとしました。

以下はリードタイムを箱ひげ図にしたものです。ヒゲの長さは (Q3-Q1)*1.5 を上限とし、その範囲外を外れ値としました。

結果として最も特徴が出たのはデータ修正系のバグでした。中央値は低い一方、分散がかなり大きくなっています。ここに大きな問題があるのではないかと仮説を立て、分散が大きくなる理由を定性的に調査しました。

なぜデータ修正系のバグはリードタイムの分散が大きくなるのか

バグ修正を細かく見ていくと「参照の数によってかかる時間が大きく変わる」こと「ユーザーへのコミュニケーションのリードタイムがかかる」ことの 2つがリードタイムに大きく関わっていることが分かりました。

1つ目は「参照の数によってかかる時間が大きく変わる」です。データを修正する際にはそのデータの参照先への影響を確認したり、そのリスクを取り除く必要がある可能性があります。参照が多いデータは重要度が高いため優先度も上がる可能性が高く、そのような修正もいくつか今回の対象に入っていました。しかし、そのような参照の多いデータは網羅的に対応することが難しく時間がかかっていることが分かりました。逆に作られたばかりで参照が明らかに少ないデータ修正は数分で終わることもありました。データ修正系のリードタイムの分散の大きさにはこの要素が大きく関わっていそうです。

2つ目は「ユーザーへのコミュニケーションのリードタイムがかかる」ことです。データを変更するにはユーザーへの通知が体験上必要なこともあります。自分が設定したものを勝手に変えられて説明がないとユーザーは困惑してしまいますし、信頼感を損ないます。そのため、メールやサイト内通知を行いますが、このような通知で誤配信をしないように確認を丁寧に行い、結果的に時間がかかってしまうケースが多いです。

他にも、リードタイムが長いことが分かっているから丁寧な確認をしたり、調査のためのデータ収拾に時間がかかったりすることも分かりました。

「データの負債は高利子」である

今回の調査で分かったこととしてデータ修正は他の技術的負債と同様に日が経つにつれて膨れ上がっていくが、その大きくなるスピードが早いことが分かりました。技術的負債というメタファーになぞらえるならデータの負債は高利子であると言えます。他の負債と同様に早期に発見、対応したり、無駄に負債を生まないようにすることが重要ですが、フロントエンドやバックエンドの負債以上にデータの負債はよりその重要性が高いと言えます。

データの負債がやっかいだという認識は感覚的にはありましたが、今回の調査で明らかになり、より一層データの負債にフォーカスしていこうというと考えています。 Quality Control Squad ではこのような取り組みやアーキテクチャの刷新をして Wantedly 全体の品質を支えています。もし興味があるかたは下の「話を聞きに行きたい」からカジュアルにお話ししましょう！