スピードを上げても品質を落とすな!QAの挑戦

こんにちは、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%を維持

次は品質観点での工夫を教えてください。

QA歴20年以上のuemuさん 最初にやったのはwindows95のアプリのテストだったそう
QA歴20年以上のuemuさん 最初にやったのはwindows95のアプリのテストだったそう

uemu:テスト後にもバグは出るんですけど、さっきのような取り組みのおかげで重要なバグはあまり出ないのでその段階ですぐにリリースとかも出来ちゃいます。あとお客さんに影響がないようなバグであっても、それを残すと将来的にそのお客さんから指摘があるので、freeeプロジェクト管理の場合、リリース時には直さなかった不具合っていうのも2スプリント内に全部消化するというルールでやっています。

だいたい1スプリント1週間なので、リリースして2週間で基本的に綺麗な状態になっていて、あとはもう運用フェーズってことなんですね。それはすごい。エンジニア側はどうですか?

nomu:エンジニアチームとしては、いわゆる自動テストに力を入れています。二つあって、一つはいわゆるspecです。コードで書くテストケースのメンテナンスは常にやっていて、いまだいたいカバレッジ90%を維持してます。

リリースから1年ちょっと、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さん QAチームとの仲の良さが伝わってきます
終始笑顔のnomuさん QAチームとの仲の良さが伝わってきます

nomu:定量的な話で言うと、この1年でだいたい40機能ぐらい追加機能を出せています。月に3-4件はコンスタントに出し続けてる状況です。いっぱい機能を作ってると不具合もいっぱい出るんじゃないかと思うと思うんですが、こういう取り組みをしているおかげで品質は高い状態を維持できています。欠陥除去率は95%程度ですし、外部から指摘されるような不具合も1年で10件程度と低水準になっています。

もちろんfreee内の他のプロダクトと比べてユーザー数が少ないので単純には言えないですが、それでも10件は絶対値としては少なく、結果として開発に割ける時間は多くなってます。不具合や障害が起きるとその対応に割り込みで時間を割かなきゃいけないし、突発的に起こるから計画が狂ってしまいます。そういう状況があまり発生せず開発に集中できる環境になっているため、年間で40機能という数のリリースができたのだと思います。

リリースの頻度とかPullRequestの数はどのくらいなんですか?

nomu:1デプロイで機能出しているわけじゃないので単純に言えないところがあるんですけど、デプロイ回数でいったら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プロジェクト管理がもっともっと多くの人に使われるようにしていきたいですね!

イベントの本編はここまでです。この後は「アフタートーク」でより深い技術談議が繰り広げられました。

▶今回のイベントのアーカイブ(録画)


www.youtube.com

▶freeeプロジェクト管理のプロダクトについてはfreee technight#4で詳しく話しているのでご興味ある方はこちらから


www.youtube.com

転職したばかりのエンジニアが活躍するためにやったこと

勉強会の開催風景

こんにちは、2021年4月に40代で中途入社を果たしたエンジニアの okoshi です。

freeeでの働き方について興味のある方は是非ご一読ください。

中途で入社してはや4ヶ月経とうとしています。時間がたつのは早いものです。 とはいえ、まだまだ業務への慣れは感じないし、毎日のように業務の進め方や考え方に発見があります。

これまで何度か転職の経験があるのですが、転職した直後は毎回意識していることがあります。 それは“どうやったらすばやく活躍できるようになるのか”ということです。

これからfreeeに転職したいと思っている方、あるいはすでに就職することが決まっている方は是非参考にしていただきたいと思っています。

今回の転職は入社前からどうやって活躍するかをいつもより強く意識した転職になりました。 というのもこれまでの転職ではうまくいったこともあればそうでなかったこともあって、どのようなことが効いていたのかを思い返しても決定的な理由がわかならなったからです。

そのため、転職するに当たって仮説をたて確度の高そうな仮説の検証となるように行動してみました。

