1. はじめに
QAエンジニアは採用が難しいという話がありますが、開発者からQAエンジニアへスイッチした筆者の経験でいうと社内の開発者から発掘するのも選択肢の一つと思います。
2. 筆者の例
筆者はもともとは組込み系のプログラマでしたがQA部門に異動する前はアプリ設計部門に所属して設計支援やQA業務を担当していました。その一部を以下に挙げます。
- 設計やテストのよろず相談
- 設計やテストに使用する機材の選定、調達
- テストツールの設計、実装とそれを用いたテストの自動化
- 品質メトリクスの設計、収集、収集の自動化
- 法令対応
その後QA部門の打診があり設計部門へ置いていった業務もありますが次のような理由で異動しました。
- 担当していた業務を組込み系などほかの機種へ展開しやすくなる
- QAの知識やスキルが活かせる
これまでいくつかの部署を経て要件定義、仕様設計、実装、テスト、試作立ち合い、量産立ち合い、リリース後の市場対応など経験したのがQA業務に役立っています。
また、顧客に限らず非顧客への価値提供でもある法令対応は社内の事務局の偉い人に相談したり業界団体のセミナーに参加したりもして顧客価値だけでなく社会的価値もQAのスコープのうちという認識を持つようになりました。
3. 開発者から発掘するメリット
筆者が考える開発者から発掘するメリットを以下に挙げます。
3.1 ドメインや事業と親和性がある
開発者はたんにソフトウェアを作れるだけでなく、（部外者と比べて）開発しているプロダクトや事業のことをよく知っています。ドメイン知識でいえばその分野に固有の用語といったものもあれば市場や顧客のこともよくわかっています。
3.2 ものづくりのプロセスを把握している
QAエンジニアの業務の一つにプロセス規程の改善があり規程に則った開発経験は役立ちます。実装に限らず上流から下流まで、リリース後の市場対応含めなるべく広い経験があるとなお良いです。
また、社内用語だったり新しいツールを導入するならいつごろまでに来期の予算に積んでおくといった社内ルールを把握しているのもメリットです。
3.3 さまざまな部門のメンバーを知っている
開発者は同僚の開発者だけでなく、企画、テスト、ハードウェアのエンジニア、生技、品証、品技、営業、カスタマサポートなどさまざまなメンバーを知っています。また、開発環境やテスト環境の構築に情シス部門が関われば情シスメンバーも、法令対応で法務部門が関われば法務メンバーも知り合いになります。
QAエンジニアはさまざまな部門に横串を通して回ったりするためさまざまな部門のメンバーと知り合いなのは有利です。
4. QA部門に必要なこと
筆者が考えるQA部門に必要なことを以下に挙げます。
4.1 QA部門を知ってもらう
一言でいうと開発者からQAにスイッチしたくなる魅力が必要です。
QAエンジニアはさまざまな部門のメンバーと協働する機会が多いですがそういう場に参加する開発者がリーダーばかりだと担当レベルの開発者からQAの活動が見えないおそれがあります。また、QAの業務は裏方仕事なところがあって放っておくと目立たないです。そこで意識的に露出するようにします。例えば新たに開発した品質技術を社内の技術発表会でアピールするのは良いアイデアです。
4.2 マッチング
QAエンジニアを社内の開発者から発掘するといってもQA部門と開発者・設計部門の双方にメリットがないと成り立ちません。設計部門にとって開発者は貴重なリソースであり設計部門からQA部門へ異動すると組織全体にとってメリットが大きくなることを示す必要があるかもしれません。
4.3 QAエンジニアに必要な教育、サポート体制
固有技術のエンジニアとしてプロダクトを作る業務から管理技術のエンジニアとしてプロダクトづくりの仕組みを作る業務に変わります。開発経験が大いに役立つとはいえQAエンジニアとして身につけるべき知識やスキルはたくさんあります。
読み物の例を以下に挙げます。
5. おわりに
設計部門の中でプロダクトを担当していると部門外、担当外のプロダクトの業務はなかなかやりづらいものですが、QA部門へ異動して設計部門の外に出たことで設計部門のどこの課にも出入りしやすくなりQAサービスを提供しやすくなりました。また、インプロセスQAからスプリットQA+αに守備範囲が広がったことでQAエンジニアとしてのスキルも上がったように思います。
あくまでも筆者の例、n=1の話ですが、設計支援やQA的な業務をしている開発者がいれば話を振ってみるとよいかもしれません。
QAエンジニアを社内の開発者から発掘するのはうまくはまると開発者、設計部門、QA部門、組織全体のそれぞれにメリットとなり選択肢の一つに加えると良いと思います。