品質保証の取り組みを広げる仕組みづくり〜スキルの移譲と自律を支える実践知〜

品質保証の取り組みを 広げる仕組みづくり 〜スキルの移譲と自律を支える実践知〜 2025.11.07.Fri 開発をリードする品質保証 -Findy Online Conference - 平田 敏之（tarappo） SmartHR 品質保証本部 本部長

About Me 平田敏之（tarappo） SmartHR 品質保証本部 本部長 24/09入社 ミッション 「開発生産性の向上」「品質の担保」

今日のおはなし SmartHR：スケールアップ企業 • スケールアップ企業における課題 • QA視点で見たときの課題とアプローチ • ２つの横断施策プロジェクト • （１）不具合分析 • （２）自動テストの改善 • 今後の取り組みとまとめ •

SmartHR スケールアップ企業

SmartHRとは • スケールアップ企業 参照：https://note.com/smarthr_co/n/n5143cf05feec • キーワード：「規模拡大」と「急成長」 参照： https://speakerdeck.com/smarthr_pr/smarthr-company-introduction1?slide=37

• https://note.com/smarthr_co/n/n5143cf05feec
• https://speakerdeck.com/smarthr_pr/smarthr-company-introduction1?slide=37

SmartHRが提供するプロダクト 増えていくプロダクトたち 参照： https://speakerdeck.com/smarthr_pr/smarthr-company-introduction1?slide=13

• https://speakerdeck.com/smarthr_pr/smarthr-company-introduction1?slide=13

SmartHRの開発体制 FY25下半期から 増えていくチーム 変わっていく組織体制 参照： 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

• https://www.figma.com/board/HFNrUtz5Bf1c52YABCxxrY/SmartHR-開発組織について

品質保証本部の体制 プレイング マネージャー （評価を担う） ユニット単位で やるべきことを 決める 25年10月から ユニット単位で 求めるメンバーに ついて判断する 参照： https://speakerdeck.com/qa/qa-intro-202310?slide=11

• https://speakerdeck.com/qa/qa-intro-202310?slide=11

品質保証本部における職種 SmartHR 品質保証本部の職種はQAEのみ • • TEスキル・QAEスキル・SETスキル（など）のスキルを活用 • TEスキルを深堀りしてバリューを発揮するのもOK • TEスキル x SETスキルでバリューを発揮するのもOK 必要なことに対して「自身のスキル」をもとにバリューを発揮してもらう 組織としては メンバーの「スキル把握」と「スキルアップ支援」は重要な要素

スケールアップ企業 における「変化」と「課題」

スケールアップしていく中での変化 スケールアップ企業のキーワード：「規模拡大」「急成長」 開発組織内において次のようなことが起こってくる • （１）既存プロダクト開発の拡大 • 関わる人が増えてくる = 開発チームも増える • 1つのプロダクトに複数の開発チームが関わる • （２）新たなプロダクト開発 • プロダクトを作る新たな開発チームが組成される 多くの「プロダクト」および「開発チーム」が誕生し続ける

プロダクト・開発チームのスケール 成長すると プロダクト プロダクト プロダクト プロダクト 増えていく 開発 チーム 開発 チーム 開発 チーム 開発 チーム 開発 チーム 開発 チーム 増えていく 既存プロダクト開発の拡大 新たなプロダクト開発 多くの開発チームが多くのプロダクトを開発していく

組織がスケールしていく中での「課題」 プロダクトや開発チームが多く存在してくると起きる課題（の一部） • （１）他チームに対する認知の低下 • 「他チーム」のことが分かりづらくなる • 「他チーム」との連携するためのコストが高くなる • （２）横断的なアクションの難易度の向上 • 自チームの活動がメインとなるため横断的なアクションはおこないづらくなる • 横断的な課題がわかりづらくなる 他にも「組織課題」はたくさん生まれてきますが、今回の話の対象外なのでまた別の機会に

組織がスケールしていく中での「課題」 次の事象が起きたとして何が問題となってくるのか？ • （１）他チームに対する認知の低下 • （２）横断的なアクションの難易度の向上 （１）と（２）によって 「複数チーム」にまたがる課題が見えづらくなっている 「複数チーム」にまたがる課題に対するアプローチが（あまり）進まない この課題に対して「QA」という面で見たらどうか？

