不具合の可視化のためにやっていること

QA

この記事は弥生 Advent Calendar 2024のシリーズ2、16日目のエントリーです。

こんにちは！弥生で会計NextというサービスのQAエンジニアをしているはるたです。 担当している会計Nextというサービスは、新規でサービスを開発して、先日リリースをしたサービスになります。

開発をしているときから、検出する不具合の情報をチームがわかるようにするために可視化の取り組みをしてきました。 どのようなことをしてきたかを書きたいと思います。

不具合の可視化の取り組みをはじめたきっかけ

最初に、なぜ、この取り組みを始めたかということを書きたいと思います。

私が担当するサービスは、開発チームが4～5チームに分かれていて、多くの人たちが開発にかかわっています。このようなチームで進めていると、かかわる人たちの人数が多いゆえに、正しい情報が良いタイミングで全員にいきわたらなくなりがちです。開発にかかわる人たちが、今の状況がどういう状況なのか、ということをいつでも分かるようにしておくことが、品質を良くしていくための基本になると考えたため、この取り組みを始めました。

弥生では、不具合管理はBacklogというサービスを使っています。Backlogに所定のフォーマットで不具合情報を登録しています。登録した不具合情報をMicrosoft Power BIというサービスを使って任意の条件で集計結果をグラフで表示できるようにしています。PowerBIのグラフをもとに、各チームで傾向分析をして、その後の改善につなげられるようになっています。新しい仕組みの検討や導入をするより、この仕組みを活用したほうが早くやりたいことが実現できるため、極力この仕組みを活用して進めようと思いました。

どのようにすすめたか

ざっくり不具合情報の可視化をしましょうといっても、考えられる観点はいくつもあります。

思いつく切り口で傾向を出しても、有益な情報を伝えることにはならないと思いました。まず知りたいことの問いを立てて、その問いに答えるような切り口で傾向を出すようにしてきました。 どんな問いに答えるような分析をしたのか？ということについて、具体的にやったことを以下に記載していきます。

プロダクトのどこがどのように弱いのか

毎月、不具合の傾向をConfluenceの記事にまとめて、簡単なコメントを添えてチームに共有するということをやっています。大きなリリース向けのテスト期間中は毎日、不具合の傾向を伝えるようにしています。ここでこたえる問いは「プロダクトのどこがどのように弱いのか」です。

たとえば、下記のようなことを記事にまとめています。

  • 不具合数の推移
    • 月や日単位で時系列の推移を示すことで、いまどのぐらい不具合が出ているのかを把握できるようにしています。
  • 不具合の深刻さごとの内訳
    • 重大なものがどのくらいあるのかを把握できるようにしています。
  • 機能ごとの内訳
    • 開発チームごとに担当機能が分かれているため、それぞれのチームのメンバーに伝わりやすいように機能ごとの内訳を入れています。
  • デグレード発生状況
    • 自動化を行う範囲を決めるときに、どこの部分でデグレが発生したかということを参考にして決めています。そのため、どの機能でデグレードがどのくらい起きているかということをわかるようにしています。
    • 自動化についてはこちらの記事に詳しく書いています。

tech-blog.yayoi-kk.co.jp

記事に記載する内容は、その時の状況により変えていっているところもあります。大切なのは、大勢のメンバーが開発にかかわっているという環境で、「プロダクトのどこがどのように弱いのか」を皆が知りたいときに知ることができる状況になっていることなので、その状況になるように続けています。

「○○の不具合が多い気がする」「△△が心配」といった感覚は本当にそうなのか

定期的にチームにフィードバックをしているのは上であげた「プロダクトの弱さ」にかかわる情報です。もう１つの別の考え方で不具合情報のフィードバックをしていることがあります。

開発をしていれば、「最近、○○に関する不具合が多い気がする」「△△は結構難しいところだから心配」という感覚をもつことがあると思います。不具合の件数など実際の数字を見てみたら、その感覚は当たっていることもあれば、そこまででもないこともあります。なんとなくの所感や感覚の裏を取っていくということは大切だと思います。 そこで、実際の不具合情報をもとに「本当にそうなのか？本当にその傾向があるとしたらどの程度なのか？」といったことをまとめて共有するということをしています。

例えば、下記のようなことです。具体的な内容はオープンに記載するのが難しいため、イメージとして例を挙げます。

  • ここ最近、特定の業務の計算処理の不具合が多い気がするがどの程度か？
  • 特定のサービスが複雑な処理を担っていて、不具合の混入が多くなりそうだが本当にそうだったか？

上記のような問いに対して、データとしてはどうなっているかをさくっとまとめて、Slackなどでチームに伝えています。定期的に周知するというのではなくて、気になることを見つける都度、その時点のデータでまとめています。

まとめ

不具合情報をチームに伝えていくために行っている取り組みを書いてきました。不具合に限らず、「品質の可視化」という取り組み自体は新しいことではなくて、どこのチームも色々な形で取り組んでいることと思います。私の場合は、チームの状況を考えつつ、どういう情報をつたえていくのか、ということを考えるのが思ったよりも難しかったです。まだまだ改善したいことはあるものの、プロダクトがどういう状況なのか？について、チームが知ることができる状況にはなっていると思います。今後、仕組化や傾向分析の観点の見直しなど、取り組んでいきたいと思います。



弥生 Advent Calendar 2024を引き続きお楽しみください。
qiita.com
弥生では、一緒に働く仲間を募集しています。
herp.careers
弥生のエンジニアに関するnote記事もご覧ください。
note.yayoi-kk.co.jp