2022.11.04

アジャイル開発においてQAはいらないのか？

著者株式会社SHIFT　マーケティンググループ

Introduction

アジャイル開発におけるテストはアジャイルチーム内で実施すればよい、よってQAチームによるテストは不要、という意見を聞くことがある。確かに、スクラムガイドに書かれているのは『開発者』であり、QAという役割は定義されていない。しかし、果たして本当にQAという役割は不要なのだろうか？

開発者がテストすればいい？

スクラムガイドの『開発者』に対するとらえ方は人それぞれだ。多くの人は、『開発者』をプログラマーのようにとらえる意識が強いように思う。しかし、スクラムガイドでは、開発業務に必要なメンバーを総じて『開発者』と表記している。すなわち、開発者はデザイナーであり、プログラマーであり、QAでもありうる。前述のように、開発者をプログラマーだけと意識すると、プログラマーはリリースまでのすべてのタスク(UIデザイン、コーディング、テスト全般など)をこなす能力が必要になってくるだろう。そのため、プログラマーに求められるレベルは高くなってしまう。その結果、すべてに精通した人材を求めようとするケースをよく見かける。

さまざまな役割に精通した開発者はいない？

さまざまな役割に精通した人材を求めるのは１つの正解であるかもしれない。ここでは、そのような開発者をオールラウンダーと呼称する。
しかしながら、オールラウンダーを探す場合に採用と育成の２つの問題に直面する。採用面ではレベルが高すぎて見つけることができない問題があり、育成面ではオールラウンダーの育成がむずかしい問題だ。

レベルが高すぎて見つけることができない

オールラウンダーは転職市場を見渡しても少なく、ほとんど見つからない。転職市場にいない人材を採用しようにも時間がかかってしまい、ビジネスとのスピードを考えるとミスマッチが起きる。仮にオールラウンダーを採用することができたとしても、プロジェクト管理をせざるを得ない状況になることが多いため、本来の力を発揮することができずに、期待通りのパフォーマンスや成果を出すことができない。

オールラウンダーの育成はむずかしい

オールラウンダーを育成する場合、さまざまな領域の能力を育成する必要がある。例えば、新規領域の開発を立ち上げるときには必要な知識が多岐に渡るだろう。さらにオールラウンダーはいろいろなことを学ばないといけないので育成には時間がかかるはずだ。メンバーを増やさないといけないスピードと育成速度にミスマッチが起きた結果、目的を達せずに失敗に終わる。サッカーでキーパーが別のポジションをやることは少ない。やらせたところで試合に勝てないことは容易に想像がつくが、現実そういう対応をとっている。
そうすると、能力値が求めるレベルに達していない中途半端な開発者となってしまう。その結果、さまざまな役割に精通した開発者を求めたときに、この開発者は残念ながら対象外となる。
また、開発者として成長していくなかで各分野の知識や経験を積んでいくとプロジェクト管理を任されることが多い。現場経験よりもマネジメントスキルを求められるようになるため、オールラウンダーを目指せる開発者が少なくなっている。

一人のオールラウンダーではなくオールラウンドなチームを目指す

オールラウンダーは簡単には手に入らない。また、オールラウンダーの割合が少なければ少ないほど、オールラウンダーが管理コストを払わなければならなくなり、本来出せるはずだった成果を出せなくなってしまう。
この問題に対処する一つの解決策を見ていこう。

一人のオールラウンダーが率いるチームはプロジェクトリスクが高い

プロジェクトリスクの一つの要因に作業と知識の属人化があげられる。属人化が起きる背景の一つとして、作業レベルに分解してそれに個人がアサインされるため、個々の作業に閉じてしまい、結果にたどり着くまでの経緯をチームに共有することができない。個人で作業を実施すれば当人に知識が蓄積されるが、チームの財産にはならない。知識が個人に蓄積された結果、突発的な休みが発生した場合、本来やるべき業務をチームが巻きとれずにプロジェクトが遅延する。最悪の場合、個人がチームから離脱することになると、その人がもっている知識はチームから失われてしまう。その知識の引継ぎにも時間がかかるうえ、チームにすべての知識を共有することは不可能だ。その人がオールラウンダーやチームの中核であった場合は、プロジェクトの計画見直しを迫られるほど大きな痛手になるだろう。

オールラウンドなチームを目指す

