こんにちは。@tak_koheiです。このエントリーは、エムスリーキャリア Advent Calendar 2023の4日目です。
私たちは開発エンジニアとQAエンジニアがより近い距離で共働するエンジニア組織で活動しています。その中でも、実装完了直後（テスト実行開始直前）のタイミングで、開発エンジニアとQAエンジニアが設計/実装/テストについて雑談する場を作って『QAセッション』という名称で運用したときの事例をご紹介します。
活動を進める上で大切にしたポイントや実践してみて感じたメリットなどについて言語化してみました。特に「開発エンジニアとQAエンジニアで協力して開発を進めたい（けど具体的に何をしたら良いかわからない）」といった要望をお持ちの方の参考になれば幸いです。
きっかけ
始まりは開発エンジニア1名とQAエンジニア1名（私）の2人で構成される小さな開発チームが結成されて間もない頃でした。QAエンジニアとして自分自身の関与する領域をより上流工程へとジワジワ広げつつあった時期に、開発エンジニアから何気ない相談をいただくところから始まりました。
この手の場作りは、これまでどちらかというとQAエンジニアである私から開催をお願いすることが多かったのですが、この時は開発エンジニア起点で提案をしてもらえたのが非常に嬉しかったのを今でも覚えています。
相談を重ねながら開発プロセスの中に開発やテストの内容について雑談する仕組みを組み込んで、それを「QAセッション」と命名して運用を始めました。
QAセッションとは
実施方法
システム開発の案件ごとに、設計/実装/テスト観点/懸念事項などについて開発エンジニアとQAエンジニアが直接会話して意見交換します。対象案件の規模は数週間程度のものが多く*1、案件の規模に関わらず１回の所用時間は30～60分くらいです。
開催タイミング
QAセッションを開催するタイミングは、開発エンジニアが実装を完了した時点で、第三者の開発エンジニアがコードレビューを実施している間です。また、QAエンジニアはテスト設計を完了させ、テスト実行が開始できる状態になっている前提です。
ごく短い期間ではありますが、QAエンジニアにとってはコードレビューで改修が入る可能性があるのでテスト実行は開始できず、開発エンジニアにとっては実装が完了している、というスキマ時間を利用して開催していました。
会話の内容
最初はユニットテストの実施内容を説明してもらって雑談するだけの内容から始まったのですが、回数を重ねるたびに話題はお互いが興味のある内容にどんどん広がっていきました。そして、開発視点とQA視点それぞれが話題を提供するような形になり、最終的には以下のような話をするようになりました。
設計実装について（主に開発視点の話題）
- 最終的に仕様はどう確定したか（改めて最終確認）
- データや処理の流れ、通信のタイミング、がどうなっているか
- 処理が共通化されている箇所があるか（それはどこか）
- 複雑な処理になっている箇所があるか（それはどこか）
- ユニットテストのテストパターン（深さ、広さ、網羅性）
テスト観点について（主にQA視点の話題）
- 全体の機能的な確認視点（テストパターンや期待結果の確認方法など）
- 条件やパラメータの組み合わせがある場合、どこまでテストする必要があるか
- 省略可能なテストはあるか（そのまま鵜呑みにはしないけど）
- テストの手間が大きい時に楽にテストする方法が他に無いか
懸念事項について（開発/QA両者視点からの話題）
- 変更されていないように見えて実は手が入っている箇所が無いか
- 仕様の考慮漏れがあるとしたらどの辺りにありそうか
- もし万が一発生したらダメージの大きい障害はどんなものか
- リリースや運用に対する懸念（DBマイグレーションの影響についての懸念、バッチ処理とリリースのタイミングで起きそうなトラブル、など）
メリット
QAセッションを開催することによるメリットをまとめてみました。開発エンジニア視点のメリットについては、一緒にQAセッションの取り組みを進めてくれた開発エンジニアのかたに感想をいただきました。感謝。
開発エンジニア視点
テスト中に欠陥が検出された場合の対処がスムーズになる
- 事前に仕様や懸念点を共有することで準備ができる
- 特殊な仕様やその背景などロジックレベルでしかわからない点を伝えられる
全体の品質が高められる*2
- QAセッションで伝えるべきことを事前にまとめることで気付きにつながる
- ユニットテストの不足を解消したり、動作確認でバグを潰せたり、コンフルを充実させたりできる
QAエンジニア視点
テスト観点を精錬できる
- ロジックの変更箇所を理解してテストを考えられえる
- テスト条件やテストデータを具体化できる
- 気付いていないテスト観点を補完できる
テストの重み付けを工夫できる
- 複雑な仕様や実装箇所を優先的にテストできる
- 起きそうな不具合を想定したテストが早めに実施できる
- ユニットテストの担保範囲をふまえてテストの濃淡が調整できる
多様な視点で懸念事項を洗い出せる*5
- 機能改修が及ぼす影響を認識できる
- リリースの際の注意事項を意識できる
- 前後にリリースされる他の改修の影響も考慮できる
大切にした３つのこと
QAセッションを実践するにあたってのポイントや気を付けていたことは以下の通りです。
その１：QAセッションの目的や方法の認識を合わせる
まず１つ目は、QAセッションの運用を始める前に、その目的や実施方法について開発エンジニアとQAエンジニアでお互いの認識を合わせたことです。
目的
- QAセッションを通じて何を得たいか
- どんなことができたら嬉しいか
- 敢えて目的に含めないようにすることはあるか
方法
- いつやるか
- 何を準備するか
- どんなことを話すか
- どんなことは話さないか
QAセッションを実施することで何を得たいのかを明確にしたり、そのために「やること」と「やらないこと」を事前に認識合わせするところが重要だったかなと思います。
その２：活動を定期的にふりかえって改善する
2つ目は、定期的にふりかえりをして、QAセッションで行っている会話の内容について精査をし続けたことです。開発案件ごとにリリースし終えたタイミングでふりかえり会を開催していたので、その中でQAセッションがどうだったかについても話題に挙げて改善をしていました。
QAセッションのふりかえりポイント例は以下の通りです。（書き出してみたらなんとなく緩いKPTAになってたのかなと後から感じました）
KEEP：どんな内容の会話が有効だったか
- 会話して良かった/助かったのはどんな内容だったか
- 会話の内容がQAセッションの目的に合致していたか
PROBLEM：逆に、今後はしなくてもよい内容の会話はあったか
- やってみて実りが少ないと感じた会話は無かったか（どんな会話だったか）
- QAセッションの開催目的自体を見直す必要は無いか
TRY：次回のQAセッションではどんな話をすると良いか
- 抜け漏れを検出したり新しい気付きを得られるのはどんな切り口か
- お互いのヒントになりそうなのはどんな話題か
ACTION：次回のためにお互いどんな準備が必要か
- 次回のQAセッション開催までに集めておく必要がある情報があるか
開発とQAの二人がお互い気にしていたのは「限られた時間の中で本当に価値のある会話ができていたか」という点です。QAセッション自体はやる前から「コレきっと楽しいよねー」がお互いの共通認識としてあったものの、「楽しいだけで実が無い時間の浪費はしたくない」というのもお互いの共通認識でしたので、少し厳しめにふりかえりをしていた気がします。
その３：QAセッションだけに依存しないよう注意する
3つ目は、全てのコミュニケーションをQAセッションに集中させないように、常に何かあればお互いやりとりを絶やさないようにしていたことです。
コミュニケーション方法は主にSlackでの「つぶやき」です。対面での相談も適宜行っていましたが、思いついた時点でSlack上で雑にでもつぶやいておいて、つぶやいた方が後から補足を入れたり、つぶやかれた方がフォローしてコメントを返したり、というやりとりで可能な限り溜めこまないようにしていました。
以前、別のエントリーでも書いた「違和感に気付いたらすぐに共有」の実践です。
その後
2人で始めたQAセッションですが、現在はこの取り組みの事例を組織全体に展開して実践しています。ただ「QAセッション」って用語自体は殆ど使われなくなりました。特に意識せず開発エンジニアとQAエンジニアが常にインタラクションするのが当たり前になったから、でしょうか。共有の実施タイミングも特に実装完了直後に限定することなく臨機応変に行われているようです。特別な取り組みとしてではなく組織の文化として根付くことが一旦のゴールなのかなと思ってます。
当時QAセッションの開催を提案してくれて、一緒に改善を進めてくれている開発エンジニアK氏に、この場を借りて深く感謝します。
以前、本で読んだ憧れの世界に少しでも近付けるように、これからも活動していきたいです。
www.oreilly.co.jp ja.wikisource.org
皆さまの困難なソフトウェア開発の中にも、小さな幸せがどうか訪れますように。
最後まで読んでいただきありがとうございました。
