1. はじめに
「QA」がさまざまな意味で用いられ「職種と職務がゴチャゴチャになっているのが現状のようだ」という認識のもと、QMファンネルは品質エンジニアの専門性と役割をTE、SET/PE、QAの3つに整理しています。
TE SET/PE QA テストする人 自動化する人 みんなをよくする人 テストの実行・設計・計画・戦略立案・管理・推進など （E2Eも含めた）テスト自動化、 CI/CDやCT（継続的テスト）のパイプライン構築、SREやMlops、自動化戦略立案など チーム全体の品質向上、ふりかえり力向上＆プロセス改善、フロントローディング/シフトレフト、品質戦略立案など テストやレビュー、メトリクスの測定など製品やサービスの評価技術のエキスパート 様々な自動化を行うエキスパート（SETやSRE） 組織能力を高めるエキスパート 検証技術と価値重視文化を担う 自動化・デジタル化技術とエンジニアリング文化を担う 組織能力向上の技術と文化を担う プロダクトマネージャーへのキャリアも考えられる デベロッパーやエンジニアリングマネージャーへのキャリアも考えられる スクラムマスターへのキャリアも考えられる
組織によってはテスターやテストエンジニアをQAエンジニアと呼ぶようですが、QMファンネルにおけるQAはテストする人ではありません。テストする人はTEと定義しています。例えばインプロセスでテストする人を「インプロセスTE」ではなく「インプロセスQA」と呼ぶと話がかみ合わなかったりQMファンネルの本領を発揮できないおそれがあります。
- QMファンネルのQAを「テスター、テストエンジニア」と誤った解釈をしてQAとスクラムマスターの親和性が低そうに見えるという話を見たことがありますが、TEに習熟して考えられるキャリアはそもそもスクラムマスターではなくプロダクトマネージャーです。
- 「QAに習熟するとスクラムマスターへのキャリアも考えられる」は、QAファンネル振り返り術の資料が参考になると思います。
2. QMファンネルにおけるQAの役割
TEやSET/PEが「イメージしやすいし、分かりやすい」のに対してQAは「イメージしにくいし、分かりにくい」とあります。たしかにQAの特徴として「全社的な推進計画」「部門横断的な問題解決」といった開発部門、設計部門にとどまらないスコープの広さがあり、QAにはさまざまな業務がある一方で個々のQAエンジニアが担当するのはその一部に過ぎず経験ベースで全体像をつかむのは難しいといえます。
例えば、あるネットワーク機器がセキュリティの脆弱性を突かれて踏み台にされた場合、その製品の顧客が困るのはもちろんですが顧客でない人も踏み台の巻き添えになって困ることになります。製品は顧客ではない人々に対して迷惑をかけないことも必要で、顧客への価値提供だけでなく非顧客への価値提供もQAの役割になります。こういうのは言われてみれば当たり前と思いますが製品セキュリティやPSIRTに関わる機会がないと経験ベースでは気付かないかもしれません。そこでQAの理解を助けてくれそうな資料やトピックスを挙げてみます。
2.1 みんなをよくする人
QMファンネルの前身となるQAファンネルから資料をたどるとヒントになるスライドがあることがわかります。
-
Re-collection of embedded software QA in the last decade（JaSST'20 Tokai, 2020/10/16）
- QAのマインドセットと役割(p.40)
- QAのミッション：納得感の共感を高める(p.41)
- QAのマインドセット：サーバントシップとカイゼンサイクル(p.42)
- QAのマインドセット：ミッションシェアとアップストリーミング(p.43)
- QAのマインドセット：ストーリー化(p.44)
- 予防的QAとレジリエントQAを組み合わせる(pp.64-65)
- 横串が通っているから、うまく焼けるのです(p.76)
- 右利きの組織が左利きにもなれるようになるための考え方(p.77)
- 両利きになるためのポイント(p.78)
- 新しき葡萄酒は、新しき革嚢に(p.85)
- 品質の高い製造業の品質マネジメントをイマドキの考え方で整理してみた/Demystifying quality management for large scale manufacturing in modern context(DevOpsDays Tokyo 2021, 2021/4/16)
2.2 組織能力を高めるエキスパート
QMファンネルやその前身のQAファンネルを筆者なりに一言で表すと、「おもに製造業で培われてきた日本式の品質マネジメントをソフトウェア開発へ応用するためのツール、モデル」です。その日本式の品質マネジメントはJIS Q 9005:2023 品質マネジメントシステム―持続的成功の指針として規格化されています。2023年の改版で経営・事業の視点から品質部門が果たすべき役割が追加され、その条文「6.2.3 品質部門の役割」は組織能力を高めるエキスパートの理解に役立つものと思います。
6.2.3 品質部門の役割
6.2.3.1 一般
品質部門は，事業の持続的成功を実現するための品質マネジメントシステムを運用し，管轄する部門であると認識し，自らが果たすべき役割を明確にするとともに，その役割を果たすために必要なプロセス及び仕組みを計画し，確実に実施することが望ましい。6.2.3.2 価値提供のための運営基盤の整備及び推進
品質部門は，製品・サービスの品質の観点から価値提供を確実に実現できるために，各部門が担うべき業務分掌，プロセス，手順などの必要な運営基盤を整備することが望ましい。品質マネジメントシステムに関わる全ての部門が顧客価値及び社会的価値提供の重要性を理解し，改善及び革新を含む様々な活動を自律的に行えるように，全社的な推進計画を立案し，確実に実施することが望ましい。
運用に当たっては，定めた業務分掌，プロセス及び手順に沿った業務を行うための各部門への必要な支援の提供（箇条7 及び箇条8 参照），並びにその運用が適切になされているかの評価及び改善（箇条9 及び箇条10 参照）を行うことが望ましい。
注記 推進計画には，次のような項目を含むことがある。
－ 各部門個別の改善活動の推進及び改善ツールの活用に対する支援
－ 品質管理教育の企画，実施，評価及びフィードバック
－ 重要品質問題又はトップマネジメントからの特命による，部門横断的な問題解決，又は課題
達成プロジェクトの推進
－ 表彰，奨励制度の整備及びその実施6.2.3.3 CQO の確実な任務遂行のための支援活動
品質部門は，経営全般を担当する関連部門と連携し，CQOが自らの任務を確実に遂行するために，その方針に沿って，又はCQOの指示に応じて，次の事項に関する調査，分析，調整，取まと（纏）め，構想などの支援活動を行うことが望ましい。
－ 経営及び事業における品質マネジメントシステムの位置付け及び重要性に関する，トップマネジメントの理解促進
－ 価値提供のための運営基盤に関する問題認識及びその解決策の立案
－ 品質マネジメントシステムの実施状況及び成果の，トップマネジメントへの報告
ソフトウェア開発に当てはめると、例えば開発者向け情シスとして静的解析ツールを始めとする設計支援ツールを導入、運用したりするのは品質部門の役割といえます。「メタエンジニアリング 【第2版】 技術広報・採用・組織開発による個人と組織の支援（塩谷 啓・著）」は管理技術や品質マネジメントと重なる部分がありこちらも組織能力を高めるエキスパートの参考になるでしょう1。
3. QM（品質マネジメント）= TE + SET/PE + QA
QMファンネルのQAはふりかえり力向上やプロセス改善や組織能力向上の役割もあります。狭義のQAにとどまらず、カスタマサポート部門と協力して市場要望や市場クレームを上流工程へフィードバックしたり、プロセス改善でいえばSPI（Software Process Improvement）やSEPG（Software Engineering Process Group）、組織能力向上でいえば技術ロジスティックスやテックシェルフ2、技術プラットフォームの構築や運用を担う技術企画や技術管理3もQAの仲間になります。
ところでQMファンネルの専門性（TE、SET/PE、QA）は「どれか一つだけじゃなくて、3つを理解できて初めてちゃんとQMができる4」、「それぞれのスペシャリティが別の人に割り当てられている状況でも、 他のスペシャリティのことを理解していなければ良い仕事はできない5」というものです。越境しないと品質マネジメントの役割を果たせないケースもあり、自分の業務に境界線を引いてサイロ化、個別最適化するためのものではありません。
例えば「生成AIを活用した組み込みSW設計書検索システム開発（三菱電機株式会社・塚田 真規）」は技術資産である設計書を効率よく扱うための技術プラットフォームという点で技術企画、QAの領域といえますが生成AIを活用した自動化環境という点でSET/PEの領域ともいえます。
4. おわりに
QMファンネルにおいて「イメージしにくいし、分かりにくい」とされるQAについて、QAの理解を助けてくれそうな資料やトピックスを挙げてみました。特に2023年に改版されたJIS Q 9005はQAファンネルやQMファンネルがお披露目された当時はまだなかったのですが、これのおかげでQAの理解が深まったこともありおススメです。