QAという面で見たときの 課題とアプローチ

QAという面にフォーカスした場合における「課題」 チーム単位で「品質保証活動」へのアプローチを進めたとしても、 全体としての「品質保証活動」は放置されやすい • どういったことが進みづらくなるかの例（一部） • （例１）可視化 • 開発チーム単位での可視化になってしまう • → 全体における品質傾向の可視化はあまりおこなわれない • （例２）共通利用コードへの対応 • プロダクト共通で利用しているコードに対してのオーナーシップが希薄になりやすくなる • → CI/CDサービスに対する改善は弱くなる SmartHRのQA組織だと上記の問題はおきないのか？

今のQA組織の体制 特定開発チームへ 関わるケースが多い 役割がちょっと異なる

今のQA組織の体制と関わり方 前提 • 掌握範囲は決まっている • 開発チームの数は多い すべての開発チームに フルコミットはできない QA組織の今の関わり方のパターン • Case１）開発チームの一員として関わっていく • Case２）開発チームに優先的に加わって動いていく • Case３）開発チームに加わらずに「なにかある場合」に動いていく あくまで現時点での 関わり方のパターン 主に開発チームへの取り組みが主体となるため 複数開発チームにおいての取り組みはどうしても置き去りにされやすい

横断部分へのコミットメントのむずかしさ なにがたいへんなのか？ • 対象が広い範囲になればなるほど動くのが難しい • 「誰がおこなうべきか？」のオーナー不在の問題 • 関係者が多いことによる初期コストの高さ • 課題を解決するのに必要なスキルの問題 • 「どういった課題」があるかがわかっていない • 顕在化してからアプローチするケースが発生する 「オーナー」と「最初の一歩」をどうするか ここを整えればあとはそこまでむずかしくないケースなこともある

横断的な課題に対しておこなったこと 主にたいへんなのは「オーナー」と「最初の一歩」 • 組織的な課題はEMがリードすることが望ましい なので、 • EMである私がオーナーになり最初の一歩を進める ただし、 • 常に私が進めるでは「再現性」はなく「スケール」していかない 今回話すのはこちら したがって、 • スキル移譲をしていけるように「場」を設計していくことが重要 • 組織体制を強化していくことでの「再現性」を作ることも重要 • EMが複数いる＆他と協働で動ける状態を作ることが必要 こちらも推進中 （本部化がその一部）

横断的に動く中で考えること • どのように進めていくかにおいて考えるべき点 • （１）誰が進めていくか：「（まずは）私が進めていく」 • （２）誰とどこから進めていくか • （３）どのように手を離していくか 解消に向けて 進めている別課題 継続性という意味で重要なのは次の２点 • （２）誰とどこから進めていくか • （３）どのように手を離していくか （２）と（３）を設計することで継続していけるようにする

スキル移譲をしていくことの重要性 次のようになっていることが重要 • 同じようなことを進める必要性ができたときに対処できる人が増えている そのためには • スキルを獲得していくことが必要 • 単に「解決」するのではなく一緒に進める、スキル移譲していく作りが大事 同じことが起きたら「最初からスタート」するのではなく、さらに積み重ねて進められることが重要 「強くてニューゲーム」ができる組織になることが重要

進めているプロジェクト 「不具合分析」と「自動テスト改善」

さまざまなところで起きうる組織課題 ③ ① ② 成長すると プロダクト プロダクト プロダクト プロダクト 増えていく 開発 チーム 開発 チーム 開発 チーム 開発 チーム 開発 チーム 開発 チーム 増えていく 既存プロダクト開発の拡大 新たなプロダクト開発 ①②③に対してそれぞれ「課題」が発生してくる

今回の話におけるフォーカス対象：① ③ ① 今日のメインの話はコチラ プロダクト ② プロダクト プロダクト プロダクト 増えていく 開発 チーム 開発 チーム 開発 チーム 開発 チーム 開発 チーム 開発 チーム 増えていく 既存プロダクト開発の拡大 新たなプロダクト開発 ①についてを今回フォーカスし、②と③についてはまた別の機会に！

