QMファンネルってなんだったの？ 〜QMファンネル批判への自問自答編〜
はじめに
この記事は、「QMファンネル批判 〜鵜呑みにするとキケンな魔術書〜」に対する自分なりのアンサーです。
私はテスターなので批判だけでも価値があると思っていますが、QAエンジニアとして答えなしでいるのは業界のためでもないと思って記載します。
こちらはあくまでごまずんの理解であり、公式見解ではないことをご了承ください。
本当のところをお知りになりたい人は関西のテスティングアイドルT氏や葛飾の区長I氏といった有識者に聞いてください。
間違いの指摘があった場合は、誰からの指摘を明らかにした上でこの記事に追記しますので、よろしくお願いいたします。
QAエンジニアは不要論一体どこから？
QAエンジニア不要論というのは、「開発者完全仮説」という考えがあったと思います。私の認識ではにしさんの造語で「開発者が完全にフルスタックであればQAエンジニアはいらない」という言説だったはずです。
実際に当時のスクラムガイドでは「QAエンジニア」は定義しておらず、「開発者の中にも様々な専門性があるよ」的な注釈もなかったので、人によっては「開発者はフルスタックであるべきだからQAエンジニアは不要」と言っていたことがあったのだと思います。
一方でこちらについても「開発者不完全仮説」というものがあるみたいです。
実際のほとんどの組織のエンジニアは完璧ではなく、どうやっても品質が低下していくという言説です。
QAエンジニアはそうした「開発者は不完全である」という仮説のもと、優しく寄り添って、開発組織を支えてあげるロールとして必要なのだと認識しています。
品質文化とQAエンジニア、そしてチーム
品質文化について
「品質文化」にはいろんな意味合いが込められていそうです。
必要に応じて「LEADING QUALITY」といった文献が参考になるかもしれません。
ここでいう「品質文化」とは、「製品やサービスの価値を最大化するためにルールに従うのでなく、内発的動機に従って、自律的にカイゼンやリーダーシップをとることができる」と理解しています。
「品質」とは何かについてはここでは扱いません。ざっくり「誰かがいい感じになる」くらいでいいと思います。
ここからはにしさんと個人的にお話しした時に理解した内容なのですが、「文化」というワードには組織が持つ、社会的事実のように思えました。
いい品質を作るために全てをルールにしてしまうと、それを理解して実践することがドンドン難しくなります。そこで、敢えて明文化しない「品質文化」というものを心の中に持つことで柔軟に自分で考え行動していくことが必要になると思っています。
モチベーションとソフトウェア品質
ソフトウェア開発の特徴として、「ほとんどが知的活動である」ということが挙げられます。
製造業のモノづくりの現場においても人間の卓越した知識や技術があるのは言うまでもないですが、ことソフトウェア開発においては「簡単にコピーできる」「物理的な制約がない」「日々発展している分野である」「スピード感がある」という事情から、人間の脳みそが事業を左右する「知的活動」であると言えます。
知的活動はおそらく「モチベーション」に支えられ、ルールや製造工程などで定義は難しいと考えられると思います。
そのため、ソフトウェアの品質というものはモチベーションに支えられるため、現状は人に依存したものであると考えています。
品質文化におけるQAエンジニアとチーム
品質文化を"良きもの"とした時、QAエンジニアの動きは「外部からルールを作る人」から「チームに寄り添って内発的動機付けを行いながら、品質に対する意識を高めるために活動する人」というものに変わると思っています。
全てをテストするわけでもなく、全ての開発工程を見張るのではなく、「QAエンジニア以外の開発者自身に品質に対する意識づけを行う」という位置付けになります。
これらは個人に対する働きかけになりますが、フォーカスすべきは「組織」という単位になると思います。
QMファンネルの文脈では高品質を届けることは"良きこと"とされています。
なので、組織能力を品質向上の方向性で上げていくことが正となるわけです。
上記の都合から、後述するQAの専門性は「組織能力の向上」になると認識しています。
組織的にQA系の技術を上げる意義
「品質はエンジニア自身でモチベーティブされないと上がらない」と仮定した時、「QAはQAさんにお任せ」では成り立たなくなります。
チーム全体で把握して、組織のケイパビリティとして技術を磨き、成長していくことが必要になってきます。
これらはQAエンジニアの存在を否定するものではなく、逆です。
QAエンジニアは率先してチームのQA技術を引き上げ、あるいは後押しして、コーチングなりティーチングなりシェルパなりジェネレーターなりになって、自分だけのものとせずに「組織としての品質技術を上げる」という働きが期待されると考えています。
品質戦略は誰のもの？
「品質戦略」が何を意味しているのかについて、私にはわかりません。
ただ、ここでは「品質文化を具体的な対策にまで定義したもの」としますか。
そうした場合、「品質戦略」はQAやマネージャーだけが持つものではなくなります。
品質文化をインスタンス化したものなので、品質文化との整合性や、みんなとの納得感が必要になってきます。
決して誰かが決めてお仕着せの品質戦略をするのではなく、自分たちで考え、自分たちが納得する品質戦略を実行することで、モチベーションを失うことなく品質活動を続けることができるのだと考えます。
QAの各ロールの意義
フェーズゲートQA・QAサービス
QMファンネルは何故かこのロールだけが「出荷判定」を担うことになっています。
これには歴史的経緯として、IV＆Vのプラクティスが反映されているのではないかと考えています。
ざっくり「独立した機関からも太鼓判押してもらえたら安心」ですね。
「出荷判定」が開発チーム内でできない理由はよくわからないですが、これについは「QAは開発組織とワンチームである」というニュアンスが含まれているのではないかと予想します。
QAエンジニアだけが出荷判定を行うのではなく、みんなで合意して納得して出荷判定を行うのがいいと思っているのだはないかと思っています。
イマドキのweb系QAエンジニアはフェーズゲートQAに否定的かもしれません。
これはアジリティが求められるプロダクトでは邪魔になるのは間違いではありません。
一方でミッションクリティカルな製品や、人の生死が関わるような製品では、重厚な品質保証としての出荷判定を行い、それらが今生きる我々の財産や人命を守っているということを忘れてはいけないと思っています。
そういったことを忘れてフェーズゲートQAを見下すのはいいプラクティスではないと考えます。(そもそも誰かを見下すことは自己満足以外のメリットはないかもしれません)
追記 2024.4.28
yoshikiitoさんから本件についてアンサーをいただきました。
このブログを受けて思ったことなのですが、各ロールは固定なのではなく、チームやプロダクトの状況によってQA自身が明示的に使い分けて、場合によっては役割を越境したり、そういった使い方ができるのでは？という気づきを得ました。
また「イマドキの〜」というのは特定の誰かを想起して書いたわけではありません。
ていうかフェーズゲートQAに否定的なのは私自身であります。
ただ、フェーズゲートQAの存在意義を考えた時に、やっぱり必要な場合があるよな、と思って自分自身への戒めとしてこの文章を書きました。
QAの実業務の近さ
前述の通り、QAは組織文化でもあるため、QAに関する活動をすべてがQAを担うという必要はないと考えます。むしろQAの専門性があれば「QA」という名前でなくても積極的に実行して、より品質の高い製品をなるべく早くリリースするべきだと考えます。
そのため、QMファンネルでは「実業務への近さ」という概念で、チームの品質文化の実際の作業をどれだけ担っているかという匙加減を表しているのだと思っています。
実業務における"品質文化"とは
QAコンサルタントは「品質文化」に関わらないみたいです。
それは「あくまで文化とは行動に現れる」という強めの思想が出ているように思えます。
QAは道筋を提示するだけで、それを文化とするかはチームがオーナーシップを持って決めることであり、決して強制では文化として花開かないのではないかと考えます。
各ロールの上下関係？
これについては「組織に定義による」という理解です。
組織のフェーズによって求められる専門性や知識が異なるので、そこでの上下関係があっても別にそこはいいと思っています。
一方で、誰かが「ある組織でのインプロセスQA」だからといって「別の組織でのQAコンサルタント」の人が「俺以下だな」と評価するのは組織の文脈が違うので成り立たないと思っています。
それは求人票でも同様で、「ある組織でのQAコンサルタントをやったからといって、どんな組織でもフェーズゲートQAできるわけではない」というのが私の所感です。
QMファンネルにおける専門性
価値重視の文化を担うTE
QMファンネルによるテストエンジニアとは「価値」を重視するみたいです。
そうなった経緯はよくわかりませんが、テストエンジニアが考える「バグを出そう」という考え方、「悪さの知識」の裏には「製品の価値を損なうかもしれない」という価値観が現れているのかもしれません。
エンジニアリングを担うPE
品質保証において、開発者のモチベーションが重要であるというのは前項で述べましたが、モチベーションを上げるためには「開発者体験」が重要になります。
実際の仕事の中で障害があり、それをエンジニアリング的な技術で解決して、結果的にプロセス品質を上げて、プロダクト品質に貢献する、というのがPEの役割だと思いました。
よくある「SETはテスト自動化だけですねん」は、PEの文脈では「テスト自動化はQAやTEを含む開発者体験をアップさせてるための一手段である」という理解をしています。
組織能力のQA
散々言ってきたのでここでは省きます。
スペシャリティの融合
それぞれのスペシャリティは単一ではうまく機能しません。
TEとして価値を出し、それのエンジンとしてのPE、それらを支えるQAが一体となって同じような品質文化やミッションを持って、それぞれのプラクティスをいい感じに融合させながらQAをしていくことがここでは必要になってくるということになります。
キャリアの方向性
「キャリアの方向性」と記載されていますが、これらは決してそれぞれのキャリアが、それぞれのスペシャリティの専門性であることを表していないと私は考えます。
あくまで今まであるロールに対して、これだけ貢献できますよ、あるいは新しいことにもチャレンジできますよ、という後押しだと私は理解しました。
さいごに
こちらはあくまでごまずんの理解であり、公式見解ではないことをご了承ください。（２回目）
ところで、QAマップとQAオクタゴンはどこへ？
参考文献
この記事が気に入ったらサポートをしてみませんか？