アドベンチャーアドベントカレンダー2022の16日目の記事です。初日に書いたんですが枠全然埋まらないのでまた書きました。
誰
株式会社アドベンチャー skyticket品質保証担当です。
僕は新卒で日立製作所のグループ企業に開発者として入社し、日立流の品質保証の薫陶を受けて育ちました。また、第三者検証会社に在籍していた時期も、直属の先輩はやはり日立グループ企業の品質保証部出身であり、開発としてもQAとしても日立製作所の品質保証アプローチに強い影響を受けています。
スクラムと品質保証
さて、僕が日立にいた00年代はまだまだウォーターフォールが主流であり、品質保証もウォーターフォールを前提としたものでした。ところが現在はアジャイルが主流です。アドベンチャーでも、遅ればせながら現在スクラムの導入を進めています。ここで問題となるのが、スクラムにおいて品質保証をどのように行うのか、我々QAはどのように立ち振る舞うのかです。
ウォーターフォールはフェージングアプローチであり、基本的には各工程の区切りでQAが成果物の検査を行います。最終的に製品検査とマニュアル検査が行われ、合格すればリリースが可能になります。これはソフトウェア工場モデルに基づくシンプルながらよく機能する形ですが、中間工程を持たないアジャイル開発には当然適用できません。それなら中間工程の検査をなくして最終成果物の検査だけをやればいいかというと、それはリスクが大きすぎます。品質に関するフィードバックはもっと早くから行われるべきです。
人によってはQAはステークホルダーであると位置付けるケースもあるようですが、僕はもっとスクラムに深く入り込み、より積極的な品質保証活動を行うべきだと考えています。
というわけで、あれこれ考えた結果を図にしたものがこれです。
まず前提知識として、検査は成果物の品質を直接確認する直接検査と、プロジェクトの管理状態を確認する管理検査に大別されます。
スクラムにおいては、管理検査は特定の工程として行われるのではなく、スクラムがルール通りに機能しているか常に確認し続ける必要があると考えました。スクラムではプロジェクト管理はドキュメントベースではなくコミュニケーションベースになりますから、QAもスクラムイベントに欠かさず出席し、ルール通りに事が運んでいるかを確認し続けることが望ましいと考えます。
一方で直接検査ですが、スクラムでは各スプリント毎に実際に動作する成果物ができます。一般的にはプロダクトバックログアイテム（PBI）単位でスプリントレビューでデモが行われるはずです。であれば、完成したPBIを片っ端から検査していけば直接検査は成立するのではないかと考えました。また、エンドゲームにおいてはリリース可能なプロダクトが完成しているはずですから、そこでシステム全体を対象とした最終的な直接検査を行えば、副作用やデグレードがないことも担保できます。こうして、PBI単位の検査による迅速なフィードバックと、エンドゲームにおける最終検査によるウォーターフォールの時と同水準の品質保証を組み合わせるのが、スクラムにおいては望ましい形であろうと考えています。
アイデアは整ったので年明けからこの運用を開始します。細工は流々、仕上げをご覧じろ。
参考図書
この記事の内容は以下の書籍に大きな影響を受けています。