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