はじめに
私の所属する組織は、スピードを重視します。
※品質よりスピード、ではありません。
そのような環境で、QAは何を測るべきなのでしょうか。
現在収集している指標
現在、私たちは以下の指標を収集しています。
- 市場不具合件数
- 4Keys（デプロイ頻度、変更のリードタイム、変更失敗率、平均復旧時間）
市場不具合については、原因別に分類・集計をしています。
- 要件漏れ
- 設計ミス
- 実装不備
- テスト不足
- 環境依存 など
しかし、ここで違和感がありました。
「原因分析」はこの組織に合っているのか？
市場不具合を原因別に集計すること自体は、一般的には正しいアプローチです。
しかし、私たちの組織文化は、
- まずスピード
- 議論より実行
- 深掘りより前進
という特徴があります。
原因分析をしても、 「それを改善することでスピードは上がるのか？」 という問いに答えられない限り、優先度が上がりません。
つまり、
品質向上のための分析ではなくスピード向上のための分析
でなければ、この組織おいては有用ではないと考えました。
発想の転換：「リリースを遅らせた不具合」に着目する
そこで考えたのが、
リリースを遅らせている不具合を集計してはどうか？
というアプローチです。
具体的な収集方法
- タスクごとにリリース日の予実を記録する
- 予定と実績の差分（日数）を算出する
- リリースが遅延したタスクを抽出する
- 紐づく不具合情報を参照する
- 不具合の「起票〜完了までの時間」を算出する
これにより、
- どの種類の不具合が
- どれくらいの期間リリースを止めているのか
- 修正にどれくらい時間がかかっているのか
が見えるようになります。
見たいのは「犯人」ではなく「傾向」
重要なのは、誰が悪いかではありません。
見たいのは、
- 仕様の曖昧さに起因するものが多いのか
- 環境依存が多いのか
- 結合観点の漏れが多いのか
- 影響範囲の見積もり不足が多いのか
つまり、
リリーススピードを実質的に阻害している構造的パターンです。
ここが見えれば、
- レビュー強化
- 事前検証の導入
- テスト観点のテンプレ化
- 仕様定義プロセスの改善
といった具体策につなげられます。
しかもそれは、
「品質のため」ではなく「スピードを落とさないため」 の施策です。
まだ集計開始段階
正直に言うと、まだ集計を始めたばかりです。
仮説段階ですし、うまくいく保証もありません。
ですが、
- 品質という言葉が刺さらない組織で
- QAが価値を出すためには
- 組織の価値観に翻訳する必要がある
と考えています。
QAは「ブレーキ」ではない
スピードを重視する組織では、QAはブレーキ役だと誤解されがちです。
しかし本来QAは、
無駄な減速を防ぐための存在
です。
リリース直前で発覚する不具合、市場での重大障害、想定外の手戻り。
これらこそが、本当の減速要因です。
もし 「どの不具合がリリースを遅らせているか」 が見えるようになれば、
QAはスピードの敵ではなく、スピードを守る存在になれるはずです。
今後、集計結果が出てきたらまた共有します。
スピードを最優先する組織でQAをしている方の参考になれば幸いです。
