技術を土台にして自分なりのQAエンジニアを目指す本連載の第7話のテーマは「スクラムマスター」の専門性です。
これまでの連載では、テスト設計、テストマネジメント、テスト自動化といった、テストエンジニアの職能に直結するいわゆる「王道」の技術についてお話ししてきました。
しかし今回は、少し視点を変えて、チーミングの領域、特に私が学び・実践してきたスクラムについて深掘りしたいと思います。
皆さんは、アジャイルやスクラムに対してどのようなイメージをお持ちでしょうか？
私がスクラムという概念に初めて触れたのは、市谷聡啓さんの著書『チーム・ジャーニー』がきっかけでした。本の中では、バラバラだったチームが対話を重ね、困難を乗り越えていく姿が描かれています。
■チーム・ジャーニー 市谷 聡啓 著／翔泳社
「アジャイルとは、チームを輝かせる手法なんだ」「あらゆる問題が起こりながらも、チームで向き合う現場で働きたい」。
ひと昔前には「キラキラQA」という言葉が使われたこともありました。私自身、そうなりたいと強く願ったことを覚えています。
しかし、実際に現場でスクラムをやってみると、現実もまた簡単ではありませんでした。 本を読んでトラブルを追体験することと、現場の当事者としてトラブルの泥を被ること。その間には、大きな差があったからです。
そして、「QA」あるいは「テスト」という専門性をその環境で発揮するためには、「スクラム」というフレームワークやその背景にある「アジャイル」を謙虚に学び続ける姿勢が必要だと考えました。
記事一覧：技術を土台にして自分なりのQAエンジニアを組み立てる -あるQAの場合
スクラムマスターの専門性
本来、スクラムマスターは「チームの成果」に責任を持つ重大な役割です。
私はQAエンジニアであり、スクラムマスターそのものではありません。しかし、彼らが持つ「チームを支援し、障害を取り除く」という視点やスキルは、私たちQAにとっても学ぶべき重要な「ふるまい」だと考えています。
本記事ではスクラムマスターのふるまい、あるいは専門性を以下のように捉えます。
アジャイルソフトウェア開発が実現したい”状態”を理解し、その実現のためにチームの一員としての具体的な支援が可能であること
もちろん、実際のスクラムマスターの責務は、障害物の排除やチームの集中支援など多岐にわたり、本記事の内容だけでは収まりきりません。ここで語る専門性だけで「スクラムマスターになれる」わけではないことは、あらかじめお伝えしておきます。
アジャイルにおける「テストを分業する」ということ
“QAエンジニア”が存在し、かつそのチームが”アジャイル”を標榜しているとき、「プログラマーが作る人」「QAはテストする人」という明確な境界線が引かれてしまうケースは少なくありません。もしかしたらプログラマーだけが「開発者」と呼ばれているかもしれません。
しかし、アジャイルの価値観において、この分業は時に過度であり、「毒」にさえなり得ると考えます。
「それは私の仕事ではない」「仕様は誰かが決めているはず」。 こういった考えが蔓延すると、アジャイルチームであるはずが、いつの間にか「プロセスやツール」を「個人との対話」よりも優先するようになってしまいます。
QAがアジャイルを形骸化させる
こういった現象が起こる背景には、導入の動機が関係しているのではないでしょうか。 つまり、「顧客満足」や「自己組織化」といったアジャイルの価値観への共感ではなく、「”ウォーターフォール”が嫌だから」という消極的な選択の結果であるケースです。(そして、多くの場合、”ウォーターフォール”への理解すら十分でないことも多いでしょう)
スクラムは、シンプルかつ軽量で、無料で公開されている、気軽に適用できるフレームワークです。
スクラムを適用したその結果、例外なく多くの問題に直面すると思います。しかし、それはチームが真剣に向き合っているからこそ起きる、避けては通れない壁なのだと思います。
問題に直面したとき、そこから学習し、適応しようとする姿勢を失ってしまうと、いわゆる“なんちゃってスクラム”に陥ってしまいます。（私はこの言葉があまり好きではありませんが、状況をよく表していると思います）
集中力を欠いたデイリースクラムや、心理的安全性を履き違えたレトロスペクティブ。 これらは典型的なアンチパターンですが、見方を変えれば、スクラムを実践しようとした結果として表出した課題であり、ある程度の成熟度があるからこそ見える問題だとも言えます。
恐ろしいのは、形骸化したアジャイルチームに加えてQAエンジニアという専門職がいることで、「品質はQAの仕事だよね」という分業が加速し、“開発者“の品質への責任感が薄れてしまうことです。
そのようなチームでは、誰もが品質を気にかけたいと願っているのに、構造的に「誰も品質に責任を持てない」。そんなもどかしい状況に陥ることが少なくありません。
これに対して私はどうしようもない停滞を感じてしまう時があります。
「動くソフトウェア」を共通言語に、開発プロセスを再構築する
構造的に品質に責任を持てない、そんな停滞した空気の中で、現状を変えるきっかけを作れるのが、私たちQAエンジニアだと考えています。
なぜなら、私たちには「動くソフトウェア」という共通言語があるからです。
「QAエンジニアはテストを考えて、バグを見つけることに責任を持つ」という考えはアジャイルにとって悪い方向に作用しうると考えます。テスト技術の真価は、バグを見つけることだけではありません。プロダクトの現状をありのままに映し出す「透明性」を確保することにあります。
続きを読むにはログインが必要です。
ご利用は無料ですので、ぜひご登録ください。