その仮説とはエンジニアの文化への順応を意識して行動できると活躍できるというものでした。 その他に思いついた仮説はいくつかありました。 しかし、年齢的に若かったことが作用しているとか検証が不可能なものであったり、例えば過去にSIerに所属していたときは指名で仕事が舞い込むことが多く、仕事内容の特性が強く作用していたことが明らかで、業務内容の違うfreeeでトライすることは現実的ではありませんでした。 あるときは、社内のエンジニアの文化を無視して、周りに自分のやりかたを押しつけ、それが孤立につながったことも過去に経験しました。

freeeのエンジニアの文化ってなんだろう

入社してみると様々な研修があり、これから起こることにワクワクしながらも“文化”の理解を意識し始めました。

  • 「どうやったらすばやく文化に触れられるか」
  • 「誰に聞けばわかるんだろう」

頭の中にはこららが渦巻いていたのですが、早々に”文化”の含まれたスライドに出会います。

それは“freeeエンジニア向け会社説明資料”です。Culture of Developers 開発文化というタイトルのページがあります。

  • 失敗して攻めよう
    • 学びのある失敗をして最速で成長しよう。学びのある失敗とはチームやプロダクトの成長につながる失敗。学びのある失敗をしていないのは挑戦が足りない。
  • 何でもやれる、何でもやる
    • チームで扱う課題について、特定の技術や領域に固執せずオールラウンドに取り組めているか。アプリもインフラも、サーバーサイドもフロントエンドも、早さも正確さも。
  • 必殺技
    • チームの中で自分が貢献できる特徴を理解して発揮しているか。また、その特徴を増やしていけるか。
  • カッとしてシュッとやる
    • 最低限はここまで、に満足せず自分がやりたいことを載せていけるか。システムのボトルネック、負債に対する怒りをプラスの方向に関心を持ち、解決できるか。
  • 世話を焼いていくスタイル
    • チーム内外問わず周囲を自分の知見で助けられているか。レビューしているか、システムor人間のアラートに疾風迅雷のごとく反応しているか。

「お、素直にこれをやってみよう」そう思いました。 こういう出会いは決して運ではなく、普段からアンテナを張っていなければないと思っているので、とてもうれしかったことを覚えています。

どんなことをしたのか

すぐにやれることをやる

入社してすぐは当然ながら業務知識はありません。しかし業務知識がなくても活躍することはできます。 ではどんなことをしたのかというと、自分の持つITスキルを以て開発環境の改善に努めました。

開発環境は運用がまわるようになると、改善が滞るのは経験上よくあると思っていたのと、エンジニアにはスピーディーな作業が求められているのはよくあることです。そのため改善の対応が後手に回っている可能性があります。 なぜ簡単なことが後手に回っているかというと問題は認識しているが、解決方法を調べる時間がないからという理由もまたよくあることです。 その中にはたまたま解決方法を知っているものがいくつかありました。 そして入社者オンボーディングとして実施しているタスクの隙間時間で、いくらかの開発環境の改善を進めました。カッとしてシュッとやるということですね。

幸い、これまでスクラムマスターを経験することが多かったので私の所属したチームでスクラムマスターを務めさせてもらうことにありました。 最近では社外のスクラムコーチにコーチングを仰ぎ、スクラムマスターとしての技量を伸ばしています。必殺技の体現です。

入社してすぐの方の特権と考えているものがあります。それは“失敗させてもらえやすい”ということです。 もちろん事業の継続に影響のあるような失敗はしないようにすることは強く意識しなくてはなりませんが、プログラムやアーキテクチャなど社内の実質的な標準があるかもしれないことや、実施している背景のわからないイベントに対してあえて自分のやりかたをぶつけてみました。 多くの場合失敗するのですが、その結果“なぜそうなっているのか”を理解することができました。 これは結構勇気のいる行動かもしれません。しかしその失敗は劇的な成長につながります。失敗して攻めようということですね。

自分の存在をアピールする

freeeの社員はエンジニアだけではありません。営業職、デザイナー、マーケター等様々です。そういった方々にも私の存在を認識してもらうと活躍の場を得られる可能性が高くなると思っています。 freeeでは入社すると、自己紹介を自分で動画に撮って社員にみてもらう週間があります。通常はスマートフォンで自撮りをするのですが上記のようなこともあり目立ちたかったので動画にテロップをつけたりBGMを付けるといったことをしてみました。

