【QAエンジニア考案】スクラムチームの品質保証を強化する「不安ニングポーカー」

こんにちは！QAエンジニアのhigesawaとkaomiです。私達は労務ユニットAに所属しており、開発チームの品質保証を支援する役割を担っています。品質保証部連載第10弾である今回の記事では、私達が課題を解決するために考案した「不安ニングポーカー」を紹介します。

品質保証活動における課題感

労務ユニットAは、特定の開発チームに属さず、複数の開発チームを横断して品質保証活動を行なっています*1。重要な業務の一つとして、各開発チームからの品質保証に関する相談や依頼に対応し、ノウハウ提供や実業務のサポートを行なっています。この業務を進めていくうちに開発チームから、「QAチームとの関わり方の判断基準を開発チームが持てるようにしたい」という声が聞こえてきました。その意図は、次のようなものでした。

開発チームがQAチームに相談するタイミングが不明確
どの程度の課題感で相談すべきかどうか判断基準がない
品質保証の課題が潜在的に存在していても気づけていない可能性がある

つまり開発チームは、自分たちで十分な品質保証活動を行なえているか、QAチームと適切に連携できていないのではないか、という不安を抱えていました。
この課題を解決するために、「不安」という感情に着目し、定量的な指標を用いることを検討しました。

「不安ニングポーカー」とは？

不安ニングポーカーとは、品質保証に関する不安を5つのカテゴリに分類し、プランニングポーカーの要領で1〜10のポイントを付けるというものです。それによって開発チームが品質保証の不安を言語化し、可視化・定量化するための仕組みです。
この仕組みを通じて、大きく以下の3点が達成されることを目的としています。

カテゴリを明示し、開発チーム内での品質保証に対する議論を促す
チームが抱える潜在的な課題感を共有し、認識を合わせる
開発チームがQAチームへの相談が必要か否か判断できる

着想のキッカケ

ある日、お風呂に入っていたhigesawaにそのアイディアは降りてきました。

最初は、開発チームの何らかの状態を定量指標として設計し、それを測ることで課題感や不安を浮き彫りにしようと考えました。しかし、不安に対して直接アプローチし、定量化する方法があるのではないかと。

そこで、定性的なものを定量化するプロセスとして分かりやすい例を探していたところ、プランニングポーカーの仕組みが頭に浮かびました。バックログに対しポイントを出して見積もる仕組みは、まさに定性的なものを定量化したものであり、手段としても開発チームに馴染み深いものでした。また、適性診断や心理テストのように、自身の心理状態に対して5段階や10段階で評価するプロセスは、多くの人にとって馴染みがあるはずだとも考えました。

検討プロセス

まず、不安の種類をカテゴライズすることから始めました。具体的な内容については後述の「不安ニングポーカーの詳細」に記載していますが、ホリスティックテスティング*2の考え方を取り入れ、各開発フェーズにおける不安を言語化しました。

ホリスティックテスティングの図に付箋を貼って各フェーズにおける不安を各自挙げた図

出典:アジャイルQAに求められるプロセス全体を俯瞰する「ホリスティックテスティング」とは何か？（翻訳） – 旅と子育てとアジャイルコーチのブログ「世界」

次に、いつ・誰が・どこでこの仕組みを活用できるのかを検討しました。開発チームがどのタイミングでこの仕組みを利用すると有効かを考え、新しいフィーチャー開発の着手前後や、プロダクトバックログリファインメントなど、チームで不安を感じたタイミングでいつでも使ってもらえる形を目指しました。

ポイントの付け方についても試行錯誤しました。フィボナッチ数列を用いた評価、5段階評価、10段階評価のどれを採用するかを比較した結果、フィボナッチ数列では心理的な不安の評価がしづらく、5段階評価では粒度が粗くなり、異なる意見があっても同じポイントになってしまうことで議論につながらない可能性があると考えました。最終的には、より細かく不安の度合いを表現できる10段階評価を採用しました。

また、開発チームがQAチームに相談すべきかどうかの判断基準も作成しました。具体的には、特定の不安カテゴリの平均ポイントが8以上の場合や、不安ポイントの合計が30ポイント以上の場合には、QAチームに相談することを推奨しました。ただし、これらの基準は絶対的なものではなく、確認したいことがあればポイントに関係なくこれまで通り相談してもらっています。
（※ この基準は現時点では明確な根拠があるものではありません。今後運用の中で調整していきます。）

最後に、評価媒体はGoogle スプレッドシートを利用することにしました。使い慣れたツールで、誰でも手軽に記録・管理できるようにすることで、導入のハードルを下げる狙いがあります。

以下で具体的な実施手順などを紹介していきます。

不安ニングポーカーの詳細

実施手順

各不安カテゴリに対し、チームメンバーで「せーの」でポイントを入力する
数字がバラけた場合、その理由を話し合う
共通認識が取れたら再度ポイントを入力し、平均を算出する
ポイントをもとにQAチームに相談するか判断する

不安カテゴリ

フィーチャー(ドメイン)特性による品質担保の不安
テストプロセス（戦略・計画・設計など）に対する不安
テストの実行に対する不安
リリース計画に対する不安
リリース後の不安
※「テストの実行に対する不安」はこれまでの相談依頼で特に多かった内容なので「テストプロセス」から切り出してカテゴリとして明記しました。

QAチームに相談が必要となるポイントの基準

特定の不安カテゴリの平均ポイントが8以上
合計ポイントが30以上
もちろん上記未満でも相談OK

活用タイミング例

新しいフィーチャー開発の着手前後
テスト開始前
日々のスクラムイベント（プロダクトバックログリファインメント、レトロスペクティブなど）
その他、品質保証面に不安を感じたタイミング

実際の不安ニングポーカーのスプレッドシートのスクリーンショット。人ごとにポイントを入力できる欄とメモ欄がある。 — 不安ニングポーカーのスプレッドシート（例）

不安ニングポーカーをやってみた結果

不安ニングポーカーを実施した開発チームから以下のようなフィードバックが得られ、狙った効果が正しく発揮されていると感じました。

相談依頼の基準としての参考になった
議論のフレームワークとしてとても便利
この活動を通してメンバーが抱いている不安を共有できて良かった
実際にチームで試してみて、チーム内の認識やズレが明らかになった
moreな点として、不安が低いときでも参考資料を提示し、ネクストアクションにつなげられると良い

不安を可視化することで開発チーム内で議論が生まれ、各メンバーが感じる不安を共有しやすくなりました。また、開発チームが品質保証について改めて考える機会を増やせたことも大きな成果の一つです。

今後の展開

今回紹介した不安ニングポーカーは、期待した効果がすでに出ている一方で、さらに活用の幅を広げる余地も見えてきました。今後は不安を感じたときだけでなく日常的に気軽に使える仕組みを整えるなど、より多くの開発チームに活用してもらえるよう改善を進めていき、効果的なサポートができるよう取り組んでいこうと考えています。