こんにちは、2021年7月に入社したDevBrandingのellyです。6月18日に配信した「freee Tech Night Online #12 〜スピード上げても、品質落とすな！QAの挑戦」の様子をご紹介します。freeeプロジェクト管理のQA担当uemuとエンジニアリングマネージャーnomuの二人に、スピードと品質の両立のための工夫について語ってもらいました。
uemu：写真右上 2019年9月入社。 約7年エンジニアを経験、その後は20年以上QA一筋。 freeeプロジェクト管理・freee人事労務のQA担当。
nomu：写真左上 2019年11月入社。 関西支社エンジニアリングマネージャー。 freeeプロジェクト管理の開発マネジメントを担当。
のぶじゃす (@noblejasper)：写真右下 ラジオパーソナリティ、2017年に中途入社 mixi、ソーシャルゲーム企業でソフトウェアエンジニアを経験し freee に。入社後はエンジニア→エンジニア採用担当→エンジニアと DevBranding を担当。 しゃべりたがり。声が大きい。
実装前にQAとエンジニアでテスト設計レビューを実施して抜け漏れを防ぐ
まずはスピードの観点から工夫していることはありますか？
uemu：いかにスピードを落とさずにリリースまでこぎつけるかで重要なのはやっぱり不具合が少ないことだと思います。いかに上流工程で不具合を潰すかということです。
freee はスクラムでスプリントごとに開発するというプロセスが主で、一般的な流れだと実装が終わったらテスト依頼が来ると思いますが、freeeの場合エンジニアが実装を始めると同時に QAもテスト設計を始めてます。実装の前にテスト設計を終わらせて、エンジニアとテスト設計レビュー会を開いて抜け漏れがないかを確認したり、こういうテストをするというのをQAからエンジニアに提示するようにしています。
リストを渡すだけじゃなくてエンジニアと読み合わせをすることによってここの実装が漏れてるかも、ちょっと確認しますねみたいなやりとりができています。逆にこういうテストも行ったほうがいいよってエンジニアから言われることもあります。
リリースする直前にテストするんじゃなくてこまめにテストケースが出てくるんですね、スピードと同時にクオリティも上がりそうですね。
uemu：実際、実装が終わってテストするっていう段階では、ほとんどテスト終わってるようなもんで手戻りとかも少なくなってますしクリティカルな問題というのはなかなか出ないです。不具合も少なく済むし結果的にリリースが早くできています。
エンジニア側からレビュー会が面倒くさいとか、最後にまとめてテストしてほしいみたいな意見っていうのはないんですか？
nomu：そういった意見はあんまりなくて、むしろ開発した機能のテスト設計レビューを早くしてほしいという意見のほうが強いと思います。
最後にまとめてどかんとテストしたら、この仕様お互い勘違いしてたよねとか、こういう不具合もあるよね、とか後から色々出てきて、リリース直前にいっぱい起票されたチケットを泣きながら対応することになる・・・それよりもやっぱり順々にできたところからテスト設計して、観点をすり合わせて足りないところは実装して、というふうにやっていったほうが最終的にやることは減るという感覚があるので、自然にみんな受け入れていると思います。
新しく入ってきたメンバーでも抵抗感はないんですか？
nomu：あまりないと思います。1回やるとそのメリットがすぐ分かると思うんですよね。 テスト設計レビューというかたちで、具体的なテストケースを起こす前にテストの設計内容を読み合わせする会があるんですけど、そこで得られるものが大きいです。こういう実装観点あるよねとか、この仕様だったらこの実装も必要だよねとか。気づいてなかったけど実装しなきゃいけないポイントをエンジニアが気付かされるシーンが多くて、そのことに気付くとこのやり方は有用なんだっていう感覚を持ちやすいんだと思います。
リリースから2スプリント以内に影響の小さいバグも消化、自動テストとE2Eでの操作テストでカバレッジ90%を維持
次は品質観点での工夫を教えてください。
uemu：テスト後にもバグは出るんですけど、さっきのような取り組みのおかげで重要なバグはあまり出ないのでその段階ですぐにリリースとかも出来ちゃいます。あとお客さんに影響がないようなバグであっても、それを残すと将来的にそのお客さんから指摘があるので、freeeプロジェクト管理の場合、リリース時には直さなかった不具合っていうのも2スプリント内に全部消化するというルールでやっています。
だいたい1スプリント1週間なので、リリースして2週間で基本的に綺麗な状態になっていて、あとはもう運用フェーズってことなんですね。それはすごい。エンジニア側はどうですか？
nomu：エンジニアチームとしては、いわゆる自動テストに力を入れています。二つあって、一つはいわゆるspecです。コードで書くテストケースのメンテナンスは常にやっていて、いまだいたいカバレッジ90%を維持してます。
リリースから１年ちょっと、90%を維持しているのはやばいっすね！
nomu：そうなんですよ、多分この規模のプロジェクトで90%維持できているのってなかなかないと思います。当初から90%を目指そうと合意をとって開発・リリースしたので、初期状態が高くなっててそこから下げられないんです。下げるとかっこ悪いし（笑）毎週スプリントレビューでそのカバレッジを確認して落ちてたらなんでやねんって話をします。
もう一つはE2E（End To Endテスト）というのをやっていてSeleniumというWEBブラウザの操作をシミュレーションするツールを使って画面の操作をテストしています。基本的にはuemuさんに作ってもらっているんですが、エンジニアが画面を修正するときにはあわせてE2Eも修正し回ることを確認してから機能を出すようにしています。
E2Eの修正もエンジニアが対応するんですね、それは大変じゃないですか？さっきからエンジニアが大変じゃないかという話ばかりしていますが（笑）
nomu：これも先ほど同じで、トータルでやること減るってことなんですよね。 フロントエンドにしろバックエンドにしろ、軽い気持ちで入れた修正がすごい問題を引き起こすことがあるんですよね、一行変えたら壊滅的なことが起きるみたいな。
そういったことに気付けるようにE2Eテストにも力を入れています。E2Eを実行することで、実機ベースとは言わないまでも動作ベースで確認することができるんですよね。しかもそれがステージング環境にデプロイするたびに自動で実行されるので、致命的な不具合を起こしても本番環境に出る前に気づくことができるんです。早めに気付くことで結果的にやることが減るので、エンジニアにとってもすごく意味がある仕組みになっていると思います。
スペックとかテスト書くのってしんどいじゃないですか。チーム内で当たり前にそれをやる意識付けをするために工夫していることはありますか？
nomu：カバレッジやチケットの消化率は OKR にも入れてみんなで追いかける指標なんだよっていう合意をとって進めています。あと、元が高い分下がると恥ずかしいのでそこはなんとかしようっていう流れになってます。どのPullRequestで下がったかも調べれば分かるし、調べる人がいます（笑）
毎日デプロイしても欠陥除去率95%、不具合報告は約10件
取り組みの結果で定量的に良くなった部分はありますか？
uemu：品質に関しては欠陥除去率っていうのを出しています。要はどのくらいの不具合をリリース前に除去できたかという割合なんですけど、お客さんから不具合の報告があるとだんだん下がってきますし100個のバグのうちリリース前に50個見つけられたら50%みたいな指標です。
freeeプロジェクト管理に関していうと95%くらいで、5%は漏れてるけど95%は止めてるっていう状況です。品質ってSaaSだとだんだん落ちてくるんですよね、最初は当然使う人も少ないですしバグの報告も少ないんですけど、1年くらい経ってユーザーが増えてきて、それでも5%ぐらいしか落ちてないということはそれなりに品質を保てているということだと思います。
一般的なサービスで1年ぐらい経った頃の欠陥除去率ってどれくらいなんですか？
uemu：販売しているアプリケーションだと90%くらい、医療系とか軍事系になると当然ですが99%くらいです。そういうところと比べても比較的高い数値なので、今後の課題としてはこれをいかに下げないかっていうところですね。
そこで重要なのがさっきお話したような負債をためていかない仕組みづくりです。 お客さんからの問い合わせがあると別の作業やらなきゃいけないので生産性も当然落ちていきますし。
エンジニア側はどうでしょう？
nomu：定量的な話で言うと、この1年でだいたい40機能ぐらい追加機能を出せています。月に3-4件はコンスタントに出し続けてる状況です。いっぱい機能を作ってると不具合もいっぱい出るんじゃないかと思うと思うんですが、こういう取り組みをしているおかげで品質は高い状態を維持できています。欠陥除去率は95%程度ですし、外部から指摘されるような不具合も1年で10件程度と低水準になっています。
もちろんfreee内の他のプロダクトと比べてユーザー数が少ないので単純には言えないですが、それでも10件は絶対値としては少なく、結果として開発に割ける時間は多くなってます。不具合や障害が起きるとその対応に割り込みで時間を割かなきゃいけないし、突発的に起こるから計画が狂ってしまいます。そういう状況があまり発生せず開発に集中できる環境になっているため、年間で40機能という数のリリースができたのだと思います。
リリースの頻度とかPullRequestの数はどのくらいなんですか？
nomu：１デプロイで機能出しているわけじゃないので単純に言えないところがあるんですけど、デプロイ回数でいったら1年間で200回弱やってますね。 1年間の営業日がだいたい240日程度でかつ金曜日はデプロイしてないのでほぼ毎日ということになります。
品質改善を定期的に実施する仕組みづくり
品質改善に対して意識的に投資していることってありますか？
uemu：自動テストみたいなところを拡充していくっていうのはコンスタントにやっていて、できるだけ手でやる部分は減らしてます。あとは大きくなるとパフォーマンスが悪くなることがありがちなのでそういったところもケアを考えていて、エンジニアがあげたプルリクの中身もQAで割とチェックをしていて、この辺はやっぱりテストしたほうがいいんじゃないかっていうのは自発的に見てます。変なコードが入らないように監視役的な役割もやったりしてます。
nomu：スプリント中の取り組みでいうと日番（ニチバン）っていうのがあります。神戸の方言でいわゆる日直なんですけど、割り込み当番みたいな意味合いです。日番になった日は普段の機能開発をせず、不具合や問い合わせの対応をおこなったり、改善チケットとして積み上がっているものを消化していったりということに集中します。担当を明確にすることで、日番担当じゃない人は機能開発に集中できる状況を作っています。そうすることで、日頃から負債を残さないようにしつつ、開発スピードを落とさないという工夫をしています。
551スプリントっていうのもやってると聞きました。
nomu：独自ワードが出てきて恐縮です（笑）日番はスプリント内で対応していく人を日毎に立てるってスタイルなんですけど、551の方はスプリント丸ごと全員で改善するというものです。今だとだいたい2-3カ月おき、大きな機能開発が終わった後に1週間ほど改善の時間を確保しています。551でどういう改善に取り組むかをみんなでリストアップして、それをみんなでワーッと直してます。その時はチームも結構ごちゃまぜで、やりたい人と一緒にチームを組んで改善をしていく感じです。
551スプリントの時は新規の開発は動かないんですか？
nomu：動かないです。
勇気がある！肉まんの551なんですか？
nomu：さすがですね、それも意識しつつ語源としてはGo Go 1スプリント改善です。
uemu：無理やり（笑）
QAとエンジニアの情報格差をなくし一体感を持って開発する
組織全体でうまくこのような取り組みを回していく秘訣ってなんですか？
nomu：QAとエンジニアの一体感を作っていくことがすごく大事かなと思ってます。 QAの人はエンジニアにとって敵じゃなくて、すごく頼りになる仲間だと思って、one teamで開発していくんだという気持ちを持つことが大事かなと思っています。
実際、私はuemu さんと毎週のように1on1をしていて、そこでテストのやり方変えてほしいと言う話をしたり、逆に開発にこういうのやってほしいと言われたり、忌憚なく意見を言い合っています。その関係性が、品質面でのいろんな施策をやっていける土壌になっているので、そういう信頼関係を築いていくのが大事なことだと思います。
一体感を維持するために何か意識していることとかありますか？
nomu：朝会や機能開発MTGみたいな要所要所のMTGには基本的に一緒に出てもらってます。あとからまとまって情報だけぼんと渡すスタイルじゃなくて、その議論の過程だったりとかどういう変遷を経て今の状態になっているのかみたいな過程も含めてすべて共有してます。
情報格差なくコンテキストがちゃんと共有される状態でQAとエンジニアが伴走していくってことですね
uemu：このプロジェクトは大阪・名古屋・東京でやっていて、私は東京で離れている状況なんですが、いまはコロナで行けないけど、定期的に一緒にご飯食ったりとかっていうようなコミュニケーションを結構大事にしてるしMTGには常に入って最初の段階からエンジニアと同じ情報を持って格差のない状況ができているのは大きいですね。
今後も一体感を持って品質とスピードを両立してfreeeプロジェクト管理がもっともっと多くの人に使われるようにしていきたいですね！
イベントの本編はここまでです。この後は「アフタートーク」でより深い技術談議が繰り広げられました。
