はじめに
カイポケリニューアルプロジェクトでQAエンジニアを担当している北村です。 今回の記事では、2024年1月に入社した後、自身の所属チームで行ってきた品質保証関連の取り組みについてお伝えできればと思います。 エス・エム・エスの品質保証活動について興味がある方は是非目を通していただければ幸いです。
エス・エム・エスのQA組織の行動指針について
エス・エム・エスのQA組織は「行動指針」という形で、QAエンジニアが大切にしている考え方を言語化しています。行動指針の詳細については、以前の記事で説明しておりますので是非ご覧ください。
今回の記事では、行動指針の一つでもある「チームで品質保証」を実現するために行なっている施策について紹介いたします。
「チームで品質保証」実現の第一歩はテストドキュメンテーション
ここでは「チームで品質保証」を実現するための第一歩として実践したテストドキュメンテーションについて説明します。「テストドキュメンテーション」は「テストに関する情報のドキュメント化」を指しています。少し紛らわしいのですが、今回の記事で言っている「品質保証」は「品質を向上するために行う作業全般」を指しており、「テスト」はQAエンジニアによる手動テストだけではなく、開発者テスト・自動テストも含めたテスト全体のことを指しています。「品質保証」と「テスト」を明確に定義して線引きをするというよりは、「テストも含めた品質を向上するために行う作業全般」の話をしているんだなという認識で読んでいただければ幸いです。
「チームで品質保証」つまり「チームメンバー全員参加の品質保証活動」を実現するためには、「品質保証活動の目的とは何か」「どうやってプロダクトの品質を向上させていくのか」について認識を揃える必要があります。「品質保証」という言葉だけでは人によって解釈・受け取り方が異なるため、具体的な活動内容が想像できるように「品質保証方針」というドキュメントを作成しました。
品質保証方針には「品質保証活動を行う目的」「品質を向上するための実際にやること」「Quality / Cost / Deliveryのバランスをどう取るか(トレードオフの関係という意味ではない)」といった情報を記載していて、この方針を元に各機能開発における品質保証活動をしていきましょう、という宣言のようなものです。
各機能開発においては、QAエンジニアが「テスト要求分析レポート」「テスト計画書」といったドキュメントを作成します。この２つのドキュメントを簡単に説明すると、「テスト要求分析レポート」は主に「テスト対象機能の特定」「テスト目的の設定」「テスト戦略の概略整理」という目的で作成し、テスト計画書は「テストの目的や目的達成に至るまでの具体的な手段・スケジュールを明確にする」という目的で作成します。
ここからは「なぜこのドキュメントが必要か」「このドキュメントを通じて何を達成したいのか」といったドキュメント作成の意図も交えながら各種ドキュメントについて解説していきます。
テストドキュメント各種について
「品質保証方針」について
「品質保証方針」は各機能開発における品質保証活動の前提となる考え方で、「私たちのチームは基本的にこうやって品質保証活動をしていきます」という方針が記載されているものです。「品質保証活動で達成すべきもの」「品質向上の基本方針」「品質保証プロセス」といった項目で構成されています。
「品質保証活動が達成すべきもの」とは
品質保証方針では、「品質保証活動が達成すべきもの」は「チームで達成すべきもの」とイコールであるという書き方をしています。そもそも「品質って何？」については現状明確な定義をしておらず、チームで掲げている目標を達成するための手段として品質保証活動があるんだよ、ということを表現しています。人によっては(あるいはチームによっては)「テスト・品質保証活動はチーム内の独立した活動である」という考え方もあると思うので、品質保証活動とプロジェクト活動が一体であることを強調しています。また、「Quality / Cost / Deliveryのバランスをどう取るか」についてもこの項目で言及しており、プロジェクトの状況に応じて「今の段階では早くリリース(Delivery)して価値検証を優先しましょう」「こういった機能については品質(Quality)を重視しましょう」といった方針が書かれています。
「品質向上の基本方針」について
「品質向上の基本方針」には、仕様の検討からリリースまでにどう言った方針で品質を向上させていくかを記載しています。「不具合は早期発見を目指す」「不具合は予防と検知に分けて対策を講じる」といった方針が記載されており、この方針に従ってテスト計画を立てていきます。
「品質保証プロセス」について
「品質保証プロセス」については、品質保証方針を前提とした各機能開発におけるプロセスを書いています。 簡単に表現すると以下のような内容です。
最後に補足的な話ですが、この品質保証方針は「初版」の段階で、これからチームのみんなでアップデートしていくものだと考えています。現状ではチームメンバーに対して共有するタイミングが少なく完全に浸透しているとは言えないのですが、今後は品質保証方針を通じてチームの品質保証活動を導いていきたいと思っています。 特に「品質の定義」「品質保証活動の目指すもの」についてはアップデートしていく必要があり、達成すべき品質の基準を作りながら品質保証活動を最適化していこうと思っています。
「テスト要求分析レポート」「テスト計画書」について
「テスト要求分析レポート」作成は「テスト計画書」作成前の情報整理のような立ち位置にしており、互いに結びつきが強いためセットで取り扱います。 それぞれに記載している内容は以下の通りです。
テスト要求分析レポート
- 分析のインプット(リファレンス)
- テスト対象の特定
- テスト戦略の概略整理
- テストフローの設計
テスト計画書
- 計画のインプット(リファレンス)
- テスト対象・目的・戦略
- 制約事項
- リスクマネージメント
- テスト開始・修了基準
- 不具合管理
- テストスケジュール
項目で見ると「テスト対象の特定」「テスト戦略」が重複していますが、テスト要求分析レポートではあくまで「概略を整理する」ことを目的としており、テスト計画では「明確な決定事項(これで進めるよ、と言えるもの)を記載する」ことを目的としています。ただし「テスト要求分析レポートではここまで書く。これ以上書かない」といった明確な基準を設けていないので、状況によって記載する粒度・いつどこまで決め切るかを柔軟に変更して対応しているというのが実状です。早めにテスト観点の整理や要求・仕様の構造化を行なって合意を取りたいのであれば、テスト要求分析の段階で行うこともあります。その時のニーズに合わせながら、テスト要求分析 -> テスト計画と段階的に品質保証活動を具体化していきます。
こういったドキュメントを作成しておくことで、後から見直した時に「あの時はこういう経緯・意図でこうゆうテストをやったんだな」ということがわかるので、貴重な資産にもなります。勿論リリース後に万が一インシデントが起きてしまった場合、どの工程に問題があったのか特定するのに役立てることができます。
また、これらのテストドキュメントは他のロール(PdM 、PO、Dev)にレビューしてもらっていて、レビューを通じてリリースまでに行う品質保証活動の認識を揃えています。他ロールのレビューは毎回必ず行っているものではないのですが、ドキュメントのレビューや情報共有を通してQAエンジニアが実現したい品質保証プロセスをチームに定着させていきたいと思っています。
ドキュメント作成の基本方針について
ここまで「品質保証方針」「テスト要求分析レポート」「テスト計画書」という３つのドキュメントを作成しているという説明をしてきました。説明を読んでいる間「そんなにたくさんドキュメントを作って時間かからないの？」という疑問を持つ人もいたかもしれませんが、全ての機能開発で全てのドキュメントを作成しているわけではありません。テスト対象・テストで確認する観点が明確な時は「必要なものを必要な時に作る」を基本方針としています。必要かどうかは「ドキュメントを用いた情報整理が必要か」「誰とどんな合意を取りながら進めるべきか」と言ったところを勘案して決断しており、開発対象物やチーム・プロジェクトの状況に応じて適切な動き方をすることを重視しています。
その他「チームで品質保証」を実現するためにやっていること
実例マッピング
冒頭でご紹介したQA組織の行動指針についての記事でも簡単に紹介していますが、私が所属しているチームでも実例マッピング(Example Mapping)を導入しています。
実例マッピングでは開発がスタートする前にPdM ・PO・Dev・QAエンジニアが揃ってユーザーストーリーについて疑問点を洗い出し、解消していきます。こう言った活動からも品質リスクの軽減を目指しています。
私が所属しているチームでは、ロールに関係なくチームメンバー全員がサービス理解・ユーザーへの貢献に対してモチベーションが高く、仕様・デザインの共有の場では積極的に議論が行われます。プロダクト要求やデザイン共有の時点で、各ロールのフィードバックが行われ活かされていくと、その後の開発品質向上・不具合混入防止が見込めるのでとても有効です。
テスト実施状況・不具合抽出状況の計測
まだ導入して間もないのですが、バグヒット率(何件テストを実施し、何件どのようなバグが見つかったか)の計測を開始しました。テストの成果となる指標を中長期的に取ることで、「致命的な不具合がどれぐらい出ているのか」「QAエンジニアのテストでどれぐらい致命的な市場不具合を防ぐことができているのか」を可視化できる状態にしておくことが狙いです。どのような傾向が読み取れるのか不透明な状態ではありますが、まずは簡単に計測できるところから開始しています。
こういった傾向分析をチームの品質保証活動にフィードバックしていって、品質保証活動全体の質を向上していけたら良いなと思っています。
まとめ
私の所属チームでは、ここまでで説明したようなテストドキュメントを通して良い効果が出始めていますので、最後に少し紹介します。
例えば、テスト計画書レビューでは開発者とテストスコープやテストの仕方について議論する機会を作ることができています。開発者視点での品質リスクを出してもらったり、QAエンジニアから開発者に「こういうところはテストしておいて欲しい」といった依頼をしたり、効率的にテスト活動を行うための情報共有ができています。 PdMやPOにも同様の機会を設けているのですが、対象の開発案件で実現したいユーザーストーリーの認識を合わせたりテストの全体像を共有するだけではなく、プロダクトリスク・プロジェクトリスクといったリスク管理について議論をすることができています。リスク管理のところはPdM・POから良いフィードバックを得られることが多いです。 テスト要求分析レポートのチーム内QAレビューでは、特にテスト戦略のところでは議論が白熱することが多く、どの段階でどのような粒度でテストを行うか、どのようなテスト技法を使うかといったところを議論しながら進めることができています。
開発者・PdM・POそれぞれの得意領域で良いフィードバックをもらいながらテスト計画を改善し、テスト活動を実行していくことで「チームで品質保証」を実現していきたいと思っています。 ただ、今のテストドキュメントやテストプロセスが最善だと思っているわけではなく、チームの状況やプロダクトを取り巻く環境の変化に合わせて改善し続ける必要があります。テスト計画の内容は適切だったのか、計画通りにちゃんと実行できていたのかといったことを振り返るのがとても重要です。
今回ご紹介した取り組み以外にも行っている活動や、今後やりたいと思っていることもたくさんありますので、「もっと詳しく聞いてみたい！」と言う方は是非カジュアル面談の場でお話しましょう！
