1. はじめに
公開されている資料をたどってQAファンネルやQMファンネルの理解を深めたいと思います。
2. 資料
2.1 QAファンネル＠JaSST'20 Tokai（2020/10/16）
JaSST'20 Tokai 基調講演
2.2 QAファンネル＠JaSST'21 Tokyo（2021/3/15～16）
JaSST'21 Tokyo セッションB8、新しい品質保証のかたちを目指して～君の心に「ファンネル」はあるか？～
SigSQAでは、新しい品質保証の形を目指して、組織や個人の品質保証の状況を表す仕組みを作ってきました。QAファンネル、QAオクタゴン、QAマップなどがその一例です。モデルケースや事例を通じ、みなさまの現場で活用いただけるようご紹介します。
品質保証に興味がある方、自分たちの品質保証にもやもやしている方、自分たちの品質保証がどの位置にいるか知りたい方、自分たちの品質保証の戦略を立てたい方、などなど品質保証に興味がある方、集まってください、楽しい時間を過ごしましょう！
agileな人・waterfallの人、組み込みの人・Webの人・汎用機の人、営業・企画・エンジニア、それぞれ役割や立場は違えど、品質に対する想いがあればつながれる、そんな世界を信じていただける方にご参加いただきたいです！
2.3 QAファンネルをふりかえる夜（2021/4/6）
Agile Testing Night #5でSigSQAとQAファンネルの紹介、ウイングアーク１ｓｔさんの事例紹介、パネルディスカッションが開催されました。
2.4 QMの三角錐＠DevOpsDays Tokyo 2021（2021/4/15～16）
2.5 QAファンネルをふりかえる夜 後編（2021/5/18）
SigSQA主催のQAファンネルをふりかえる夜 後編でSigSQAとQAファンネルの紹介、リンクアンドモチベーションさんの活用事例（QAファンネルの活用事例、QMの三角錐の活用事例）、パネルディスカッションが開催されました。
2.6 QMファンネル＠Scrum Fest Osaka 2021（2021/6/21）
2.7 QMファンネルの活用事例＠JaSST'22 Tokyo（2022/3/10～11）
JaSST'22 TokyoのセッションA6、新しい品質保証の形を目指して
2.8 にしさんのX（旧ツイッター）のポスト
以下に挙げるにしさんの連ツイも理解が深まると思います。
QAファンネルのご質問の件。午前中にSEA-SIGSQAで議論してました。ご質問のように、僕らも複数のプロジェクトというか組織マネジメントと捉えるものとして考えてました。（2021年11月14日）
https://twitter.com/YasuharuNishi/status/1459712486756605955
（広義の）QAの実務は多岐に渡ります。なのでQMファンネルではTE、SET、QAに分けました。 （2022年8月30日）
https://twitter.com/YasuharuNishi/status/1564603247569956865
2.9 JIS Q 9005 品質マネジメントシステム―持続的成功の指針
QMファンネルはTQMのソフトウェアへの応用例と見ることができます。TQMを体系化、JIS規格化した「JIS Q 9005:2023 品質マネジメントシステム―持続的成功の指針」も押さえると理解が深まると思います。
3. QAファンネル・QMファンネルを読み解く
3.1 QAファンネル
QAファンネルはJaSST'20 Tokai（2020/10/16）のにしさんの基調講演、「Re-collection of embedded software QA in the last decade」のp.15、「どんなテストをしているのか、説明できますか？」に「QAファンネルによるロールバランスの可視化」で初めて登場します。
次に登場するのはp.40の「QAのマインドセットと役割」でQAファンネルの各ロールの名前が示されます。
ここで「QAプロモーターがきちんと組織的な戦略を立てて、QAファンネル（QA内のロール）のバランスを取る」「自組織・自プロダクトのQAの戦略を立てて推進する役割（QAプロモーター）は必須であり、最も重要である」とあるように組織的な戦略（グランドデザイン）を描くのが一歩目となります。
また、「育成や技術開発・技術導入をきちんと進めていく必要がある」ともあり、グランドデザインを描く際にプロダクトやチームの将来の成長、成熟度に合わせた品質施策をAQUAフレームワークでバックキャスティングし、人員配置の構想をQAファンネル・QMファンネルで立ててみるのが活用方法の一つと考えられます。
品質保証戦略の立て方はにしさんの次の資料に解説があります。
QAプロモーターに期待される振る舞いやスキルは質問回答対応表も参考になると思います（強調筆者）。
- QAプロモータが自分で手を出さない理由への回答（にし）：自分で手を出すと（出してばかりいると）QAファンネルをうまく構築できなく恐れがあるからです。自分で手を出してる時間を、QA全体の戦略や組織設計などに回して欲しいからですね。
- QAファンネルのレイヤとスキルレベルへの回答（にし）：もちろんQAプロモーターに近いほどQAスキルが高くないといけません。得手不得手はあっていいのですが、少なくとも理解していないといけません。そしてそのレイヤに近いほど戦略構築能力や経営陣との交渉・調整能力が必要です。
- 部長クラスでもQAプロモーターの役割が担えないにへの回答（にし）：組織によって理由は異なりますが、スキル不足が大きいです。テストやレビュー、品質把握のスキル。自動化やツールチェーンの知識と戦略立案能力（実装能力はそれほど要りません）。組織や人を癒やす能力。開発や周辺組織との調整・説得能力。QA全体の戦略立案能力など。
QAプロモーターは「最も重要」「QAスキルが高くないといけない」「部長クラスでも役割を担えない」とあってハードルが高く見えますが、とはいえグランドデザインを描いてみるのは誰でもできます。まずやってみるのが大事で、同僚や上長、関連部署の偉い人を巻き込んでたたき台のブラッシュアップを繰り返しているうちにスキルは付いてきます。
続いてAQUAフレームワークなどの解説を経てp.40と同じスライドがp.47に再登場し、p.48からQAファンネルの図解とダメなバランスのQA組織の例が3つ示されます。
縦軸はロール、横軸は人口比率です。横軸は質問回答対応表の説明が参考になると思います。
- ファンネルis人口比率への回答（にし）：そうです。ただし線形（5:4:3:2:1）ではないです。上がたくさんいて下が少しいる、というイメージですね。
- QAピラミッドじゃない理由への回答（にし）：セールスファネルという概念から着想したからです。それと同じように、多分現場ではフェーズゲートQAがたくさんいてQAプロモーターがいないのが多いと思われるので（他のパターンもあるのは理解してます）、少しずつでもいいから増やしましょうね、という趣旨です。
縦軸は次のような設計思想で作られているそうです。
QAファンネルの各要素のMECE性への回答（にし）：QAというのはすべからく、MECE性を求めつつ、でもMECEにすると間がスッポリ抜けてしまうという矛盾と闘わなくてはいけません。そのためファンネルのレイヤは「別組織」のようなMECE性を担保する概念と、「時々」のような間をつなぐ概念が混在しています。
縦軸は先に挙げたにしさんの連ツイも参考になります。
もともとQAファンネルの縦軸は「主に影響を与える組織の大きさ（スケール）」なわけですが、それは「自分たちの対象の顧客（お客様だったり社内組織だったり）の大きさ」かもしれないし、「自分が採ることの多い施策の間接度」かもしれないわけです。
（主に）具体的な開発・QA業務にKPTなりPDCAを回すのはQAファンネルの上位層で、（主に）仕組みや評価制度に関わるのが下位層ですが、それが間接度になります。
でも、それだけじゃないよね、と。組織は常に変わり続けなくてはいけない、という、ある意味アジャイル的な、もしくはティール的な、もしくは成長前提の経営的な前提に立つならば、QAファンネルの縦軸は、変化の大きさ（スケール）を意味しているのだろう、と。フェーズゲートQAはテストサブチーム、インプロセスQAは一つのチーム、QAコーチは複数のチーム、QAコンサルは全てのチーム、QAプロモーターは会社全体を変化（改善や変革）させないといけません。
ということは、QAファンネルの使い方は、確かに組織内のロールバランスやロールパス（≒キャリアパス）、それらの速度になるわけですが、それだけではなく、組織に起こす変化（改善や変革）のバランスやそのための人材の再配置などの目安にもなるんだろう、と。
https://twitter.com/YasuharuNishi/status/1459712486756605955
JIS Q 9005における改善は次のように受け身というか自ら改善を仕掛けていく感じが薄いため「変化（改善や変革）させないといけません」というのはアグレッシブでドラッカーの「イノベーションに優れた企業は競争相手によってではなく自らの手で自らを陳腐化させる」を思い出しました。
10 品質マネジメントシステムの改善
10.1 改善
10.1.1 一般
組織は，次の事項を通じて得られた様々な問題点を改善の機会として捉え，製品・サービス及び品質マネジメントシステムを継続的に改善することが望ましい。
文末の「することが望ましい」はお気持ちではなく規格に特有の表現です。ISOなどの規格は要求事項規格とガイドライン規格があり、規格要求事項は「shall、何々しなければならない」、ガイドライン（指針）は「should、何々することが望ましい」と表現されます。
JIS Q 9005はその適用範囲の説明で「品質マネジメントシステムについての指針を示す」「この規格は，認証，規制又は契約に用いることを意図していない」とあり「することが望ましい」となっています。
（参考：ISO規格要求事項とは何かを学ぼう｜ISO研修ならテクノファ）
縦軸はあくまでもロール（役割）であって役職ではありません。ロールを果たすために役職が必要なことはあるもののQAファンネルはロールと役職は切り離して扱います。仮にQAファンネルに役職を持ち込むと一番上の「出荷判定を担う」品質保証部の部長は偉い人だしQAプロモーターはCQOという説明があってこちらも偉い人で、単純に下へ行くほど役職が高いわけではなく偉い人と偉い人にサンドイッチされています。
QAプロモーターは品質担当のCTOへの回答（にし）：そうです。CQOですね。ちなみに某グローバル事業会社（notソフト専業）は、CSQOのVP（ソフト品質担当副社長）がいるそうです。すごいね！
QAファンネルはあくまでも型であって、各々の組織のコンテキストに合わせてアレンジして使うものという説明です。もしSigSQAの提示するQAファンネルに違和感があるならこれは「QAファンネルフレームワーク」にSigSQAが想定したコンテキストを当てはめて生成したサンプルと考えるのが適当と思います。
QAファンネルって何だ？ p.13
例えば「各社の品証部長が語るソフト品質保証の取り組み」によれば、「品質保証部と事業部が分かれている組織」と「事業部内に品質保証部が設置されている組織」のどちらもあります。
また、組み込み系に属する筆者は開発とは別組織の品質保証部が出荷判定を行うことに特に違和感がないのですが、出荷権限を品質保証部が持つかは組織や分野によるようです。
QAファンネルは1)独立QA部門と開発内QAの二本立て、2)開発とは別組織のQA部門が出荷判定を担う、という建付けなことやSigSQAの方もアレンジを勧めていますので、自組織とマッチしない部分は適宜アレンジするのが良いと思います。
QA部門が出荷判定の権限を持つかどうかは「探針テストと「強いQA」「弱いQA」」が、QA部門と開発部門の独立性は秋山さんの「第111回： テストの独立性と開発との関係」が参考になると思います。
以下の図でソフト構造とハード構造はQAファンネル、QMファンネルが、戦略は後日QAスタイルファインダー（旧QAオクタゴン）がSigSQAから提示されました。QAスタイルファインダーはRSGT2022での発表の様子がYouTubeに残されています（RSGT2022 Day2: 2F Main Hall WEST 手前）。
QAファンネルって何だ？ p.21, p.33, p.34
3.2 QMの三角錐とQMファンネルにおけるQA
「品質の高い製造業の品質マネジメントをイマドキの考え方で整理してみた/Demystifying quality management for large scale manufacturing in modern context」でQMの三角錐とQMファンネルにおけるQAの説明がありました。
DevOpsDays Tokyo 2021のタイムテーブルで
この発表では、発表者の経験から、高品質を生み出すTQMの考え方を以下の4つのマインドセットにまとめ、説明していきます。
- 品質という終わりなき旅
- 全員を愚直で賢くする
- 納得感の共感を高める
- 弱さに寄り添う
とありますが、なぜ製造業の品質マネジメントがQAファンネル、QMファンネルに関係するかはp.3を見ると分かります。
- QM（品質マネジメント）にはTE、SET&SRE(PE）、QAの3つロールがある
- TEがQAになるためのマインドセットとして、ハードウェアのTQMをものすごくデフォルメして紹介
QMファンネルをお披露目する前に、QAファンネルとQMファンネルを橋渡しするQMの三角錐の説明と併せてTQM（をにしさんがソフトウェア向けにアレンジしたもの）の説明を挟んだようです。
質問回答対応表からQMの三角錐やQMファンネルのアイデアはJaSST'21 Tokyoの時点ですでにあったことが伺え、DevOpsDays Tokyo 2021ではその説明がアップデートされていることがわかります。
Q：QAファネルだけでなく、テストファネル、テスト自動化ファネルみたいなものはないですか？
A：テストファネルへの回答（にし）：あります。個人的には、品質関連ロールはSET+SRE、TE（テストエンジニア、ただし探索バカではない）、QA（開発の弱いところに寄り添って納得感の共感を高める）の3つがあって、それぞれに三角形のファンネルがあって全体として三角錐になると思っています。
「組織能力を高めるエキスパート」について、JaSST'20 Tokai 基調講演「Re-collection of embedded software QA in the last decade」から関係しそうなセンテンスをいくつか拾ってみます。
- テストとは、開発組織やテスト組織の能力を 持続的に革新するための作業である(p.4)
- 開発者が「腕が上がった」と思える施策を立案する(p.38)
- QAのミッションとマインドセットをもう一度明確にする(p.40)
- 納得感の共感を高め、チームの弱いところをチーム自らがカイゼンしていけるようにすることがQAのミッションである
- サーバントシップ、カイゼンサイクル、ミッションシェア、アップストリーミング、ストーリー化がQAの持つべきマインドセットである
- 「悪さの知識」に着目し、知恵の循環が組織全体で行われるようにする（フロントローディング）
- 品質は組織能力の表れであるので、あらゆる組織の能力向上がミッションのはずである(p.76)
- 開発とQAで一緒になって、自社の全社的なものづくりの「あり方」を構築しよう(p.85)
- 組織の持続的革新能力と活気をどのように発生させ充満させていくのか
p.4に登場する11年前のスライドはJaSST'09 Tokaiの基調講演、「テストの改善、テストによる改善」のものですね。
「TE？SET&SRE？QA？どれか一つだけじゃなくて、3つを理解できて初めてちゃんとQMができる」と釘を刺しています。
また、QMファンネルにおける（狭義の）QAのロールをハードウェアのTQMをソフトウェア向けにアレンジして次の4つにカテゴライズし、アジャイルテストの4象限に対応づけて提示しています。
- ずっと「品質とは何か」を考え続ける：Business Facing
- 全員をより賢い愚直にし続ける：Guide Development
- 納得感の共感を高め続ける：Technology Facing
- 弱さヲ抱擁スル：Critique Product
3.3 QMファンネル
にしさんいわく、QMファンネルの3面は次に引用するような考えで生まれたという話です。
DXの時代になって、品質文化って一体何だろう、と問い直している自分がいる。 #jasstkansai
せっかく日本のTQCは顧客価値だけじゃなくて「全部だ」と言ってたのに、なんだか最近のQC業界は顧客価値だけに絞っているような気がしている。しかも静的な。
なのでQMファンネルでは品質文化を、顧客価値重視文化、組織能力向上文化、エンジニアリング文化の融合だと考えてみたのね。（2021年6月26日）
https://x.com/YasuharuNishi/status/1408693884645904396
（広義の）QAの実務は多岐に渡ります。なのでQMファンネルではTE、SET、QAに分けました。 （2022年8月30日）
https://twitter.com/YasuharuNishi/status/1564603247569956865
TQCの発展形であるTQMのモデル（JIS Q 9005のQMSモデル）をエイヤでTE、PE、QAで色分けしてみたのがこちらの図です。
TEは検証技術と価値重視文化を担うことから検査・試験に限らず研究開発（検証技術の開発）や顧客支援（顧客価値を損ねる市場流出バグの対応）なども含めています。
QAのエリアが広いですがQAプロモーターはCQOとの解説もあったし、グランドデザインを描いてみようという人は読んでみるのをおススメします。
「8.製品・サービス実現」の設計プロセスをDevOpsのモデルに置き換えてみたのがこちらの図です。DevOpsのライフサイクルの内側、外側のどちらにもTE、QAの役割があることがわかります。
モデルでものごとを考えることについて、にしさんの「モデルと作戦盤」が参考になると思います。
QMファンネルはTQMをソフトウェア向けに次のようにアレンジしたものという見方ができます。
- JIS Q 9005のQMSモデルで7つの箇条に分かれているのをTE、PE、QAの3つに集約
- JIS Q 9005で標準化、改善と項目が分かれているのを「チーム全体の品質向上、ふりかえり力向上＆プロセス改善・・・」と平易に表現
- ロールのバランスを可視化できるように
JIS Q 9005の標準化は「個人がもつ情報並びに知識及び技術を共有化し，適用するための手順を確立し，実施し，維持すること（出典：JIS Q 9005:2023 7.4.1）」です。「西康晴氏のソフトウェア開発における標準化に関するツイート」も参考になると思います。
Scrum Fest Osaka 2021の「品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話（3D版）」でQMファンネルが紹介されました。
Scrum Fest Osaka 2021でのセッションということでスクラム屋さん向けに導入部分が書かれていますが筆者はスクラム開発は門外漢のため飛ばします（スミマセン）。
p.6とp.8に表現を変えて登場するTE、PE、QAエンジニアの専門性を次の表にマージします。
| TE | PE | QAエンジニア |
|---|---|---|
| テストする人 | 自動化する人 | みんなをよくする人 |
| テストの実行・設計・計画・戦略立案・管理・推進など | （E2Eも含めた）テスト自動化、 CI/CDやCT（継続的テスト）のパイプライン構築、SREやMlops、自動化戦略立案など | チーム全体の品質向上、ふりかえり力向上＆プロセス改善、フロントローディング/シフトレフト、品質戦略立案など |
| テストやレビュー、メトリクスの測定など製品やサービスの評価技術のエキスパート | 様々な自動化を行うエキスパート（SETやSRE） | 組織能力を高めるエキスパート |
| 検証技術と価値重視文化を担う | 自動化・デジタル化技術とエンジニアリング文化を担う | 組織能力向上の技術と文化を担う |
先に挙げたにしさんのツイートではTEの価値重視文化は顧客価値重視文化を指すように見えるものの、筆者はおおもとのTQMに立ち返って顧客価値と社会的価値の両方を含むと解釈しています。
p.10のQMファンネル（3D版）は専門性がTE、PE、QAと詳細化され、これまで明示されないでいたロールが登場したりもしています。
出荷判定がスプリットTEにマッピングされていて出荷判定を行う品質保証部の部長を「テストエンジニア」と呼ぶのは違和感があるのですが、TEは便宜上そう付けられた名前のため気にしないことにします。
TEは、テストやレビューをしたり、製品のメトリクスを測定・分析したりする人です。現代的に言うと、プロダクトやサービスの価値を気にする人であって、テストだのレビューだのは手段です本来。でもバグを見つけるのも大事な仕事です。
本来はVE（バリュー・エンジニア）とか名付ければよかったんだと思いますが、TEの方が馴染みがよいし、VEというのは（H/Wの）生産管理の分野でメチャメチャ有名な用語なので、使いたくありませんでした。なのでTEです。
https://x.com/YasuharuNishi/status/1564607467496935426
QAファンネルでは「開発とは別組織のQAの実業務」に含まれるものの明示のなかったコンプライアンス系のロールがQMファンネルではスプリットQAに明記されました。スプリットなのは独立性を高めてガバナンスを効かせる（事業部に対して牽制を働かせる）ためですね。専門性は、コンプライアンスを社会的価値と対応付けるとTEが良さそうですが組織能力向上を担うQAに配置してあるのはRe-collection of embedded software QA in the last decade p.59の次の説明に合わせたものと思います。
認証が必要なら モデルベースQAやアジャイルQAに対応するよう受審を変化させる
- 審査員の指摘を無くすのではなく、自分たちが納得感の高い開発をしていることを審査員に共感してもらえるような説明力の高い開発・QAを行う
QAファンネル・QMファンネルはほかのフレームワークと組み合わせるのも一案です。例えばPEプロモーターは「…自動化・デジタル化技術の方向性やビジョンを示し…」とありますが、例えばAQUAフレームワークと組み合わせると「サービス立ち上げ期であればUTレベルのCI、サービス安定期であればE2Eテストの自動化やフルCI」のように組織やプロダクトのコンテキストに合った方向性やビジョンを示すのがやりやすくなる期待があります。
こちらはJaSST'22 Tokyo セッションA6、「ウイングアーク１ｓｔのQMファンネルを使ったキャリアイメージ」の資料から引用したものです。
SigSQA版と見比べると出荷判定がスプリットTEからなくなっていたり監査がスプリットQAからQAコーチへ移動していたりとアレンジされていることがわかります。また、資料の後のページではロールが担当する業務や成果物が解説されています。
QAファンネルはまずグランドデザインがあってそのグランドデザインはそう頻繁には変化しない一方で、業務や成果物は毎年ちょっとずつ変わる可能性があります。例えばQAコンサルタントに組織内品質基準策定とあり、来期は策定した基準の有効性レビューがあるかもしれません。グランドデザイン→QMファンネル→QAキャリアイメージ→個々の業務や成果物とブレークダウンしていくのは、QMファンネルの活用事例として分かりやすいと思いました。
また、QMファンネルを使ってQAキャリアイメージを描いてみるでは「注意2：まだまだ考慮不足はあるため、今後頻繁に変わる可能性があります。」とありますが、定期的に―例えば今期の振り返りや来期の目標を立てるタイミングで―見直したり改善するのも一案と思います。
ウイングアーク１ｓｔさんのQAキャリアイメージは次のような経緯で作られたそうです。組織に合うように調整されたQMファンネルにもとづくキャリアイメージはその組織に属するメンバーにとって役立つように思いました。
さて、この記事に書いた通り、私は今年の6月からSPQI部の部門長になり、さまざまなことに取り組んできました。その一環としてメンバー全員との1on1をしました。1on1を通してメンバーからのフィードバックで一番多いコメントが、「キャリアが明確にない」ことでした。
そこでちょうど良い機会なのでQMファンネルを使って、ウイングアーク版のQAキャリアイメージを描いてみようと思ったのが全てのきっかけです。
出典：QMファンネルを使ってQAキャリアイメージを描いてみる
QMファンネルを個人で活用するメリットを挙げると
- 自分の得意不得意、強み弱みをマッピングできること
- 自分が不得意なものも強制的に目に入ってくること
- どこに軸足を置いて活動するかを地図のように描けること
と思います。例えばテストに強い品質エンジニアを目指したり、経営に貢献する品証部門を作れるようチームで成果をあげるためのスキルを伸ばしたり。SigSQA版が提示するのはロールまででそこからブレークダウンした業務や成果物はないのでそこは各自で決める必要がありますが。
新しい品質保証のかたちへのつながりへの回答（にし）：WF的にはプロセスとメトリクス、Agile的にはQAは定義されておらず探索と自動化（でも現実は人力）、というのが古いかたちだと個人的に考えています。要するに、目の前の仕事しか見えていないのが古いかたちです。そこから脱却するための一つ目のツールがQAファンネルです。
QAファンネルがQMファンネルになってTE、PE、QAの三面そろってQM（品質マネジメント）と示されたことで面の薄いところを認識しやすくなったように思います。得意でない領域のことはなかなか自分では気づかないしつい避けてしまいがちなので。
筆者はもともとは組み込み系の開発者でハードウェアをテストするためのソフトウェアなどを担当していましたが、その後インプロセスQAにスイッチし、ソフトウェアのテストを体系立てて押さえる必要があると考えてJSTQB FLを取得しました。これはQAファンネルが登場する前の話ですが、QMファンネルで言えばQAエンジニアに軸足を置きつつTEの領域を補ったものと言えます。
ハードウェアをテストするソフトウェアは身近なものだとパソコンのPOST（Power On Self Test）がイメージしやすいと思います。例えばメモリ（RAM）のテストは「CとGNU開発ツールによる組み込みシステムプログラミング 第2版 6.4 メモリの検査」が参考になるでしょう。
4. おわりに
QMファンネルはその進化の過程をQAファンネルからたどるとさまざまな資料が公開されていることがわかります（SigSQAの皆様ありがとうございます！）。応用例だったり、自分が疑問に思うことが質問回答対応表にすでに載っていたり、イベントによっては動画が残されていたり、TQMのソフトウェア向け解説がされたりと理解を助けるものがいろいろあります。なるべく広く資料にあたったりTQMをかじってみるとよいと思います。