品質保証部タレントマネジメントユニットのチームビルディング内容紹介

品質保証部のタレントマネジメントユニットは4名で構成されており、うち3名が2025年の3, 4月に入社したばかりのメンバーです。現チーフである自分もそのうちの1人で、4月に入社しました。

今回は、まだSmartHRについても熟知できていない、メンバーともはじめましての中で、チームとして動いていけるよう、どのようにチーフとして立ち回ってきたかについてご紹介します。

前提

4人チームで、1名は2年在籍、1人が3月入社、2人が4月入社(現チーフ込)
全員別々のプロダクトにアサインされており、実質的な業務上の絡みはなし
入社後1ヶ月ほどのメンターが付く時期を除くと、他メンバーと話をするのは週1のユニット定例・チーフとメンバーの1on1のみ

主な内容

決起会
タイプ分け診断
ユニット定例
各プロダクトハンズオン
モブ作業
ユニット内スキルマップ
勉強会

決起会

チームの方向性についての説明と「これからチームビルディングをやっていくぞ！」という節目を作るために、決起会を開催しました。

アジェンダ
- 我々は何を目指していくべきか
- 何を評価するのか、何を評価しないのか
- それをするためにどういうチーム体制になる必要があるか
- そのために何をするか

タレントマネジメントユニットの目指す姿については、カジュアル面談資料に載っていますので良かったらぜひ見てみてください。
speakerdeck.com

タイプ分け診断

まずはお互いのことを知ろうということで、コーチ・エィが提供しているタイプ分け診断を行いました。
test.jp

SmartHRでは社内のコーチング室に依頼をするとチームビルディングのサポートをしてくれます。

タイプ分け診断はコミュニケーションスタイルを4タイプに診断するテストのことです。はじめましてのメンバーが多い中で、これからコミュニケーションを取っていくにあたってお互いのタイプや行動パターン、考え方について理解を深めることができました。

ユニット定例

メンバー全員が異なるプロダクトを担当しているため、ともすれば全く交流がない状態にもなりかねなかったので、定期的に集まる場としてユニット定例の立ち位置を定義することにしました。

業務内容の共有に関しては部定例でも行っていたのでそちらに任せる形とし、ユニット定例は交流に主体を置いたので個人の話をする場としての色を強めます。

接触回数を増やしたかったので週2回それぞれ30分
1回ごとに2人ずつ、1人あたり15分
アジェンダは個人にフォーカスしたことを主体
全員必ず1~2分のアイスブレイク
プロダクトでスプリントレビューがあった週であれば、それの紹介
今週のﾄﾞﾔｯ
関心事・心配事
小耳に挟んだことシェア

「関心事・心配事」や「小耳に挟んだことシェア」は、最初はうまくワークしないかもと少し心配しながら始めたのですが、実際には他部署の動きや商談の詳細など、メンバーが高いアンテナで集めた耳より情報を共有する場として機能したので、だいぶ嬉しかったです。

各プロダクトハンズオン

普段の業務を部定例やユニット定例でシェアするようにはなったものの、他のプロダクトを触る機会があまりないので具体的な画面や機能についてはなんとなくでしか分かっていない状態でした。理解をするには触ってみるのが一番ということで、各々のプロダクトに対してメンバーにHands Onを開催してもらい、基本的な機能について触れる機会を作りました。

チームとして動いていく目的の一つに「自分で解決できない問題があった時にチームを頼れるようにしたい」というものがあったのですが、他のチームの問題の解決に協力をするには当然そのプロダクトについて一定の理解が求められます。このHands Onだけで十分な理解に到達するのはボリューム的に難しくはあるのですが、部定例やユニット定例の解像度が上がることや、いざとなった時の参入コストが下がったりと効果は感じられました。後にプロダクト間連携が行われた際にも、概要を把握できていたことが一定の助けになったと思います。

モブ作業

プロダクトHands Onをしたことで他メンバーのプロダクトにも一定の知見が溜まったので、次は実際に一緒に作業する機会を設け、より具体的にどんな風に互いの助けになれるのかを実感しやすいようにしました。

