QAエンジニアの働き方や期待値が分かるオンボーディング資料を作ったので公開します

こんにちは、アルプ株式会社でQAエンジニアをやっている nametake です。

今回はQAチームのオンボーディング資料で使ったものを公開します。

新しく働き始めるQAエンジニアの動き方や期待値を整理している資料のため、もしアルプに興味を持っていただいたときの参考になれば幸いです。

オンボーディング資料

早速ですが、以下が今募集しているQAエンジニアのオンボーディング資料です。

背景と課題

上記で紹介しているオンボーディング資料は、入った直後にどういう期待値かを揃えるための資料です。

一方で、上記期待値の人が必要になった背景や組織的課題もあるため、そちらもセットで紹介しようと思います。

背景

アルプではQAチームは、Agile Testingの考え方を参考にしながら振る舞い駆動開発(BDD)で開発に関わっています。

今現在は人数が少ないということもあり、基本的にはチームに入らず外側から開発を支援する動き方が主体でした。

BDDはドキュメント化や自動化がよくフォーカスされますが、まずはその前に正しく要件を捉える取り組みが必要なプラクティスです。

アルプでは書籍でも紹介されているワークショップの「実例マッピング」を使用してその取り組みを推進してきました。

実例マッピングは手軽ながら効果もわかりやすいワークショップだったため、チームにはどんどん浸透していきました。

チームへの一定の浸透はしたと思ったため、QAチームとしては次のステップであるドキュメント化や自動化に取り組み始めています。

しかし、人数の問題もあり、現在QAチームは基盤や仕組みづくりを中心に行い、実際には開発チームに定式化と自動化はお願いしているという状況です。

課題

上記のようにBDDの運用体制は整ってきたのですが、実際にチームで運用を始めたら、いくつか課題が出てきました。

1. ドキュメント化が後回しになりがち

BDDの取り組みでは、要件を正しく捉え(発見)、その内容をドキュメント化(定式化)してそれが自動で実行できるようにする(自動化)、という流れを要件定義の段階から実施して、開発に入ってからの手戻りを少なくする取り組みです。

現在チーム内にQAエンジニアはいないため、定式化はチームの要件を決める人(アルプではPdM)を主体にやってもらっているのですが、自動化ができるようにドキュメントを書くことのコストが無視できなくなってきてしまっています。

もちろん、今までも要件定義の段階でPdMは操作シナリオを書くということはやっていましたが、自動化が前提になったドキュメントではそれらよりも厳密な記述をする必要があります。

今まで厳密な記述が無かった分どこかで暗黙的になっていたということなので、要件定義の段階で厳密なドキュメントを用意するメリットはチームにも理解していただいていて、導入自体は受け入れてもらっています。

しかし、コスト自体が下がるわけではないため、他にもやることが多いPdMやその他チームメンバーではドキュメント化が後回しになってしまいがちになっています。

2. BDDのサイクルに乗らない開発

発見の取り組みである実例マッピングが浸透してきたとはいえ、人を集めて行うワークショップである以上一定のハードルがあるため、小さな改善の開発では行われないこともあります。

そういう場合は、大抵要望がわかりやすくすぐに開発に入れてしまうため問題が起きづらくはあるのですが、開発が終わって機能確認の段階で大きめの認識ズレが発覚してしまうケースもまだまだ発生しています。

発生している認識ズレも実例マッピングを一度行っていれば発見できる可能性があったものが多いため、そういった部分にQA視点で実例マッピング実施のハンドリングをしていきたいのですが、いかんせんQAが外側にいる現状ではタイミングが難しいのが現状です。

3. 組み合わせテストの不足

まだまだ完全ではないとはいえ、発見のステップが上手くいくようになったことで、要件を捉え間違えるということは減少してきました。

結果として今度は機能の組み合わせ表を使うようなテスト部分が不足しているということも見えてきました。

今はチーム内のエンジニアが必要だったら作るという形をとっているのですが、テスト表を正しく作るには時間もスキルも必要です。

現状チーム内ではそこまでの時間確保はできておらず、チーム内に専門的なテスト表作成のスキル自体も不足しています。

QAチームとしても作成された表のレビュー自体はしているのですが、大きな機能での因子や水準の漏れは外側にいるとやはりレビューだけでは発見しきれません。

課題の原因と解決策

発生している課題は総じて、「チームにQA専任の人がいない」というところに落ち着きます。

それでは私がなぜチームに入っていないかという話になると思うのですが、以下のジョブディスクリプションの整理において、現在私はL-QA(リードQA)とA-QA(オートメーションQA)の2つの役職を兼任しながら働いています。

組織構造上、L-QAとA-QAはチームの外側にいるため兼任しても調整を効かせやすいのですが、T-QA(チームQA)はチームで取り組んでいる内容についてアンテナを張り続ける必要があります。

そのため、私がT-QAまで兼任してしまうと私自身がボトルネックになる可能性が非常に高く、現在T-QA的な業務はチーム内のメンバーに任せています。

そんな中、パートナーとして関わってくださる方向けに、アルプのQAチームの働き方や期待値を資料としてまとめる機会がありました。

上記課題の根本的な解決策としては採用なのですが、外から見たときにQAエンジニアはどういう期待値を持たれているのかが把握し辛い問題があります。

今回公開した資料はアルプでQAエンジニアがどういう期待値を持たれていて、どういう働き方ができるのかが外から見てわかりやすい資料になっていると思います。

これを公開することで、興味のある人につながればいいなと思っています。

アルプではQAエンジニアを募集しています

今回の資料はガッツリ採用向けのものですが、アルプでどういった働き方ができるのかが分かるようになっています。

また、今回はどちらかと言うとT-QAに特化した資料になっていますが、A-QAとして働いてみたいという方もまだまだ募集しています。

もしこの記事を見てアルプに興味が出た、もしくは話を少しでも聞いてみたいという方は、お声がけください。

meety.net