この記事は株式会社カオナビ Advent Calendar 2024の7日目の記事です。
こんにちは、iaroと申します！
この記事では2024年の上期からはじめたQAリソース安定化への軌跡について書いてます。
絶賛取り組み中なものになっておりますが、振り返りの意を込めて紹介していきます。
1.
新体制構築の目的と背景
〜安定したQAリソース管理を目指して〜
私たちQAチームは、今期チーム横断型の協力体制構築に取り組みました。
その主な目的は、各チームにアサインされているQAメンバーがチームを跨いで協力できる体制を作り、QAリソースを安定して管理することでした。
この取り組みの背景は、各チームで案件によってテスト工数が不足し、リリース延期などのリスクが発生していた現状があったためです。
そういったリスクを回避し、安定したリリース体制の構築が必要でした。
様々な現場でも同じような状況に置かれることは多いのではないでしょうか？
2. 
具体的な取り組み：4つの柱
新体制の構築にあたり、私たちは以下の4つの柱に基づいて取り組みを進めました。
・・・・といっても、難しいことは特にしていません！!
チーム体制をつくために必要なことを少しづつ推進していきました。
(「え、当たり前じゃない？」みたいな施策が多いかとおもいます。それでもどこかの誰かには参考になるといいなぁと願いつつ簡単に紹介します
）
2.1 コミュニケーションの創出
- miroを活用したグループQCメンバーの自己紹介
- 各施策実行時のフィードバックの場づくり
- 定例MTGや1on1の実施
- Slackチャンネルの作成
2.2 テスト品質の底上げ
- グループ内レビュー体制の構築
- 他機能を知る会、案件説明会の開催
2.3 効率化への取り組み
- リーダーMTGでのmiro活用によるタスクや進捗共有
- レビュー依頼＆管理の自動化
- グループQC活動運営のドキュメント化
2.4 リスク管理
- グループ内リソース調整
- 仕様ドキュメントの作成
- 定例MTGでの情報共有
3. 
取り組みを実施してみた所感
3.1 リソース管理について
リソースを見える化する際に使ったものは、スプレッドシートのタイムライン機能です。以前は結構雑に手動でセルに色をつけてみたいなやり方をしていました。タイムラインだといくつか設定は必要ですが、期間さえ入力すれば勝手に線を引いてくれます（といってもこれにかわるようなツールはたくさんあるとおもうので、使いやすいものを使えばよいかと思います）
これによって全体のスケジュールは可視化でき、上期はいくつかの案件で必要なチームに対しリソースを調整し、ヘルプ対応を行ったりすることができました。
こんな感じ
ただ下期についてはリソースはほぼ埋まっている状態が明らかになりました。今後は、この状況下でいかに効果的な体制を構築していくかが課題です。
昔はこんな感じ
3.2 miroよかった
miroの活用により、タスクとステータスが直感的に把握可能になり、認知コストを低下させることができたのは良かったポイントです。
気になる方はこちら。公式サイト：miro
よく使われるブレストパターン
3.3 ドメイン知識を広げる
「他機能を知る会」は、カオナビの機能について理解を深めるための取り組みです。この会の主な目的は、自分が担当している機能以外のカオナビ機能について学ぶことで、ドメイン知識を広げることです。
この取り組みの狙いは以下です。
- 他チームをヘルプする際、立ち上がり工数を減らす
- テスト内容レビューのハードルを下げる
- 機能を横断したテスト観点の充実につなげる(知った知識を自チームに持って帰って活かせたり、お土産的な要素を期待)
「他機能を知る会」は以下の流れで進めました。
1.機能の概要説明：その機能はどんな機能なのか、基本的なユースケースがわかる
・サポートサイトなど何かしら補助資料を用いると、準備コストを下げられる
2.デモ：画面をうつしながら基本的なシナリオを説明し、より具体的に理解できるようにする
3.実際に操作しようの会：参加メンバーに一緒に手元で操作してもらい、各自体験してみる
・誰か1人に画面共有してもらい、担当者のナビゲーションのもと他参加メンバーも自分の手元で操作行う
・機能の担当者：適宜補足をしたり、質問対応などを行う
・他の参加者：自身でも操作しながら、自由に質問やリアクションをする(口頭でもチャットでも。にぎやかしも歓迎)
まだ一部の機能しかできていないですが、基本的な機能ついては理解できたんじゃないかと感じています。とはいえ、1度のみだと理解できる限界もあるので、繰り返し触ってもらう機会を作る必要があるかなと感じています。
3.4 新体制構築の難しさと協力の重要性
新体制の構築にあたり、何から始めるべきか、何が課題なのかを一から洗い出す必要がありました。この過程で、主軸となるメンバーは2名で基本進めていきました。
互いにアイデアを出し合い、壁打ちしながら進められたことが、スムーズな立ち上げにつながったと感じてます。(多すぎるとそれはそれで進みづらくなるので、2人ぐらいがちょうどよかったです)
3.5 グループでの関係性構築
グループの人数が増えたことで、メンバー間の関係性構築が課題となりました。
上期では自己紹介や振り返りにフレームワークを活用し、お互いを知る機会を増やす工夫をしました。
使ったフレームワーク：ありたい姿 starfish
ただそれだけでは関係性が構築できるかと言われると難しい部分でもあります・・。
現実問題、チーム内で質問しづらいといった声もあがっていました。
また、横断的な取り組みへの協力度やモチベーションレベルが多様でした。この多様性に対応しつつ、メンバーをまとめ、鼓舞することの難しさを実感しました。
そのため、チームを跨いでより協力し合える文化を醸成するために、最近では定例時に以下のようなアイスブレイクも導入し始めました。
こちらも効果はウォッチしつつ改善点などあれば色々模索しながら進めていこうと思っております！
1人1分ぐらいで、テーマは以下
①業務に有益な情報系(自チームでやってよかったこととか、最近見たIT系の情報とか)
②困っていること系(今うちではこういうことに困っているけど他のチームどう？みたいな）
③上記2つが出てこなければ自由テーマ
3.6 効果的なレビューワークフローの構築
SlackとSpreadsheetを連携させたレビューワークフローの構築は個人的に良い仕組みだなと思っています。チーム数と人数が多い中で、レビュー対応の漏れを防ぐ仕組みを作ることができました。
具体的には以下のようなレビューのワークフローを構築しました。
3.7 レビュー進行の難しさと改善の必要性
当初のレビュー方式は、机上かつ挙手制で行っていましたが、レビュー対象となる機能が多岐にわたり、自チーム以外の仕様理解の難しさや、作業負荷の高さから参加障壁が高くなってしまいました。結果として、一部のメンバーに負荷が集中する傾向がありました。
そのため、レビューの進め方については、改善に着手しており、全機能を対象とするのではなく、関連性の高い機能やメンバーの社歴を考慮してグループを作り、レビュー対象を絞り込んでいます。また、対面レビューを中心とする形に変更しました。
「3.3 ドメイン知識を広げる」で紹介した取り組みも併せ、実施状況を見ながら、さらなる改善を進めていく予定です。
3.8 リソース活用の戦略的アプローチ
現在は、テスト工数が足りないチームへのヘルプ要員として余剰リソースを活用していますが、長期的な視点も必要だと考えています。単に空いた工数を他チームのヘルプに充てるだけでなく、自チームでのスキル向上や業務改善にも時間を割くことで、長期的な安定化につながる可能性があります。このバランスを考慮しながら、リソースの安定化を進めていければと考えています。
4. おわりに
QAチームの横断型組織構築は、多くの課題と向き合いながらも、様々な取り組みを実践している最中です。
現状は効率化、コミュニケーション強化、品質向上、リスク管理の各面で進展が見られ、より安定したQA体制の基盤ができつつあります。
今後も、直面する課題に柔軟に対応しながら、さらなる改善と発展を目指していきます。この取り組みを通じて得られた知見と経験を活かし、より強固で効率的なQA体制の構築に努めていこうと思います！