この連載では、1人目QAとしてのチームの立ち上げや組織づくりに関して、私が実践したことや試行錯誤中のことも含めてお伝えします。
前回の記事では、QA組織立ち上げのための２人目以降のQAエンジニア採用にあたって考えることについて解説しました。
今回は、QAエンジニアの採用が進んだ先でチームとして成果を出すための、チームビルディングについてご紹介します。
QAエンジニアに限らずどのロールにおいても、ただ採用を行ってメンバーを増やせばよいわけではありません。メンバーがその能力を発揮し、成果を出すための仕組みや関係構築が必要です。私も現在所属している部署では、QAエンジニアを採用しチームを構築している最中です。採用やチーム構築にあたっては、過去に所属していた企業でのノウハウを用いて取り組んでいます。本記事では、チームビルディングに関する一般的なポイントから、とくにQAチームにおいて重要な点についてご紹介します。
そもそもチームビルディングとは
QAチームの話に入る前に、まずは一般的なチームビルディングについて見ていきましょう。
チームビルディングはチーム（組織）をビルド（構築）することですが、前述の通り単純に人を集めるだけではいけません。『チーム・ビルディング[新版] 人と人を「つなぐ」技法』によると、チームビルディングとは「チームを機能させるための働きかけ」である、とされています。
チーム（組織）は、グループ（集団）とは違います。チームがチームであるためには
- 共通目的
- 貢献意欲
- コミュニケーション
が必要です。チームビルディングではこれらの要素をそろえて、個人の集まりであるグループから、共通の目的に向かうチーム（組織）へと進めていくことになります。成果を出せるチームに育てていくこと、と捉えても良いかもしれません。
チームビルディングの基本ステップ
同書では、チームビルディングの基本ステップ、という考え方が紹介されています。
チーム・ビルディングの基本ステップ をもとに作成
チームビルディングの要素としてよく雑談などが取り上げられます。これらは①会話に該当し、チーム内の関係性を築く、土台としての役割です。チームビルディングにはその先があり、対話や議論を通じて意味の探求・行動の変革につなげ、そしてふりかえり（省察）をしてチームづくりにフィードバックと続きます。
QAチームでのチームビルディング
ここまでは、一般的なチームビルディングの定義や意味について説明しました。ここからは、QAチームの立ち上げフェーズを、タックマンモデルで考えてみましょう。
タックマンモデル
タックマンモデル をもとに作成
タックマンモデルとはチームの成長の段階を表したもので、以下の4段階があります。
- 形成期：メンバーが集まり関係性を築く時期
- 混乱期：メンバーの考え方の枠組みや感情がぶつかり合う時期
- 統一期：共通の規範や役割分担ができあがっていく時期
- 機能期：チームとして機能し、成果を出していく時期
※各期の呼称は情報源によって複数ありますが、今回は前述の書籍に合わせています。
チームビルディングをうまく行うことで、機能期に至るまでを早められます。
QAチーム形成期
形成期はメンバーが集まり関係性を築く時期のため、とくにチームビルディングにおける基本ステップのうち、①会話 を通じた土台づくりが行われると考えています。
雑談や分報（Times）などを通じて会話や自己開示の機会を増やし、相互のキャラクターなどを理解する施策が一般的です。
このほか、エンジニアチームの形成期には「スキルや得意分野の可視化」を行うのが個人的にオススメです。QAチームのメンバーそれぞれが
- 【第1回】QA組織立ち上げの流れと組織の形 | Sqriptsでも触れたQMファンネルにおけるスペシャリティ
- QAスキルアセスメントの結果
- Test.SSFをもとにした所有スキル
などを可視化・共有することで、相互のスキルや得意な分野を把握できます。このようなスキルの可視化・共有は関係性作りに有効で、とくに「誰が何をできるか」だけでなく「チーム全体として経験がない分野は何か」がわかります。補うための勉強会を開催してさらなるコミュニケーションの機会にしたり、QAエンジニア教育のための仕組みやコンテンツ整備をしたり、といったアクションが取れるためです。
QAチーム混乱期
「混乱」や「感情がぶつかり合う」というと表現が強めなので、どちらかといえば「方向性がまだ定まっていない時期」くらいに捉えておくのが良いと考えています。
QAチームを立ち上げてメンバー間の関係性が出来てくるとともに、チームとして会社や組織の中でどのように価値を発揮するのかや、ミッション、業務の進め方など大きなレベルのものごとを定める必要があります。
個人的な意見ではありますが、この「チームのミッションや方向性を定める」という活動自体が、とくに立ち上げ中のチームにおけるチームビルディングでは大きな意味があると考えます。もちろん組織化ができあがったあとであれば仕方ありませんが、チーム立ち上げのいわゆる初期メンバーとしてJoinするのであれば、そのチームの方向性や大きな意思決定に関われないと面白くありませんよね。
私もまさにQAチームを立ち上げている最中ですが、最初に自分が立てた「QAチームのミッション」等はメンバーがJoinしてある程度組織の状況をキャッチアップしてもらった時点で、一緒に再検討するようにしています。
QAチーム統一期
統一期は、共通の規範や役割分担ができあがっていく時期、です。形成期のところでスキルや得意分野の共有について触れましたが、そこでトライした分担などが固まってきます。この段階では、チームの方向性と現在とのギャップもハッキリしてくるため、たとえば「SET:Software Engineer in Testが必要」といったロールごとの明確な人材募集をかけたり、あるいはQAチームと開発チームの関係性についても形が見えてくるころです。
QAチームの形のパターンについては、第1回 アジャイルな品質・QA組織パターン | Sqriptsも参考にしてみてください。
混乱期から統一期にかけて、チームビルディングの基本ステップにおける②対話や③議論に相当するやりとりが必然的に増えてきます。ここで細かいテクニックですが、定例会などで雑談タイムを設けていた場合は、雑談＝①会話のためのMTGと、チームとしての方針や個々の業務について話し合うMTGをそれぞれ別枠で用意するのがオススメです。混ざっていると、業務のトピックによって雑談が飛んだり、逆に雑談が盛り上がって議論の時間がなくなったりするので、明確に分けたほうがいいですね。
QAチーム機能期
機能期は、チームとして機能し、成果を出していく時期です。ここまで来ればあとは何もしなくてOK・・・ではありません。チームビルディングの基本ステップにあるように、④省察を行いながら、関係づくりなどのステップが回っていきます。「チームができあがったのでもうコミュニケーションは減らしていいよね」とはいきませんよね。
ベースができて安定してきたチームでより成果を出すために、
- QAエンジニアの育成・教育
- QAエンジニアの評価
なども（もしまだあいまいであれば）整備する必要があります。
まとめ
今回はチームビルディングの概念や考え方の説明と、QAチームにおけるチームビルディングについて、タックマンモデルの各段階をもとに概要をご紹介しました。
ポイントになるのは、単純にコミュニケーションの機会を増やせばよいというわけではなく、そこから対話や議論へと進めていくことです。そのためには、チームの方向性・ミッション、チームの構造パターンなどを一緒に考え、試行錯誤することが大切だと考えています。
今回ご紹介した書籍以外にも、チームビルディングやエンジニア組織に関する書籍や資料は数多くあるため、ぜひ読んで参考にしてみてください。
参考
- チーム・ビルディング[新版] 人と人を「つなぐ」技法（日本経済新聞出版）
- チーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで（翔泳社）
- 【第13回】人がプロジェクトの源泉！チームは育てて強くする［後編］ | Sqripts