エンジニア向けには、自分が持っている知識を知ってもらうためにドキュメント化を進め、社内に浸透していないような技術に関する記事で反響がありました。

それ以外に自分のわからないことを一覧化しました。例えば Ruby はわかるが Go 言語についてはわからないといった感じです。自分の知らないことを共有するのはパーソナルブランドに傷がつきそうで少し恐れを感じる方は多いかもしれませんが、わからないことにはサポートしてもらえたり、あるいは逆に頼ってもらうことができるようになるので有用だと考えています。

社内に仲間を増やす

いかに自分の存在をアピールしたとはいえ、話したことのない人との交流には壁を感じるものです。 そこで私は、チームのメンバーに限らず、社内向けドキュメントの自分の記事に”いいね”やコメントをいただけた方の中から気になった方や、紹介された人と1on1を積極的に行いました。

それ以外に勉強会の開催も行いました。参加者を募ってそこでつながった人たちとは面識ができます。面識があると相談するときの話が早くなるといった効果が見込めます。

採用に貢献する

開発文化の何でもやれる、何でもやるというのは主にエンジニアリングに関することですが、それを拡大解釈してやれそうなものはやってみると考えていました。

そんな中、入社して2ヶ月経った頃採用イベントが行われるということで、参加させてもらいました。 採用は経営課題のため、会社に貢献できたと考えています。

それ以外に社外でのLTに積極的に参加し、freeeのアピールを行いました。 大きなイベントではQiitaのイベントでもLTをさせてもらいました。

後の人のために苦労したことを残す

入社してすぐは、わからないことが非常に多いと思います。 自分がわからないことはこれから入社する人も同じようにわからないはずだと考えました。 私が入社した後一ヶ月後にも、中途入社者がいることがわかっていたので私がわからなかったことを同じように困らないようにしておきたいと思いました。 そのため、困ったことやわからない言葉を一覧化して残しておきました。 これは世話を焼いていくスタイルを体現したものでもあります。

自社のプロダクトを知る

freee には比較的多くのプロダクトがあるためいきなりすべてを把握することはとても難しいと思います。

そうなると必要になったときどうしたらいいかわからなくなってしまうのでなんとかしたいと思いました。 困ったときに聞ける相手がだれかを知っておけばなんとかなりそうと想い、先輩社員にどういった社員がいるかを聞いて将来に備えました。 あるいは聞きそびれていたとしてもすぐに誰に聞けばわかりますか?と聞くようにしています。

これは今すぐ効果があるような行動ではありませんが、これから効いてくるはずです。

その他には、社外の利用者の動画を見るといったことも行いました。 社内から見るプロダクトはアーキテクチャであったり、プログラム、仕様等といったところがとても見やすいのですが、利用者がどう使っているかまでは見えません。

大変ありがたいことにfreeeのプロダクトは多くのユーザーにご利用いただいており、使い方の解説を動画サイトで公開されている方がいらっしゃいます。 利用者がどう使っているのかを手っ取り早く確認するためにこの動画サイトの動画が非常に役に立ちました。

これは先述の開発文化とは無関係ですが、ある程度の自社プロダクトの知識は必要だと思いますのであえて紹介させていただきました。

終わりに

最初は業務になれるためにまわりに合わせるという考え方もあります。しかし私の経験上成果を出せない状況がしばらく続き、人の意見を聞かないと動けない人という印象を周りに与えてしまう恐れがありパーソナルブランドを低下させてしまうのでやめたほうがいいと思っています。

特に気に入っているのは“失敗して攻めよう”です。これがないと素早い成長を阻害すると思うのです。 これがもし”失敗したら責めよう”だったとしたら新しい挑戦はしにくいし、心理的安全性もなくなり、組織は硬直化していくと思います。

こうしてやったことを振り返って思ったのは、何でもやれる、何でもやる世話を焼いていくスタイルに関しては十分にできているとはいえない状況であり、完全に文化に順応できたとはまだ言えないでしょう。 それでもLTに出ないかと言ってもらえたり、こういった記事を書かないかというお誘いをいただけるのは自分の行動に対する効果が現れ始めているからだと感じています。