一人のオールラウンダーがチームを率いてプロジェクトを推進するよりも、一人ひとりがそれぞれの領域におけるスペシャリティを活かしながら運営するチームを目指したい。それぞれの領域におけるレベルの高い人材(スペシャリティをもつ人材)が必要だが、集めるべきなのはそれぞれの分野で推進役となる人である。
フロントエンド、データベース、QAなどそれぞれに推進役がいると、お互いの情報や経験、知識、トレンドを共有し合うことでチーム全体のレベルを引き上げることができるのだ。

オールラウンドなチームのスキルと伝播の見える化

それぞれが得意とする知識をチームに共有していく必要があるが、スキルの分類は細かくなることが多く、またそのすべてを洗い出すことはむずかしい。仮に洗い出すことができても、新技術の登場などでメンテナンスに時間がかかる。細かくすべてを洗い出すのではなく、チームでの共通認識をもちながら抽象度の高いところから話をする、もしくは、自分達が得意とする分野を出していくことからはじめていくのがよいだろう。目的は、その分野を見ながらメンバーが伸ばすべき次の分野や、スキルをチームで共有することである。そのときに使うコミュニケーションツールとして、星取表を紹介しよう。

縦がチームメンバー、横が役割と作業とし、それぞれの得意分野や現在のスキル、今後のスキルアップしたい分野を記載した表である。
チームごとに星取表を作成していく手順を紹介していこう。注意すべき点としては、いきなり大きな表をつくらないことである。小さくつくって、足りない部分や分けるべき部分を拡張しながら作成していくことでチームの役割と活動の理解を促す。
星取表のスキルのレベルや記載方法は、チームでディスカッションして相互理解を進めてほしい。表をつくるだけであれば機械的につくることはできるが、星取表の作成を通じてチームがそれぞれの理解をすることが主目的だ。

Step1
メンバーがそれぞれの役割を共有する。チームがつくられたときは、すでに管理者から役割が与えられていることが多い。もし与えられていない場合は、管理者から説明を求めたり、体制図から役割を書き出してチームに共有しよう。

Step2
役割から期待されるスキルや行動を洗い出す。他の役割に期待するスキルや行動もあげていく。この作業を通じて、1つの役割が複数の作業や期待される行動があることがわかるはずだ。このプロジェクトに必要なスキルや経験を列挙しよう。

Step3
スキルや経験に対して、チームメンバーを並べる。メンバー自身の役割ではあるが、できるできない、スキルすべてを網羅できていない、違うスキルで補っている、といったことがあれば記載していく。その際には、できるできないだけではなく、このチーム活動を通じて吸収したいことや、興味がある、苦手、もしくは絶対にやりたくないことをチームメンバーと共有するとよいだろう。

Step4
星取表にあがったスキルにはチームごとに得意不得意がある。作業を進めていくと、チームにいくつかのスキルが足りないことが見えてくるはずだ。この例では、POの『バックログの整理』は斉藤さんの「しりたい」しかなく、チームに不足しているスキルだと判断することができる。足りないスキルが見えるようになってはじめて、チームは不足しているスキルをどう埋めるかを議論できるようになる。例えば、スキルアップで補う、レビューや知見を共有してもらうなどの対策が考えられるだろう。

チームの作業の見える化とスキルや業務の伝達

ここでは、モブワークと呼ばれるやり方を紹介する。モブワークは非同期な作業ではなく、一つのタスクをみんなで進める方法だ。相談やフィードバックがその場でできるため、一人で作業し、レビューを受けてよりよい方法が見つかるといった手戻りが発生しない。タスクの実施方法を決める経緯もチームで共有できることで属人化を防ぐ。また、チームがタスクの進捗を把握できることにより、進捗を共有する時間は不要となる。モブプログラミングやペアプログラミングは開発のやり方で存在するが、モブワークはさらに開発以外のタスクも含めてチームで行う。

モブワークのやり方と注意点