なにをおこなったか？ 複数チームが関係する「プロダクト」においての課題へのアプローチ どこからなにをおこなうべきか？ • （１）課題を見えるようにする • 複数チームにまたがる「課題」を可視化することを進める • （２）すでに見えている・見えかけている課題への対処 • すでに見えている課題をより「クリア」にし対応をする 見えている課題は見えているから簡単というわけではなく 対応されていない＝対応がむずかしいことが多い 課題の可視化は チーム外の人への理解を 高めるためにも重要 見えている課題の 放置は不安の種となるため 解決が必須 それぞれを進めるための「プロジェクト」を組成

すすめている2つのプロジェクト 複数チームが関係する「プロダクト」における課題へのアプローチ • （１）課題を見えるようにする • 問い合わせからの不具合分析 • （２）すでに見えている・見えかけている課題への対処 • 自動テスト実行時間の肥大化改善 相談ベース からのスタート

課題の可視化 不具合分析

対象範囲の決定 データがなければ課題の可視化はできない • データがなければ「プロセスの整備」と「データがたまるまでの時間」が必要 • すでにデータが整っている箇所があればそこを優先的に活用するのが望ましい そこで次を実施 • 現状を確認し、データが整っている箇所があるかどうかを把握 • その中から優先順位を決めてどこから進めるかを検討 • 優先順位：効果、継続性、コスト 特定機能に対する 問い合わせのデータが有効と判断

ユーザーからの問い合わせ アクション 全体傾向 の確認 プロダクト に対する 問い合わせ ユーザ ユーザ ユーザ 問い合わせ アクション アクション カスタマー プロセス改善 サポート 不具合傾向は 見ていない 傾向の確認 質問・相談 連携が 必要なもの 関係者 関係者 関係者 QA視点についての アプローチはおこなえていない

どのように進めていくか 次の３点を考える必要がある • （１）誰が進めていくか • まずは私が進めるため「誰が」は考えなくてもよい • ただし、かかる・かける工数は考える必要がある 私がボトルネック になるため • （２）誰とどこから進めていくか • 継続性を出すために誰と進めるかは大事な観点 • 将来的に同じことができるようになってほしいメンバーが良い • （３）どのように手を離していくか • 進めながら設計するのもよいが、最初からある程度考えておくほうがよい

誰とどこから進めていくか • 今回のケース：問い合わせベースの不具合分析 • ある程度、プロセスが整っている • 関係者は多いが他に影響を与えずに進められる（将来的には連携が必須） • 獲得できるであろうスキル • 関係各所と連携しながらリードするスキル • 不具合分析からのNextをすすめるスキル 誰と進めるか • マネジメントレイヤーの「チーフ」が適任 • どこから進めるか • 他の影響を少なくしながら進められるため最初から一緒に動くことが望ましい •

どのように手を離していくか 移譲の重要性 • 継続的にできるようにするには「移譲」できることが重要 • 移譲は個人ではなくチームであることが「継続性」においては大事 今回のケース：横断的な不具合分析 • 最初の「土台整備」を整えた後にやるべきことは次のサイクル • （１）不具合種別の設定 • （２）不具合分析の実施と共有 • （３）改善施策の推進 （１）（２）（３）では必要とするスキルが異なる

どのように手を離していくか どのようにすすめていくか？ • （１）不具合種別の設定 • （２）不具合分析の実施と共有 • （３）改善施策の推進 一度にすべてを手放すのではなく「離しやすい箇所/任せやすい箇所」から離していく （１）→（２）の順番で手を離していくことを念頭に入れてスタート そういう場所は「スキル獲得の場」としても機能しやすい 「場」として活用することで「同じ動きができる」メンバーが増える

不具合分析の進め方

不具合分析を進めるための土台準備 前提 • 進めやすくするため「疎」から進めて後に「密」にしていく • 最初は既存プロセスに影響を与えない • ただし進めていることは関係者に共有する はじめたときの状況 問い合わせデータは分類されており、その中に「不具合」という判定はある • ただし「不具合」の詳細については記載されていない • 「不具合種別」を設定する必要がある ここを整えれば始められる

