先日行われた「求められるQAエンジニア」とは ‐ いとうよしきさん、tsuemuraさんに聞くキャリアの歩み方 - connpassにて以下質問をいただき、その場では時間の都合で回答はできなかったので、ここでお答えしたいと思います。

このほかにも、時間の関係でお答えしきれなかった質問については順次回答を記事化していきます。（ブログネタになるので大変ありがたい・・・

QAのプロジェクトふりかえり

このような質問をいただきました。

プロジェクトを振り返る時間が取れていません。QAエンジニアとして、どのような点を考慮して振り返りをしたら良いでしょうか？また、そのために必要なスキルは何でしょうか？

ふりかえり大事ですよね。

私自身も過去「ふりかえりをすべきだ！」と言ってふりかえりをして、成功したり失敗したり色々とありました・・・。

雑なお答えとしては、『ふりかえりガイドブック』おすすめです。過去に記事も書きました。

『アジャイルなチームをつくるふりかえりガイドブック』を読んだ - テストウフ

いろいろな手法が載っているのもそうですし、「チームが思考錯誤しながらふりかえりできるようになっていく」というストーリーが、おそらく質問者さんの状況に合うのではないかな、と推測します。

本を伝えて終わり、では味気ないので、私なりの回答も・・・。

前提

質問を拝見して、以下のような疑問をもちました。（※ダメと言っているわけではないです！Streamyardのコメント欄で、かつイベント中なので、細かい背景書くのは無理というもの。）

  • ふりかえりの参加者単位はどこまでか
    • 開発者やPdMなども含めた、開発に関わった皆のふりかえりか
    • そのプロジェクトを担当したQAエンジニアのふりかえりか
  • ふりかえりをしたい、という動機はなにか
    • バグが多いとか、プロジェクトの進め方に不満があるとか
    • あるいは「やったほうがいいよね」なのか

このあたりによっても若干回答が変わってきますが、一旦ここでは

  • 開発者やPdMなども含めた、開発に関わった皆のふりかえりで
  • QAエンジニア（たち）としてはプロジェクトの進め方になんだかモヤッているのでそれを他のロールふくめて認識・改善していきたい

という状況だと仮定します。

QAエンジニアとして、ふりかえりで考慮すべき点

これは私なりの考え方ですが、まず前提として「開発者はやることが多い」というのを理解してふりかえりに臨むとよいかなーと思います。

実際に開発マネージャーと雑談していて聞いたことなのですが、いまどきのソフトウェア開発においては「やるべきこと」とか「やったほうがいいこと」「ベストプラクティス」みたいなものが本当に多いんですよね。アジャイルがいいとか、TDDをやるべきとか、開発者はべき論を社内外でたくさん浴びています。

しかし、質問に「プロジェクトを振り返る時間が取れていません」とあるように、おそらくQAも開発もみなそれぞれに忙しい状況なのだと思います。

そういった中で、新しくなにかを追加したり、始めようというのは、かなりハードルが高いです。イネイブられたいと思っている開発者は居ない前提で動く - テストウフにも書きましたが、あちこちからイネイブられている開発者は全部はやっていられません。

なので、ふりかえりをすること自体や、ふりかえりによって出てきたアクションを実行することは、開発者にとっては「新たな負担」になってしまう可能性が高いです。

この前提でふりかえりを始めるのが大事なんじゃないかなと思います。

たとえば

  • 各ロールのリーダーだけでまずはふりかえりを始める
    • 全員の時間を合わせたり確保しようとしたりすると反発がありそう
  • 楽になるためにやる、という前提でふりかえりをする
    • やることを増やすためではなく、効率化・省力化のためにも大事だよね、という言い方をする

などが、心がけとしては求められると考えています。

ふりかえりに限らずQA活動全般に言えるのですが、色々と改善を試みると、プロジェクト全体としてはやることが増えるように見えてしまう場合も多いです。そうなると、そんな余裕はないとか、めんどくさいとか、やらない方向に力が働きます。

そうではなく、「プロジェクトを振り返る時間が取れないような日々を抜け出すために、一旦思い切ってふりかえりの時間を確保しようよ」というのを皆に納得してもらう必要があります。

わたしの例：開発チームでのテスト設計を勧めた

ふりかえりではないのですが、QA活動の一貫として開発者にテスト設計を勧めたときの話をさせてください。

私の所属する開発部門では、QAが少ないので基本的に開発者がテストも行っています。しかし、テストで何を担保しているのかがわかりにくい等の問題があったので、テスト設計を行うこと（正確にはテスト分析→テスト設計あたりを軽量なプロセスで行うこと）をオススメし、実際にそのようなプロセスに変えてもらいました。

それまではテストといえばExcelでテストケースを列挙して実行、というやり方だったのに対し、一度テストすべき点を列挙して開発チーム内で認識を合わせ、それから具体的なテストケースを書き起こす形になりました。

これは、単純にタスクだけで見るとやることが増えています。そのため、もし当時「こうすべきなのでこうしてください」だけでお願いしていたら、受け入れて貰えなかったと思います。

このときに説明したのが、“一度テストすべき点を列挙して開発チーム内で認識を合わせ、それから具体的なテストケースを書き起こす"という方法であれば、レビューがしやすくなって手戻りが減るので、結果的に楽になりますよ、という理屈でした。従来の方法だと、ずらずらーっと並んだテストケースをレビューしてヌケモレを指摘するのはそれなりに辛く、とくに開発チームのリーダーにとっては負荷がかかるタスクでした。この手のものは負荷はかかる一方で、開発者だけで「そうだテストプロセスを見直そう！」とはなかなかなりづらいですよね。

テストケースを書き起こすまでのタスクは一見増えるものの、その仮定でのレビューが楽になり、かつテスト内容の理解も進むため有効な指摘ができる→バグの見逃しが減る、といった良い効果が得られました。

先のふりかえりの話に戻ると、ふりかえり自体や、ふりかえりで出たアクションの実行についても、このように「一見タスクが増えるとしても、トータル楽になって余裕が生まれる」と思ってもらうことが、実行に移すうえで大事なことがと考えています。

必要なスキル

そのために必要なスキルは？に対するお答えとしては、やはりふりかえり自体もスキルなので、まずはそこから身につけていただくのが良いかなと思います。

  • ふりかえりの手法を複数知っていて、最適なものを選べる
  • ふりかえりの場のファシリテーションができる

などですね。

そのほか、「QAとしての」という点で行くと、やはり開発現場における課題解決の引き出しをたくさん持っていることが大事です。ふりかえりで出た課題に対して、QAとしてどのようなアプローチを提示できるか。プロセス改善、不具合分析、自動化、などなど。

これらは必ずしも経験があって上手にできて、という必要はないと思います。それこそ本で読んだでも他所で聞いたでもいいので、「＊＊＊ってのをやるといいかもしれないので、みんなでやってみようよ！」と言えるくらいのネタをたくさん持っておくこと、がふりかえりをするうえで大事なスキル、ではないでしょうか。

「忙しいからふりかえりできないよね」ではなく「忙しいけどふりかえりやらなきゃ」になるためには、やっぱり「やったらいいことがある」という実体験の積み重ねしかないと思います。それには、「QA込でふりかえりちゃんとやると、どんどん改善されていって、いいよね！」と感じてもらう。そのための引き出しの多さの確保、ですね。

以上、参考になれば幸いです。「そういうことじゃなくて・・・」等あればぜひ教えてください。