チームでテストをアクティビティとして捉えどこでもテストするまでの道のり

この記事は毎週必ず記事がでるテックブログ "Loglass Tech Blog Sprint" の65週目の記事です！
2年間連続達成まで残り41週となりました!

こんにちは、ログラスのQAをしているコタツです。一気に寒くなってきましたね。体調崩さないよう暖かくしてまいりましょう。今日はログラスにおいてどこでもテストを実践するために工夫していることをご紹介していこうと思います。

前提

ログラスのQAはアジャイルテスティングの考え方に基づいて、プロダクト開発チーム全体のQAケイパビリティを上げることをミッションとしています。
参考資料：
https://speakerdeck.com/kotatsu/8-mu-findy-wantimudesheng-tu-purodakutotimunozhong-denoqaenzinianohurumaishi-li?slide=33
ログラスにはQAが2名しかおらず、もう一名の方は別のプロダクトチームのQAをしています。私は一人で20数名程度の開発チームのQAをしていますが、QA一人で全ての機能開発を詳細に見て一緒に進めることは難しい規模感です。

いままで

プロダクトチームとしては、テストを早期に何度もやる・どこでもテストすることの説明を聞いて価値を理解はしているが、まだまだ引き出しが少ないことで実践に至らなかったり、タイミングを逸してしまうことも多い状況でした。
そんな中でもテストプロセスの一部のアクティビティは普及はしてきており、去年の年末のアドベントカレンダーではエンジニアがテスト設計と実装の関係性について考察する記事を書いてくれました。
https://zenn.dev/loglass/articles/b8b8b5688e91a2
テスト設計とテスト実装をして得られたロジックの抽象化をプログラミング実装にどう活かしていくかが主に語られている記事となっています。これは私の広め方・伝え方の問題が大きいのですが、当時は個別のテスト設計技法の導入は進んだが、テストプロセスの普及までうまく出来ていなかった状況でした。

シフトレフト/シフトライトの実践が難しい原因

テスト実施はもちろんしている、テスト自体のテスト分析・テスト設計の練度がまだまだで、高めていく必要がある。そして、シフトレフト/シフトライトの実践や、どこでもテストもしていきたいが、チームとして浸透しきっていない。そんな状況で、原因は複数あると思うんですが、私は「どのタイミングで何をすれば良いのかがわからないのではないか」と仮説を立てました。
ログラスのプロダクト開発チームは意識が高く、新しい手法やツールを誰かが提案したら即誰かが使ってみる・試みてみるような組織です。一方で、それができていないのは必要なインプットが足りない・もしくは足りていたとしても発動タイミングが判断できないのではと考えました。

解消するべく、プロセスごとに様々なやり方があることを伝えるためシフトレフト・カタログなるものを作ってみました。
※今回便宜上シフトレフト・カタログと書きましたが、シフトライトも含んでいます。

シフトレフト・カタログ

2023年8月版

上記のエンジニアが書いた記事と時期は前後するのですが、去年シフトレフト・カタログというものを作ってみたのがこちらです。

W字モデルをベースに何やらいろいろ各プロセスに吹き出しをつけて、具体例を書いてある図です。恥ずかしいのでモザイク強めなんですが、だいたいご想像どおりだと思います。
恥ずかしい理由は未熟でツッコミどころ満載だからです。そしてこの図が絶望的に流行らなかったからです。流行らなかった理由は深く考察していませんが、キャッチーさとわかりやすさが足りなかったように感じています。また、W字モデルはスクラム開発していたチームの実際のプロセスに当てはめづらく、どのタイミングで何をやるべきかの指針になりづらかったというのもあると思います。

ちなみに去年の夏時点、この図をお披露目したときのNotionを見ると、当時も同じような抽象度の高いプロセスにおけるテスト活動の不足について課題認識をしていたようです。

2024年9月版

最近ログラスはFASTというアジャイルフレームワークを用いて開発を行っています。FASTにはスクラムイベントのように定義されたイベントがありません。自分たちで各々考えて、シチュエーションに応じてイベントを実施するというような枠組みになっています。そのため、FAST導入当初から、スクラムチームのアクティビティとして行われてきた基本的な営み（例：リファインメント、受け入れ基準作成、プランニング、スプリントレビュー）をうまく実行できなくなる可能性を認識しており、危機感を感じていました。
FASTについての詳細はこちらです。
https://prd-blog.loglass.co.jp/entry/2024/09/12/181043
そこでシフトレフト・カタログを再度作ってみて、いつ・何をやるとより良い状態になるのかを示し、開発時のやることリストとして使えないかと考えたことが一年越しの挑戦に至った理由です。

今度はやっぱ普通に恥ずかしいのと、ここが論点ではないのでまたもや部分的にモザイクさせていただきました（ツッコミはもちろん大歓迎なのですが、受け止めきれる情報量のキャパシティに自信がないため、実際に会ったときに直接教えてください）
特徴としては以下です。

