バグを潰すのではない、作り込ませないのだ　～品質向上の取り組み～

はじめに

はじめまして！QAグループのyamaです。
2023年5月にKINTOテクノロジーズに入社しました。
普段は主にKINTO UnlimitedのQA業務に携わっています。

今回のテーマについて

今回は「品質向上の取り組み」として、私が入社後に取り組んできたことについてお話していきたいと思います。

QAグループ 今後の展望

上図はマネージャーのzumeが社内発表時に示したQAグループの今後の展望です。
QAが立ち上がって約3年、チームとして安定してきた所で 次になにをやるか？を表しています。

私が入社したのは、ちょうどそんな時期になります。
前職のシステム開発会社でも、QAを生業として「質が高いテストを提供することで品質向上に貢献する」ことを目標に活動してきましたが、経験を積むとともにテストで品質を担保することの難しさを感じるようになっていました。
バグを潰すだけでは限界がある。そもそもバグを作りこまないようにすることが必要だ…と。

そこで、次はこの取り組みができる職場で仕事がしたいと思い、KINTOテクノロジーズに入社しました。

現状把握

入社後、まずは社内の開発＆QA工程と担当プロジェクト(KINTO Unlimited)の現状把握に努めました。

すると、当初私が想定していたよりも開発スピードに対するウェイトが高いことがわかりました。
(前職でもスピードは求められていましたが、KINTOテクノロジーズほどではありませんでした)
これはKINTO/KINTOテクノロジーズが新しいサービスを創り出す事業会社であり、遅れがビジネスチャンスの損失に繋がるためです。 なるほど…と納得しました。

従って、品質向上の施策を打つ際は、開発スピードが低下しないようなやり方が必要だと感じました。
また 前職の経験から、担当者に負担が掛かる(≒メンドクサイ)やり方は長続きしないことも分かっていたので、なるべくシンプルなやり方にしようと考えました。

一方で、今のプロジェクトには現在の品質を客観的に見る指標が足りないことに気づきました。
自分たちが作っているプロダクトの品質状況が見えないと、「バグを作りこまない」ための改善ポイントが見えてこないので、まずは品質を可視化する仕組みを作るところから始めることにしました。

やったこと

とは言え、いきなり「品質UPのために●●やりましょう！」とブチ上げたところで、すんなり受け入れてもらうのはなかなか難しいもの。

そこでまずは開発案件を通し、従来より少し踏み込んだ形での品質分析を行い、プロジェクトへ分析結果をフィードバックしてみました。
その時点ではバグ票に品質分析用の項目が充分ではなかったため、一旦QAチームにて個々のバグ票の解決経緯を調査、分類して品質分析を実施しました。

分析資料(抜粋)

そして、案件終了時の振り返りの場で分析結果を披露し「バグ票にこういった分類項目があれば、今よりも品質状況や現状の課題が見えてくるかも！」とアピールしました。
分類項目は絞り、入力方法をシンプルにすることで、出来る限り担当者の負担にならないようにすることも添えて。

新たに取り入れた分類項目

その結果、ありがたいことにこちらの提案が受け入れてもらえることになり、現在は上記の品質分類用項目を組み込んだ状態でバグ票の運用が始まっています。

今後やりたいこと

品質向上に向けた取っ掛かりを作るところが出来たので、今後は得られた情報をプロジェクトに定期的にフィードバックし、解決すべき品質課題を開発/QAで一緒に考えていくようにしていきたいと考えています。 またこの取り組みを継続的に行い、品質状況の推移(改善状況)を可視化していく予定です。
そして、ゆくゆくは他案件にも水平展開することで、その流れをより大きいものにしたいと思っています。

それが 冒頭に示した「QAグループ 今後の展望 ⇒ 全体品質向上」に繋がると信じて、取り組んでいこうと考えています。