freeeの開発文化の理解が深まり、いっしょに働きたい会社だと思っていただければ幸いです。

freeeアクセシビリティー・ガイドラインVer. 202107.0を公開しました

こんにちは、freeeのアクセシビリティー・ガイドラインおじさんの中根です。

先週末に外出したら夏が思いの外本気を出し始めていてすでに夏バテ気味の今日この頃、皆様いかがお過ごしでしょうか。

さて、今回もfreeeアクセシビリティー・ガイドラインの更新情報をお届けします。

と言いつつ、今回もあまり大きな変更はありません。

だから、というわけではありませんが、最後に近日開催予定のイベントのお知らせもありますので、最後までお付き合いください。

ガイドラインの文言を一部変更

以下の2つのガイドラインについて、文言を変更しました。

入力ディバイス:[MUST]キーボード・トラップの回避

変更前:
動画プレイヤーなど、特定のコンポーネントにフォーカスした状態から、Tabキー、矢印キー、Escキーで抜け出すことができるようにする。
変更後:
ページ中のあらゆるコンポーネントについて、Tabキー、矢印キー、Escキーなど簡単な操作でフォーカスを外すことができるようにする。

このガイドラインは、ページ中にあるコンポーネントに一度フォーカスすると、キーボードだけではそこからフォーカスを外せないというような状況を生まないように、という意図のものです。 このガイドラインの基になるWCAGの達成基準が考えられた頃には、Flashのコンテンツ、Javaアプレットなどがこういった問題を引き起こすことが多く、中でも動画や音声のプレイヤーが埋め込まれている場合によく見られる問題だったことから、このような記述にしていました。

しかし、最近は動画プレイヤーなどでそのような現象に遭遇することが随分と減った印象があります。 その代わりというわけでもないのでしょうが、何らかの機能を実現するためにJavaScriptで実装されているコンポーネントなどが、こういった問題を引き起こしているケースに出会うことが多くなってきているように思います。

そこで、必ずしも動画や音声プレイヤーに限った話ではないということを明確にする必要もあると考えて、このような変更をすることにしました。

動画プレイヤーなどを埋め込む場合にも引き続きこの点に注意する必要はありますので、「音声・映像コンテンツ」カテゴリーにある同じ内容のガイドラインには変更はありません。

なお、この変更に伴って、チェックID:0201の文言も修正しています。

ページ全体:[MUST] 画面方向を固定しない

変更前:
特定の画面方向(縦置き/横置き)での利用を強制しない。
変更後:
コンテンツの性質上必要不可欠な場合を除いて、特定の画面方向(縦置き/横置き)での利用を強制しない。

対応するWCAGの達成基準では例外を認めた上でAAになっているのに対して、freeeのガイドラインでは例外を認めず[MUST]になっていました。 WCAGに合わせて例外を認めることにしたのが、今回の変更です。

この検討の中で優先度についても検討しました。 その結果、どういった場合に許容される例外となるのかということについては、その都度丁寧な検討が必要だと思いますが、例外を認めた上であれば[MUST]のままで問題ないだろうという判断に至りました。

その他

変更内容が軽微だったためこのブログではお知らせしませんでしたが、Ver. 202106.0もリリースしています。

参考情報に掲載しているNVDAチートシートが配布元で更新されたことへの対応などをしています。

他にもいくつか細かな変更をしていますが、詳しくはリリース・ノートをご覧ください。

引き続きご意見などお待ちしています

今回の変更についても、それ以外の部分についても、ご意見やお気付きの点など、GitHubリポジトリーのIssuesやPull Requestsでお知らせください。

イベント開催のお知らせ

元々freeeアクセシビリティー・ガイドラインやチェックリストは社内で使うために作り始めたものですが、最近では社外でも活用してくださっているというケースが出てきました。 そこで、実際に活用してくださっている方にお話しを伺おうというイベントを企画しています。

  • 日時:2021年7月29日(木)19:00~21:00
  • 会場:オンライン
  • 参加費:無料

以下のページからお申し込みください:

https://connpass.com/event/218780

connpass.com

【freee x メルペイ】QA Tech Talk 〜リリースを早めるQA〜 に参加しました

