スケールアップ企業のQA組織のバリューを最大限に引き出すための取り組み
2.8K Views
March 27, 25
スライド概要
2025.03.27 Thu. JaSST’25 Tokyo
関連スライド
各ページのテキスト
スケールアップ企業の QA組織のバリューを 最大限に引き出すための取り組み 2025.03.27 Thu. JaSSTʼ25 Tokyo 平田 敏之（tarappo） SmartHR 品質保証部 Manager
About Me 平田敏之（tarappo） SmartHR 品質保証部 Manager 24/09入社 ミッション 「開発生産性の向上」「品質の担保」
今日のおはなし スケールアップ企業とは • バリューを最大限に引き出すための取り組みについて • （１）メンバーが成果を出せる環境づくり • （２）メンバーの成果が正当に評価される仕組みづくり • （３）メンバーの成果を知ってもらう仕組みづくり • まとめと今後の取り組み •
スケールアップ企業 SmartHRとは
SmartHRが提供するプロダクト たくさんのプロダクトたち 参照： https://speakerdeck.com/smarthr_pr/smarthr-company-introduction1?slide=20
SmartHRの開発体制 たくさんのチームたち 参照： fi https://www. gma.com/board/HFNrUtz5Bf1c52YABCxxrY/SmartHR-%E9%96%8B%E7%99%BA%E7%B5%84%E7%B9%94%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6
SmartHRとは • スケールアップ企業 • キーワード：「規模拡大」と「急成長」 参照：https://note.com/smarthr_co/n/n5143cf05feec 参照：https://speakerdeck.com/smarthr_pr/smarthr-company-introduction1?slide=11
品質保証部の体制 プレイング マネージャー （評価を担う） ユニット単位で やるべきことを 決める ユニット単位で 求めるメンバーに ついて判断する 参照： https://speakerdeck.com/qa/qa-intro-202310?slide=12
QA組織のバリューを 最大限に引き出すための取り組み
なにを「まず」やるべきと判断したか 24/09：Manager（Acting）として入社 • 25/01：ActingがはずれてManagerに就任 マネージャーとして「部のバリューを最大限に引き出すこと」が重要 • • そのためには何が必要となるのか？ • （１）現状把握 • 関係者（メンバー全員、関係部署のPdE）と1on1、VPoEとの継続的な1on1 • 各ドキュメントのチェックなど • （２）現状把握し続け「何をするべきか」「いつするべきか」を判断 バリューを発揮するために必要な「コトに向かう」ための土台整っていない そこを整えることがまず「すぐに」やるべきことと判断 24/09〜25/03までにおこなったことの話し
バリューを最大限に発揮するために必要なこと QA組織がバリューを最大限に発揮するために成果を出し続けられる土台が必要 「成果」を「継続的」に出し続ける そのためには次の3つが必要 • （１）メンバーが成果を出せる環境づくり • （２）メンバーの成果が正当に評価される仕組みづくり • （３）メンバーの成果を知ってもらう仕組みづくり （１）〜（３）に対して改善を重ねていくことでバリューを最大限に出せるようにしていく。 これらを「まず」整えることが 組織をリードするマネージャーとして重要なことであると判断
土台を整えていく中での方針 私が馴染んでから進めるのでは遅すぎる すべてを合議制では決めない • リーダーシップと責任を持って、マネージャーが進めていく • 言語化を怠らない • 課題は何か、なぜやるのかを言語化して共有 • 進めている途中のものでもメンバー（またはチーフ）に共有 • FBは真摯に受け止める • 都度、説明をする • 移譲時期を都度判断する • 最初はマネージャーがハンドリングするが、少しずつ移譲できるように整える • 急いでやるべきことと、多少時間がたってからでもいいものかは都度判断
３つの土台づくり QA組織がバリューを最大限に発揮するために必要な土台 • • ① メンバーが成果を出せる環境づくり • ② メンバーの成果が正当に評価される仕組みづくり • ③ メンバーの成果を知ってもらう仕組みづくり
① メンバーが 成果を出せる環境づくり
「成果を出せる環境」とは 「成果を出せる環境」には、次が重要。 部として、次ができていること • （１）進む方向を共有できていること • （２）進むにあたっての不必要な「壁」を減らすこと • （３）進むことを後押しすること 進む「方向性」の提示、進む先の「壁」の軽減、進むことへの後押し 1度おこなったら終わりではなく （１）〜（３）を定期的におこなうことが重要
（１）進む方向を共有できていること やりたいこと：「進む先、進み方が分かっていて一緒に同じ方向へ進んでいる」 • （１−１）進む先 • 部、ユニットとして「何を目指しているのか」が分かっている • 「目指す姿」を提示し、そこから自分たちの「目指す姿」を考える • 定期的に「現在地」を確認する • （１−２）進み方 • 部のスタンス、自身への期待が分かっている • 自身がどう振る舞うべきか • 自身がどう進めていくべきか
（１−１）進む先：「作る」 やりたいこと：「部・ユニット・メンバーが一緒の方向を向いている」 1st step：おこなったこと • 部の「目指す姿」の用意 • 「なぜ、それを目指すのか」「それには何が必要なのか」も含めて共有 • 2nd step：お願いしたこと • 部の「目指す姿」をもとに具体性を高めたユニット単位の「目指す姿」の用意、共有 • 作成したドキュメントは部のポータルページに 貼って全体に共有 （１）進む方向を共有できていること
（１−１）進む先：「現在地確認」 やりたいこと：「定期的に目指す姿と向き合う」 「目指す姿」をもとに「定期的に向き合うタイミング」を用意。 「部の半期の流れ」 • 期中ふりかえり • 半期単位（QA Summit） • 今期のふりかえり：今期、どうだったのか • 来期の「部の方針」「ユニットのミッション」の作成：来期、どうしたいのか 「任意（推奨）」 • 都度 • ユニット単位で状況確認 （１）進む方向を共有できていること
（１−２）進み方 やりたいこと：「自分たちがどのように進んでいくべきか、進んでいいかを理解してもらう」 • 考え、期待することの言語化と共有 • マネージャーのスタンス • チーフに期待すること • メンバーに期待すること 本来、自律的におこなっていいが、心理的ハードルがあったりもします。 上記を言語化することで「やっていい」ということを後押しします。 言語化するだけでなく1on1や他の場でも定期的に共有 （１）進む方向を共有できていること
（２）進むにあたっての不必要な「壁」を減らすこと やりたいこと：「コトに向かうことができない要因となる壁を減らす」 ここでいう「壁」とは何か？ • 個人より組織としてなんとかするべき「壁」のこと • 難易度が高いことを進めるうえでの「壁」は個人のスキルアップにつながるので対象外 • → 別の方法で支援する（後述） たとえば、 • 方針という「壁」 • 相手のことを知らないことによる「壁」 • お金周りという予算の「壁」
「壁」を減らす 前提：「壁」を定期的に把握する必要がある 後述 等級要件の更新 方針という「壁」 • 例）等級要件がマッチしていないところがあった • おこないたいことに対して「方針」という「壁」 • 相手のことを知らないことによる「壁」 部内連携の場の • 例）他ユニットが何をしているかが分からない 用意 後述 • 協力できることなど他者を「知らない」という「壁」 • お金周りという予算の「壁」 • 例）なにかしらのサービスを試したいが予算の有無が分からない、予算を確保していない • おこないたいことに対する「躊躇」という「壁」 • 予算の確保と共有 （２）進むにあたっての不必要な「壁」を減らすこと
（３）進むことを後押しすること やりたいこと：「メンバーが進むうえでの現状把握をし必要な後押しをする」 いま進めていること • （３−１）1on1による後押し（チーフ、マネージャー） • 相手を知り、自身を知ってもらう • （３−２）一緒にプロジェクトを進めることによる後押し • 場の用意とスキル移譲による後押し • （３−３）タレマネ施策による後押し • メンバーの状況を把握しスキルアップにつなげていく
（３−１）1on1による後押し やりたいこと：「1on1を通してメンバーの状況を把握し、後押しをする」 実施頻度：メンバーによって判断（状況に応じて頻度を変更） • チーフは１週間に１回 • メンバーは２週間に１回または３週間に１回 • 実施内容（例） • 傾聴：相手を知る、おこなっていることを聞く • 共有：部としておこなっていることについて伝える • 壁打ち：私が得意とするスキルセットに関する相談 • 土台が固まるまで私との1on1は一定間隔で実施 パブリックな集まりの場がベースとしてあったうえでの1on1 （３）進むことを後押しすること
（３−２）一緒にプロジェクトを進めることによる後押し やりたいこと：「自分と一緒にプロジェクトを進めることで後押しをする」 ユニットとしておこなえていないことで、組織として重要なことを「プロジェクト化」 • 組織として取り組むべきもの • 私がスキルを発揮できるもの プロジェクト化したうえで相談したうえでメンバーをアサイン • プロジェクトを移譲するにあたって適切なメンバー • スキルの後押しができるメンバー 組織として「おこないたいこと・おこなうべきこと」を一緒に進めていく。 そしてスキルの移譲とプロジェクトの移譲をする。 （３）進むことを後押しすること
（３−３）タレマネ施策による後押し やりたいこと：「メンバーを部のタレマネ施策によって後押しする」 タレマネ施策 • 把握する • メンバーの「スキル」や「今後やりたいこと」を把握 • ユニットが必要とする「スキル」の把握 • 部が必要とする「スキル」の把握 • 支援する • 「今後やりたいこと」「必要なスキル」をもとに獲得支援 ※現在、進めている施策かつ時間の関係から本発表では詳細は割愛します※ 今期は特に本件について強くコミットメントをしています （３）進むことを後押しすること
３つの土台づくり QA組織がバリューを最大限に発揮するために必要な土台 • • ① メンバーが成果を出せる環境づくり • （１）進む方向を共有できていること • （２）進むにあたっての不必要な「壁」を減らすこと • （３）進むことを後押しすること • ② メンバーの成果が正当に評価される仕組みづくり • ③ メンバーの成果を知ってもらう仕組みづくり
② メンバーの成果が 正当に評価される仕組みづくり
正当に評価される仕組みづくり 成果を出せたとしても「正当に評価」されなくては、持続性がありません。 当人にとって（外部から見ても）正当に評価がされることが重要です。 そのためには次の２つが重要となってきます。 • （１）評価の軸の明確化 • （２）評価の軸の共通認識化 評価の軸を明確にし、関係者との共通認識とする ※評価は会社における「評価制度」に依存する※
前提：弊社における評価制度について • 等級要件（※）を参考にしつつ今期おこなう「ミッション」を作成 • （１）ミッションの「方向性」 • どういったことをおこなうか • （２）ミッションの「難易度」 • 自身の期待値に応じてどこまでおこなうか 期初に関係者と合意しておき、期中・期末に「ミッション」の進捗度を評価します。 評価期間は半年ごと（6ヶ月）の年2回あります。 ※等級要件とは 職種ごとに詳細があり、等級は7段階あります。 等級は【入学要件】であり、再現性があると認められると該当等級に昇格します。
（１）評価の軸を明確にする 評価の軸である等級要件をどのように作っていくか？ • メンバーを「正当」に評価するための軸である等級要件を作るには、そのメンバーの職種を理 解した人がリードしたうえで作っていくことが必要 • マネージャーである私が作成 QAEの「等級要件」が次を満たしているかどうか • 被評価者視点：ミッションを作るにあたって十分な情報があるか • 評価視点：メンバーを評価するにあたって適切な情報になっているか 等級要件は一度作ったら終わりではなく組織状況に応じてアップデートをすることが重要です。
QAEにおける等級要件の課題 前提 • QA領域は求められる「スキルセット」の幅が広い • ただし、人によって適正はある • 弊社はQAEという職種1つのみにしている • 幅広く色々なことをやりやすくできるようにしている 今までの課題（の一部） • 等級に対して特定のスキルがすべて満たされている必要があった • スキルの適性が考慮されておらず「コトに向かう」ことが一定できないことがあった • 等級に対する詳細な情報が足りないケースがあった 等級要件を次の評価期間までに更新することを決定 （１−１）更新タイミング （１−２）更新に伴う方針 （１）評価の軸を明確にする
（１−１）等級要件の更新タイミング 「等級要件」を更新するタイミングは年に2回。 ※期中の見直しを原則おこなっていないのは不利益変更をさけるため※ SmartHRでは次のようになっています。 • 期：1月〜12月 今回のケースでは、 • 上半期：1月〜6月 今期のはじめ（2025年1月〜）に使えることが必須 • 下半期：7月〜12月 今後のために 更新タイミングを含めた「部の半期の流れ」は「図示化」して部内で共有 「更新の有無」を判断するタイミングを用意 （１）評価の軸を明確にする
（１−２）等級要件の更新に伴う方針 変更ポイント • 等級に応じて「求める成果」のレベルを定義 • 特定のスキルがある「だけ」ではNG • なにかしらのスキルを発揮し、等級に見合った成果が出せているかどうかで判断 自身の専門性を「広さ」または「深さ」をもとに発揮して「求める成果」を発揮できればOK （１）評価の軸を明確にする
等級要件の例（QAE） 【3等級の入学要件】 発揮すべき成果 • QAの領域に関する基礎スキルと専門スキルを活用し、即戦力として周囲と協力しながら自律 的に課題解決に向けて完遂できる 次のいずれかを満たし「発揮すべき成果」を達成できること • テスト設計をおこない、特定のテストレベルにおける必要なテストケースを設計したうえ で、自動テストをチームで運用できるレベルで実装できる • プロセスを通して見つけた課題に対して、解決案の提案とその施策を周囲と協力しながら進 められており、改善サイクルを回すことができる • 「テスト設計」のレビューなどを通して開発チームへ基礎スキルレベルの移譲が進められてい る ※上記は記載されている情報の一部です より具体的な事例を 補足資料として用意 （１）評価の軸を明確にする
（２）評価の軸の共通認識化 等級要件は等級に応じて発揮すべき成果のレベルについて記載しています。 しかし、言語化されたものを読んですぐに認識するのは難しいです。 認識を共通化するためにおこなったこと • （２−１）どういったスキルを発揮するといいのかという補足事項の用意 • 全ケース網羅はできないため都度、更新をしていく想定のもの • （２−２）全メンバーに対して次を実施 • 等級要件についての説明会を実施 • 作成したミッションに対してメンバーの期待値に応じてFB 言語化して共有だけではすぐには共通認識とはならない。 したがってミッション作成、評価のタイミングで定期的にFBしていくことが重要。
（２−１）補足事項の用意 課題 • 等級要件に全ての情報を記載することは難しいため、具体例が不足している • QA領域において扱うスキルの幅は広いことも要因 対応策 • どういったスキルを発揮して何ができているといいのかという具体的な補足事項の用意 • 等級単位で例をいくつか用意 • 全ケース網羅はできないため都度、更新をしていく想定のもの • 補足事項にはNG例も記載 （２）評価の軸の共通認識化
（２−１）補足事項の用意（実例） 3等級の等級要件に記載されている情報 • テスト設計をおこない、特定のテストレベルにおける必要なテストケースを設計したうえで、自 動テストをチームで運用できるレベルで実装できる 具体例 • 例）テスト設計で現状の守りを特に弱めることなくE2E自動テストの運用コストを最適化する • （補足）すでにあるテストを活用する形で構わない • （補足）リードするテストレベルは複数でなく特定のものだけでいい（例：E2E自動テスト） • （NG）他のテストレベルなどを一切考慮せずに、特定のテストレベルのテストケースをただ 増やすだけになっている • （NG）実装者しか理解できない、運用が高負荷になるコードを実装している （２）評価の軸の共通認識化
（２−２）説明会の開催とミッションFB step1）全メンバーに対して次の説明会を実施 • 等級要件までの道のり • 等級要件の変更点 • 等級要件の補足事項 step2）作成したミッションに対してメンバーの期待値に応じてFB • ユニット単位で全メンバーのミッションに同期FB • 「ミッションの方向性」：ユニット（チーフ）で基本決まっている前提 • 「ミッションの難易度」：こちらに対して私が主にチェック • 該当メンバーの期待値に応じて1人1人FB （２）評価の軸の共通認識化
３つの土台づくり QA組織がバリューを最大限に発揮するために必要な土台 • • ① メンバーが成果を出せる環境づくり • ② メンバーの成果が正当に評価される仕組みづくり • （１）評価の軸の明確化 • （２）評価の軸の共通認識化 • ③ メンバーの成果を知ってもらう仕組みづくり
③ メンバーの成果を 知ってもらう仕組みづくり
メンバーの成果を知ってもらう仕組みづくり QA領域は色々なところの関わりを持ったうえで進めていくことがベースとしてあります。 しかし、私たちの成果は分かりづらいことも多いです。 そのために、情報を「意識的」に共有し知ってもらうことが大事です。 （１）品質保証部内で他ユニットについて知ってもらう • （２）品質保証部について知ってもらう • （３）品質保証部の活動について知ってもらう • （４）QAという領域の解像度をあげてもらう • （１）〜（４）を継続的に繰り返していくことでQA領域の「解像度」を上げてもらうことが重要。 成果の「妥当性」に対する解像度も上がっていくはずです。
（１）品質保証部内で他ユニットについて知ってもらう やりたいこと：「他ユニット、他メンバーについて知ってもらう」 課題 • 横断組織でもある品質保証部だと「意識」しないと他メンバー、他ユニットの状況を知らな いことがある 部内でおこなっている取り組み • 部定例（週1開催） • 期中ふりかえり会（期中に1度） • QA Summit（半期に1度） この手の取り組みは短期視点ではないため、組織として浸透するまでの間はマネージャーがハ ンドリングをし、なぜ必要なのかを都度共有していく。
（２）品質保証部について知ってもらう やりたいこと：「部外の人に品質保証部のことを認知してもらう」 前提 • すべての開発チームにQAEが所属しているわけではない • 関わりのない職種もある プロダクトサイドメンバーにフォーカスをして次を実施 • PdEの新規入社メンバーにオンボーディングの実施 • 部についての説明とQAについての座学の２本立て • PdEの新卒入社メンバーにオンボーディングの実施（予定）：25/4〜 • プロダクトメンバーが集まった定例で月1（以上）、部から情報発信
（３）品質保証部の活動について知ってもらう やりたいこと：「品質保証部がおこなっていること（の一部）を認知してもらう」 ブログの連載 • 品質保証部集中連載：24/9 - 25/3まで（現在、11本公開中） • ユニットの紹介 • ユニットの事例紹介 • 勉強会での登壇 • 3/25（火）QA Test Talk Vol.4 • 部内LT会 • 部のメンバー全員が部内でLT会 • プロダクトメンバーが集まる定例で部から情報発信 • 活動についても発信 • 社内外へのアウトプット 社内へのアウトプット
（４）QAという領域の解像度アップ やりたいこと：「QA領域そのものの解像度を上げることによる成果への解像度アップ」 おこなっていること • オンボーディング • PdE新規入社メンバー向け • PdE新卒メンバー向け • PdEアンケートの実施とアンケート結果を元に施策の検討、推進 • QAに関する記事の作成と共有 • レバレッジ推進ユニットの誕生と推進 まだまだここはやることが「もりもり」な状態
３つの土台づくり QA組織がバリューを最大限に発揮するために必要な土台 • • ① メンバーが成果を出せる環境づくり • ② メンバーの成果が正当に評価される仕組みづくり • ③ メンバーの成果を知ってもらう仕組みづくり • （１）品質保証部内で他ユニットについて知ってもらう • （２）品質保証部について知ってもらう • （３）品質保証部の活動について知ってもらう • （４）QAという領域の解像度をあげてもらう
まとめと 今後の取り組みについて
まとめ QA組織としてバリューを最大限に引き出すための次の3つの土台について話しました。 • （１）メンバーが成果を出せる環境づくり • （２）メンバーの成果が正当に評価される仕組みづくり • （３）メンバーの成果を知ってもらう仕組みづくり これらはそれぞれ独立しておらず相互に関係しており、連携させつつ進めていきました。 変化のはやい「スケールアップ企業」において、「変化し続ける」ことが重要です。 したがって、この土台は作ったら終わりではなくて定期的に整えていく必要があります。
改善ポイント すべてがうまくいったわけでもありませんし、今なお整っていないところもあります。 もっとやる必要があるところ • 共通認識とすることの難しさ • 言語化し、共有をしても100%伝わるわけではありません • 何度も伝えたり、ズレうめを定期的にしていく必要があります • QA領域の解像度を全社的にあげる難しさ • 普段、一緒に働くメンバーではない職種の人に伝えることの難しさ • ボトムアップ、トップダウンの両方の施策が必要 • 自分たちのAsIsを知ることの難しさ
今後の取り組み 組織としてスケールアップ企業の中で育っていくには 中長期視点が大事になってきます 【今進めている取り組み】 • 中長期視点のための仕組みづくり • 品質保証部としての今後のロードマップの作成と共有 • 「部のタレマネ施策」の仕組みづくり • 今期取り組んでいることころ • 今まで関係性がなかったところとの連携に向けた種まき などなど
We are hiring！！ 一緒に「目指す姿」に向かって 進んでくれるメンバーを募集しています カジュアル 面談は こちらから https://recruit.smarthr.co.jp/career/?category=qa