こんにちは。@tak_koheiです。このエントリーは、エムスリーキャリア Advent Calendar 2023の18日目です。
私たちはシステムの開発ライフサイクル全域でQAエンジニアが活動することにより、QAエンジニア以外が行っている開発活動の質を高める支援をしたり、開発するプロダクトそのものの品質を高めたりする取り組みを推進しています。また、プロダクトや開発活動の品質を向上させるだけでなく、より良いサービスや事業を実現することにも繋がりたいと考えています。
本エントリーでは「事業や開発と並走するQA活動」について、QAエンジニア全員がより具体的に何をしたら良いのかを考えられるようになるための仕組みを整備して運用した話を共有します。QAエンジニアとして「プロダクトに対するテストだけに留まらない広範囲な活動をしたい」という想いはありつつも、なかなか具体的な取り組みが広がらないという課題を乗り越えるために行ってきた試行錯誤の記録です。
課題：ふんわりイメージの『並走QA』
当初、QAチームとして「事業や開発と並走するQA活動をしていこう！」という方針を掲げてはいたものの、より具体性のある組織的な取り組みにしていくためにはいくつかの課題を感じていました。
課題１．活動の理解度にばらつきがある
まず、QAチームに所属するメンバーのレベル感が様々*1で、「並走するQA活動」の理解度にばらつきがある、という課題がありました。
- 何をしたら良いか具体的にイメージできていないメンバーがいる
⇒ 具体性を持てないのでなかなか行動に移せない - QAチーム全体で「並走するQA活動」に対する共通認識が持てていない
⇒ 何をどうするのが正しいのかチームとして同じ方向を向けない
課題２．活動の浸透状況が測りにくい
また、「並走するQA活動」と一口に言っても実際に何をするのか漠然としているため、活動の浸透度合いが測りにくいという課題もありました。
- 各自が何をどれくらいできるようになったのか測り難い
- QAチームがチームとしてどれくらい成長しているか判断し難い
- もっと活動を強化するべき重点箇所はどこなのか特定が難しい
解決：「並走するQA活動」を構造化する
そこで、「並走するQA活動」が誰でもより具体的にイメージできるようにするため、活動の範囲と具体的な行動を紐づけて可視化する仕組みを作ろうと考えました。ソフトウェア開発を進める上で通る各工程に対して、具体的なQA活動例*2を紐付けられれば、どのタイミングでどんなことを行えば良いのかイメージできるようになるはずです。
構造化１．プロセス
まずは、開発全体の流れ*3を、扱いやすい適当な粒度で6つのプロセスに定義しました。
P1. 課題ヒアリング・要件確認
利用者からの要望や課題を詳しく聞き出し、システム開発の目的や要件を定めるプロセスです。QAの観点からは主に、要件が正確に理解され、適切に文書化されて相互の認識が合っていることを確認します。
P2. 起案・見積もり
要件に基づいたシステムの開発案を作成し、開発にかかる工数や日程など計画を検討します。QAの観点からは主に、開発案の考慮漏れが無いかを確認したり、テスト計画の視点で必要に応じて開発案にフィードバックします。
P3. 要件深掘り・仕様調整
詳細な要件の理解と仕様の調整を行うプロセスです。QAの観点からは主に、要件や仕様に対して不足や認識の齟齬が無いよう確認したり、既存機能との不整合が無いかや、運用時の注意点を事前にフォローします。
P4. 設計実装・テスト分析設計
設計に基づき実際にシステムを開発し、同時にテスト内容の検討も進めます。QAの観点からは主に、テスト観点を設計や実装にフィードバックすることで、テスト実行以前により品質を高める活動を実施します。
P5. テスト実行・不具合修正
実装が完了したシステムのテストを行い、不具合が見つかった場合は修正します。
P6. リリース・リリース後
テスト完了後に本番環境へリリースします。リリース後の効果測定も活動内容に含みます。
※私たちの開発組織ではこの流れで開発することが多いです。ただ、全て同じ流れではなく、これとは異なるフローで開発が進む場合もありますので、場合によっては読み替える必要はあります。
構造化２．ステップ
次に、各プロセスいずれのQA活動においても共通で考えられる進め方の手順としてステップを3つ定義しました。
S1. 接点の獲得
QA活動を始めるために各プロセスでステークホルダーとの接点を得る。
S2. 検討と提案
獲得した機会を通じて各プロセスにおける開発活動を推進または支援する。
S3. 記録と整理
後からふりかえりができるよう検討の過程や結果を整理して記録に残す。
各プロセスと各ステップの組み合わせが、開発工程におけるQA活動を紐づける対象になります。
構造化３．アクション
最後に、各「プロセスｘステップ」の組み合わせに対して、該当するQA活動にはどのようなものがあるかを考え、28個のアクションとしてリストアップしました。
概略図
アクションの内訳と概要は以下の通りです。
『P1. 課題ヒアリング・要件確認』ｘ『S1. 接点の獲得』
「要件の源流に触れる機会を得る」
- A1-1-1. 要件のヒアリングに参加する
- A1-1-2. 課題解決方法の検討に参加する
『P1. 課題ヒアリング・要件確認』ｘ『S2. 検討と提案』
「解決したい課題が何かを考える」
- A1-2-1. 要件を認識して解決したい課題を特定する
- A1-2-2. 仕様案に対して品質やテスト容易性について懸念があれば指摘をする
『P1. 課題ヒアリング・要件確認』ｘ『S3. 記録と整理』
「課題の検討結果を記録に残す」
- A1-3-1. ヒアリング内容や検討結果のサマリを記録して関係者に共有する
『P2. 起案・見積もり』ｘ『S1. 接点の獲得』
「自身で起案したり起案された内容を知ったりする機会を得る」
- A2-1-1. 開発案件を起案するための検討会に参加する
『P2. 起案・見積もり』ｘ『S2. 検討と提案』
「起案された内容を精査し補完したりプロジェクト計画を策定したりする」
- A2-2-1. 起案できるレベルまで仕様を詰める検討に関与する
- A2-2-2. ROIの試算に関与する
『P2. 起案・見積もり』ｘ『S3. 記録と整理』
「起案に必要な情報を記録に残す」
- A2-3-1. 開発案件の開始に必要なドキュメントを作成する
- A2-3-2. 元になる要件と洗い出した仕様を紐付けた記録を残す
『P3. 要件深掘り・仕様調整』ｘ『S1. 接点の獲得』
「仕様を検討する場に参画する機会を得る」
『P3. 要件深掘り・仕様調整』ｘ『S2. 検討と提案』
「適切に判断していくための視点をチームに与える」
- A3-2-1. 仕様の曖昧な点を指摘して必要に応じて修正する
- A3-2-2. 未決定の仕様があれば指摘して仕様の確定までフォローする
『P3. 要件深掘り・仕様調整』ｘ『S3. 記録と整理』
「詰めていく仕様や変化していく仕様を把握し易いよう記録に残す」
- A3-3-1. 確定した仕様を整理してコンフル等に記載する*6
『P4. 設計実装・テスト分析設計』ｘ『S1. 接点の獲得』
「テスト分析テスト設計の結果を開発へ早期にインプットする機会を得る」
- A4-1-1. テスト分析やテスト設計の内容を開発担当者に早期にフィードバックする
『P4. 設計実装・テスト分析設計』ｘ『S2. 検討と提案』
「設計やテストに対して新たな視点を加え気付きを得る」
- A4-2-1. E2Eテストをメンテする観点で指摘をしたり自身で直接改修したりする
- A4-2-2. 非機能要件に対する懸念事項の指摘やテスト実行の検討をする
『P4. 設計実装・テスト分析設計』ｘ『S3. 記録と整理』
「仕様の記録に加え設計やテスト分析テスト設計の注意点など記録を残してふりかえりができるようにする」
- A4-3-1. 仕様や設計の変更に合せてコンフル等の記載を更新する*7
『P5. テスト実行・不具合修正』ｘ『S1. 接点の獲得』
「最終的な実装と最新のテスト観点を擦り合わせる機会を設ける」
- A5-1-1. テストの開始前に開発者と仕様やテスト内容の認識合わせをする場を設ける
『P5. テスト実行・不具合修正』ｘ『S2. 検討と提案』
「テストの途中経過を踏まえながらテスト実行自体も臨機応変に変化させ最適化する」
- A5-2-1. バグ検出状況からテストの優先度変更やテスト観点の追加をする
- A5-2-2. 案件の規模や状況に合せてQA担当者以外も参加する探索的テストの会*8を開催する
『P5. テスト実行・不具合修正』ｘ『S3. 記録と整理』
「最終仕様と実態が乖離しないよう最後までドキュメントをメンテし続ける」
- A5-3-1. バグの修正で仕様に変更があれば該当のコンフル等を更新する
- A5-3-2. テストの実施内容や結果を記録し、テスト完了時に開発担当者へ共有する
『P6. リリース・リリース後』ｘ『S1. 接点の獲得』
「次の案件の上流を見据えてQA活動の足掛かりを得る」
- A6-1-1. 開発案件の担当者やステークホルダーを交えてふりかえりの機会を設ける
『P6. リリース・リリース後』ｘ『S2. 検討と提案』
「各プロセスの品質指標を元にふりかえりを推進して改善を図る」
- A6-2-1. 開発プロセス全体の課題や改善施策の検討および実施を推進/支援する
- A6-2-2. QA中バグの検出傾向を分析して、次回の開発活動にフィードバックする
『P6. リリース・リリース後』ｘ『S3. 記録と整理』
「続く開発活動に改善が働くよう活動結果を可視化して周知する」
- A6-3-1. QA活動の結果を記録して、改善活動に利用できるよう分析する
- A6-3-2. ふりかえりの結果を記録して、ふりかえり自体をふりかえれるようにする
完成と課題解決
以上で開発プロセスと具体的なQA活動の紐付けが完了しました。QA組織のメンバー全員で内容を読み合わせして認識合わせすることで、1つ目の課題であった具体的なQA活動の理解度を揃えながら、並走するQA活動の取り組みを進めています。
また、ここまでの取り組みでは理解度を揃えただけなので、実践するスキルにバラつきは残っています。以下の取り組みを通して少しずつバラつきを解消していくことが必要だと感じています。
- 熟練者と協働することで教わる
- チーム間で情報交換してノウハウを共有する
- 各自が業務を通じて実践方法を学ぶ
計測：アンケートで測る並走するQA活動の浸透
以上の仕組みで並走するQA活動の具体化により実践を進めているのですが、取り組みの状況を把握するためにQAメンバーから定期的にアンケートを収集しています。
実は取り組み始めて1年が経過しておりまして、2022年の取り組み初期に収集したアンケートと、1年経過して実践してきた今年2023年にもアンケートを実施しています。
今回、2022年と2023年のアンケート結果を比較して、成長の実感と新たな課題の抽出を実施しましたので併せてご紹介します。
目的
主に以下の3点を目的として並走するQA活動の実践状況をアンケートにより計測しました。
並走するQA活動の浸透度合いを実測する
⇒ 現時点における自分たちの実情を知る今後より注力すべき活動を特定する
⇒ 現時点における自分たちの課題を知るチーム全体の成長を定量的に実感できるようにする
⇒ 前進できている自分たちを褒めたい！
実施方法
アンケートの収集方法は以下の通りです。
１．28個の各アクションに対して個人の実践状況を一人一人が回答する
２．実践状況は全アクション共通で以下の三段階で回答する
- 【Good】80%以上の開発案件で実践できている
- 【Fair】20%～80%の開発案件で実践できている
- 【Poor】20%未満の開発案件で実践できている
アンケート結果：前半（成長を実感）
以下にアンケート結果の一部をご紹介します。
前半は特に取り組み開始当初の2022年と比べて今年2023年のアンケート結果でより成長を実感できている部分です。
ステークホルダーから要望をヒアリングする場にQAエンジニアが直接参加する割合が増えているのが判ります。
同様にヒアリングした要望を元にどんな課題を解決したいのかの特定にもQAエンジニアの関与が増えています。
要件定義の後の仕様検討やROIの試算にも関わりが増え、並走するQA活動の実践が浸透しているのがアンケート結果から確認できました。
また、開発が完了した後の活動についてもふりかえり会の開催を主導する役割も担うことが多くなってきています。
併せてふりかえりで抽出した改善施策の推進役としての関わりも強化できていることが確認できました。
いずれもまだまだ伸びしろを多く含んではいますが、『並走するQA活動』の具体化によって浸透が進められていることが実感できています。
アンケート結果：後半（新たな課題）
一方で、以下はまだまだ課題が多く残っていると感じた比較結果です。
要望のヒアリングに参加し、課題の特定はできているものの、その過程である課題解決の実現方法を検討する場への参画はあまり増えていません。
要件に対する記録と整理の点でもトレーサビリティを確保する活動にまだまだQAが貢献できていないのが現状のようです。（それぞれ役割分担があるので、全てにおいてQAが関与するのが正解ではないということもありますが）
柔らかい仕様に対する指摘や固めに行く活動も80%以上の比率は多いもののまだまだ底上げする余地は残っていそうです。
開発終了後の活動にもまだまだ改善の余地はありそうで、QA活動結果の記録は実施していますが、結果を分析してフィードバックするところはまだまだ必要です。
ふりかえりも主導できるようになってきていますが、ふりかえり自体のふりかえりについてはもっともっとQAが主体的に改善活動を推進する役割を担えるはずです。定型の雛形をベースにふりかえりを続けていくとどうしてもマンネリになって本当に必要な改善が見逃される状況が生まれやすくなるため、ふりかえり活動そのものの改善も進めていけると良いと思っています。
まとめ
取り組みを通じて『プロセスｘステップ』という構造でこれまでの範囲外だったQA活動を定義することができるようになったのが大きな収穫でした。メンバー全員の認識を合わせやすくなり、浸透状況の計測も行えるようになりました。自分たちの成長を実感するとともに、今後の課題を具体的に特定して取り組みを改善していけるようになったのも、仕組みが上手くメンバーの活動を後押しできたからなのではないかと思っています。
また、アクションの定義自体もまだまだ改善の余地が残っていて、『プロセスｘステップ』の構造をベースにしながら新しいアクションを抽出して定義したり、不要になったアクションを統廃合したりと、具体的な活動と紐づけて改善が進めていければと考えています。例えば今後は、実装した機能が本当に使われているかを調査してフィードバックしたり、指標をもとに事業課題がどれだけ解決されているかを測定して次の課題の改善につなげたり、といったアクションを新たに定義して、より広範囲にQAエンジニアが活動していけるような仕組みにしていきたいですね。
引き続きより幅広い役割を担ってサービスや事業に直接貢献できるQA組織を目指して活動を進めていきたいと思います。皆さまの困難なソフトウェア開発の中にも、多くの協力者がどうか現れますように。
最後まで読んでいただきありがとうございました。
*1:QAエンジニア歴20年のベテランから、キャリアをスタートさせたばかりの新人さんまで、多様なメンバーが在籍しています
*2:テストなどの一般的なQAの活動は除いて
*3:要件が発生してから開発してリリースして効果を測定するまでを全体と定義しています。
*4:開発がQA担当者抜きで勝手に進んでいて、テストの段階になって初めて呼ばれる、といったことが以前はありました
*5:ちょっとこれだけ粒度が小さすぎないか？という懸念もありましたが、煩雑になりがちな情報をなるべく一元管理するプラクティスとして入れてあります
*6:最近は仕様書をQAが書くことも多い
*7:仕様書を開発者の聖域にはせず、積極的に加筆しにいく
*8:モブテストとブリッツテストを掛け合わせた取り組みで、私たちの中ではモブリッツテストと呼んでいます
