TL;DR
1位：品質エンジニア。2位：QMエンジニア。ただし広いQAとエンジニアリングマインドを指向しよう。そうすれば品質は持続的に向上していきます。頑張りましょう！
イントロ
私たちが働いているソフトウェアやITと呼ばれる業界には、QA（品質保証）エンジニアやテストエンジニア、テスターなどの職種があります。最近ではどうもその定義は曖昧で、新たに品質エンジニアという呼び方も出てきました。その違いについてJaSST nano Vol.6で「Quality Engineeringって何なのそれ美味しいの？」というLTをしましたが、その続きについて少し考えてみようと思います。長い割にグダグダ書いているだけなので、ヒマな時にお読みください。
QAとは
QAはQuality Assuranceの略であり、日本では品質保証と呼ばれます。
もともと日本には製造業を中心にTQC（Total Quality Control、全社的品質管理）やTQM（Total Quality Management、総合的品質管理）というマインドセット・技術体系があり、多くの企業での高品質の達成に大きく寄与してきました。TQCやTQMについて勉強したい方は、「日本的品質管理」や「現代品質管理総論」を読むとよいでしょう。
さて最近、面白い本が出ました。「TQM みんなの“大誤解”を斬る！」という本です（以下「誤解本」）。この本の中に、TQCやTQMという文脈でのQAについて書かれているので、少し引用してみましょう。
QAのドーナツ化現象
「1960年ごろ…『品質管理のドーナツ化現象』といわれる現象が起きました…品質管理の手法を使って、原価低減、生産性向上…などの改善が盛んに行われ」
たそうです。2021年末頃の私たちになぞらえて言えば、見かけのベロシティを上げるためにふり返りミーティングで単体テストを書かないようになる、といった感じでしょうか。確かに、これはまずいですね。
このドーナツ化現象への対処として「品質保証」という用語が使い始められたそうです。ここでの品質保証の定義は
「お客様が安心して使っていただけるような製品・サービスを提供するためのすべての活動」
です。私たちがQAエンジニアと聞いてイメージするお仕事よりも広いですね。この定義だと、シフトレフトなどが必要なのは当たり前だと思えます。
ISO9000という黒船
「ISO9000」という言葉を見聞きした人は多いかもしれません。例えば引っ越し屋さんの宣伝やトラックなどに「ISO9000認証取得」などと書いてありますね。これは、ISOという国際標準化団体が策定した品質マネジメントおよび品質保証に関する国際規格群で、初版は1987年に発行されています。
あまり品質管理や品質保証に詳しくない方は、日本で発展したTQCやTQMが国際規格になったものがISO9000シリーズだと勘違いしがちです。現在では日本からのISO委員たちの尽力によってその差はずいぶん埋まったようですが、本質的な差があります。誤解本には、以下のように書かれています。
「日本での意味は、お客様との間で明示的に約束しようがしまいが、とにかく徹底的に満足させてやろうとすることです。」
「日本人は、総合的な品質保証、品質管理、品質経営を自慢しているのですが、欧米人から見れば、品質保証をきちんとするとは、仕様どおりの製品・サービスを提供している証拠の提示みたいなものです」
確かに、かなり違いますね。日本では1950年代から一生懸命品質管理や品質保証を発展させてきたのですが、1980年代後半からISO9000という黒船が来航して、品質保証という考え方に混乱や誤解が発生したわけです。
引っ越し屋さんは、お客様との間で契約された業務内容をきっちり遂行するタイプの仕事です。あまり引っ越し屋さんで旅館のおもてなしのようにお客様に感動を与えるという話は聞いたことがありませんね。ですからISO9000がよく馴染むようです。
ちなみにこの「証拠」というのは、私たちテスト系の技術者が想像するテスト結果だけではなく、品質保証の体系やプロセスの実証ですので、テストよりもかなり広い範囲を含みます。
品質管理と品質保証
さぁ、ここまでの短い文章でも、似たような言葉が出てきて皆さんは混乱したと思います。品質保証、品質管理（Quality Control）、品質マネジメントは何が違うようのでしょうか。誤解本では、以下のように説明されています。
品質マネジメント ＝ 品質方針＋品質方針の実施
品質方針の実施 ＝ 品質計画＋品質保証＋品質管理＋品質改善
「QCは、ISO9000の世界では、抜取検査、デザインレビュー、手順書、内部監査などの、品質管理手法品質管理活動要素というような意味です」
そうすると、私たちソフトウェアやITのテスト系の技術者に置きかえてみると、テスト技術はQCの一部となるでしょうし、テストの活動や結果はQAの一部となるでしょう。いずれにせよ、QCやQAはテストよりも広い概念だということが分かります。
一方で、TQMは元々TQCと呼ばれていたことからも分かるように、日本でのQCは手法や要素だけでなく品質マネジメント全体を穏やかに意味しています。誤解本には以下のように書かれています。
「日本は相当早い時期に、品質管理をずっと広い概念と受け止め、QCという用語を、ISO9000でいうQMと同じような意味で使っていました。」
日本的QAと欧米的QA
ここまで紹介してきたISO9000の世界でのQAの概念は、欧米の話であり、ソフトウェアやITではない産業の話です。ざっくりとISO9000のQAを「契約型の狭いQA」、日本におけるQAを「実質型の広いQA」と呼ぶとしましょう。
私には、アジャイル開発の普及という契約型から実質型へのシフトに伴って、欧米でのQAの意味も契約型の狭いQAから実質型の広いQAにシフトしてきたように感じます。特にアジャイル開発では、切り分けられた単一の仕事しかしないし興味のない単能工型エンジニアスタイルではなく、全ての仕事に興味を持ち関わっていく多能工型エンジニアスタイルが推奨されますので、より相性のよい定義になった気がしています。とはいえ、現場がアジャイル開発を行っていても企業や産業がミッションクリティカルだと、契約型のQAも重要な位置づけになります。その場合はきっと、2種類のQAを別の職種として分けた方がいいでしょう。
文化や産業構造と職種の関係
職種定義というのはその企業や産業の事情のみで決まるものではなく、その国の文化を反映します。文化というのは大げさですかね。雇用慣行と呼びましょうか。
日本では入社前のインターンシップはまだまだ盛んではなく、新卒一括採用で総合職や技術職といった大まかな職務記述が一般的です。そのため、多能工型エンジニアリングスタイルが馴染みやすい雇用慣行であり、大学での教育も割とそれに対応して広めに教えるようになっています。大括り入試と呼びますが、細かく学科やコース、プログラムといった単位で入試をするのではなく、大まかに学部や類、系といった単位で入試をしておき、入学後に色々勉強しながら専門を決めていく、という方針をお役所が打ち出したりしています。要するに、日本人は自分の専門に関して柔軟な気がしています。
すると、日本人は狭いQAよりも広いQAに向いているということになります。言い換えると、決められたことだけを行うのを推奨されるのではなく、品質や組織能力の向上などといった目的を達成するために必要なことは全て行うのを推奨されやすい文化であると言えます。でも本当でしょうか？
バブル期を過ぎてからの日本は、なかなかに悲惨な道を歩んできました。特に景気の減退に伴う経営状態の悪化によって、派遣化や外注化が進められました。ソフトウェア開発の世界では、プロジェクトマネジメントブームの到来やオフショア開発のブームがありました。これらは単能工型の狭いスタイルを強制することによって単価や賃金を下げるという目的に利用されました。言い換えると、多能工型の広いスタイルは正社員や一次請けが担うというものです。さぁ2021年の現在、こうしたやり方はどういう結末を迎えたでしょうか。皆さんもご存じの通り、少なくともソフトウェアやITの世界の多くの企業では、単能工型の狭いスタイルを強制すると一時的にコストが下がるものの、目的を達成するために必要なことをする人が組織に減って組織能力が低くなり、技術的負債が増えて、競争力がガタ落ちしたわけです（もちろん上手にやった組織もあるにはあるでしょう）。要するに、苦手なことを強制して能力を落としてきたと言えます。そのアンチテーゼとして、アジャイル開発や内製化、開発組織統合などが現在ブームになっているわけですね。そしてQAエンジニアも、なんと欧米から、シフトレフトなど広いQAをしなさいよと言われてしまっているわけです。
さて皆さんはこうした背景の中で、自分のキャリアを狭いQAに限定しますか？それとも広いQAを目指しますか？
QAとQCとQM
先ほどQA（品質保証）とQC（品質管理）とQM（品質マネジメント）という用語が出てきました。そしてQAエンジニアという職種も出てきました。また私たちの業界ではテスターやテストエンジニアという名前でも呼ばれています。どう呼ぶのは適切なのでしょうか？
まず自分のキャリアを広いものにすると仮定しましょう。日本ではQCエンジニアと呼んでも構わないと思います。しかし欧米ではQCエンジニアと呼んでしまうと、手法や要素しか意味しなくなってしまう可能性がありますから、QCはボツ。
QAエンジニアはどうでしょう。日本的な意味であれば問題ありません。しかし欧米では、本当は、品質方針の策定にも品質計画の立案にも改善にも携わらない意味になる可能性があります。確かにソフトウェアテストの国際規格であるISO/IEC/IEEE29119シリーズには（現在のところ）品質方針の策定や品質計画の立案、改善に関する記述はありません。ですから、本来はボツ。
では最も広く捉えるのであれば、QMエンジニアと呼ぶのがよいことになります。しかしこの頭文字を展開してカタカナで書いてみましょう。品質マネジメントエンジニア…。なんだか違和感がありませんか？
エンジニアリングとマネジメント
その違和感の正体は、日本ではエンジニアリングとマネジメントが対立概念として捉えられてきたという歴史にあると思っています。エンジニアは技術者でマネジャーは管理職。モノをつくるのはエンジニアで、人を回すのが管理職。生涯現場一筋のように出世に興味がないのがエンジニアで、出世していくのがマネジャー。ひどい産業では、エンジニアは理系でマネジャーは文系。ここまでひどくないにしても、まぁこんな感じのイメージがありますよね。
でも本当は、エンジニアリングとマネジメントは対立概念ではないんです。TQC/TQMではそこを整理するために「固有技術」と「管理技術」という呼び分けをしてきました。対立概念を持つ人たちは管理が上手であることを人間性やセンスに帰着させたり、コツと呼んだりしていますね。しかし（TQC/TQMに携わる人たちの多くが理系っぽいこともあるでしょうが）、管理を上手に行うにはそれ相応の技術が必要なんです。
その「技術」は確かに物理化学法則とは関係ありませんし数式でも表しにくいものですが、組織構成などに依存はするものの、ものごとを上手に行う再現可能で一般化可能なことの体系です。もうこうなると技術の定義の話になりますので、これ以上踏み込まないことにしますが、例えばプロジェクトマネジメントで使われるPERT図やアジャイル開発でのバーンダウンチャートなどは、管理のための技術として分かりやすいと思います。
誤解本にはこう書いてあります。
「効果的・効率的な目的達成のためには、その分野に固有の専門知識・技能とともに、それらを組織的に活用するための方法論としてのマネジメントが重要である。…固有技術にあたるエンジンや駆動輪と、管理技術にあたるステアリング、ブレーキ、アクセルなどの車両制御の両方の機能がなければ、車はまともには動きません。」
つまりQMエンジニアとは、品質に関する管理技術を用いて（固有技術を最大限に活用し向上させ続けることによって）お客様が安心して使っていただけるような製品・サービスを提供するためのすべての活動を行う人、ということになります。ふむ、悪くありません。
では開発エンジニアとはどのように定義されるでしょう。それは固有技術を用いてお客様が安心して使っていただけるような製品・サービスを提供するためのすべての活動を行う人、となります。まぁただ、ある産業における固有技術と管理技術の境界線は、他の産業でも同じとは限りませんし、境界線そのものも曖昧だったりします（境界線を明確にしようとするスタンスが「広いQA」とは相容れません）。
エンジアリングマインド
ではQMエンジニアでいいじゃないか、という考え方は確かに成立します。私はこれも嫌いではありません。しかし2021年現在のソフトウェアやITの世界では、少し異なる事情があります。それはDX（デジタルトランスフォーメーション）です。もう少し平たく言うと、開発の自動化・自律化です。
DevOpsやCI/CDという言葉は既に一般的になりました。知らない人はいないでしょう。テストの自動化も話題ですし、自動化の先にはAIを使って自律的にテストしていくという話題も出ています。開発に関しては、自動デバッグや自動プログラミングといった話もチラホラ聞こえてきます。つまり2021年現在のソフトウェアやITの世界の課題やブームは、自動化や自律化です。
テストは開発に比べて「受けの技術」です。テストだけで一から十までやり方を決めることはできず、色々なことが開発に依存します。そのため柔軟性が必要で、自動化があまり発展してきませんでした。しかしスピードが重視される世界に突入して、人力のテストでは間に合わなくなってきて、自動化が急速に必要になってきました。
この人力のテストと自動化されたテストとの間に、2021年現在の日本のソフトウェアやITの開発やQAの現場では、まだまだギャップがあります。私たちは現在、そのギャップを一生懸命埋めなくてはなりません。そのために必要なマインドセットが、エンジニアリングマインドです。これはどうも一般的な用語ではないですが、要するに「機械にやらせられることは全部機械にやらせて、人間は人間にしかできない創造的な仕事をしよう」という考え方です。そしてそのサブセットには、機械にやらせるために必要な考え方がぶら下がります。例えばLarry Wallの「プログラマの三大美徳」などですね。
ややこしいのは、自動化によって「管理技術に関する固有技術」が生まれたってことです。まぁでもこの辺は、テスト技術が固有技術に含まれるってことも含めて、また場を改めて議論します。
さて、エンジニアリングマインドを阻害するのが「安いから人間にやらせよう（i.e. 安い第三者検証会社に発注しよう）」「バラバラで面倒だから人間にやらせよう」「とりあえず納期があるからここは人間にやらせてしまおう」などの木こりマインドです。木こりというのはもうご存じですね。木こりのジレンマという逸話に出てくる、なまくらな斧を研がずにずっと無駄な仕事を長時間し続ける人です。
ソフトウェアやITの世界では、ここ20年ほど単能工型の狭いスタイルを強制することによって単価や賃金を下げてきました。その時に活躍するのは、エンジニアリングマインドの無い、管理技術を身につけておらず固有技術への敬意も無い、品質意識にはほど遠い、クソ管理職です。彼らにはエンジニアリングマインドはカケラもありません。しかし彼らは管理職であり「マネジャー」などと呼ばれています。
そうです。日本では木こりマインドとマネジメントが混同されている現場が数多くあり、エンジニアリングマインドの普及や浸透の邪魔になっています。そうした現場で「品質マネジメントエンジニア」という呼び方をしてしまうと、品質＋木こりマインド＋エンジニアリングマインドという矛盾した印象を与えてしまいかねないのです。というわけで、QMエンジニアはボツ。そしてQxマネジャーは全てボツ。
テスターとテストエンジニア
私は大学を卒業してから数年、小さな第三者検証会社に在籍していました。その会社は、他の会社の下請けを色々とやっており、とても低単価な仕事も請けていました。そうした仕事に携わる人たちは、高い技術を持っていたとしても、蔑みを込めてテスターと呼ばれていたりしました。他には、テスターさん、外注（呼び捨て・さん付け）、派遣さん、協力会社さん、パートナーさん、BPさん（ビジネスパートナーの略）など色々呼ばれていましたが、少なくない現場で開発よりも下に見られていました。
そうした会社では、低単価のためロクに技術教育もされず、新しい技術に触れる機会もほとんどなく、常駐先にずっといて自社にほとんど戻らず、単純作業のテスト実行やCPM法によるテストケース増殖しかさせてもらえず、一度テスターになったらもう開発には戻れないとキャリアに絶望している人たちがいました。今でもいるかもしれません。私は彼（女）らに、自分はテストエンジニアだと、エンジニアだと、技術者だと誇りを持って欲しいですし、そうした会社には彼（女）らをエンジニアとして処遇するようになって欲しいと考えています。そもそもそういう会社の経営者はテスト技術に敬意が無く、軽作業派遣と同様だと思っていたりしますしね。
なので私はずっと一貫して「テストエンジニア」と呼んできました。これは私の闘争です。VSTePがダイアグラムを使うのもその一部です。Excelだけだとエンジニアっぽくないですからね（偏見）。ですから、最近では「海外ではテスターと呼んでいるからテスターでいいじゃないか」と主張するキラキラしたWeb系のテストエンジニアさんがいらっしゃいますが、キラキラしてていいなぁ、と思います。まぁそんなわけで、個人的な闘争として、テスターとは呼びたくないなぁ、と感じています。これはあくまで私の個人的な闘争の話なので、木こりマインドに満ちている第三者検証会社さんやその卒業生の皆さんには同意してもらえると思いますが、他の人に強制しようとは思いません。
でも、テスターちゃんは、テストエンジニアちゃん、だとなんか変ですね。私の記憶にあるテスターという嫌な響きを洗い流してくれるという意味でも、テスターちゃんは本当に素晴らしい作品だと思います。
では何と呼べばいいの？
テスターとテストエンジニアという呼称は、狭い印象を与えてしまうのでイマイチ。QCとQAとQMだとQM > QA > QC。マネジメントやマネジャーという用語が入ると、エンジニアリングマインドが強調されにくい。
というわけで、結局LTと同じ結論になりますが、品質エンジニア（QE）という呼称はあり寄りのありかな、と思います。次点はQMエンジニアですかね。決して略語を展開しないこと。
ただし大事なことは、品質エンジニアの職務は実質型の広いQAであり、仕様や契約にかかわらず、とにかく徹底的にお客様（組織）を満足させようとする、という意識です。QM全体が職務だと認識することです。そして、木こりマインドを見つけたらエンジニアリングマインドを浸透しようとすることです。
また品質エンジニアと呼べば何でも解決できるわけではありません。SEA-SIGSQAでは、評価方面と自動化方面と組織能力向上方面とで分けるといいよね、と言っていますが、品質エンジニアのミッションや職務を定義し、見直し続けることです。そしてプロセス改善担当やISO26262担当のように、もし自組織に昔から品質に関係する職務があれば、それらを含めてきちんと整理して、広いQAを指向してもらうようにすることです。
そうすれば、必ず皆さんの組織の品質は持続的に向上していきます。頑張りましょう！