10Xにおける目指すQAの姿とそうしたいワケ
2022/9/22
2020年5月にリリースしたStailerは、現在2周年を超え、またパートナー企業も日々増えていっています。
2022年4月に1人目のSETとして平田 敏之さん(@tarappo)が入社し、QualityチームのリーダーとしてStailerのQA（Quality Asuuarance）の管理・改善に取り組んでいます。10Xの1人目SETで、Quality Teamのリーダーでもあるtarappoさんに「10Xにおける目指すQAの姿」と、その理由について話を聞きました。
DeNAのSWETグループに所属しいろいろなプロジェクトや施策に携わる。 テストを広げるためにTest Nightなどの勉強会の設立や「iOSテスト全書」や「Androidテスト全書」を執筆。2022年4月より10Xに入社。2児の父で好きな食べ物は餃子。
QAチームのよくある姿と、10Xとのミスマッチとは
ーまず、一般的によくあるQAの姿とは、どういう状態なのでしょうか？
リリースされるまでの大雑把な流れとして、企画→設計→開発→テスト→リリース、となり、そのうちの「テスト」の箇所だけをQAチームが担当する、というようなスタイルの会社が一定あるかと思います。
下記の図でわかる通り、QAチームが「テスト」の部分だけを担うということは「リリース前の最後の砦」として存在するという状態ですね。また、QAチームが他チームとの関係性をもたずに独立化していることも多いです。
ー上記のようなQAチームが独立している状態というのは、何か問題があるのでしょうか？
上述したような独立したQAチームのあり方ですと、QAチームが開発チーム全体に対して「権威化」してしまったり、もしくは「下請け化」してしまうことがあります。そうなると、全社としての協力関係が欠落してしまったり、他チームの品質に対する責任感が薄れてしまったりするんですよね。
開発チームとしても「最後はQAに任せればいい」という気持ちが生まれてしまい、結果的に初期品質が悪化していくことも過去に経験があります。
ーその他にはどういった問題があるのでしょうか？
テストを行う工程が主に最後だけになることで、この「テスト」フェーズ自体がボトルネックになりやすくなることも挙げられます。
例えば、スケジュールの締め切りが変わらず、検証期間だけ短くなるというのはよくある事例だったりします。その場しのぎの対応として、メンバーを追加して、人数ありきでなんとかしようとする、という対策をすることもありますが、そのスタイルだと長続きしません。
なぜかというと、リリースをするために必要な人数がある程度必要になると、全体におけるQA人員のコストが高くなりすぎてしまうからですね。特にサービスを作り続けるスタイルの場合、なにもしなければQAコストは膨れ上がってきます。検証する内容を増やすことはしても、減らすということは「なんとなく怖くて」できないことがおおいですね。
また、障害がおきた際に、とりあえずその該当機能に対してテストケースを追加するという再発防止策をおこなうケースもよく発生します。バグは早期検出のほうがかかるコストは少なく、リリース前や後のバグ検出が多いと、結果としてQAコストによって利益の大半が消えてしまうことも普通にあります。
ー逆に、QAチームが独立している会社も多いと思うのですが、なぜそうしたスタイルを取っているのでしょうか？
QAチームが独立していることで、品質を守れる、と言われるケースもあるからだと思います。開発チームと近いチームにいることでどうしても、相手を忖度したり、データを改ざんしたりといったことが起きうることもあるので、あえてQAチームと開発チームに関係性を持たせないという体制にする組織もあります。
プラットフォームだからこそ、「守るべき品質水準」は高く
ー10Xの状況に適したQAのあり方は、どうやって考えればよいのでしょうか？
あるべき姿を考えるにあたっては、先ほどお話したような課題への対策だけでなく、10Xにおいて扱う「Stailer」というプロダクトのことについても考慮する必要があります。
Stailerは扱っている範囲が広く、そして「プラットフォーム」でもあります。Stailerというサービスが「プラットフォーム」として成長し続けていけば、toCの観点・toBの観点からもより幅広い人の生活を多方面から支えているものになってきますよね。「プラットフォーム」は強い責任を伴うもので、リリース後になにかしら動かなかったらすぐ直せばいいというスタイルはよくありません。
また、バグは軽微であろうが、その数が積み重ねれば関係者の信頼を失ってしまいます。また「軽微なバグ」が続くようなスタイルであれば、いずれかは「重大なレベル」の問題がおき、信頼を一気に失うだけでなく場合によっては誰かの生活をおびやかしてしまう恐れすらあります。1件の「重大なレベル」の問題が生まれてしまう背景には、それを積み上げてきた何件ものヒヤリハットがあることがほとんどなんですよね。従って、Stailerでは「守るべき品質水準」は高くしなければならないというのがあります。
しかし、リリースサイクルの速さ、QA人員のコストなどの課題、10Xの事業の永続性を考えると、QA独立型のスタイルで行うことは難しいだろうなと考えています。
10Xに必要なのは「QAという観点を持ち込んだ全員品質」
ーありがとうございます。それでは、10Xで目指すQAの姿について、教えてください
10Xで考えている、QAの目指したい姿は、次の図のとおりです。
これは、昨今話題にもあがっている「ホリスティックテスト」というもので、全体的な視点からテストを考え動いていくというものです。この中のステージは早く進むところもあれば、時間がかかるところもあります。場合によってはチームとして一旦停止して前のステージに戻る必要があるかもしれません。
同じように「チーム全体としてテストをしていくか」というものとして「Testing Manifesto」というものがあります。
（from：http://www.growingagile.co.za/2015/04/the-testing-manifesto/）
- 最後にテストするよりもずっとテストし続ける
- バグの発見よりもバグの防止
- 機能性をチェックするよりもチームが理解している価値をテストする
- システムを破壊するよりも最高のシステムを構築する
- テスターの責任よりも品質に対するチームの責任
参考：https://nihonbuson.hatenadiary.jp/entry/TestingManifesto
総じていえるのは、「早い段階で見つけられるバグは見つけてなくしてしまいましょう」ということですね！
ーなるほど。早い段階でバグを見つけるためにも、上記のようなホリスティックテストの体制が必要になるのですね。
10XにおいてはQAチームはすべてのステージならびにチームと関わりを持つ、「QAという観点を持ち込んだ全員品質」という姿を目指しています。
全員品質を目指すということは、どのステージにおいてもQAの観点を持ってテストを実施してリリース前の早い段階で課題を見つけること、そしてリリース後においても課題があれば早期に見つけることができるようにするということです。そして、結果として、トータルとして少ない工数で品質の良いプロダクトをリリースでき、プロダクトのリリース期間を早めることが出来ますし、開発体験も楽しくなると考えています。
関連Podcast：
#33 10Xの1人目SETが『全員品質』が大事だと考える理由【ゲスト：平田 敏之さん / ＠tarappo（Software Engineer in Test）】
「今、QAチームがやっていることは将来必要なくなる」状態を繰り返していきたい
ーこの姿をめざすにあたって、どのような取り組みを進めているのでしょうか？
現状、QAチームがすべてのフェーズに関わることはリソース的には難しいですし、求めている姿を進めていくにあたって一緒に進めてくれるメンバーの採用がすぐにできるというわけではありません。
そのため、①「各種分析の結果（不具合分析、本番障害などの定量的データ）や案件を通して得た定性的データなど」をもとにすすめるべきタスクのプライオリティを判断して粛々とすすめる、② この姿に向けてリードできる人の採用を進める、という2点を10Xとしてがんばっています。
また、QAチームとして関わる開発フローを拡大していっていますし、全社におけるQAの認知及びレベルアップも進めていっています。具体的には社内で「QA週報」という形で、QAがその週行ったことを社内に周知をしたり、新入社員にむけた「Onboarding」でQAチームのことについて話したり、「バグバッシュ」という、Stailer内のバグをチーム対抗で探すような社内イベントを実施したりもしています。
LegalのToshikiさんが参加された時のコメント。
チーム問わずさまざまなメンバーがバグバッシュに参加しています
全社への働きかけとは別にQAチーム内外の輪読会なども実施しており、メンバーのレベルアップの機会もつくっています。
ー最後にメッセージをお願いします！
今はまだまだ「目指す姿」においてやるべきことはいろいろとあります。また、QAチーム「だけ」ではできないことも多くあります。そこで、リソースやプライオリティを考慮しつつ、各チームとコラボレーションをしながら「目指す姿」に近づいていければと思っています。
現在の10XのQAの目指す姿はお話した通りですが、ソフトウェア開発やそれを取り巻く環境は日々変化しています。現在の「目指す姿」が将来の10XとStailerにおいて、最適な姿でなくなる未来があるかもしれません。しかし、この目指す姿をつくれる体制をつくっていれば、そうなる前に、次のあるべき姿を考えていける体制になっているとも思っています。
また、今進めていることのレベルを定期的に上昇させ「今、QAチームが主体的に行っていることは将来的に必要なくなる」状態を繰り返していきたいと考えています。つまり、定期的に新たなことに挑戦できるようにし、ワクワクするようにしたいです！
