いま帰省中でスマホから書いているのでレイアウトが崩れていたらすみません。
今回言及したいのはこちらの記事です。
https://note.com/usk_ymst_p/n/n4de0aac50059
この記事に書いてある質問に勝手に回答していきたいと思います。
私は誰か？というと、以前、某製造系IT企業でQAエンジニアをしていたものです。にしさんの資料でいえばフェーズゲートQA、TE、QAに近い役割だったと思います。紆余曲折あって今はクラウドサービスのインフラ運用エンジニアをやっています。
長らくQAの実務からは離れていますし、最近はQA系の勉強会に参加していないので、文脈がわかってない部分が多いし間違いを多く含む回答になると思います。
ですが、勉強会からしばらく離れていた僕ですらワードは何度も聞いたQMファンネルの考え方は、個人的には非常に大切な考え方のように思います。
なので、私の間違いを多く含む記事を叩き台として、多くの議論がなされることを望みます。QA、テストに関する業務をしている方、これに興味を持って読んでいる方のご意見を伺いたいです。
原典はこちら
QAエンジニアってなんだろうってなんだろう
スクラムにQAが必要かどうかは 「スクラムガイド」に書いてあるんじゃないでしょうか？
QAエンジニアがどんなロールかわからないのはスクラムだけの話なんでしょうか？
QMファンネルってスクラムの文脈だけで通用する概念なんでしょうか？
ごめんなさい。このあたりは僕がスクラムの開発をやったことがないので全然わからないです。有識者の見解求む。
品質文化ってなんですか？
チーム全体で品質文化が浸透していて何が嬉しいんでしょうか？
QA"系"エンジニアとQAエンジニアの違いってなんなんですか？
品質文化とは「品質って大事だし、守らないといけないよね。上げていきたいよね」という共通認識があることだと思います。
対極の例を上げるなら「納品して客から金がもらえるなら、品質なんかどうでもいい。品質は余ったコストとスケジュールで余裕があれば考えればいい。ユーザビリティ？知るかそんなもん」というのがアンチ品質文化だと思います。
なので何が嬉しいのかと聞かれればそれは「長期的に見たらそっちの方が利益が上がりやすい」ということだと思います。品質を意識することで作業のミスは減り、プロダクトにバグを作り込みにくいプロセスを考え、納品前に未然にバグを効率的に発見、修正する仕組みを入れることで顧客からのクレームも減り、ユーザの体験もよくなるかもしれないし、開発コストが減ることで利益率も上がります。 フィリップ・B・クロスビー氏のいう「quality is free」ですね。本来ならば品質を考えることは決して無駄なコストなどではなく考えれば考え抜くほどに無駄なコストは削ぎ落とされプロダクトとしての魅力も上がり企業としての利益もどんどん上げられるようになるーー と、私は考えています。
QA"系"エンジニアについては、文脈的には「QAっていう明確な役割を割り当てられてはいないけど、テスト自動化に詳しかったり、CI/CDの面倒をみてたり、テスト設計のレビューで「前に似たようなバグあったし、ここもテストしといたら？」と妙に鋭い指摘をいつもしてくれたり、といった品質に貢献する系の活動に得意分野が多いエンジニア」のことだと思います。
どんな活動でも品質には貢献してるだろ！ふざけるな！という意見が出るかもしれないですが、だからこそQA「系」って言ってるんじゃないかなあと思いました。
なんでQA系の技術に熱心なチームとイマイチなチームがいたりするんでしょうか？
組織全体でQA系の技術を高める必要性ってなんですか？QAだけがQAしてたらなんでダメなんですか？
それは品質を考えることは必然的に長期的なアプローチをとることが多く、短期的には損をするように見えることが往々にしてあるからだと思います。
バグの報告をそもそもしてないチームがバグ分析を始めるには、そもそも今までやっていなかった「みつけたバグを報告する」という仕事が増えます。これは手間が増えてますよね？なので「品質改善なんて考えてるヒマがあったら、さっさと新規プロダクトをリリースしろ！」となるわけです。これは言わずもがな「QA系の技術に熱心ではないチーム」です。バグ分析の勉強会なんて全く興味を示さないでしょう。
QAだけがQAしてたらなんでダメか？というと、品質改善や品質保証を考えていったときにQAにできることには限りがあるからです。
これはたぶん後々の質問でも似たようなことを回答するような気がしますが、基本的な考え方として「バグは後から見つけるほど対処コストが高い」です。お客様からクレームがあれば、組み込みソフトなら最悪リコール、億単位の負債。それが納品直前にみつけられたなら、納品を遅らせてリコールは免れますよね。それがシステムテストで見つけられたら、納期遅らせなくてもチームが頑張って残業してリリースに間に合うかもしれない。単体テストなら担当者が「やべ！」って気づいて直せばOK。設計段階なら「次の打合せまでに直してきますね」となるだけ。不具合は早めに見つけるに越したことはないし、もっと言うなら作り込まないにこしたことはないのです。
と、ここまでの前提で「QAだけがQAする」とすると… あれ、QAって設計段階には関与できるんでしたっけ？仮に設計レビューには参加できるとして、コードのリポジトリは共有してもらえるのだろうか？それをQAが「ここ違うよ」って指摘できる？… と、こういう感じで、品質のことをQAしか考えてない組織でQAするというのはほぼ不可能だと思います。理想は「全社的品質管理」なんじゃないかな？と個人的には思います。品質のためにできることというのは、様々なロールに散在していると思いますし。
品質戦略なんてマネージャーが決めるもんじゃないのでしょうか？
なんで「担わされる」なんて表現するんでしょうか？
僕もマネージャをやったことないのでなんともいえませんが「品質戦略はマネージャが勝手に決めるものである」とすると、違和感があります。
僕の思想は先述のとおり「あらゆる立場のひとが品質に対して高い意識を持ちフラットに意見できることが望ましい」というものなので、マネージャが「今期はこれでいくわ。」と勝手に決めたもので簡単に品質保証できるわけないだろと思います。1人で品質保証戦略立ててきて「この通りやってね」でうまくいってるところ、みたことありますか？私はないです。
品質保証の戦略というのは前述のとおり多岐にわたる領域で検討を進める必要があると思っていて、コードの状況もわかっていないといけないだろうし設計メンバーのスキルもわかってる必要があるし今のテストの状況も知ってる必要があるし、そのうえで世の中にはどんな品質保証のアプローチがあってウチの組織にマッチしそうなのはどんなアプローチで…というところも考えなくてはいけないし、とてもじゃないけどマネージャの業務に忙殺されている人が片手間で考えられるものではないと思います。よく知らないですがマネージャのメイン業務はメンバーの育成とかコミュニケーションとか経営層からの意識の伝達とか、各種成果物のレビューと承認とか、そのあたりなのではないでしょうか。
僕の中で品質保証戦略を立てるというのはこちらの資料でいう「QAアーキテクチャの設計」のことだと思っています。責務としてはマネージャが担うかもしれませんが、「マネージャが1人でやる」はさすがに無理だと思います。
https://www.slideshare.net/slideshow/qa-67559281/67559281
QA系エンジニアのロールを整理する必要がある
えっ唐突
これが出てきたのは先述のとおり「QAが全部やればいいんじゃないの？」って思う人が多いからそうじゃないこともあるよってことが言いたかったんじゃないかなと思います。しらんけど
開発と別組織ってどういう状態ですか？
QAの実業務ってなんなんですか？
出荷判定はこの下のロールにないけど、フェーズゲート・QAサービスにしかできないんですか？
開発組織に常駐したら出荷判定できない理由はあるんですか？
これは私は経験があるので回答できます！これは「独立性の担保」が目的です。
一番「別組織」なのは「第三者検証会社に発注」です。これはいうまでもないですね
僕が経験あるのは「品質保証部」という開発チームとは別の部署にいたことがあります。フロアも分かれてたし、打ち合わせがなければあまり頻繁に会話もしてませんでした。
これ、何がしたいかというと「悪意を持ってバグを見逃す、みたいなのを防ぎたい」というのが一つの理由としてあります。開発チームが内部でテストをしてたら、バグを見つけてチーム内で報告しても「みなかったことにしよう。」ができます！
それが外部の部署だったらどうでしょうか。結構難しいのではと思います。（というか、開発チームに忖度してバグを報告しないQAなんて、いてほしくありませんね）それが第三者検証なら？まず無理でしょう、バグはバグとして報告されます。それが仕事ですから。
こういった「カッチリした」出荷判定は往々にして金融系やら公共系やら、バグが深刻な影響を生むことが多いところでよく採用されています。
なので、別に開発チームでも出荷判定はできます。事実いま私のいるチームでは開発チームが出荷の判定をしてます。ただそれをやりたくなくて、なるべく独立性の確保されたところで出荷判定をやりたいというニーズがあるのです、先に述べたようなところで。
公共系の大規模案件で重大な障害があって、原因追及をされたときに「開発チームが自ら出荷の判定を行っていた」と報告したら「第三者の目を入れるべきだ！」と提言されるのは想像に難くないと思います。
独立性についてはSQuBOKに記載があった気がする…いま手元になくてわからないけど
ちなみに僕がQAの実業務としてやっていたのは、設計書やコードのレビュー、テスト計画の作成、テストの設計と実行と報告、あたりです。
開発組織に常駐するかしないかってなんでそんなに大事なんでしょうか？
QAコンサルタントが品質文化に関わらないのはなんでですか？
そもそも開発組織の常駐具合をこんなに識別する意味はなんでしょうか？
とても大事だと僕は思います。常駐するかしないかで得られる情報が変わりますし、先述した独立性も変わりますからね。
たとえばチームにいたら世間話もできるしプロダクトの品質保証のヒントを得られるかもしれないですよね。そのかわり独立性は失われ、仲良しのプログラマを残業させたくなくてバグをあえて見逃すかもしれません。
コンサルタントなら別に常駐してもらうメリットはなくて、むしろ第三者的な目線でみてもらうべきでしょうから、常駐はあんまりよくないんじゃないかなあとなんとなく思います。お金もかかりそうですし。
品質文化についてはたぶんコンサルには難しいんじゃないでしょうか。そもそも品質文化ないところはそういうコンサル入れない気がしますし、無理やり入ったところで誰もいうこと聞かないと思います。（これもコンサルやったことないので、ただの想像です）
常駐の具合を分けてるのは、ロールによってできることや求められることが変わるのと同様に、その「できること」が開発チームからの独立性の高さ低さによっても変わるからだと思います。
QAプロモーター 組織全体にQAを推進していく役割（自分で手を出してはいけない）
自分で手を出してはいけないってなんでなんですか？
ていうか「手を出す」って具体的にどこまでが良くてどこまでがダメなのでしょうか？
プロモーターだからダメなんじゃないでしょうか。みんなでQAやろうよ！って推進していく人なんですから、その人がQAやってくれたら「あの人がやってくれるからいいや」ってなるじゃないですか。そうなったらプロモーターじゃなくてただのQAですよね。
どこからがOKなのかは組織によるからわからないです。個人的にはテストチームの一員としてテストケースの大部分をひたすら消化してそのまま帰宅してたらそれはプロモーターの仕事とは言えないんじゃないかなと思います。
SETってE2E自動化するだけの人ではないのですか？
自動化するのってQAとどう関係あるんですか？
これもSETが何を指すかは組織によるのでわからないです。
でも自動化はすごくQAと関係あると思います。自動テストでやってるテストケースを知ってたら、同じテストをQAでやってるテストケースから削れるかもしれません。あるいは、QAでやってるテストケースの一部を自動化したら、マニュアルでしか確認できないテストや探索的テストみたいな別の領域のテストをもっとやっていけるようになるかもしれません。なのですごく関係あると思います。
QAエンジニアってテストする人じゃないんですか？
「チーム全体の品質向上」って何を指してるんですか？
「ふりかえり力向上＆プロセス改善」ってQAと何が関係あるんですか？
「フロントローディング」って何ですか？
「本来はいらないルールを押しつけてくる人ではない」ってそれは開発者がルール守らないからじゃないですか？
私も「QA＝テストする人」じゃないと思ってます。言葉の定義なのでそう思わない人もいると思いますが。私は、資料にもあるとおりふりかえり力向上＆プロセス改善、フロントローディング／シフトレフト、品質戦略立案などもQAがやれたらいいことだと思います。
チーム全体の品質は…僕もわからないです。品質って抽象的な言葉なので。
ふりかえりとプロセス改善もすごく関係あると思います。例えば「こんなバグがあったから次の機能の実装は変えよう」はふりかえりしてなかったらできないですよね。「作業ミスしないように作業順序変えてわかりやすくしようか」はプロセス改善といえると思います。どちらもQAの仕事の一部だと私は思います。
フロントローディングは先述したとおり設計とかのようなウォータフォールでいう「前工程」から品質を作り込むという考え方です。
そもそもルール守る守らないみたいな話が違くて、ルールを守ることが目的になってるのがよくないんだと思います。
ソフトウェア開発におけるルールや規則、基準や標準ができたのって、全部後付けですよね。いろんなベストプラクティスをまとめて整理していった結果「こういうところは守るとうまくいくこと多いよね」を集めたのが本来のルールや標準ですよね。
自己啓発本と同じです。
「朝5時に起きたら成功する」ではなくて「成功した人にアンケートをとったら早起きの人が多かった。（実際は人による）」のです。
「テスト計画の項目を全部埋めたら成功する」ではなくて「うまくいったプロジェクトを振り返ってみたら、テスト計画をちゃんと立てていることが多かった（現場や案件にもよる）」のです。
後付けでできたものなのに「ルールを守ったのに品質が上がらないじゃないか！」というのは「自己啓発本の通りにしたのに成功しなかった！」というバカな人と同じです。僕のことです。
なのでルールを作るにしても押し付けるのではなくみんなで「どんなやり方ならもっと品質が上がるだろうか？」と考えるのがいいんじゃないかなと思います。
ありがたいことにこんな疑問に過去ににしさんが答えてくれました。参考になるかもしれません。
https://speakerdeck.com/nihonbuson/history-of-quality-assurance?slide=11
テストエンジニアってバグ出すのが仕事じゃなないんですか
「価値重視文化」ってなんでテストエンジニアの責務になってるんですか？
メトリクスの測定ってプロマネとかQAさんの仕事じゃなくて？
資料を読んだ感じだと「評価技術のエキスパート」ということなんでしょうね。
テストの目的はバグを見つけることだけではないと思います。とある方は「ソフトウェアテストは、鏡だ」とおっしゃっていましたがまさにその通り、品質を測る目的でもテストは行われます。一つもバグが出なかったとしても評価はできます。この辺のテストの目的の話は、JSTQBのシラバスにもあったような気がします。
価値についても同じじゃないでしょうか。この3区分で価値を測れるのってこの人だけですよね。なのでテストエンジニアの責務なんだと思います。価値っていうとよくわからないですけど例えば「機能がイケてる」も一つの価値だと思いますし、それを測れるのはこの区分だとTEだけです。
メトリクスもそうです。この人のロールを「評価のエキスパート」とするなら、当然メトリクスの測定もこの人ですよね。
ちなみにマネージャにメトリクスの測定をさせるなんて、それこそよくないと思います。マネージャはメトリクスをみて判断するのが仕事ですし、判断はマネージャにしかできませんから、測定なんかやってもらってる場合ではないと思います。
唐突なSRE
これも私は唐突と感じませんでした。まさに私はQAの経験はSREのロールにも通じると思いながらいま運用の仕事をしています。
SREはソフトウェアやシステムの信頼性や安定運用に対して責任を負う立場だと思いますが、そのためには高い品質を常に確保しなくてはいけません。例えば頻繁に障害が起きるようではSREとしての責務を果たせているとはいえないと思います。そのために自動テストや自動デプロイの仕組みを整備したりもしますし、運用で作業ミスが多かったことを自動化したりもします。で、これはSETとやっていることが一部共通していますよね。なのでここに書いてあるのだと思います。
QAと組織能力ってどんな関係があるんですか？
組織能力向上の技術と文化って開発者とかプロマネが担うべきじゃないんですか？
ここではQAがやるということになっているようですね。
組織能力という言葉を私もよく理解できてませんが、イメージでいうなら「作業ミスが少ない」とか「品質に対する意識が高い（品質文化がある）」「過去のバグを知見として蓄積している」みたいなことなんじゃないでしょうか。
で、これは先述の通り開発チーム自らできればいいですができない組織もたくさんあります。理想としては、開発チーム自らできたらいいですね。
プロマネの責務の一つでもあるかもしれませんが、プロマネにとっての品質マネジメントは業務の一部しかないので限界はあるだろうと思います。
それぞれの専門性でやった方が認知コスト下がっていいんじゃないですか？
サイロ化ってなんですか？
なんで融合しないといけないんですか？
ダウト。サイロ化の意味知らないとその質問は出てこない。
というのは冗談として、私はお互いにやってることが分かっていた方がいいと思います。理由は完全に分けるのが難しく微妙に領域がかぶってるからです。最終的に目的が品質なのも共通していますし。たとえば自動化する人がテスト設計のこと何も知らなくてコーディングしかできなかったら、無意味な自動テストが量産されて大して品質変わらないと思います。
むしろ、完全分業でうまくいく感覚が私は全くないです。「もう少しお互いの業務を知っていたら、もっとうまくいったのになあ」と思ったことは何度もあります。
TEはなんで価値重視なんですか？ (2回目)
エンジニアリング重視ってなんですか？
QAが組織能力に重視する理由ってなんなんですか？
先述のとおり、価値を測るロールはこの中でTEしかいないからです。
エンジニアリングも抽象的な言葉ですが私は「コードの実装」「アプリの設計、開発」に近いものなのかなと受け取りました。なのでそれらの技術の向上を重視するってことなんじゃないでしょうか。
QAが組織能力を重視するのも、それを担うのがこの3区分だとQAしかいないからだと思います。
TEの上位の職種がプロダクトマネージャーなんですか？
PEの上位の職種がデベロッパーやエンジニアリングマネージャーなんですか？
QAの上位の職種がスクラムマスターなんですか？
これらは別の専門性ではないんですか？
TEの上位がプロダクトマネージャというのは納得します。理由はこの中で誰よりも「プロダクトの価値」を考えて仕事してるのがこの人だからです。
PEについても同意です。設計やコーディングなどのエンジニアリング技術に最も長けているのはこの人たちなので、そこからデベロッパーやエンジニアリングマネージャになるのも自然な流れかなと思います。
QAもそうですね。組織の力を強くするのなんて、スクラムマスターのやることそのものでは？と思います。
それぞれ別の専門性ですが、上位に挙げられている職種とは強い関連があると私は思います。
おまけ：納得感の共感
納得感の共感ってなんですか？
ごめんなさい、これはちょっと質問の文脈がわからず、回答できませんでした。
結局QMファンネルの何が嬉しいのか
私はこの資料読んで勉強になりました。というのも、ちょうど自分もSREになるために運用の経験を積もうかなと思ったりしていたところだったので、自分が今やってることやできていることはどのあたりのことなのかなというのを見れて参考になりました。
今でこそQAエンジニアという言葉を知ってる人が増えてきましたけど以前は転職の面接で「Q&Aに答えるだけの仕事をしているの？w」と明らかにバカにされた質問をされたこともありました。あまりにアンテナの低い人事にがっかりして、即選考を辞退しましたが。
で、その頃ってSETみたいな言葉も出たばかりで、「QAたるものテストコードかけて当然、自動化できて当然」と言う人と「オレは出荷検査を30年やり続けている」という門番みたいなフェーズゲートQAがどっちもQA名乗っててわけわかんない感じになってて
…っていうのからしばらくして登場したのがこの資料だったと思ってるので、とにかくQA周りのロールの認識がカオスだったんですよね。なのでそういうのを整理する材料としては非常に有益なのではないかなと僕は思います。
とはいえ、これもあくまで「こんな考え方をしてみたけど、どう？」というもので、定義ではないし、これを信じ込んだところでnoteに書いてあったように求人票にまつわる誤解が生まれるわけで、言葉の定義に縛られるのはあまり良くないと思うんですよね。
なので「この言葉の意味は違うんじゃないか」という議論にあまり意味はないと思います。というのも、それは組織によって変わるからです。
それでも、こうして自分の認識を確かめるためにこういった資料があることはありがたいですよね。
じゃあ何が嬉しいのかというと、キャリアパスやロールモデルの参考になると思います。
私は昔これでいうTEもPEもQAも全部1人でできるようになりたい、ならねばならないと思っていました。理想が高すぎたのです。本来はこの資料にあるとおり「組織として」バランスよくできていればいいのに、です。なんでも出来るような人なら別ですが、私のような中の下くらいの凡人エンジニアにはどれか一つを極めるというのですら難しく、そういう私にとってはこの資料は進む先をある程度見据えることができて非常にありがたかったです。
TEもPEもQAも全部できる人はべつにこの資料読まずに「そんな考え方あるのかー」くらいで良いんじゃないかなと思います。
ところで、QAマップとQAオクタゴンはどこへ？
僕も知らない。
長く書いてしまいました、すみません。書いているうちに、本当に私は多くのことをたくさんの方から教えていただいてきたんだなと実感しました。ここに書いてあることはどれも色々な方や本から教わったことです。
最後にいうと、にしさん、この批判の記事をもし読んでたら嬉々として「意見ありがとう！君の意見を聞かせてよ。」って言ったのではないかなと思います。わたしも何度も何度も何度も、にしさんに質問して色々なことを教えていただきました。
貴重な問題提起、ありがとうございました！
