1. はじめに

「ゲーム作りで「第１世代目はなぜ一線級を保ちつづけるのか？」と、そのなり方、落とし穴」を拝読し、諸説ある「QAエンジニア」に "第一世代、第二世代" を取り入れると見通しが良くなるのではと思いました。

第１世代：一人で全部やるため全てのスキルを身に着けることができ、全体感を獲得できる
第２世代：第一世代が敷いた分業化のレールの上に乗るため、高い専門性を獲得することができる

以下、こちらのブログ記事を引用させていただきながらQAエンジニアに当てはめてみたいと思います。

2. 第一世代

第１世代の最初は、すべてが足りないし、わからない中で行うため、足りないものはとりあえず自分でやってみるというのをやってきた世代である。テキストを書いたことがないけど、書いてみる。企画をやったことないけどやってみる。ストーリーを作ったことがないけどやってみる。絵を書いたことがないけど描いてみる。ビジネスがわからないけどやってみる。わからなければ本を読めばいい。わからなければ知ってる人に聞けばいい（いないことが多いが）。わからなければ検索すればいい。どこかにできる人間がいるなら、30点くらいのものなら自分でもできるはずだ。
出典：ゲーム作りで「第１世代目はなぜ一線級を保ちつづけるのか？」と、そのなり方、落とし穴

第二世代のQAエンジニアにとって「あって当たり前」のさまざまなものが第一世代の最初は整っていません。例えば開発部門とQA部門の役割分担を示すのに組織図や業務分掌が必要となったら書いたことがなくても見様見真似で書いてみるのが第一世代のQAエンジニアです。そんな感じで第一世代のQAエンジニアはQMS(Quality Management System)の部品をいろいろ作ってシステム化してゆきます。

また、「とりあえず自分でやってみる」のは第一世代のQAエンジニアにとって大事な素養です。0のまま足踏みしていても先に進めませんが「30点くらい」でもこれをたたき台にして改善できます。

3. 全体感

ゲーム開発でいうと全体感を持った人というのは、例えば
・隣の部署の仕事の理解
・ワークフロー
・パイプライン
・コスト構造
・マーケット接続
・自己とマーケットの切断
・ゲームのやり込み
・他業界からの価値転移
みたいなものを理解している人間である。
出典：ゲーム作りで「第１世代目はなぜ一線級を保ちつづけるのか？」と、そのなり方、落とし穴

これはゲーム開発に限らずソフトウェア開発やもっと広くもの造り全般も当てはまる話と思います¹。

また、ソフトウェア品質保証は業務を通じて全体感を体得する方法に加えてソフトウェア品質知識体系(SQuBOK)ガイドやISO 9126、ISO 25000 (SQuaRE)といった体系があり書籍や文献に頼ることもできます。筆者は開発者からQAエンジニアへスイッチしましたが開発者として得た知識経験にソフトウェア品質保証の体系を足していきました。筆者が参考にした書籍や記事を以下にいくつか紹介します。

体系的な話
マネージャや経営層の視点
- ソフトウェア品質保証部長の会の資料群
- 基礎から学ぶQMSの本質
お金の話
- コストマネジメント入門
- 品質問題の本質と解決の考え方『品質でもうけなさい』目次

このほか、この記事を書くためにググっていたところ「プロジェクトマネージャが目指すソフトウェアの品質確保とは（日立ソリューションズ、2012年）」という資料を見つけました。品質管理の枠組み作りとして「1.役割分担の定義、2.品質管理指標（メトリクス）、3.品質目標値基準の設定、…（p.29）」など紹介されておりもっと早く知っていたかったと思いました。

開発者からQAエンジニアにスイッチして変わったことの一つにいろいろな部門のマネージャや経営陣と関わる機会が増えたというのがあります。QAエンジニアは他のエンジニアよりも品質について考える機会が多いと思いますが「品質」とマネジメント層の関心が高い「利益（売上、コスト）」の関係は押さえておくと良いでしょう。

品質が良いとは、顧客満足度が高く、よく売れて高値で売れること。
品質が悪いとは、余分なコストがかかること。