こんにちは、2021年4月にfreeeに新卒で入社したberryです。

今年は5月末にほぼリモートの新卒研修が終わり、6月頭から新卒はそれぞれの部署に配属されていきました。私はQA配属となり、現在テスト技法やテスト自動化の勉強に勤しんでおります。

本記事では2021年6月23日にfreee株式会社と株式会社メルペイさん合同で開催されたイベント、【freee x メルペイ】QA Tech Talk 〜リリースを早めるQA〜について、理解のために各ディスカッションをまとめ、新人なりに考えた/感じたことを残したいと思います。

目次


上流工程で何をやってQAを早めているか

  • メルペイでは
    • 開発段階で開発チームと一緒に要件定義や開発の設計を考える
    • 外部パートナーと仕事をする際は企画段階から初期品質を作ったりしている
      • 開発前の意識のすり合わせなどにQAも入っていく
    • QAをしてバグを見つけるというより、発生する前に防ぐ
  • freeeでは
    • スクラム開発なのでスプリント(一週間)の初めにengとQAそれぞれ開発計画テスト計画を立てる
    • 実装が始まる時にリスク洗い出し会を行い、テスト項目について議論し、プロダクト&テストをそれぞれ作り始める
    • 実装し次第テストも順次行われるので実装が終わる頃にはQAも7~8割終わっている
    • 実装中にQAで仕様の抜け漏れなどを発見できると、本来なら間違ったまま進めて手戻りが発生していたところをカバーできることがある

まとめ

基本的に根本の部分であればあるほど間違った際に見直さなければならない範囲が広くなってしまうため、そういった部分はなるべく早めにテスト&開発側との議論を行う必要がある。と理解しました。

QAの方たちは難しい仕様をどうやってカバーしているのか

  • メルペイでは
    • 大変で課題になっているが、オンボーディングの充実やメンターとの話し合いでキャッチアップしていく
      • QAが横断的に仕様を理解することによって上流の話し合いにも入っていける
      • eng側はどうしても各マイクロサービスを突き詰めることになり、他サービスとの連携時に齟齬が発生しやすいため、QAが架け橋となって課題やプロジェクトの状態を整理していく
  • freeeでは
    • メルペイさんとほぼ同様
    • サービス間の連携がある場面で、マイナス金額の考慮の仕方が違うことがレビューによって判明したため、横断的な視点を持てるQAの存在は重要

まとめ

開発時にバグが発生するのは、開発対象とそのプロダクト以外との繋ぎ込み部分になりやすい。そのためQAとしてプロダクトに関わる時は、それぞれのサービス同士の知る必要がある仕様を相互に把握できるように動けると良いと感じました。

先ほどメルペイさんの回答にあったQAのオンボーディングとはどのようなことをやっているか

  • メルペイでは
    • マイクロサービスを理解するために、自分の理解を他人に説明したり、処理の流れを説明したりなどして理解ができているかを確認しながら進める
    • 最近はテクニカルな部分も増えてきているため、一筋縄ではいかない場面も増え、難しい課題となっている

まとめ

他人に説明するという行為は理解度チェックにおいてとても強力な手段であり、かかる時間に見合った効果がありそうだと感じました。私も自分が理解できた!と思ったらその物事を説明させてもらう場を作ってみたいと思います。

また、現在私は毎日日報を書いており、得た知識を自分がどう咀嚼したかどうかを含めて先輩方の見えるところに投稿しています。私は内容に関してフィードバックや補足をもらったり、先輩方からは私がどの程度理解を進められているかを把握できるという利点があると考えています。

開発中のテストでどういうことをやってリリースを早めているか

  • メルペイでは
    • 開発段階からQAがspecを確認、把握して、テストを書いていく
    • テストを書くとき(一番プロダクトについて詳しいとき)にリグレッションテストを一緒に作る
    • postmanを利用していたが、自社作のAPIテスト用ツールを制作し、使っている
  • freeeでは
    • フィードバックを早くすること
    • 開発時にunitテストを書く文化があったり、ステージングデプロイ時にUIやAPIレベルのテストが走るなど、素早いリターンを意識している
    • 会計帳簿などのドメインとして重要な機能は確実にチェックするようにしている
    • 本当はもっと手前側(開発に近い側)でバグ等を拾っていきたい
    • 手前側でやる基盤やテストの書き方の浸透がまだまだなため、課題となっている

