1. はじめに
「第一世代のQAエンジニア」で紹介したソフトウェア品質保証部長の会の資料を中心に、組織構造・業務範囲・権限・評価の話題を取り上げたいと思います。
2. 組織構造
「各社の品証部長が語るソフト品質保証の取り組み1」において組織構造（QA部門の位置づけ）が3パターン挙げられています。
①経営直轄型：事業部門から独立して、品質の砦として位置づけられる
②技術支援型：事業部門に対する全社的技術支援業務の一環
③事業部内型：事業部門内におかれ、事業特性に合わせた機能を持つ
QA部門を設けるならQAエンジニアやQA部門をどのように位置づけていて、将来どうしたい（どうなりたい）というビジョンを持っておくと良いように思います。以下は架空のビジョンですがこういのうが一枚あると経営側とQAエンジニア側で認識合わせがしやすくなるのではと思います。
- 最初は商品Xの設計部門へ入ってインプロセスQAとしてQAサービスを提供する
- QAエンジニアの効果を示して商品Y、商品ZへもQAサービスを展開し、並行してQAコーチ、QAコンサルタント、QAプロモーターとしてQA部門を組織化していく
- 出荷判定の権限を設計部門からQA部門へ移管しフェーズゲートQAとして出荷のGo/NoGo判定を行う
3. 業務範囲
「各社の品証部長が語るソフト品質保証の取り組み」によると、業務範囲として「QA（プロセス）」「QA（成果物）」「SEPG」「（品質）教育」「保守（出荷後障害管理）」「リスク管理（プロジェクト）」が挙げられていて、
QA（成果物・プロセス）および教育を業務範囲としている組織が多い
※組込系に比べ、エンタープライズ系の業務範囲は多岐にわたる
という話です。組み込み系の筆者にとって組み込み系のQAの業務範囲は妥当な感じがしました。
また、「1からQAエンジニア採用を始めるあなたへ【QAエンジニア採用の教科書】 」ではQAエンジニアの業務内容を大きく①テストに関する業務内容、②品質基準の策定やテスト実施後に起きる業務内容、の2つで整理されています。ただ、「一人目のQAエンジニアは、品質基準の策定からテストの実施までを自ら行うため業務範囲はものすごく広く、採用難易度は高めです」についてはQA部門の業務範囲とQAエンジニア個人の業務範囲が混ざっているように思いました。
QA部門の業務範囲が広いのはその通りで中にはこれもソフトウェアのQAの範疇なの？と思うようなものも持ち込まれたりすることがありますが、そうは言ってもリソースは有限なので重要度や優先度でやるやらないを決めて対応します。また、QAエンジニア個人でいえばどの分野もできるというよりも得意な分野がいくつかとその他は広く浅くという感じと思います。QA部門を設けて品質改善を図るなら得意分野がちょっとずつ異なる複数のQAエンジニアでチームを組んで業務範囲を広げていくのが良いのではと思います。
4. 権限
ここでいう権限は出荷判定の権限で「各社の品証部長が語るソフト品質保証の取り組み」によると「組込系は品質保証部、エンプラ系は開発・製造部門 に明確に分かれた」という話です。
QA部門が出荷判定の権限を持つかどうかは「探針テストと「強いQA」「弱いQA」」も参考になると思います。
5. 評価
「各社の品証部長が語るソフト品質保証の取り組み」によると、品質保証部の組織としての評価項目に「出荷後のバグ・不具合件数」「出荷後の事故費用、回収不能コスト」「プロジェクトの赤字数。赤字額」「社内への貢献（レビュー指摘内容、ES指標など）」が挙げられていて、
組込み系とエンタープライズ系で、評価尺度に大きな違いがある
・組込み系：出荷後の不具合を減らすという具体的指標
・エンプラ系：ビジネス全体の品質を向上させるという幅広い指標
とのことです。組み込み系の筆者にとって組み込み系のQAの評価項目は妥当な感じがします。また、業種によって指標が異なるのは興味深かったです。
また、グリー品質管理 Advent Calendar 2021の「より良い成長につなげるために！QAメンバーの目標設定」では「目標とはかくあるべきか」からスタートしてさまざまなKPI、KGIを紹介されています。
6. おわりに
今回取り上げた組織構造、業務範囲、権限、評価はいずれも経営の専権事項と考えられるものです。
第二世代のQA部門（分業体制が確立しているQA部門）で担当者としてQAの仕事をするのであれば「品証部長はこういうのも考える必要あるのですね」と眺めていられるのかもしれないし、少なくとも経営側はQA部門の役割をきちんと説明できることが求められます。
一方、一人目のQAエンジニアを採用するなどしてQA部門を立ち上げる場合は経営側にQA部門やQAエンジニアの知見が不足している可能性があります。自分自身で成果を出すだけでなくQA部門がスケールするようにレールを敷くのも第一世代のQAエンジニアの役割である以上、経営の専権事項といえども組織と自分自身のどちらもバリューを出せるようQAの専門家として助言してゆくのが良いと思います。