はじめに
CastingONEでQAエンジニアをやっています松本と申します。
今回はインシデントの情報を収集、分析を行ってみた取り組みについて紹介してみようと思います。
どうして情報を集める必要があったのか
QAエンジニアというからには、日々のテストを行うだけでなく品質を向上していく必要がありました。
私がCastingONEに入社した際には、品質関連のデータが一切ない状態でした。
CastingONEの品質は”特別悪くはないかな？”くらいの肌感はありましたが、私の主観でしかなく、またどういった改善施策を行えば良いかは全く見えない状態でした。
まず現状把握をきっちり行うために情報を集めることにしました。
どのような情報を集めたのか
現在集めている情報は大きく以下のものになります。
- 本番環境で発生している不具合 ※今回の記事の中心
- QAテスト（一般的な総合テストにあたるもの）で検出した不具合
- QAテスト実施時のテストケース不備
集めた情報を整理するために必要なこと
不具合の情報は集めただけでは意味がなく、どう言った傾向があるのかなど分析する必要があります。
分析できることは色々ありますが、最も大事なことは「どの程度影響のある不具合だったのか」だと思っています。
定義がないと発生した不具合がユーザーにどの程度影響を与えるものか定量的に判断することができないため、最初にインシデント重大度の定義を行いました。
定義したインシデント重大度
重大度は影響度（ユーザーにとってどの程度の影響があったか）と影響範囲（どれくらいのユーザーに影響したか）を掛け合わせて判断することにしました。
最初に重大度定義を行ったと記載しましたが実はその定義のために、影響度と影響範囲の定義を行っています。
影響度は High , Mid-high , Mid-low , Low の4段階でそれぞれ以下のように定義しています。
| 影響度 | 例 |
|---|---|
| High | ・すべての機能が利用できない ・重要な機能、機能の一部が利用不可で、回避方法なし |
| Mid-high | ・重要な機能、機能の一部が利用不可で、回避方法ある ・重要ではない機能が利用不可で、回避方法なし ・重度のレイアウト崩れ |
| Mid-low | ・重要ではない機能が利用不可で、回避方法あり ・重要ではない機能の一部が利用不可で、回避方法あり ・あまり発生しないようなレアケースでクリティカルではない |
| Low | ・文言誤り ・軽度のレイアウト崩れ |
影響範囲は 大半 , 一部 , ごく一部 , 社内のみ の４段階で以下のように定義しました。
| 影響範囲 | 影響範囲（％） |
|---|---|
| 大半 | 30％～ |
| 一部 | 5%～29％ |
| ごく一部 | ~5% |
| 社内 | - |
そしてこの2つの掛け合わせで緊急,高,中,低,不急の５段階で以下のような重大度定義となりました。
この記事を書きながら「緊急」や「不急」は重大度のレベルとしては微妙な言葉な気がしてきましたが気にしないでいただけると幸いです（笑）
| 影響度＼影響範囲 | 大半 | 一部 | ごく一部 | 社内 |
|---|---|---|---|---|
| High | 緊急 | 緊急 | 緊急 | 高 |
| Mid-high | 高 | 中 | 中 | 低 |
| Mid-low | 中 | 低 | 低 | 低 |
| Low | 低 | 低 | 不急 | 不急 |
| Not incident | 不急 | 不急 | 不急 | 不急 |
集めた情報の活用方法
ここまで不具合の情報を集めたり分析するための定義などのお話をしてきましたが、それらの情報をどのように活用しているかもお話ししたいと思います。
現時点での主な活用方法は以下のとおりです。
①品質状況を知る、知ってもらう
リリースバージョンごとにどれだけのインシデントが発生したのかをまとめて共有しています。
インシデントの一覧は別途用意していますが、一目でわかるようなグラフを用意しています。
現状を知ってもらうことは品質への意識につながる大切なことだと思っているので、分かりやすさも重要だと思っています。
②品質の推移をチェック
30日あたりの重大度中以上のインシデント数及び、それを用いた近似曲線で品質の推移をチェックしています。
まだ収集を始めて間がないためデータが少なく有用なデータとなっていませんが、今後活用できるデータになっていくと思われます。
また新しい品質施策を行った際の効果測定としても活用できるのではと考えています。
③ポストモーテムの参考
CastingONEでは月に1回程度ポストモーテム読書会を行っています。
その議題に挙げるインシデントを決める際に分析した結果を用いています。
現状では影響度Mid-high以上のものを議題として取り上げることが多くなっています。
④今後の施策検討の材料
収集、分析した結果問題点が見えてくるはずなで、それを改善するための施策を考えることができます。
データ収集そのものの課題
こうした品質データの収集を行ってきましたが、１つ問題が発生してきました。
それは拾えていないデータがありそうということでした。
それまでインシデントの情報はインシデントを取り扱うSlackチャンネルやユーザーからの問い合わせを取り扱うSlackチャンネルで行っていました。
これらのチャンネルはユーザー影響があったものについてのみ扱うチャンネルであったため、開発者が他のチャンネルのスレッドの中だけでやり取りを行い情報が閉じてしまっているものがありました。
後から他のチャンネルのすべてのスレッドを追うことは非現実的なので、Slackとスプレッドシートを連携し、incident reportのスタンプを押すとその投稿がスプレッドシートに記載されるようにしました。
インシデントを取り扱うSlackチャンネルに投稿しない情報があれば、incident reportのスタンプを押すという運用にし、収集漏れをかなり防ぐことができるようになりました。
今後の展望
現状行えている分析は最低限のもので、細かい部分はまだ手がつけられいていません。
ごく一部のインシデントに対してのみ行っている、「埋め込まれた原因」や、「どうして検知できなかったか」などを、他のインシデントでも簡単に分析できるような仕組みを作れればと考えています。
また今はインシデントに特化していますが、ユーザーからの問い合わせに関してのデータも収集、分析することで見えてくることもあるかと思いますので、その辺りも将来的に何かできればと考えています。
おわりに
情報を収集し整理、分析してみることで多くのことがわかるようになりました。
この活動をきっかけとし、今後品質を向上していけるような取り組みを行っていければと思っております。
また紹介できるようなことがあれば、記事を書きたいと思いますのでその際はまたよろしくお願いします！
Discussion