Chris Faraglia著
今日の仕事環境では、いたるところでリモートチームやハイブリッドチームが取り入れられているだけでなく、一般的になっています。これは、QAチームにとってはどんな意味を持つのでしょうか？QAは分散された作業環境に適していますが、分散QAチームを管理する場合に特に考慮すべき事項があります。
この記事の内容:
- ハイブリッドワークおよびリモートワークのさまざまな形式
- ワーキングアグリーメントの活用法
- 「完了 」の定義を導入する
- QAの 「技術的負債 」を可視化する方法
- 分散チームのプロセスを強化する4つの具体例
- 継続的改善のための仕組み
「分散型QAチーム 」の定義
リモートワークの性質が進化していることを背景に、組織はさまざまなモデルやアプローチを採用しています。この記事の理解を容易にし、改善に役立てるため、分散型ワークモデルの定義として4つのタイプを示します。
1.ハイブリッド分散型ワークモデル
このアプローチでは、チームはオンプレミスで働くメンバーとリモートで働くメンバーの両方で構成され、複数のタイムゾーンや場所にまたがっています（たとえばオンプレミスのメンバーはニューヨークに、リモートのメンバーはリスボンにいるなど）。
2.リモート分散型ワークモデル
このモデルでは、チームのメンバー全員がフルリモートで仕事をし、複数のタイムゾーンや場所に分散しています。
3.ハイブリッド集中型ワークモデル
このモデルでは、チームにはオンプレミスとリモートのメンバーが混じっており、同じタイムゾーンまたは地域内にいます。
4.リモート集中型ワークモデル
このモデルでは、チームはフルリモートのメンバーで構成され、全員が同じタイムゾーンまたは地域内にいます。
さまざまなハイブリッドワークおよびリモートワークのモデルを定義し、理解することは、チームを作りあげ、 タックマンモデルでのチーム開発の段階 （形成期、混乱期、統一期、機能期）を進んでいく上で不可欠です。また、各モデルに特有の課題や改善の機会について有益な洞察も得られます。
共通の課題
リモートチームおよびハイブリッドチームの構造を明確に理解したところで、これらのモデルに共通する課題をいくつか挙げます。
- 優先事項を処理する際の効率の悪さ: 労力を効率的に集中させたり、最優先事項に集中して対処することが困難です。
- SDLCの成果物の重複: テストケース、不具合レポート、ユーザーストーリーなど、ソフトウェア開発ライフサイクル（SDLC）のさまざまな要素が重複します。
- SDLC内での説明責任があいまい: 「コードがマージされる前に自分のテストが通っていたから、私の責任ではない……」といった発言に代表されるように、責任の所在が明確でないため、あいまいさが生じます。
- チームのベロシティ（速度）のばらつき: チームの速度、つまり特定のイテレーションやスプリント中に完了できる作業の量に一貫性や予測可能性がありません。
規制対象業界に共通する課題
さらに、 規制対象業界で働くチームは、他にも特有の課題に直面します。規制対象業界とは、政府の厳しい規制によって管理される業界であり、教育や金融サービスなどが該当します。ここでは、リーダーとチームメンバーが考慮するべき個々の課題の概要を説明します。
- 国際的なチームに適用されるさまざまなコンプライアンス基準: 国境をまたがるリモートチームは、業界ごとに異なるコンプライアンス基準に対応し、遵守する必要があります。
- 災害時復旧のためのクラウド構成: 災害時復旧やレプリケーションのために特定のクラウド構成を確立し、アプリケーション環境の冗長構成（複数AZ構成）を確保することが必要になる場合があります。
- 機密情報のデータアクセス制限: 特に機密データに関しては、特定の国に属さないチームメンバーに対して、厳格なデータアクセス制限を実施することが求められる場合があります。
コミュニケーションを最大化するための戦略
ハイブリッドチームやフルリモートチームには多くの利点がありますが、効果的なコミュニケーションが難しい場合もあります。コミュニケーションを通じてチームのパフォーマンスを高めるために注力するべき重要な領域として、「ワーキングアグリーメント」の確立や、「シフトレフト」の考え方を採用することなどがあります。
ワーキングアグリーメント
ワーキングアグリーメントとは、チームの総意に基づく一連の「ルール」であり、チームメンバー全員が同意し遵守する必要があります。このルールは、スプリントのレトロスペクティブミーティング（アジャイルチームの場合）や根本原因分析セッションで繰り返し参照され、動的な「生きた文書」として扱われます。
ワーキングアグリーメントの条項が扱う内容として、管理やソフトウェア開発ライフサイクル（SDLC）に関するトピックまで含めることができます。これには、キャパシティプランニング、チームメンバーの役割と責任の明確化、リリース承認のワークフローなどの側面が含まれます。
次の例では、ワーキングアグリーメントは、管理（キャパシティプランニング）と SDLC（リリースワークフロー）の両方の側面にまたがる問題に対処しています。
ワーキングアグリーメントの例
スプリントのレトロスペクティブミーティングでの例
合意事項1: キャパシティプランニング
- 現状: 仕事が均等に分散されていないため、チームメンバーが負担を感じているケースもあった。
- ディスカッション: 効率向上のための作業負荷バランスの重要性について議論します。
- 調整結果: チームはワーキングアグリーメントを次のように更新することに同意します。「スプリント計画時、チームは共同で各個人の作業負荷を評価する。偏りが確認された場合は、公平な業務分担が行われるよう調整される。」
根本原因分析セッションでの例
合意事項 2：リリースワークフロー
- 現状: リリースプロセスが遅れがちで、伝達ミスも多い。
- ディスカッション: 根本原因分析を行い、リリースワークフローにおけるボトルネックを特定します。
- 調整結果: チームは次の新しいワーキングアグリーメントを盛り込むことに同意します。「各スプリントには、リリースコーディネーターが指名される。リリースの承認とコミュニケーションチャネルのための文書化されたワークフローを確立し遵守する。」
管理的な側面と SDLC の側面の両方にまたがる事項に対処することで、チームは、ソフトウェア開発プラクティスだけでなく、チームの有効性に影響を与えるより広範な組織的・管理的なプロセスについても足並みを揃えることができます。
「完了 」の定義
現在、ソフトウェア開発チームの大半がなんらかの形式の アジャイル方法論を採用しているため、「完了基準」に関して共通の考え方を確立することが、分散チームにとってより重要になっています。
「完了基準」の概念はチームによって異なることがあります。Leading Agileは、完了（DoD）を「ソフトウェア製品が満たすべきすべての条件または受け入れ基準が満たされ、ユーザー、顧客、チーム、または消費システムによって受け入れ可能な状態になった時点」と定義しています。
「完了基準」の例
以下に、ソフトウェア開発におけるさまざまなタスクの「完了基準」の例を示します。
ユーザーストーリーの実装:
- すべての受け入れ基準を満たしていること
- コードの作成、レビュー、承認が済んでいること
- 単体テストと統合テストが作成され、合格していること
- ユーザードキュメントが更新されていること
- コードがメインブランチにマージされていること
バグ修正:
- 検出されたバグの修正と検証が済んでいること
- 適切な単体テストと回帰テストが作成され、合格していること
- バグ修正を反映するようドキュメントが更新されていること
- コード変更のマージとデプロイが済んでいること
機能開発:
- すべての機能要件が実装されていること
- コードがコーディング標準とベストプラクティスを遵守していること
- 網羅的な単体テストと統合テストが作成され、合格していること
- ユーザードキュメントおよびAPIドキュメントが更新されていること
- コードがメインブランチにマージされていること
「完了」の定義について共通の認識を持つことで、分散されたチームメンバーが作業項目の完了に関して設定された基準に沿っていることを担保できます。チームメンバーは、明確化が必要な状況が発生した場合、ワーキングアグリーメントを活用し、支障なく業務を継続することができます。
分散チームのプロセス強化
ソフトウェア開発チーム内で特定のプロセスを定義し、実装することは、品質とアウトプットに大きく影響します。分散チームで運用する場合、これらの要因はプラスにもマイナスにも拡大する可能性があります。ここでは、分散チームの有効性と効率性に大きな影響を与える重要なプロセスをいくつか紹介します。
1.テストケースのレビュープロセス
QAチームメンバーだけでなく、テスター、QAエンジニア、利害関係者を含むすべての人が参加し、負債ではなく「維持価値のあるテスト資産」とみなされる高品質のテストを確実に作成することに取り組むべきです。チームは、テストの種類（単体、統合、機能、手動など）にかかわらず、体系化されたレビュープロセスに従うべきです。
主な検討項目は以下の通りです。
- ワーキングアグリーメントに従うこと: テストケースのピアレビューは、ワーキングアグリーメントに定められたガイドラインに従う必要があります。
- コードマージ前の品質ゲート: レビュープロセスは、マージされるコードに対してテストケースを実行する前に、徹底的な検証を行う品質ゲートとしての役割を果たすべきです。
- 共通のプラットフォームを活用する: さまざまな種類のQAテストにまたがるコメントを追跡、表示、解決するための統一プラットフォームを採用し、効率的なコラボレーションを促進します。
2.「環境の所有宣言（Environment Claim）」の定義
多くのチームは、開発中の機能の迅速な開発、テスト、および受け入れを促進するために、テスト対象製品またはシステムの複数の環境を利用しています。チームが分散されていたり、プロセスが十分に確立されていない場合には、環境が「いつ、何を、どのように」デプロイされ、更新されたかを確認する際に混乱が生じ、生産性が低下する可能性があります。
「環境の所有宣言（Environment Claim） 」コンセプトの活用
チームの環境のバージョンと目的を 「主張（クレーム）」または追跡するというコンセプトを採用することで、開発およびマイルストーンのプロモーションプロセスを通じて、チームメンバーが環境を活用できるようになります。ここでは、チームの環境管理をよりよくサポートするためのプロセスの例をいくつか紹介します。
- チームオーナーと目的を明確にする: デプロイされた各環境のチームオーナーと目的を明確にします。この情報をワーキングアグリーメントに追加することを検討します。
- 「環境の所有宣言」のページを維持する: 手動または自動で「環境の所有宣言」ページを作成し、常に更新される有効な文書として維持します。
- CI/CDパイプラインの整合性を確保する: 環境のデプロイメントおよびプロモーションに関するワーキングアグリーメントに沿って継続的インテグレーション/継続的デプロイメント (CI/CD)パイプラインの整合性をとり、自動または手動でデプロイを行います。
- CI/CDとテスト管理の統合を実現する: 継続的インテグレーション/継続的デプロイメント (CI/CD) とテスト管理の統合を実装し、リリースの前に、プロモートされた環境に対して実行されたテストを追跡できるようにします。これにより、プロセスが合理化され、環境の変化に応じてテストの進捗状況を包括的に可視化できます。
3.QA技術的負債の可視性を高める
開発チーム内のコラボレーションは、ソフトウェアエンジニアとQA/テスト担当の間だけで行われるものではありません。分散チームは、インフラやテストに関する技術的負債を可視化することで効果を得られる場合があります。ここでは、プロダクトオーナー、ステークホルダー、QAの間で技術的負債の可視性を高めるためにチームが注目すべきプラクティスを紹介します。
- プロダクトバックログを管理する: チームのアジャイル作業管理/トラッカーツール(Jira、Rallyなど)内で、テストと品質に関連する技術的負債のための専用のプロダクトバックログを維持します。これにより、可視化と優先順位付けを確実に行えるようになります。
- テスト候補の追跡を自動化: 自動化の候補となりそうな手動テストと、すでにチームの自動化スイートに統合されているテストを追跡します。これは自動化の優先順位に関する効率的な意思決定に役立ちます。
- テストをアプリケーションコードのように扱う: テストをアプリケーションコードと同等に考えます。欠陥のあるテストや壊れたテストに対して不具合の報告やタスクを作成し、レビューを開始し、定期的な「トリアージ」セッションで優先度と影響度に基づいて対処します。
4.継続的改善の重視
分散チームで作業したり、チームを管理したりする場合、全員が自分のパフォーマンスを評価し、改善する機会を持てる環境を整えることがより重要になります。
「1on1」ミーティングの実施
分散チームを管理するリーダーにとって、個人の課題や成果を可視化することは、一元的なチームと比較して困難な場合があります。「1on1」形式の定期的なチームミーティングを実施することは、非常に効果的です。ミーティングでは次のようなトピックを扱います。
- 個人的に改善できたと思う項目を1つ 振り返ります。客観的な振り返りやレポート、チームの速度や欠陥などのメトリクスを利用することができます。
- チームの速度や欠陥、リリース品質などを客観的に考慮し、チームが優れていた点を1つ挙げます。
- 反省に基づき、どのようなアクションを取る必要があるかを考えます。
チームの「スキル向上（アップスキリング）」
QAチームのメンバーは、職務上求められることがますます多くなるため、一般的に「スキル向上（アップスキリング）」と呼ばれる継続的な学習への意欲を維持することが極めて重要になります。分散チームを監督するリーダーは、継続的な能力開発を確実にするために、新しいスキル、テストツール、テストプロセスの習得を重視して時間を割くべきです。
その際、２つの重要な点を考慮する必要があります。
- スプリント計画における優先順位付け: チームのスプリント計画の中で自己学習とトレーニングの時間を割り当て、スプリント全体の不可欠な一部とします。
- 測定可能な目標: LeetCodeチャレンジやTestRailアカデミーのように、認定、コース修了、スキルベースの評価などの目標を取り入れ、測定可能なトレーニング目標を確立します。これにより、継続的な学習に対する具体的かつ目標志向のアプローチが実現できます。
分散QAチームを管理することや、その中で働くことは、チームの潜在能力を最大限に引き出す適切な手段を講じなければ、困難なものになりかねません。この記事のヒントと戦略を実行することで、分散チーム内のコミュニケーションとコラボレーションが大幅に向上します。
キーポイント
- チームワークアグリーメントを定義し実施する
- 作業項目の完了を確認するために、合意された「完了」の定義を活用する
- 品質保証の技術的負債をプロダクトログに整理して追跡し、可視化する
- SDLC全体を通して環境の「クレーム」と使用状況を維持する
- ワーキングアグリーメントに従ってテストケースのレビューと承認を実施する
- パフォーマンスを振り返り、改善を促すための「1on1」ミーティングを実施する
分散チームの管理についてより詳しく知りたい場合、このウェビナー「Strategies for managing distributed QA teams」では、規制の厳しい業界を含むあらゆるセクターに適用できるハイブリッドおよびリモートQAモデルの強化に関する洞察を得ることができます。
Chris Faragliaは、TestRailのソリューションアーキテクト兼テスト推進者です。原子力発電およびヘルスケアITの領域において、15年以上にわたってエンタープライズソフトウェアの開発、統合、テストに従事してきました。また、米国、中央ヨーロッパ、南西アジアに分散するテストチームを管理し、連携してきた経験があります。
（この記事は、開発元Gurock社の Blog 「Managing Distributed QA Teams」2024年3月14日の翻訳記事です。）
関連する製品
テスト管理ツール TestRail
テストケースの管理やテスト結果の記録、チームでの情報共有など、Excelを使ったテスト管理の業務に限界を感じていませんか？TestRailはシンプルで使いやすいUIを提供し、テストにかかるさまざまな管理コストの削減に貢献します。
■ TestRailの特長 ■
- テストにさまざまな情報を関連づけて一元管理
- Webブラウザー上でテストケースを簡単に入力や編集可能
- テスト実施の準備と結果の共有が容易
- 進捗や比較などのレポートを提供
- 要件 / 課題管理ツールやテスト自動化ツールと連携
日本国内では、テスト管理にExcelを使っていたお客さまからの乗り換えが多く、Web上で完結するテスト管理を実現されています。
TestRail でテスト管理のお悩みを解決しませんか？