品質の良い商品・サービスだけを提供できれば，無駄がなく“原価”を抑えることができます．
つまり，安上がりにできるということです．

一方で，品質の良い商品・サービスというのは，顧客のニーズを満たしているのですから，顧客からの反応が良く，よく売れていきます．
それだけではありません．
他社に比べて“高値で”売れるのです．
出典：基礎から学ぶQMSの本質　第6回　品質を経営の中心に据える(2016-2-29)

品質改善というのはコストダウンと同じ意味です。
出典：『品質でもうけなさい』2-2.品質とは「良さ」なのか？

成果の可視化を色々な視点で実施してきましたが、やっぱりコストで示すのが一番有効でした！
出典：「受身から攻めのQA」に至るまでの道のり | BLOG - DeNA Engineering

4. QAディレクター

ただ、作り手としては第１世代には圧倒的な強みがある。必要な分野を垂直統合できる能力だ。別にすべての分野を極めなくても良い。実工程自体は専門家に外注できる。認識できて分野のボトルネックがわかれば良い。これこそが「ディレクター」そのものの能力であり、成果の根幹である。
出典：ゲーム作りで「第１世代目はなぜ一線級を保ちつづけるのか？」と、そのなり方、落とし穴

第一世代のQAエンジニアは「とりあえず自分でやってみる」を繰り返すうちにさまざまな「引き出し」ができます。引き出しは技術的なものもあれば頼れるメンバーが増える、予算を組んで来期の品質活動に備えるといったものもあります。

ソフトウェアを開発してリリースするサイクルを回すのに専任のQAエンジニアは必須ではありません。それにも関わらず専任のQAエンジニアやQA部門を置くとしたら置くと決めた側になにかしらの課題や期待している効果（例えば開発部門のメンバーと協力して品質問題を解決してほしい、並行して組織全体の品質改善も図りたい、、、）があるはずです。

品質問題を整理し、目標を立て、手持ちの引き出しを増やしたり垂直統合したり水平展開したり関係各所へお願いして回ったりして品質活動を推進し成果を出す第一世代のQAエンジニアを「QAディレクター」と呼ぶのはいかがでしょうか。

5. 第一世代のQAエンジニアの役割

QAエンジニアの役割を分類した「QAファンネル」で言うと、第一世代のQAエンジニアはインプロセスQA、QAコーチ、QAコンサルタント、QAプロモーターのハイブリッドになるように思います。また、QA部門のしかるべき立場のメンバーが出荷判定を担う場合はフェーズゲートQA・QAサービスの役割も入ってきます。

立ち上げフェーズ
- インプロセスQA
  - 顕在化している品質問題を解決する
    - 開発部門に入り込んで問題を整理する
    - 品質管理指標を立てて品質を把握する
    - 問題に優先順位を付けて施策を打つ
- QAプロモーター
  - 組織化する
組織化フェーズ
- インプロセスQA
  - 品質問題の解決を横展開する
- QAコーチ、QAコンサルタント、QAプロモーター
  - 組織全体の品質改善を図る
    - 品質の目標を掲げる
    - さまざまな部門のメンバーが共通の目標に向かって走れるようにレールを敷く
      - ディレクションする
      - プロセス化する
    - 成熟度合いに合わせて目標をリニューアルしたりプロセスを改善する
- フェーズゲートQA・QAサービス
  - 出荷のGo/NoGo判定を行う

6. おわりに

「QAエンジニア」に "第一世代、第二世代" を取り入れると次のように整理できるのではないかと思います。

第一世代のQAエンジニア：立ち上げ段階から多種多様なニーズウォンツに対してQAのサービスを広く浅く（＋専門分野はそれなりに深く）提供する
第二世代のQAエンジニア：分業体制下で専門分野のQAのサービスを深く提供する

なお、第一世代は掛け持ちでボトルネックが発生したりスケールしない弱点がありますがこれは稿を改めて考えたいと思います。

「自己とマーケットの切断」はよく呑み込めていませんが… ↩