開発終了後ではなく、序盤からQA(品質保証)エンジニアに関わってもらおう。一時的でも良いのでチームに入ってもらうのもよい。テストだけでなく、仕様や設計についても一緒に考えていこう。
開発チームでは3カ月前からスクラムを採用し、スクラムガイドに記載されている役割やイベントは忠実にこなしている。開発にリズムが生まれ、スプリントごとにチームが成長している実感がある。
しかし、アプリのリリース頻度はほとんど変わらず半年に一度のままである。リリースまでの半年間の内訳は以下の通りだ。
開発チームと品質保証チームは組織が分かれている。チーム間のやりとりが発生するタイミングは開発プロセス終了時、主に仕様書などのドキュメントを介して行われる。この組織構成や開発フローは数十年前から続く、ハードウェアの開発フローをコピーして作られたものである。ハードウェア開発の特徴として、後から変更することが困難なこと、安全面に熟慮が必要なこと、業界の規格があること、などがあり、厳しいチェックを必要としている。ソフトウェア開発においても、責任ごとに部署を分け、前工程が終わったら後工程に引き継ぐやり方を踏襲している。
現状、開発プロセスが終わり品質保証プロセスに入ると「ドキュメントが不足しているので仕様を把握できず、テストができない」と言われ、追加でドキュメントを作成することが毎回発生している。テスト終了後はバグ修正を行っているが、手戻りも大きいため修正と修正後の確認に時間がかかっている。
これ以上開発チームのみで改善を繰り返してもリリース頻度がほとんど向上しない。向上しないだけにとどまらず、この状態が続くと開発チームと品質保証チームの関係が悪化していく。その結果、リリース頻度は悪化していく可能性もある。
開発チーム こんなに頑張って開発しているのに品質側はなぜ協力してくれないのか! 私たちだけでもさらに早く機能を作っていくしかない!
品質保証チーム 開発側が出してくる低品質な状態でリリースできるはずがない! これからはもっと細かくチェックしないと……。
まずはQAエンジニアと相談の場を設けよう。そして開発後ではなく、開発前から協力していくやり方を模索しよう。開発チームに入ってもらうのも手だ。開発チームと品質保証チームが異なる部署の場合、一緒のチームに入るのは難しいこともある。そんな時は、週に1日でも一緒に活動できるようにしよう。
スクラムを採用している場合、スプリントプランニング、スプリントレトロスペクティブ、リファインメント※)の活動に参加してもらうのもよい。さらに具体的なアクションとしては以下に挙げるような活動が効果的である。
このようなアクションを行い、開発開始前に認識を合わせ、無駄な作業や手戻りを減らし、本当に必要な作業に集中しよう。きっとリリースにかかる時間を改善することができるので、アクション前後の変化も計測しよう。
品質の観点から開発チームが十分信頼できると判断した場合、QAエンジニアの関与を徐々に減らしていってもよい。
※)リファインメントはスクラムの5つのイベントとは別の活動である。プロダクトバックログアイテムを分割/詳細化を行ってやることを明確にし、自信を持って次のスプリントで着手できるように準備を行うものである。他のイベントとは異なり、実施するタイミングは定義されていない。
開発チームと品質保証チームの信頼関係が強くなっている。開発チームは品質保証の考え方やスキルをQAエンジニアから学び、QAエンジニアの補助がなくても品質の高いソフトウェアを開発することができるようになっている。品質保証チームは開発チームが実践しているアジャイル開発についての理解が深まっている。
品質保証のプロセスがスプリント内に溶け込んだことにより、終盤に実施していた膨大なテスト実施&修正が激減し、以前より素早くリリースできるようになる。結果的に、ユーザーのフィードバックを受け取る回数が増え、よりユーザーが求めていたものに近づくための学習が進んでいく。
また、計測したリリースにかかる時間といった数値は、一目で確認しやすい性質もあるため、周りの懐疑的だった人が協力的になってくれることもある。
Copyright © ITmedia, Inc. All Rights Reserved.