大きいリリースの前にユニット内で探索的テスト会をしてみたり、他プロダクトでも同様の対応をしそうなfeatureに対してテスト観点ブラッシュアップ会をしてみたり。最初はモブでできる作業を見つけることがなかなか難しいだろうと身構えていたのですが、メンバーの方から積極的に発案してくださることが多く、「これモブでやってもいいかも？」と気軽に提案してくれるのがとても嬉しかったです。

モブ作業そのものでチーム内の連携が増したり、実施した対象の品質が上がったりという直接的な成果もありましたが、テストする時の手順や関心事・デバッグツールの使い方など、他の人の知見を知れたり、自分の持っている知見を意外と他の人は知らないということが分かったりと、副次的な成果が多かったのも大きな収穫でした。

ユニット内スキルマップ

周囲のプロダクトの状況も分かり、各々のメンバーが品質課題を発見・解決した事例も少しずつ積み重なってきました。それらによって自分達の今のレベル感もある程度は把握できるようになったのですが、メンバー間でスキルや経験にバラつきがあることが分かりました。そこで、メンバーのスキルレベルを可視化すると共に、ユニットとしてメンバーに目標として欲しいレベルについて言語化することで、メンバー自身が自分はどういうスキルを獲得した方が良いのかを自認しやすくしました。

今回の目的としてはメンバーのスキルを完全可視化したいわけではなかったので、ユニットとして求める主要なスキルであったり業務に利用する頻度が高いスキルに絞りました。また、その中でメンバー全員に求めたいスキルと、ユニットの中で誰か一人は獲得しておきたいスキルに分割し、得意な分野に関してはさらに上位のレベルを設定することで成長する方向性を見えやすくしました。

軽く内容をご紹介すると、メンバー全員に求めたいスキルは下記の項目としました。

バックエンド自動テスト
API Test
E2E (Playwright)
テスト計画・テスト戦略
不具合・障害分析

各項目ごとに満たして欲しいレベルを言語化しました。例えば不具合・障害分析ではこのような内容です。

不具合・障害を集計する際に、基礎的な指標に関して把握できている
JIRA・GitHub・Slackなどから適切なデータを集計し、レポーティングをすることができる
レポーティングの内容から、次にチームが取るべきアクションを提案できる

なお、テスト設計スキルと、課題発見・解決スキルは品質保証部全体を通してのコアスキルなので一番重視したい項目ではあったのですが、計測方法だったり欲しいレベルの言語化が非常に難しかったので今回は除外としました。日々の業務で比較的解像度高く把握できるであろうというのも無理に実施しなかった理由の一つです。

勉強会

スキルマップやモブ作業などを通じて、チームの現在のスキル状況と成長したいスキル、そのレベル感が判明したので、成長していくための活動を始めました。勉強会と言っても手法は一つではなく、勉強対象やレベル感に合わせて異なる方法を取っています。

課題解決の型を知るという目的で『イシューからはじめよ』の輪読会を開催しました。
イシューからはじめよ［改訂版］――知的生産の「シンプルな本質」eijipress.co.jp

1回で4, 50ページ程を週1ペースで実施し、6回の開催で通読し終えられました。「同意できるところ」「同意できないところ」「議論したいこと」「業務に活かせそうなところ」という分類で、それぞれ勉強会までに書き出しておいて内容を共有し、議論するという形式で実施しました。

共通の知見として課題の取捨選択や仮説の補強などでニュアンスが通じやすくなり、当初想定していた以上に業務でのコミュニケーションに寄与してくれました。

今はRSpec勉強会を開催したり、ユニット定例でテスト知識のLT会をしたりと、メンバーが主体となる活動も行われるようになりました。今期のユニットのミッションの中にメンバーのスキル向上に関する項目を追加しており、チーフが旗を振って頑張るという形ではなくメンバー各々が自主的に成長に向けた取り組みをしてくれているため、非常に良いサイクルが回っています。