まとめ

フィードバックが早いとリリースが早くなる理由を考えました。最初の質問と同じく間違った前提をもとにコードを書いてしまう手戻りが防げることはもちろんですが、コードを書いた記憶が新しいうちにやり直しができることにもあると思います。私も1週間前に書いたはずのコードを覚えておらず、「この部分のコードがこの書き方でいい理由ってなんだっけ?」と思ってコードを追い直す作業をしなくて済みます。

またフィードバックの早さ以外での部分でも、QAとして目指していきたい理想的な動き方がまとまっていると感じました。

自動テストの実装はQAエンジニアが対応されているのでしょうか?

  • メルペイでは
    • APIテストはQA*1、unitやe2eはengが書いている
  • freeeでは
    • e2eはQA、unitやAPIテストはengが書いている
  • 普通はengが具体度の高い部分を担当して、QAが抽象度の高い部分を担当すると思ったが、何故逆なのか
    • e2eテストをxctest(swiftのテスト)などで書いているため、engが書きやすい
    • 開発とQAが同じ視点で話をしたいため、最終的にはxctestもQAが書きたい
    • QAと開発でラインを分けたくない => 全員品質

*1 配信においてunitテストはQAが書いていると解釈していましたが、後日確認を取ったところunitテストはengの方が書いているとのことでした。

まとめ

2社で完全に逆の結果となり興味深かったですが、使用する言語の面から考えると妥当だと感じました。特にUIテストは要素の指定方法なども手段が豊富なため、同じ言語でもテストの書き方は別物になると考えています。となるとやはりある一つの言語を使って10の作業をするのと、複数の言語で半分づつの作業をするのではやはり後者の方が難しいです。それによってQAとengで書くテストが分かれるのは仕方がないと思いましたが、e2eとunit&APIそれぞれのカバーしているシナリオはお互いに把握できるべきだと私は考えています。

マニュアルテスト、ユニットテスト、E2Eテストなどは(誰が)どういう割合で実施していますか?

  • メルペイでは
    • サービスによる
    • 各チームでどこをどうテストしていくかを考えて、スケジュールやタスク量をなどを鑑みてQAとengで作業量を割り振る
    • GOを使っているが、QAもengもテストを書けるので、柔軟に対応できる
  • freeeでは
    • マニュアルテストはQA
    • unitテストはeng
    • e2eテストはseqチーム

ここでもメルペイさんは誰が何を書くかを分けずにテストを実施しているというお話でした。個人的に感動したのは、「スケジュールやタスク量をなどを鑑みてQAとengで作業量を割り振る」という部分で、作業量のバランスが偏ってしまうことによるQA待ちや開発待ちという時間が発生しにくくなるのは画期的だと感じました。

上流や開発テスト自動化ができるQA人材を生み出すためのキャリアパスはどうなるのか

  • メルペイでは
    • 夢物語かもしれないが、全てをできるQAを育てようとしていて、あえてset(freeeのseq)チームを作っていない
  • freeeでは
    • seqは存在するが、組織としてのステップアップ的にはできる人から教わって全体に伝播するという流れの途中であり、全員が自動テストを書けるようになるための勉強中

まとめ

正社員として長い期間会社に貢献し、QAもテストコードをバリバリ書け、上流工程の話もでき、プロダクトを横断する知識があるという姿を目指すのは、やはり簡単には実現しないと思います。

一方で全プロダクトを横断する知識はなくともプロダクト群の基盤関係の整備を進めていくことによって、1プロダクトが外と通信を行う部分は基盤を経由することが多くなるはずなので、基盤周りとプロダクトに横断的な理解があるQAというのはステップアップの段階として目指せるのではないかと新人ながらに考えています。