まずは、同じものを見て会話する環境を用意する。オフラインの場合、大きなモニターやプロジェクター(集まれる場所)を用意する。用意ができない場合は、オンラインで対応することも可能だ。リモート環境であれば画面共有をしながら進める必要がある。
その際には、ドライバーとナビゲーターにわかれて進めるとよいだろう。ドライバーとは、目の前の作業を物理的に推進する人(コードを書く、ドキュメントをつくるなど)を指す。ナビゲーターとは、方向性を指示する人である。
いままで個々でタスクを消化し、すり合わせて１つの形をつくる仕事のやり方をとってきているので、この方法は全員の時間を合わせる必要もあり、非効率にも見えるだろう。チームビルディングができていない状態でのモブワークは確かに効率が上がらないが、互いに信頼のおける関係性でのモブワークは相互レビューを行う際のリードタイムを割愛することができるので、効率的だ。
また、あるスキルにおいて能力値の高いメンバーがナビゲーターとして背景や歴史、効率的な方法論やトレンドを語りながら他のナビゲーターとディスカッションを行うことで、知識を継承する。ドライバーはドライブすることに注力すべきであるが、こういった場合には議論に参加してもいい。

技術力とは別に必要な推進力

これまでの開発の現場では、チームリーダーやマネージャーが方針を決めて、個々の技術力をもってつくり上げていくことが求められてきた。このやり方では、個々のメンバーのつくるという技術は高まるが、プロダクトの良し悪しに関してはチームリーダーやマネージャーが責任をもつので他力になりやすい。また、つくっている最中にもつ違和感や気づきに対してプロダクトに還元するタイミングがなく、市場とのギャップでしかフィードバックを得ることができない。そのため、プロダクトの推進に致命的な障害を生み、それぞれの技術を活かせないことがある。
当然、各役割はその専門分野の高い技術力を求める。それとは別に役割の作業をするだけではなく、個人からまわりを巻き込んでプロダクトを推進することも求めるだろう。プロダクトがよい方向に進むように、それぞれの技術力をもってチームでプロダクトを推進していく。

アジャイル開発においてどんなQAが必要なのか

このチームが求めるQAとはどんなQAだろうか。QAは不具合検知のフィードバックにはじまり、PBIをつくる段階でDoneの定義やイグジットクライテリアに対する意見を出していくこと、早期に仕様漏れを潰していくこと、開発者にテストコードを書かせること、テスト活動の整理をすることも必要だ。すべての活動は品質の高いプロダクトをつくることに寄与している。
多くの人は、QAと聞くとまずは『クオリティゲートの番人』を思い浮かべるかもしれないが、QAが貢献できることはそれだけではない。クオリティゲートの番人であると同時に幅広く品質を指南し推進していく必要があるのだ。

アジャイル開発白書 2020をダウンロード

近年、市場の変化スピードやニーズに対応するために高速リリースの重要性が高まり、アジャイル開発を導入する企業が急速に増えています。そこで、SHIFTでは、アジャイル開発を検討中、導入済の企業に対し、課題や成果、プロジェクト体制などについての調査を行い、これから導入される企業様、既に導入されている企業様のプロジェクト成功にお役立ていただけるよう調査資料にまとめました。

ダウンロード

資料ダウンロード/動画視聴

アジャイル開発白書 2020

3分で知るSHIFTのテストサービス

ソフトウェアテスト入門講座

まとめ

QAという役割はなくならない。自身の専門性や推進力を活かして、他の人でもできるように教える活動をするとともに、自身もまた他のことにも詳しくなるように他の人を巻き込んでいく。これは他の役割でも同じことがいえるだろう。冒頭でプログラマーの話をしたが、１つの役割に徹するという意味ではなく新たなスキルをもつことを歓迎している。その例として、星取り表によるチームメンバーのスキルの見える化を説明した。また、メンバーが進みたい方向性をチーム内で共有することもできる。これらの活動の結果として、スペシャリティをもつ人材をつくり上げる可能性が生まれるだろう。

この記事を書いた人

著者株式会社SHIFT　マーケティンググループ

SHIFTは「売れるサービスづくり」を得意とし、お客様の事業成長を全力で支援します。無駄のないスマートな社会の実現に向けて、ITの総合ソリューションを提供する会社です。

サービスサイト：https://service.shiftinc.jp/
コーポレートサイト：https://www.shiftinc.jp/
X（旧Twitter）：https://twitter.com/SHIFT_cp

ご支援業種

製造、金融（銀行・証券・保険・決済）、情報・通信・メディア、流通・EC・運輸、ゲーム・エンターテイメント

など多数

前のページへ

次のページへ

コラム一覧に戻る

アジャイル開発においてQAはいらないのか？

Introduction

開発者がテストすればいい？