こんにちは、QAチームの牛木です。
QAチームでは今期「品質の見える化」に挑戦しています。 この記事では、QAチームが取り組む「品質の見える化」の歩みをお話します。
なぜ「品質の見える化」をやるのか
昨今のソフトウェア開発手法の主流が「ウォーターフォール開発」から「アジャイル開発」（アジャイル開発の中でもスクラム開発）へ変化しつつあります。
アジャイル開発においてもテスト業務は依然として必要ですが、包括的なドキュメントではなく、動くソフトウェアや対話の中でのテスト設計、開発サイクル全体を見通した素早いテスト実施、開発から運用まで含めたプロセスの中での継続的なフィードバックの獲得も求められます。 こういった体制を「DevOps」とも捉えていますが、QAが継続的なテスト、継続的なフィードバックを提供する足掛かりとして「品質の見える化」に取り組んでいます。
「品質の見える化」とは何か
「見える化」とは、”「可視化」された対象を「モニタリング(監視)」し、「課題を抽出・分析」、フィードバックに基く「改善活動を行う」ことである” とQAチームでは考えます。 「見える化」という言葉は、トヨタ自動車による業務改善の観点において初めて登場した言葉です。
可視化の対象となる「品質」は、現在以下のデータに絞っています。
- QAチームが検出した不具合データ
- QAチームが担当したテスト業務データ
ソフトウェアにおける「品質」の定義は、企業によって多種多様であり、品質の対象もさまざまです。
品質の定義から、ISO/IEC9126の品質特製（プロセス品質、内部品質、外部品質、利用時の品質）を思い浮かべる人もいれば、狩野モデルの品質要素（魅力品質、一元的品質、当たり前品質）を思い浮かべる人もいるのではないのでしょうか。 この全ての品質をスコープとすると膨大なデータと、そのデータを蓄積するための運用整備が必要となります。そのため、まずはミニマムスコープとしてQAチームの管理下で蓄積・運用されているデータを対象としています。
今何をやっているのか
「品質の見える化」のプロセスとして、以下ステップを目標に活動を進めています。
- 品質データの”蓄積”
- 品質データの”可視化”
- 品質”課題抽出・分析”
- 品質”フィードバック”
- 1~4のサイクルの”運用”
- 他チームへの横展開
上記ステップのうち、1”蓄積”と2”可視化”に現在取り組んでいます。 その活動の詳細についてお話しします。
1. 品質データの蓄積
前述した品質データは、タスク管理ツール「Asana」を使い、QAチームがチケット管理をしています。 各データには以下のようなラベリングをしています。
- 不具合データ：不具合分類、不具合レベル、不具合混入工程、不具合見逃し理由、不具合検出手法など
- テスト業務データ：案件名、開発チーム、テスト工程、テスト項目数、実績工数など
QAチームが管理するAsana
各チケット（データ）はQAチームが各プロダクトチーム統括でClose作業をしており、ラベルの未入力チェックや、不具合のステータスチェック（例えば、案件がCloseしているのにも関わらず、案件に紐づく不具合がOpen中である場合には確認を入れる等）のチェック運用を行っています。
2. 品質データの可視化
BIツール「Tableau」を使い、「Asana」に蓄積された品質データのダッシュボードを作成し、社内に展開しています。 社内の役割によって気になる観点が異なるため、「全社向け」と「プロダクトチーム向け」に分けてダッシュボードを作成しています。
「全社向け」では、Classiサービスの品質状態が良いのか悪いのかを端的に伝えるために、Classiサービス全体の平均不具合件数や不具合密度の推移、不具合の改修状況などを表示しています。
「プロダクトチーム向け」には、機能毎に不具合データのラベリング別の割合や、推移を載せています。各チームが、不具合の傾向から原因や課題を拾いやすくすることを目的としています。
現在取り組んでいるステップとして「1.品質データの蓄積」と「2.品質データの可視化」をお伝えしました。
可視化のステップは次に見据えている”品質課題抽出・分析”のための活動でしたが、可視化をして最初に見えてきた課題は蓄積ステップの運用課題でした。 例えば、ステータスの中で新規起票状態のチケットが多いことが分かったのですが、これは実際に新規起票チケットが多いのではなく、ステータス更新が適切に行われていないことが原因でした。 他にも不具合レベルがあるレベルに偏っておりレベルの細分化・再定義が必要であったり、ある項目の未入力が多くフローがうまく機能がされていないことが判明したりと、可視化をすることで前ステップの改善にも繋げることができました。
蓄積されたデータが正確でなければ品質課題の抽出もできません。蓄積と可視化を反復しながら品質データが適切に蓄積されることが見える化における初めの一歩になると思います。
今後何をやるのか
今後のステップとして、蓄積/可視化の管理・運用を推進しつつ、「3.品質課題抽出・分析」と「4.品質フィードバック」の取り組みを開始しています。
品質データの「蓄積」「可視化」では、品質データの対象をQA管理下のデータに絞り込んだこともあり、QAチーム主体で活動を進めることができました。 しかし、品質「課題抽出・分析」「フィードバック」では、プロダクトチームを巻き込んだ活動でないと価値を出すことは難しいと考えています。
というのも、Classiのプロダクトチームは複数存在しており、チーム毎に開発スタイル、リリースサイクル、人数、担当機能などが異なります。チームによってデータ結果の背景・原因は異なりますし、重視している観点も異なります。
「可視化」したところで...
- 可視化したデータをそもそも見てもらえない
- データを見ても、「それで？」となる
- データ結果が実際の業務と紐付けられない
- なぜこのような結果になっているのかの根本的な背景や原因が分からないから活用できない
などなど...
Classiサービス全体としてデータの結果を表示できても、チームに寄り添った分析とフィードバックを行えなければ、「見える化」できているとは言えません。
そこで現在は、プロダクトチームに参画し、品質データを生かしたフィードバックをどう推進していくのが有効か？の情報収集をしている段階です。他チームへの展開も視野に入れて、まずは特定チームで「品質の見える化」のサイクルを確立することを目指して活動をしています。
おわりに
「QA」と聞くと「テスト業務」が連想されると思いますが、QAはQuality Assuranceであり、「品質保証」業務全般を差します。最近はQAの担当領域も広がってきましたが、品質目標やQAが担う領域は、企業によってさまざまであると感じています。わたしも勉強中の身ですが、Classiにおける「品質保証とは？」をつきつめられるように精進していきます。