リリースした後の改善活動はどうしてる?

  • メルペイでは
    • 自動化の部分
    • 新規でサービスを作るときはマニュアルテストになってしまうが、ファーストリリースの直後に頑張って自動化する
    • 後からもう一度テストして欲しい、となったときに16時間かかっていたマニュアルテストがサッと回せるようになった
  • freeeでは
    • バグを大事にしていて、再発しないように原因究明をして知見を蓄える
    • 会計帳簿や帳簿のまとまりなどは一朝一夕では身につかないため、税理士のPMの方からシナリオを作ってもらって質の良いテストを行なっている

まとめ

freeeでは税理士のPMがシナリオと作るという非常に幸運なケースだと思いました。しかし、他の分野でサービスを作っている企業にてドメイン知識を持った人材が社内で継続的に協力してくれるような状態を維持するのは簡単なことではないと感じました。採用活動の難しさの理由の一端を垣間見た気がします。

技術的負債に対してなにか取り組み等はされていますか?

  • メルペイでは
    • リリースを急がないといけない場合、負債を抱えた状態でもリリースしないといけないことがある
    • 負債が溜まってしまうと新しくリリースができなくなる
    • 負債を棚卸してどういう負債があるかを確認し、負債の再発防止方法を検討していった
  • freeeでは
    • 最初はバグが出てしまってPMの方が謝罪に行ったりすることもあった
    • バグの振り返り、言語化できていなかったが考慮が足りなさそうだと思っていたところを洗い出したりしていた
    • コードが書かれた年代に着目し、いつバグの元となるコードが入ったか、この年代の部分のコードは手をつけなくて大丈夫そうだ、というのをengと共に確認していった

まとめ

2社ともチーム内でバグや負債を一旦集めて分析するという工程が入っており、何かのきっかけで見直しをしようという動きがないとそもそも工数を取れないようなイメージを受けました。意識的に負債の棚卸しを出来ればいいなと思います。とはいえ纏まった工数を取るのも大変そうです。

使用性テストはいつどうやっているか

  • メルペイでは
    • ユーザビリティ専門の部署がやっている
  • freeeでは
    • ユーザビリティテストは普段のテストの中でやっている
    • アクセシビリティテストも時間が取れた時にガッとやっている

まとめ

メルペイさんではQAとユーザビリティは分けているという点が印象的でした。どんなサービスを作るかという点ではなく、サービスをどうやってより良くしていくかという点がQAの関わっていくポイントであると理解しました。

JSTQBやIVECなどの知識をQAにどう活かしているか

  • メルペイでは
    • 知識が馴染んでしまっていて活かせている事に気づいていないかもしれない
    • 採用などでは意識しない
  • freeeでは
    • プロダクトの知識やドメインの知識が重要

まとめ

資格の知識が馴染んでしまってそれを使っているかどうかわからない状態は、実務経験と知識が混ざり合うことで発生すると考えています。人によって適したやり方はあるはずですが、知識から入っていくという人もいると思っています。

QAが負荷試験や性能試験のテスト環境を準備するか

  • メルペイでは
    • SREチームが主体となってやっていく
    • セキュリティ面をfreee以上に重視しないといけないため、セキュリティチーム(freeeのpsirt)と一緒に考えていく
  • freeeでは
    • freeeプロジェクト管理立ち上げの時、eng, QA, SRE三位一体でやった(ガトリングを使った)

まとめ

負荷やセキュリティはドメインによってそれぞれ必要なボーダーが変わってくるため、全体を俯瞰する視点の必要性を感じました。

終わりに

今回、QA Tech Talk 〜リリースを早めるQA〜という形で配信を視聴しました。結果としてメルペイさんとfreeeそれぞれのQAの組織内での動き方を比較しながら考えることができ、とても勉強になりました。
末筆になりますが、このような機会を設けてくださったメルペイさんに心より感謝申し上げます。

