はじめに
はじめまして。with QAチームの@kiyou77です。
QAとしては現在3年目、withにも昨年12月にジョインしたばかりで、
最近ようやくつかまり歩きができるようになったばかりの新人です。
さて、今期のwith開発チームは、「ユニット制」とwith内で呼んでいる
新たな体制での開発にチャレンジしていました。
そんな中で、QAの動き方について悩むことが多く、特に
「上流工程でのQAって何をしたらいいんだ……？」
ということについて悩みながらも、自分なりに考え、いくつか気付きを得られたため、
今回はその考えや気付きについて書いていきたいと思います。
QiitaにはQA関係の記事があまり多くないように見えますが、
QA以外の方にもぜひ読んでいただいて、
QAってこういうことを考えているんだな〜というのを知ってもらえたらと思います。
新たな開発体制について
先に紹介した通り、今期からwithでは「ユニット制」と呼ばれる
新しい体制での開発が始まりました。
これはプランナー、デザイナー、エンジニア、QAが固定メンバーとして
1つのチームで開発を行っていくというものです。
ユニット制が始まるまで、withではアサイン制で開発を行っていました。
つまり、プランナーチーム、デザイナーチーム、
エンジニアチーム、そしてQAチームと分かれており、
プロジェクトごとに各チームのリーダーが
メンバーをアサインしていく、というものです。
（このセクション別の枠組み自体は、ユニット制が採用された今でも残っています）
しかしこの都度アサインという形式は、現在の開発チームの規模では
スケジュール変更に対する調整難易度や、コミュニケーションコスト
仕様把握等への認知負荷を高めてしまうなどの、いくつもの課題がありました。
そこでプランナー、デザイナー、エンジニア、QAがセットになったチームを作り
半期にわたって固定メンバーで開発を行うことで、上記の課題を解決することを試みました。
ユニット制による変化
ユニット制が導入される以前は、事前共有のあった施策と比べて
QAは他セクションよりも遅いタイミングで
アサインされることもしばしばありました。
というのも、多くのQAがそうであるように
リリース前のテストがQAの業務の中心であるためです。
当時のQAチームはリソースに余裕のある状態ではなく、
リリース前のテストだけでも手一杯だったと聞いています。
昨年、そんなQAチームに採用での人員増加が行われ、
チームとしてのキャパが大きく増加しました。
（そのタイミングでジョインしたうちの1人が私です。
そのためユニット制以前の状況はあくまで伝え聞いたもの）
そして、そのような流れの上で、ユニット制が始まりました。
ユニット制では固定のチームで開発を行うため、
これまでと異なり、仕様が定まる以前の工程から
QAが参加することが出来るようになりました。
増員によるQAキャパの増加に、体制の変化も相まって、
上流工程へのアプローチ、いわゆる「シフトレフト」の好機じゃないか！ と
肩を回しながら、自分はユニット制での開発に臨みました。
シフトレフトの好機！ だが事は急には進まない……
しかしながら、シフトレフトの好機とて、いざ真正面から向き合うと
その壁の遥かに高いのを感じることになりました。
というのも、ユニット制が始まっても、
自分の思っていたようには上流の中でアクションが取れなかったのです……。
これは全くもって当然のことなのですが、
QAが上流工程から関われるようになれば、それでもうシフトレフト！
となるわけではありません。
特にこれまで、QAが上流からしっかりと関わるフローでは開発を行っていなかったので、
QAとしても開発チーム全体としても、上流からのQAの関わり方が確立されておらず、
ゼロからこれを作っていかないといけませんでした。
QAなら誰でもそうと思いますが、
自分にとってもシフトレフトは、テストにおける最も基本的な概念であり、
かつ目指すべきものとして、常に意識して日々業務に勤しんでいました。
そのため、準備はできているもの！ と思い込んでいましたが、
いざその時が来て、こんなにも何もできないと思わず、
全ては思い上がりだった……と反省してしまいました。
しかし、チャンスであることには変わりありません。
QAの先人たちがネット上に様々な知見を残してくれていたので、
その地図をよすがに、自分なりに上流工程に道を切り拓いてみようと思いました。
新たな体制の中で考えたこと
開発体制が変わったとはいえ、
開発フローが急に変わるわけではなく、急に変えて良いわけでもないので、
道を切り開くといっても、いきなりQAの工程を増やすわけにはいきません。
そもそも何かしらはっきりとしたアイデアがあったわけではないので、
提案していくことすらできない状態でした。
そのため、自分としては
「まずはひとりで試せることをやろう！ 良さそうであればその成果をチームに持ち込もう！」
と考えて模索を始めました。
エニトグループには「信じて振りぬこう」という挑戦を是とするバリューがあります。
自分の参加したユニットは、皆さんこれを体現するようなメンバーだったので、
新たな取り組みであっても話を聞いてくれる信頼があり、
自分なりの手応えさえ掴めれば、あとは展開するだけ……！ と思っていました。
そんな中で、自分なりに上流で出来ることとして思いついたのが
静的テストと動的テストの、2方向からのアプローチです。
静的テストのアプローチ 愚直に仕様書を読む
シフトレフトの大目的は「作り込まれる前に欠陥を潰す」ということに尽きます。
そのため仕様書の中に考慮漏れや矛盾が存在しないか、とにかく読み込むことをしました。
これまで自分は、仕様書を仕様把握を行うために読んでいるところがありました。
そのように、単に書かれてある内容を理解するために仕様書を読むのと比べて、
仕様自体の妥当性を検討しながら読むことは、読み取れるものから全く異なる
ということを感じました。
例として、あるプロジェクトの中で、仕様書にメモされている実装方法を読んでいたとき、
「もしかしてこっちの方が実装方法として良いのでは……？」と思いつき、
それを提案してみたところ、実際にその方法が採用されることになりました。
自分としては、プランナーの経験もエンジニアの経験も別段なかったので、
まさか実装方法について提案することになるとは思ってもみませんでした。
しかし、専門的な知見がなかったとしても、
常識的な感覚だけで気がつけることが沢山あるということであり、
仕様書レビューの重要性を強く感じるきっかけになりました。
（もちろん同時に、専門的な知識が更にあれば、
もっと鋭い指摘ができるのだろうとも思いました）
こうした仕様書レビューは、いわゆる静的テストとして
シフトレフトのためのアクションとしては真っ先に挙がるものと思われます。
これに対して、動的テストについても何か上流工程からできる取り組みはないだろうか
とも考えてみました。
動的テストのアプローチ 品質合意に向けたアクション
動的テスト、つまりはリリース前に行っているテストにおいては、
テスト自体の妥当性を上げることが重要と思われました。
そのための方法として、テスト内容を早い段階でチーム全体に共有することで、
観点の抜け漏れを防ぐことができるのではないか、と思いつきました。
またそれ以上に、早い段階でテスト内容についての会話を行うことは、
どの機能がどれだけ重要なのか、という認識をチームですり合わせる
「品質合意」 に向けたアプローチに繋がると考えられました。
テスト内容を早い段階でチームに共有する方法として、
早々にテスト設計を行って、設計書に目を通してもらうことを考えました。
しかし、それを実行に移すことをイメージした時、
かなり問題がある方法だとも思いました。
まず、自分もテスト設計書のレビューを行うこともあるのでつくづく思うのですが
テスト設計書というのは、QAとしても読むのが大変なものです。
そもそもがテスト設計書というのは、
テストを正確に実行するために書くものであって、単に読まれるためにはありません。
更には内容としても具体的すぎて、テストの全体像が見えづらいものと思います。
もし自分がQA以外のメンバーとしてテスト設計書を共有されても、
きっと読めないだろうな（が故に読まないだろうな）というのを、
早めのテスト設計を行ってみたあとで思いました。
加えて、あまり早くにテスト設計を行ってしまうと、
仕様が変わったタイミングで設計書を修正しないといけない。
手戻りを減らすために自分が手戻りを引き受ける、
という形になっていて、本末転倒に思えました。
だったらどういったものを共有すれば良いのだろうか？
テスト内容のサマリーのようなもの？ それってどう書けば良いんだろう……？
そんなことを考えながら、
ヒントを求めてテスト設計の手法についていろいろ調べていたところ、
「ゆもつよメソッド」というテスト開発手法に出会いました。
ゆもつよメソッドはfreeeのQAマネージャーである
湯本剛さんが考案したテスト開発の方法で、
テスト分析を重要視することに特徴がある手法です。
ゆもつよメソッドの紹介記事を色々読んでいると、
「テスト分析の成果物を使ってチームでレビューを行う」とあり、
俺がやりたいのこれじゃん！！ となりました。
テスト設計をするにあたりテスト分析は必要な作業ですが、基本それを意識しないというか、
テスト分析をしようと思ってテスト分析をしたことは、自分は一度もありませんでした。
そんなテスト分析で成果物を出すこと（求められること）もまた当然ながらなく、
成果物を出しうる工程なのだとは思ってもみなかったため、大きな気付きが得られました。
テスト分析の内容を共有すればいいんだ！ と発見できたは良いものの、
いかんせん経験がないのと、ゆもつよメソッドにしても理解が難しいこともあって
実践に移すことは今期中には出来ませんでした。
もう少し勉強して、来期でチャレンジしようと思っています。
まとめ
今回の記事では、withの新たな体制について軽く触れさせてもらいつつ、
上流工程に関われるようになったQAが出来ることとして
まずは静的テストとして仕様書を誰よりも読み込むことと、
動的テストではテスト分析から品質合意の流れを作っていくことの
2つのアクションが可能であることへの気付きと、
その前後で考えたことについて書きました。
ここに書いたものは取り立てて画期的なものではないですが、
自分なりの模索の中でアプローチを見つけることができたのは良かったと思っています。
まずは勝手にやれる範囲の中で nice to have なアクションを探し、
少しずつ洗練させながらチームに開き、存在感を示していくことで、
QAの新たなアクションを must have に近づけていけたらと思っています。
……また、最後にもう少しだけ別の論点を付け加えると、今回考えたことは
あくまで「テストを中心としたものにすぎないな」と、後々になって気が付きました。
品質に対する考え方としては、
「テストによって欠陥を減らすこと中心の考え方」はわりあい旧来的なもので
近年は「ユーザーの要求に近づけているかどうか中心の考え方」が
アジャイル思想と共に流通しつつあるのではないか、と思われます。
いまwithの中では、よりアジャイルな体制に向かう機運が高まってきています。
そんな中で、品質についての考え方をアップデートさせるためのアクションも
QAとしては今後考えていかないといけないな、と近頃になって思い至りました。
なんというか、やるべきこと考えるべきことが山積みで気が遠くなりますが、
こんな風に道なき道を切り拓いていくことが、ある種QAとして
醍醐味なのだろうなとも思うので、これからも頑張っていこうと思います。