不具合分析を進めるための土台準備 不具合分析ができるようにするための土台 • （１）不具合種別を定義 • 問い合わせという特性を考えて分類 • （２）不具合種別のデータをまとめる場所を用意 • 既存のデータを活用し、参照する形で用意 • （３）可視化の準備（Looker Studioの用意） • （２）のデータを利用できる形で用意 「土台」ができたら あとは「不具合種別」の設定

不具合種別を設定時のルール決め 前提 不具合種別の設定はズレが起きやすい • 不具合の対応者に設定してもらうのではなく、自分たちで設定をする • 設定するときの流れ 自分たちの中でのズレを減らしていくためにペアプロ • 最初は時間がかかることは許容 • 設定をしていく中で初期に用意した「不具合種別」の改善も進める • 現時点では必要でないものをいくつか削除している • 例）再現しない、mergeミスなど •

不具合分析の進め方 進め方の流れ • • （１）問い合わせデータから「不具合」と定義されたものをチェック • （２）問い合わせの各種データを確認し不具合種別を決める • 問い合わせの流れ、返答内容などの確認 • 修正されている場合はPRの中身もチェック （３）不具合種別をスプレッドシートに設定 • • ペアプロで決めた不具合種別を設定 • 決める際の判断情報もメモに記載

不具合分析の進め方 データが溜まってきたら • （１）設定した不具合種別をもとにLooker Studioで可視化 • 数値だけの共有は「まずは」おこなわない • （２）可視化された情報から「不具合分析」を実施 • どういった箇所が多いか、どういった不具合が多いかなどを分析 • 分析結果、改善施策について全体共有 不具合種別の分類 問い合わせの 種類

改善サイクルをどのようにまわすか？ よくある問題 • 不具合分析の結果から「改善施策」が判断できたして、誰がそれをリードするべきなのか？ • 改善施策をたてても誰がリードするかが決まりづらい QAEがすべてリードすることで解消していくのでは 「スケール」がしないだけでなく「組織」としてもあるべき姿ではない 組織として整えることが重要！

改善サイクルをどのようにまわすか？ 組織変更の波にアライン 本件を進めている労務プロダクト開発は、2025年下半期からScrum@Scaleを導入 • 体制変更のタイミングで、全体的なQA体制を作れるようにQA組織も体制にアライン • ドメイン、各エリアのスクラムイベントにQAEが参加 • Scrum@Scaleの運営に加わって品質課題を「障害物」として登録できるよう整備 • 不具合分析からわかったことを「障害物」として登録できる土台を整備 これによって「放置」はされづらくなった 進むかどうかは組織全体の課題

不具合分析自体の改善 進めていく中で「不具合分析」自体の改善も重要 不具合分析をすすめるにあたって次の時間は計測しやすい • 不具合種別の設定にかかる時間 • 「不具合」の数に依存する • 不具合分析にかかる時間 毎月どれぐらいの時間が必要かは（比較的）計算しやすい 一方、その時間を「最適」にする改善は重要 継続性の観点からもコストがかかりすぎてしまうのはよくない

不具合分析自体の改善 どこに時間がかかるのか？ • 不具合種別を決めるときの流れ プロセス自体への アプローチも必要 • （１）情報を追うための時間 • 「改善」をしなければ最適化されない 対応中 例）トレーサビリティの強化 • （２）情報から判断する時間 • 「経験」によって獲得した「スキル」によって徐々に最適化されていく

現在の状況 • 担当：労務プロダクト品質保証部の１チーム • 現在、他チームのメンバーへも移譲中で来期から２チームで対応予定 なにをおこなっているか？ • 不具合分析の定期的な実施 • 期間（Q単位）を区切ってまとめて不具合分析 • 新たな「課題」があれば「障害物」として報告 • 不具合分析にかかるコストの最適化 関係を • 関係者との連携 疎から密へと • 課題に対するアプローチ 私が関わるのは 不具合分析の結果への FB 展開中 移譲が進んでいるため「プロジェクト」としては終了 継続的に進めている

見えている課題への対処 自動テストの改善

