こんにちは。エンジニアグループQA （Quality Assurance） チームの中塚です。
この記事はコンシューマーチームブログリレー 2日目の記事です。QAエンジニアがリスク洗い出しをサポートする取り組みの事例をご紹介します。
はじめに
エムスリーでは、チーム全員で品質保証に取り組む考え方のもと、QAエンジニア以外のメンバーも品質保証に積極的に取り組むチャレンジをしています（この取り組みを社内では「全員QA」と呼んでいます）
ちなみに取り組み内容についてはこちらの記事でより詳しく紹介しておりますので、ご興味のある方はぜひ読んでいただけますと幸いです。
この取り組みには次のような狙いがあります。
- 開発と品質保証を担当エンジニアが一貫して行えることでリリースを早くできる
- 今はQAエンジニアのフルアサインができていても、将来的に新プロジェクトの立ち上げ時にアサインできる余力がなくなる可能性があり、QAエンジニアの関わり方に柔軟性を持たせたい
一方で、一般的にはテスト設計・テスト実施などの活動をエンジニア自身が行うと、実装の正確性や機能の「作り」の視点に意識が集中しがちで、他機能への影響やビジネス・運用といった俯瞰的な観点が抜けやすいという共通の課題があります。
コンシューマーチームではこの問題に対応するため、リスクを主軸にざっくばらんに議論する場を設けることでこの問題に対応しました。
本記事では、その中で得られたナレッジを共有します。
きっかけ
前述のように、コンシューマーチームでも担当エンジニアが主体となってテスト設計やテスト実施をしています。
エンジニアがテスト設計・実施を行い、QAエンジニアはテストケースのレビューやテストに必要な観点のテンプレート整備などで支援し、全員QAを推進しています。
この体制でのコンシューマーチームでの品質保証活動は概ね大きな問題無く進んでいましたが、しばらく続けると、一般的でないユースケースやエッジケースの考慮漏れがQAエンジニアのレビューで検出される機会が多いことに気づきました。
この問題について振り返りで意見を出し合うと、次のような課題が浮かび上がってきました。
- 改修箇所以外の機能の考慮が難しい。影響が多岐に渡るような機能だと気づきづらい
- 特に歴史の長いプロダクトだと、古い機能の詳細な仕様が一部メンバーのみの知見になっている
- エンジニアQAでは処理内容やパラメータの受け渡しなどに関心が行きがちで、他機能やビジネス、ユーザへの影響への考慮といった俯瞰的な観点についてはQAエンジニアの視点が欲しいが、テストケースのレビュー時ではQAエンジニアも気付きづらい
これに対応するため、詳細な仕様やQAエンジニアの知見についてのドキュメント整備、テスト観点のテンプレート作成などを進めましたが、ドキュメントが増えるとメンテンナンスの手間も増えます。また、そもそもこのようなドキュメントは能動的に探そうとしないと見つからないので、考慮から漏れていると参照されることもありません。
更に私は複数プロジェクトを掛け持ちしており、単純にテスト設計・実施をサポートする時間を増やすことで解決するのは難しいという背景もありました。レビューにあたってもドメイン知識、改修内容の読み込みが必要となり、いくつものプロジェクト、開発を並行で、更に精度高く漏れなく見ようとすると負担も大きくなっていきます。
工数をかけずにすぐできて、しかも拾いきれない見落としを効率よく拾えるような取り組みは無いだろうか？
そこで、リスク洗い出しを目的として30分のミーティングを実施してみました。
やったこと
関係者を集めてリスクについてざっくばらんに話し合ってもらいます。
この会では、実装が本格的に進む前に見落としがちな非機能要件やビジネス面・運用面のリスクをチーム全体で洗い出すことに集中します。
とはいえ、真っ白なドキュメントを前にして「さぁ自由に話し合ってください！」というのも発言し辛いと思ったので、ある程度話題の種になりそうなものを用意し、マインドマップに追記していく形にしました。
このような見出しを順に追い、気づきや懸念点を自由に発言してもらいます。
- 絶対に必要なもの
- 欠けてはいけないもの
- 期待される機能
- 複雑な機能
- 起きそうなトラブル
- 起きそうなユーザへの不利益
- 将来的なスケーリングの予定
- 不安
- 絶対起こしたくないトラブル
- etc…
実装面の深堀りはエンジニア同士の議論で十分行われていることが多いので、この会では業務フローやユーザの利用状況、運用開始後に起きそうな問題について話し合うようにしました。
すると、機能面以外の観点でこのような問題を洗い出せました。
- ユーザからの問い合わせサポートをどの部署が担当するかの打診が必要なことがわかった
- アカウントの用意に特殊な準備が必要で、アプリリリースの審査申請時に対応が必要と判明した
- ビジネス上の都合で定期的に短時間内での大量のアクセスが発生していることが会話の中で共有され、近くその対応が必要になることが明らかになった
視野を広げて会話する機会を持つことで、開発チーム以外との調整が必要そうな見落としや、共有されていないトラブルの種に気づくことができました。
工夫
それぞれの知見を利用し、より専門的な深堀りや洗い出しにも繋げたいため、可能なら検討会には様々な立場の関係者に出席してもらうようにしています。
多くの視点から多角的に考慮漏れを検出できるほか、今まで暗黙の了解とされ、共有されていなかった知見が出てくることが多いです。
また、QAエンジニアだけがレビューする場合よりも、より専門的な知識を持ったメンバーにより細かい気付きや深堀りがされ、効果的なレビューになるように思います。
また、話す内容として要件定義や設計、実装の担当の立場から漏れがちな観点について積極的に議論するようにしています。
特に、プロダクトや機能がどのような目標を持ちどのように使われるのかについては議論済みだとしても改めて議題に出すと良いでしょう。要件定義及び設計時に十分検討されていることがほとんどですが、使われ方の認識統一のためにも改めて話題に出しリスクの洗い出しの前提となる価値観をあらかじめ共有することで、集中して議論できます。
また、プロダクトの目標にあらためて視点を向けることで、認識していなかったステークホルダーや、注意を要する性能要件、共有されていなかった運用上の懸念、ビジネスのPDCA上取るべきログ要件などの洗い出しにつながることもあります。
まとめ
このミーティングを行うことで、リスクの洗い出しだけでなく、機能開発中に見過ごされがちなプロジェクト全体の視野を取り戻す機会を作り、また、対話を通じてチームの知見を引き出すことができました。
機能を作り込むうちに意識が細部に集中してしまいがちですが、大目標を再確認しながらオープンに議論する場を設けることで、それぞれの専門的な知見を活かし、チーム全体の視点からリスクを捉えることができると考えています。
We are hiring!
エムスリーではQAエンジニアを絶賛大募集しております。 興味がありましたらぜひご応募ください！