• 2023年度版はテストプロセスと開発プロセスが2つの線で表現されていたが、今回のものは開発プロセスが円、テストプロセスはすっ飛ばされてテストアクティビティとして雲のようなものの中に手法名が書いてある
• 意図、手段、成果物がそれぞれの雲の中に別れて記載されている
• 開発プロセスは戻ることもあると真ん中に書いている

このモデルは私だけで作ったのではなく、有志の皆さんとFASTの枠組みの中で作りました。以下はFAST第三部である、つぎのバリューサイクルでやることを決める際に行うマーケットプレイスにおいて、私が出したネタ（黄色い付箋）に対して3名も人が集まった図です。

なんだったら、私以外の皆さんの方のほうがノリノリで考えてくれたほどです。

ねらい

PdMやデザイナー含め、プロダクトチーム全員が以下のように行動することを狙っています。

1. 取り扱っている機能開発が今どこの開発プロセスなのか特定し、それに見合ったテストアクティビティはどのようなものがあるのか確認する
2. 開発プロセスに見合ったテストアクティビティのラインナップの中から、取り扱っている機能開発の性質と照らし合わせて、やっておかないといけないアクティビティはなにか？を考える

実践事例

「円環」などと呼ばれながらぼちぼち使われ始めています。使ってみた声を何個か紹介したいと思います。

• 実例マッピングをQAと一緒にやってみたデザイナーが感想を投稿してくれた様子↓
  
• エンジニアが要求・要件に対して、アクティビティを当てはめて実践しようとしている様子↓
  

課題

2023年版と比較したら2024年度版はかなりわかりやすくなっていると自分では思ったのですが、全然そんなことはないようで課題が何個もあります。

• 各アクティビティのやり方は記載されていないので、各々の制度は実践者に一任される
• 初心者には難しい
  • 沢山のアクティビティが書いてあるのでひと目で見渡せないので参照することに心理的ハードルがある
  • 知らない手法は自力で取り入れることが難しい（一緒にやってみる必要がある）
  • そもそも、シフトレフトやどこでもテストをなぜやるかについては表せていない
• 矢印で方向が書いてあるので、戻れないような気がする
  • 中心に「一方通行ではない」と書いてても、あんまり意識されない
• アジャイルテストの4象限のようなMECEさがないので、例えばチームを支援する方向性において今できるアクティビティが他にないか？不足していないか？という使い方はできない

まとめ、感想

去年は本当に流行って無くて、シフトレフト・カタログを実際に参照してみる人がいなかったので課題すら寄せられませんでした。今は少しづつ使われ始め課題が何個もでてくるようになり、本当に嬉しいです。
というのも一緒に作ってくれたエンジニア2名が発信の起点となり、周りのチームメンバーに使い方を伝授してくれているようです。うち1名はCREで、モニタリングにまつわる部分の推進(シフトライト)を特に進めてくれています。2023年度版は私1人で作ったため、ここは去年とは異なる部分で、何人かで作って本当に良かったなと思いました。このように、QAだけで考えるのではなく、何人かのエンジニア交えてプロセスを作ったから実用が進んだのではないでしょうか。

また、エンジニアだけではなくデザイナーやPdMにも活用が広がっていて、みんなで育てていきチームのナレッジとなるといいなと思っています。段々と以下のような事例も出てきています。

• 前述のデザイナーの方はカタログへアクティビティや補足を追加する活動もしてくれた
• インフラチームやアーキテクトの視点からもアクティビティが追加された
• あるエンジニアがFASTで全員が用いるツールの形にシフトレフト・カタログを構築し直し、使いやすく改善してくれた

このようにチームでプロセスのあるべき状態を定義したことで、2023年版のときに乗り越えられなかった「自分たちの開発プロセスに合わせてテーラリングする」ということも徐々にできるようになってきました。

最近はシフトレフトはしたがうまくいかなかった、これ以上シフトレフト出来ない、という話がチームの振り返りで上がり、「それはテストの練度が足りてないからでは？」という話に発展していました。その後、その場ではチームでテストをうまくやるためにどうしたらいいかをテーマに話し合うことができ、チームでの感度が上がっていると感じました。

今後

QAが少ないプロダクト開発チームにおいて、シフトレフト/シフトライトのためのアクティビティを一緒にやってみて見せてみることができる人は限られているため、カタログを作ったとしても一気に状況が変わるわけではありません。
前述した課題を解消し、至らない部分をチームのみんなで改善していきながら、できる人を増やして進んでいければ良いなと思っています。

ご質問や、アドバイスなどありましたらこちらからお願いします！
https://pitta.me/matches/QcmAxXmvnPpz

ここまで読んでいただきありがとうございました。