参考資料

  1. オンボーディングとは何か?

    オンボーディングの達成度合いを図る目安として、各技術領域ごとに独自のKPIを立て、進捗確認をサーベイにて実施しています。リモートでのオンボーディングの状況を定量的に可視化することで、適切なサポートができるよう仕組み化しています。

    • 新しい分野への配属直後では、「各種スキルに対してどの程度の技量が求められているか」以前に「そもそも各種スキルは何があるのか」という段階である場合も多々あると思った。サーベイのコストを考えなければ、独自のKPIを立てて進捗確認を行うのはとても効果的だと感じた。
  2. Postmanについて

    • jenkinsのAPI単位バージョンのようなものだった
      • APIリクエストを送り、そのレスポンスの内容をテストでき、jenkins同様環境変数なども設定できる。
      • リクエストを投げ、そのレスポンスを次のAPIのリクエストに含めるなどの結合テストを行ったりもできる。
      • jenkinsのjob, SUITEのようにテスト、コレクションがある
  3. メルペイでのxcresult活用事例

    • メルペイではPRが出たときや夜間にCircleCIが起動し、テストの実行結果をTestRailで管理したい。
    • 実行されるXCUITest(スマホ用テスト)の結果をFastlane(Seleniumのスマホ版)のカスタムアクションでTestRailにAPIで連携したい。
    • テスト結果のResult Bundle(*.xcresultファイル)はXcode上で確認できるが、そのままでは人が読めない&機械的に読み取るのが難しい。
    • Appleが提供しているxcresulttoolを用いることによってxcresultファイルをjson等に変換し、集計できるようになる。
  4. メルペイ iOS にスナップショットテストを導入した話

    • iOSで画面のスナップショットをそのまま画像として比較することができる
  5. 自作ツールについて書かれている記事 APIテスト用のツールscenarigを実装した話のようです 記事内の自動化に対する考え方が興味深かったので抜粋します

    個人的に特に意識していること 早く確実に品質保証をするために、なるべく機械的にできるところは進んで自動化した方が良いと考えています。 自動化のサービスを適用できるなら検討します。ただフィットするケースが多くもないので、フィットしないなら自分で作る気持ちを持っています。 自動化するところに対しては、保守性をとても大事に考えています。 (よくある話ですが)繰り返し実施しないものは、無理に自動化しません。ただ、自動化にチャレンジすることでスキルアップに繋がる場合はチャレンジした方が良いと考えています。

    • 単純作業は機械にやらせる
    • 保守性が低いとメンテナンスコストだけかかってしまうテストが生まれてしまう
    • 繰り返し実施しないものでもスキルアップを意識してわざと書くというチャレンジは興味深かった

    • 元々内製ツールを用いたテスト時にジョブの実行結果を目視で確認していた

    • Assertを使ってテスト結果を確認するために内製ツールに機能を追加したい旨をエンジニアに相談し、実装してもらった
    • 結果、工数が2倍以上削減され、さらに目視による確認ミスもなくなった
    • と、目覚ましい効果があった模様

    個人的には「発想はあったが、エンジニアに依頼して頼るところはちゃんと頼る」という姿勢を見習いたいと思いました。仮に無理をして自力で全て実装できてもバグを埋め込む可能性は上がり、工数も余計に取ってしまうため、誰がやるといったスコープは意識したいです。

  6. 技術的負債への取り組み:より良いサービスを継続的に届けるための新しい習慣ができるまで

    • リリースラッシュによりリソースを割けず、マイクロサービスとして切り出すべき機能を既存のシステム上に実装し、技術的負債を追うことを選択したが、やはり後続のブロッカーや保守運用コストの増大を引き起こしてしまった
    • チーム内にあった「ヤバそう」という空気を実体化することを説明し、丁寧に振り返りを行った

      発生した障害の振り返り・共有 障害発生から解消までの対応率の数値化 暫定対応などチケットの対応率を数値化

    • 自動テストも作成し、デグレチェックにかかるコストを削減した

    • 結果、問題の発生に対して迅速に対応をし、チームとして再発防止策を考える風習が生まれ、数字にも現れた

    感想としては、問題に対するチームとしての向き合い方が改善されたように感じました。技術的負債の発生の原因を探るプロセスを共有したことによって開発メンバーも新たに発生したバグに対する向き合い方が変わったりなど、取り組める構造を作り出していくことがQAの役目なのかな、とも思いました。

  7. Cypress + TestRail による Frontend E2E テストの効率化について

    • Cypressというe2eテストのフレームワークをTestRailで集計する
    • 集計の行き着く先はTestRailが多い