本記事について
JaSST'21 Tokyo (JaSSTソフトウェアテストシンポジウム-JaSST'21 Tokyo)
B6）企画セッション
「アジャイル開発にQAはホントに要らないのか？」
の聴講メモです。
パネリストの方々を紹介します（敬称略）。
風間 裕也（WACATE実行委員会）
河原田 政典（グロービス）
島根 義和（ピクシブ）
城本 由希（エムスリー）
西 康晴（電気通信大学）
議論はにしさんがモデレータとして問いかけを行い、パネリストがそれに応える形で進みました。問いかけの概要は各発言の冒頭に組み込みました。
【参考】としている箇所は私が挿入しています（補足や参考資料など）。登壇者の講演内容ではありませんので、その旨ご了承ください。
議論メモ
（マーク（河原田））
「ビジョナリー・QA」という記事を書いた。
ビジョナリー・QA：グロービスQAチームの理想と3つのゴール｜グロービスデジタルプロダクト開発組織｜note
品質をQAチームだけが保証すればよいというものではなくなった。チーム全員で品質を作り上げるのが大事なのではないか。
（島根）
今回はQAチームが独立している必要はないのか、というのが議論のポイントになる。
（ブロッコリー（風間））
QAチームの役割、また各国の状況（世界の動向）について。
チームの中にQAチームがいる。テストをテストチームに丸投げするわけではない。QAチームはテストのやり方をコーチングする。
スクラムの定義にテスターやQAは存在しない。開発者の一員・ステークホルダーの一員として参加する。
テストの考え方が得意な開発者、として参加している。テストの専門職として存在しているわけではない。
（島根）
日本の動向について。
シーケンシャルの開発プロセスにおいて、QAがいなくなることは無いだろう。プログラマーとテスターは別職能として存在している。テストチームがいなくなるということは、テストする方がいなくなるということ。
テストチームがいるから品質が高かったかというと微妙だ。専門職がいるから品質が高いとは一概に言えない。
とある金融系の業務はプログラマー60名、テスター100名のような体制で大量のテストをこなしていた。だが、テストの責任者（専門職）はいなかった。
（島根）
ピクシブでは開発者だけでなく、プロダクトオーナーもテストを行う。
テストエンジニアというロールは無くなっても良いのではないか。ただ、チームにそのスキルが備わるまで、QA・テスト専門家は必要だろう。
（城本）
エムスリーでは各プロダクトに対して専任のQAチームが付く。
プロダクトごとに事情がある。その事情に合わせ、専任のQAチームがテスト方針を決める。QAチームにはテスト技法の考え方などの知見が求められている。
開発者には自分が作ったものに対して間違っていないという思い込み（認知バイアス）があり、そこを補正するためにQAが必要と考える。
（マーク）
なぜQA不要と考えるに至ったかについて。
QAの考え方はシーケンシャル開発が源流にある。製品をリリースした後のアップデートが容易ではないので、リリースまでに品質を最大限高める必要がある。
次にアジャイル開発の視点で考える。開発の初期はスコープ（機能）を限定しており、開発者が品質に責任を持つことになった。
シーケンシャルからアジャイルへ移行することでパラダイムが変わった。
（ブロッコリー）
※ブロッコリーさんよりご連絡をいただき、記述を修正します (2021/03/22)。
https://twitter.com/nihonbuson/status/1373793143389220868
品質保証とQAは違う。
ゲートキーパーは品質保証の考え方。
品質を作り込む、よりよい設計をする、というのがQAの考え方。
これらの手段としてテストがある。この手段は品質保証とQAの両方に適用できる。
品質保証は人によって考え方が違う。（品質保証＝QAだと思っている）
品質保証の考え方として、ゲートキーパー的な動きをする人もいれば、品質を作り込んだりより良い設計をするところから入り込む人もいる。
関連資料を以下に挙げる。
（城本）
カスタマーセンターに問い合わせのあったチケットの権限・ロールの範囲が自分の役割を超える場合でも気にしている。
（島根）
プロダクトに深くコミットしていると、自身の担当と直接関係のないチケットでも気になる。プロダクトに関する知識を深く知っておくと開発する時に楽だから。
プロダクトに対する愛があれば、品質が気になる。組織の縦割りで直接関係しない場合は非公式に聞いたりする。
（マーク）
QAはテストを包含するのか？QAとテストは何が違うのか？
モダンテスティングでは従来のテストの領域を超えている。
Modern Testing – Not that modern, and not that much about testing
（ブロッコリー）
モダンテスティングの広まりについて。海外でもまだそこまで聞かない。日本ではマークさんが広めている。
ただ、その考え方自体は広がりつつあるのではないか。テスティングマニフェストでも同じような観点が含まれている。
テスティングマニフェストはQAとか品質保証を対象にしているといえるかもしれない。
【参考】
【翻訳記事】テストに対する考え方「Testing Manifesto」 - ブロッコリーのブログ
（マーク）
モダンテスティングの提唱者はテストの専門家ではない。また、QAについて語っているように思える。
この背景として、海外では「テスター」の定義が広いこともあるかもしれない。
（島根）
日本ではテストという用語の領域が広まる感じはない。
日本ではテストに対する価値が低いのかもしれない。テストにも技術があるということの認識が無いのかも。
（マーク）
海外のテスターは自分の仕事（専門性）にプライドを持っている。
（にし）
テスト担当者が組織からいなくなっても本当に大丈夫なのか？
（マーク）
理想論といわれるのはよくいわれるし、その側面はあると思う。ただ、完全に実現しないものでもないと考えている。
（島根）
ピクシブ唯一のQAエンジニアとして何をしているのか？という質問に対して。
テストに詳しい人、という立場でいる。明確に権限があるわけではないので、テストコンサルとして各チームへの支援を行っている。
（マーク）
開発者にテストの技量が上がれば、（日本の意味でのテスト実行者としての）テスターを今ほど必要としなくなるのではないか。
（城本）
テスト実行者は減っていくだろう。
そうして残ったQAはテストコンサルのような役割にシフトしていくだろう。
（ブロッコリー）
テスト実行者のキャリアパスについて。テスト実行者が求められなくなったら、テストの高度な技術・スキルが求められる方にシフトしていくだろう。
（島根）
アジャイルの開発をしているからといって品質が良いわけではない。
テスターの離脱があれば、一時的にテストが滞ることがあるだろう。
アジャイルのスピード感でリリースするのであれば、人手のテストは非現実的。自動テストを導入し、維持するためのQAが必要になるだろう。
（ブロッコリー）
テスターがいなくなって本当に混乱するだろうか？その時はスピード（ベロシティ）やスコープが減るだろう。そして、開発者が何とかしなければと、モチベーションが上がるのではないか。
（城本）
開発チームの品質に対するスキル次第ではないか。品質やテストに対する基本的な考え方のある方がいれば、自分たちだけで立て直しが可能では。
品質文化を作るには品質を重視することで結果としてプロダクトが早く出せる、という意識を持ってもらうことでは。
（ブロッコリー）
リリースしたけどバグがいっぱいだった、というようなタイミングを見計らって、開発チームへアドバイスする。そして成功体験を持つことで意識が高まるのでは。
（島根）
事実を集めて、開発チームに対しこの状況は良いのか悪いのか、というのを考えてもらっている。
（マーク）
各チームの立ち位置による。これでいいと思っているのか、問題意識を持っているのか。
そのうえでQAチームがそれに合わせてアドバイスしていくなどはある。
（にし）
今回の議論の内容をまとめる。
Q & A
Q.
チームに寄り添うというのはとても共感したのですが、こちらが寄り添おうとしても向こう側が突っぱねる時もあると思います。そんな時はどんな風に対応されるのかを聞かせてもらえると嬉しいです。
A.
（城本）
相手にとってメリットのあるところから寄り添う。
（ブロッコリー）
相手にとって押しつけと感じられないように、どこに課題があるかを聞くと、お互いに寄り添い合えるのでは。
（マーク）
テスト担当者が開発担当者の立場の視点で見てみる。
（島根）
当初はテストで困っていません、と言われてしまった。いったんは引き下がり、情報を仕入れて、大きなトラブルがあったときに何か協力できませんか、と提案している。
Q.
風間さんへ質問です。ゲートキーパーの仕事には例えば要件定義のドキュメントレビューも含まれると私は考えていましたが、風間さんはどのようにお考えでしょうか？風間さんのお考えはレビューはどちらかというとQAの役割のようにも聞こえたので、質問させていただきました。
A.
（風間）
レビュアーはQAだけの役割ではない。ただ、レビューへの関わり方の違いがある。ゲートキーパー的なレビューもあるし、途中経過でのレビューもある。
Q.
テストに関する知識・スキルをあまり持たない開発者が多いのはなぜなんだろう。
A.
（島根）
個人で作っているとそこまでテストが求められない。その延長で興味が持たれないのでは。
実際の仕事をやらないと、業務全体が見えず、興味がわきにくいのかもしれない。
Q.
POよりQAのほうが仕様に関する知識を持っていることが多い気がします。
A.
（城本）
QAは製品を触る機会が多く、自然と仕様に詳しくなる。
POも細かい仕様まで気を配るべきだが、QAのほうがどうしても製品を触る時間が長いため、という差かもしれない。
Q.
多くの開発者がMacを使ってて、テスト実行にはWindowsが必要になるときがあると思うのですけど、開発者もWindowsの環境用意して検証する必要あるということなのでしょうか？
A.
（マーク）
必要があれば用意しないといけないだろう。
（島根）
開発環境とテスト環境は分けてもよいのでは。ただ、一緒にできるのであればそれに越したことはない。
Q.
ここで言っているQAは、QAという組織・ロールを指しているのか？QAという機能を指しているのか？この整理をしてほしい。
A.
（にし）
今回はわざと整理していない。この議題を取り扱うなら別セッションとしないといけない。
Q.
1つのサービスに対して複数のスクラムチームがあると、品質に関しても個々のスクラムチームの部分最適が全体最適だとは限らないので、この観点で調整する横断的QAチームは必要なんじゃないかと思うのですが、そういうQAチームもいなくなりますか？
A.
（城本）
必要だと考えている。POは気にする範囲が広いので、横断的なQAが必要になるだろう。
（ブロッコリー）
スクラムの原理原則であればPOは1名置くことになっている。POが品質まで考えれば横断的なQAは不要かもしれない。ただ、現実的なことを考えると横断的なQAは必要かもしれない。
（マーク）
大規模スクラムのフレームワークで横串のQAについては触れられていない。この観点から考えると何か見えるかもしれない。
（島根）
複数のプロダクトを見ている立場からすると、個別最適化している部分はある。その中でも最低限共通で守ってほしいラインを定義しようとしている。
Q.
QAはQAチームだけでやるものではない、というのは同意です。ただある程度の高信頼性を求められる開発では、プロダクトデプロイの品質保証のために、規模のあるテストがどうしても発生します。それを処理するQAチームが残るのではないかと感じました。
A.
（城本）
残るのではないか。
（マーク）
高信頼性にどこまでコストをかけられるかにもよるのでは。
（ブロッコリー）
海外の事例としては開発者自身が信頼性についても考えているように見える。
（島根）
現時点では各プロダクトチームに任せている。だが、チームの手に余るときはサポート依頼があり、設計から実装まで担当している。
