以前の連載である1人目QAとしての立ち回りでは、会社や開発組織の1人目QAになった人がどのような活動をするのかや、品質保証を浸透させる際のアプローチなどについて触れました。
今回の連載では1人目QAとしてチームを立ち上げていく部分、組織づくりに関して、私が実践したことや試行錯誤中のことも含めてお伝えします。
初回である今回は、連載全体で対象とする部分の概要とQA組織を立ち上げる際の流れ、序盤に考えることになる「QA組織の形」について見ていきます。
QA組織を立ち上げる際の流れ
QA組織の形について考える前に、まずはQA組織を立ち上げる前後の流れについて整理してみましょう。業種や開発組織の規模などによっても異なりますが、ここ最近筆者がみるのは以下のような流れです。
- 1人目QA採用フェーズ
- 立ち上げフェーズ
- 組織化・拡大フェーズ
- その後
順に概要を説明します。
1. 1人目QA採用フェーズ
その名の通り、これまで組織にいなかったQAエンジニアを新たに採用するフェーズです。採用される側のQAエンジニア個人としてはこのタイミングでできることは基本的になく、開発部門のトップやCTO、個々の開発者などががんばる段階です。
この段階にある各社さんは、
- QAエンジニアのイベントに顔を出し、交流する
- カジュアル面談で外部のQAに話を聞く
- 他社のQAに副業として支援やアドバイスを受ける
など、さまざまな工夫をしながら情報を集め、採用を目指しています。
2. 立ち上げフェーズ
1人目のQAエンジニアが無事採用できたら、立ち上げフェーズになります。参画した1人目QAを中心として組織を作っていく段階です。
この段階において、1人目QAにはさまざまな役割があります。
大きくは組織づくりと品質向上のための活動です。
QAエンジニアを採用したということは、開発組織としてなんらかの狙いがあります。障害が多くて困っているなど急ぎの課題を抱えている場合もあれば、今は問題ないけれど組織の今後を考えていまのうちに・・・という場合もあります。
いずれにせよ、1人目QAには開発組織内に向けたなんらかの活動と成果が求められます。これは当然ですね。このような活動を総称して、ここでは品質向上のための活動と呼ぶことにします。
また並行してQA組織づくりに対しても貢献が求められます。実際に私も1人目QAとしての業務を始めた当初は、むしろこちらの割合が多いくらいでした。2人目以降の採用のため、募集要項を作成や、会社の状況や開発組織のようすなどを積極的に社外に発信したりしました。
3. 組織化・拡大フェーズ
組織化・拡大フェーズは、QAエンジニアの採用が進み、複数人のチームで動き始めている段階です。
社内に複数の開発チームが存在する場合にはQAエンジニアがそれぞれ担当を持つなど、このあと触れる開発組織とQAとの関わり方・組織パターンがわかれてきます。
4. その後
3の組織化・拡大フェーズまでの流れはある程度各社さん共通になるかと思います。しかしこの先は組織の形や規模、プロダクトの特性などに応じてさまざまな方向に分かれます。
たとえば開発組織がそれほど大きくない場合は「しばらくQAは今の体制でいこう」といった、いったん拡大をストップしてメンバーの中でできるQA活動に注力する選択もあるでしょう。
一方で規模の大きな組織、プロダクトが大きかったり、複数のプロダクトがあったりする場合には「採用して育てる」という方針をとる会社もあります。この場合は、自社内でジュニアなQAエンジニアを育てるための教育コンテンツ整備やグレード設定・評価の仕組み作りなどもQAエンジニアが担うことになります。
ここまでの内容を図にしたものが以下です。
以前の連載である「1人目QAとしての立ち回り」は、
- 2. 立ち上げフェーズ における 品質向上のための活動
が主な範囲でした。
今回の連載では、主に
- 2. 立ち上げフェーズ
- 3. 組織化・拡大フェーズ
における、組織づくりの面を対象とします。
QA組織の形を考える
ここからは、QA組織を立ち上げる際に考えるべきポイントのひとつである、組織の形について説明します。
QA組織を立ち上げよう！と考えたときに、いきなり採用を始めるわけにはいきません。もちろん、優秀なエンジニアの採用が困難な昨今、採用活動を始めるのは早い方が良いですが、単純に複数人がいればQA組織になるわけではありません。
開発組織や会社におけるQAの立ち位置や、将来的にQA組織が何を担おうとしているのかがまず先にあって、それに応じた最適な（と思われる）組織の形があるはずです。
QA組織の形は会社や開発組織によってさまざまなものが考えられ、単一の正解はありません。自組織にとって最も良い形を模索していくことになるでしょう。
なにもないところから最適な形を考えるのは難しいため、ヒントとなる考え方を2つ、ご紹介します。
組織の形を考えるヒント：QMファンネル
1つ目はQMファンネル（3D版）です。
しばしばQAと一括りにされる、テストエンジニアとSETとQAを整理してバランスをよくするための「QMファンネル（3D版）」
QMファンネル（3D版）
として、上記の資料中では説明されています。
QAエンジニアが3つ（テストエンジニア、パイプラインエンジニア、QAエンジニア）のスペシャリティに分かれており、それぞれについて5つのロール（スプリット、インプロセス、コーチ、コンサルタント、プロモーター）が存在します。
組織の形を考えるにあたって、これらのスペシャリティ×ロールをどのような構成にするのかを検討するとよいでしょう。
資料中では「ダメなロールバランスのTE組織の例」として、ロールのバランスが悪いパターンについても例示されており、こちらも見ておくと失敗を避ける役に立ちます。
QMファンネル（3D版）より
組織の形を考えるヒント：QA組織パターン
2つ目は、このSqriptsでも連載中の藤原 大さんが公開しているQA組織パターン – 構造ごとのメリットデメリットまとめです。
こちらの資料では、開発チームとQAチームがどのような関係性・人の構成になっているかのパターンが6つ紹介されています。
たとえば私が現在の組織で目指しているのは、「QA組織横断組織体制（アサイン型2）」に近いものになります。
QA組織パターン – 構造ごとのメリットデメリットまとめより
このパターンでは横断組織としてのQA組織があり、そこに属するQAエンジニアがそれぞれ担当の開発チームを持つスタイルです。まだまだ組織を作っている最中なのでこの形は実現できてはいませんが、いずれは、と考えています。
このように、理想とする組織の形について検討しておくことは、採用のうえでもQA活動を行って組織にさまざまなものを浸透させていくうえでも大切です。
組織の形を考える過程では、QAチームのミッションや開発チームへの関わり方などについてもあわせて検討する必要が出てきます。たとえば開発チーム複数に対してQAが1名だとすると、内部に入り込んでのQA活動を行うのは限界があります。したがって、外から開発組織にアプローチするような動き方がメインになるでしょう。
このような開発組織へのアプローチについては、以前の記事【第2回】組織に品質保証を浸透させるアプローチ | Sqriptsにて触れていますので、こちらもご覧ください。
まとめ
今回は、主に1人目QAがJoinする前後の流れや、QA組織の形などについて説明しました。
1人目QAを採用する前からこういった内容が検討できるとベターですが、基本的には1人目として採用されたQAエンジニアが主体となって考えていくことになるでしょう。とくに組織の形については決まった正解がなく、悩むことも多いかもしれません。本記事でご紹介したヒント等を頼りに検討してみてください。
次回からは、
- 2人目以降のQAを採用する際の考え方
- QA組織のチームビルディング
- QAとして、チームとしてのキャリアの作り方
- 教育や評価
など、チームを作るうえでのポイントについて幅広く触れる予定です。