自動テストにおける課題 すでに見えている課題 • CI/CDサービスでの実行時間の肥大化 なにが問題なのか？ • CI/CDサービスは「従量課金」の時代となり「実行時間」は大きな課題 • 開発者体験としては「実行時間」の短さは重要 • 実行時間の短縮は並列化による対応が一般的 • しかし「トータルの実行時間」が減るわけではない 結果としてトータルの実行時間は右肩上がりになりやすい お金の問題もあるが常になんでも動かすことはそもそも「正しい」とは言えない

自動テストの改善のむずかしさ 対象：複数チームが利用する「リポジトリ」 起きること • コードが増えつづけるためテストの実行時間も長くなりがちになる（→そして並列化） • 他の影響箇所がわかりづらくなるためテストを常に回したいという気持ちになりやすい • テストサイズが大きいものはCUJだけ回しましょう！というのは王道でもそれが心理的に 支持されるわけではない • 範囲が広いため改善をするためのコストが高く対応されづらい • 横断的に効果が出やすい箇所はされる傾向にある 時間がたてばたつほど積み重ねれていき対応が大変になっていく 課題を少しずつひもといて前へと進めていく必要がある

どのように進めていくか 次の３点を考える必要がある • （１）誰が進めていくか • まずは私が進めるため「誰が」は考えなくてもよい • ただし、かかる・かける工数は考える必要がある • （２）誰とどこから進めていくか • 継続性を出すために誰と進めるかは大事な観点 • 将来的に同じことができるようになってほしいメンバーが良い • （３）どのように手を離していくか • 進めながら設計するのもよいが、最初からある程度考えておくほうがよい

誰とどこから進めていくか • 今回のケース：複数チームが利用する自動テストの改善 • なにから着手するかがむずかしい • AsIsを把握しToBeを考えたうえで１つ１つ進める必要がある • 獲得できるであろうスキル • 自動テストに関する全般的なスキル • 誰と進めるか • SETスキルを伸ばしたほうがいいメンバー • どこから進めるか • 他の影響が大きいためタスクとして切り崩したあとから一緒に動くことが望ましい スピード感も加味する と最初から一緒にやるのは 厳しいと判断

どのように手を離していくか 「タスク」として考えるなら「自動テストの実行時間の削減」が進めば完了 しかし、それで終わりにすると今後に活かせない • 自動テストの「あるべき姿（ToBe）」とAsIsからのロードマップはなかなかむずかしい • ここは更新頻度も少なく難易度も高いため「私」が担当 • まずは継続的におこなう次を任せられるように進めていく • テストコードの理解、改善 • どのテストコードをいつ実行するかの判断 テストコードは多いので「スキル獲得の場」としては適しやすい

自動テストの改善の進め方

自動テストの改善 課題：トータルの実行時間の長さ そもそもの「課題」の本質とはなにか？ 単純に「実行時間」にフォーカスすることが正しいか？ • 単純に実行時間を短くしたいのであれば、 • 「実行頻度」を減らす • 「実行ファイル数」を減らす 確かに「実行時間」は減るものの早急すぎる解決方法 得られるメリットよりデメリットが多くなりやすい

自動テスト周りの現状把握 課題と言われているものを自身でも「肌感」として課題と認識するためにも現状把握 • • • 今までとってきたアンケートの結果確認 • PdE向けに半期に一度、テストコード周りに関するアンケートを実施済 認知コストが高い という結果が出ている テストコードの確認 • 実際のコードの中身を確認 • 量が多いため全ては確認しない これだけだと 情報が不足 CI/CDサービス（CircleCI）の実行状況の確認 • 初手：CircleCIのinsightsでの確認 • 詳細確認：成果物を指定分だけDLするスクリプトを用意し内容確認

対象範囲の決定 • 現状把握した結果から分かったこと • テストサイズは大きく分けて２種類のものが存在 • それぞれが別々かつ並列にテスト実行される • （１）テストサイズ（Small、Medium）：x並列 • （２）テストサイズ（Large）：y並列 • （１）と（２）それぞれのトータルの実行時間は大差ないが、１テストケースあたりの実 行時間は「当然」Largeのほうが大きい したがって テストサイズがLargeなものに対してアプローチをするのが望ましい

自動テストへの改善アプローチ検討 • 前提 • 自動テストの改善において関係者への影響が一切ないというのはむずかしい • 急に変えるのではなく、不安な種を見つけつつ進めることが求められる • Largeサイズの自動テストの実行最適化をすすめるにあたって • テストケース数：常にすべてのテストケースを動かす必要があるか？ • 実行頻度：テストケースの実行頻度はどのぐらい減らしても平気なのか？ Largeサイズのテストは影響範囲外も含めてテストをしている 動かさないというのは不安が強い

ToBeを考える いきなり「何かを止める」というのは不安になる そこで課題の再整理をし「どうなりたいか？」「どうなるとよいのか？」を考える 「自動テストの実行最適化」 常に全テストを動かすのではなく、必要なものだけを実行する この「ToBe」にむけて現状がどういう状態で、どのように進めていくかを考えることが大事

小さく進めるために 小さく進めていくためにおこなったこと • （１）自動テストの実行における「AsIs」と「ToBe」の姿を用意 • （２）最初におこなう数ステップを用意 • 最初の数ステップは影響が０なもの • 影響が少しでも出る箇所は影響が出たらどのようなバックプランをおこなうかも明示 ToBeの姿に向けて進むにあたって どういうことをおこなっていくかを関係者に共有していくことが大事

ToBeへ向けての第一歩 すすめること • （０）実行タイミング（Trigger）のパターンを増やす • ※ CircleCIではGitHub Appsを導入することで可能 • 参照：https://circleci.com/docs/guides/integration/github-apps-integration/ • （１）自動テストの実行頻度を少し変更 • Draft PR時のPushでは動かさない • （２）Pushのたびに動かす自動テストを変更 • まずは常に動かさないテストを定義 • ※このステップで「CUJのみ動かす」は早すぎるため「動かさない」のを決める

• https://circleci.com/docs/guides/integration/github-apps-integration/

一緒に進めていること 次にむけておこなうべきことをメンバーと一緒に推進 （２）Pushのたびに動かす自動テストを変更 おこなっていること • （２−１）常にうごかすテストケースの判定 • おこなっているテストの内容を１つ１つ見て判断 • 動かさなくていいものに対して特定のタグを付与 • （２−２）テストケースの「認知度向上」 • テストケース名が実態にあわない場合、（２−１）もずれるため実態にあった名前に変更 手を離していくのはまだまだ先の予定

現在の状況 • GitHub Appsはfork PR には非対応 【done】（０）実行タイミング（Trigger）のパターンを増やす • 導入のためにfork PRをなくすことが必須で次を実施 • 1. 全体アナウンス fork PRがどれぐらい • 2. 残っているfork PRのオーナーに個別質問 残っているかはスクリプト を用意してチェック • → 結果としてfork PRは0になりGitHub Appsを導入 →【done】GitHub Appsを導入して問題が起きてないことを確認 fi 【準備中】（１）自動テストの実行頻度を少し変更 • CircleCIのcon g.ymlは肥大化しやすい • Dynamic Con gurationは導入済み fi • CircleCIの設定ファイル の変更が必須

まとめと 今後の取り組みについて

まとめ スケールアップしていく中において組織課題は至るところで発生 • 組織課題へのアプローチとしてEMがプロジェクト化して推進 • そのプロジェクトの事例として次の２つを紹介 • 不具合分析： • 自動テストの改善 • 同じことがおきたときに対応できる人をふやすことが重要 • 誰かができるようにするではなくチームでできることが重要 • そのためにスキル移譲をすすめ 「取り組み」を広げられる土台を作ることが大事

今後の取り組み • 次の両輪をさらに進めていき、おこなえる「幅」を広げていきます • （１）組織体制を強化し「再現性」の幅を広げていく • （２）いろいろなメンバーの「再現性」の幅を広げていく そのために 一緒に 働く仲間を募集！！

We are hiring！！ 一緒に「目指す姿」に向かって 進んでくれるメンバーを募集しています カジュアル 面談は こちらから https://recruit.smarthr.co.jp/career/?category=qa

• https://recruit.smarthr.co.jp/career/?category=qa