この記事はGLOBIS Advent Calendar 2020の24日目の記事です。
「ビジョナリー・QA」関係では2本目の記事です。
当社グロービスのQAチームは9月のテックブログで「ビジョナリー・QA」と自分たちを表現し、ありがたいことにアジャイル開発、特にスクラムを実践する方たちを中心に、多くの皆さまから反応を頂戴することができました。
さて、この記事は、そんな「ビジョナリー・QA」が2020年、一体どんなことをしてきたのかを主に業務面から振り返った等身大の戦いの記録です。チームの理念がどうやって作られたのかなどの背景は、ぜひこちらの記事をご一読くださればと存じます。
◉結論ファースト
10,000文字超という、ブログとしてはそれなりに長い文章ですので、結論を最初に述べておきます。時間が無い方はこれだけ読んで「ほう、なるほど」と思ってくだされば幸いです。この部分だけでもTwitterで拡散くださるとうれしいです。
実績・信用ゼロの独立QAチームが成果を挙げた鍵は、卓越したテスト技法でも、メソッドでも、品質の専門知識でもなく、ずばり「コミュニケーション」でした。PO・SM・開発者と目線を合わせ、スクラムを学び、共に難問に立ち向かった等身大の1年戦記です。
◉業務を時系列で並べてみる
QAエンジニアは視野を高く・広く持つようにと言われます。あまり個別具体的な事象に囚われたくないという思いはありつつも、やはり現場に多くの目線・興味が注がれていることは疑いようがありません。いくら理念を語っても、実践が伴っていなければ薄っぺらなものです。薄っぺらであることを自覚・自認するのはつらいところですが、少しでもQA界隈が未来に向けて進めるならばと、わずかな事例ですが、こうして記事化することにしました。
0. 前提
当社ではScrum@Scaleという大規模スクラムの手法を取り入れており、各スクラムチームのPO（Product Owner）・SM（Scrum Master）・開発者（Developer）と連携して仕事を進める必要があります。スクラムチームとQAチームは対等であり、ともに高品質なプロダクトをリリースしてビジネス価値の向上に貢献する仲間である、と考えています。
各事例でアサイン人数は異なりますが、当社QAチームは「1名だけのアサインはしない」と意思決定していますので、必ず2名以上で担当しています。
もちろん、今回挙げた以外のアプリやプラットフォーム開発へのコミットも行われました。詳しく知りたい方は、職種・転職意向を問わないカジュアル面談で包み隠さずお話ししておりますので、ぜひ当方にお声がけください。
当社QAチームのカジュアル面談については、こちらの記事も併せてどうぞ。伍ノ型までしか無いのかよというツッコミはご勘弁ください。
1. 【アプリ開発】Androidアプリのバージョンアップ
2020年が明けてから2ヶ月ほどは、アプリチームが取り組んでいた「GLOBIS 学び放題」のAndroidアプリのリリースに向けたテストに取り組んでいました。アプリチームがちゃんと単体テスト（ユニットテスト）を書いていることもあり、比較的「自分たちで品質を高める」という意識を持っていただけていました。
QAチームからは2名アサインし、テストの見通しを立てて計画し、設計し、実行するというオーソドックスなやり方に加え、アジャイル開発に適したテスト技法である（と当時から考えていた）探索的テストを取り入れ、進めました。加えて、アプリチームのスプリントプランニングに参加し、常に開発の状況と計画をキャッチしていたことが特徴的な取り組みかもしれません。キャッチにとどまっていた部分は反省点であり、この先で進歩していきます。そういった改善ポイントはありつつも、アプリチームとは歩調を合わせることができるとお互いに認識したことで、Androidのバージョンアップに向けたテストは、この後も継続的に依頼されることになります。
2. 【アプリ開発】iOSアプリ開発 フェーズ1
開発部門で2020年、必ずリリースしようと息巻いていたのが「GLOBIS 学び放題」のiOSアプリです。iOSアプリは、とある事情により更新が実施できない状態に陥っており、これをなんとしてでもメジャーアップデートしてリリースすることが課題でした。
2フェーズに分かれたiOSアプリの開発のうち、フェーズ1として行われた3月末までの開発プロジェクトは、課金を除いた部分の実装をターゲットとしました。短期だったこともあり、形式的テスト（Formal Testing：スクリプトテストとも）でテスト設計をしていては時間がかかりすぎることと、開発者がテストをしっかり実施し、品質が安定していたことから、QAチームは探索的テストでのE2Eテストを行いました。ツアーベーステスト（Tour-based Test）から着想したテストチャーターを使って推進し、不具合を見つけたらチケットを切ることはもちろん、週ごとにアプリチームには下記のようなレポートを示しました（「PJエビス」というのはプロジェクトネームです）。
（アプリチームに示したレポート、（かっこ）内の数字は前週比の差分）
カンバンを使っているので、わざわざこんな表にする意味は薄いかもしれません。しかし、週次の決まったタイミングで同じフォーマットの表を使って数値で状況を示すことで、透明性の担保と安心感の醸成を狙いました。
それなりにバグが見つかっていて、Criticalなバグは即修正され、進めることができました。TrivialなバグについてはIceboxに入れられるものもありました。その選別はQAチームからの情報をもとにアプリチームで決めていました。
iOSアプリは秋冬のフェーズ2でApple課金への完全対応を行ってから公開されますが、その前に、課金プラットフォームの更改を待たねばなりませんでした。その間アプリチームでは裏でiOSアプリのバージョンアップを重ねていました。今日提供されているiOSアプリの使いやすさは、公開できない時期に積み上げてきたアプリチームの努力が反映されているのです。
3. 【課金実装】課金プラットフォーム切り替えプロジェクト
サブスクリプション型のサービスを展開している当社のビジネスにとって、課金周りのプラットフォーム実装を避けることはできません。当社ではより利便性を高めるため、課金プラットフォームを別サービスに移行することにし、開発を進めてきました。
このプロジェクトの難易度はとても高かったです。その理由としては、継続している既存顧客については以前の課金プラットフォームを維持するという方針で進んでいたため、実装やステータスの状態が非常に複雑化したことです。また、課金に関わる部分であるため、不具合が発生してしまうと、収益に重大な影響を与えかねない点も、難易度を大きく引き上げた要因でした。こうした事情により、リグレッションテストを広範に行わなければなりませんでした。
リグレッションテストのために、開発者が作成した網羅的なテストケースをもとに、まずは形式的テストを実施しました。最初からQAチームがイニシアチブを取らなかったのは、そもそもQAチームが複雑な仕様をよく把握していない状態だったこと、また他方で、開発者からはQAチームが何をやっているのかがほとんど知られていない状態からのスタートだった、ということが背景にあります。提示されたテストケースを消化していけばバグの傾向をつかむことができるはずと考えており、形式的テストがある程度進むのを待って探索的テストを並行して進め、集中的にバグを叩きにいきました。
QAチームの取り組み方針として「必ず再現するバグだけを報告する」ことを徹底していました。それにより「QAチームからバグがあまり報告されてこない」と開発者から怪しまれるくらい、バグの報告数が絞られました。プロジェクトがある程度進んでから、開発者とバグの報告について方針を共有し、再現性を担保しやすくなるような実装を組み入れてもらいました。
背景には、QAチームに対して「スピードを阻害しない」という安心感をスクラムチームに持ってほしかったという意図がありました。開発者がQAエンジニアに抱く一般的なイメージは「違和感や再現性の無いバグまで、なんでもかんでも報告してくる」というものでした。従来型の開発プロジェクトではそれがQAエンジニアの優れた仕事だったかもしれませんが、スクラムにおいては「スピードを阻害する」という点で害になってしまうおそれがあります。
そもそも、開発者に対して意識して「バグ」という言葉を使わず「不具合・違和感系」という言葉で報告していました。「バグ」であるかを決めるのは開発者である、という意識でした。実績の無いQAチームが開発者と共に足並みを揃えていくために、まず「相手の言語で話す」ことを重要視しました。このあたりはコミュニケーションの要諦と思いますが、元々開発者だったメンバーがQAチームにいることも、この施策を実施するための大きな力となりました。
このプロジェクトから、リリース時にハッピーパスを通すツアーベースのE2Eテストも始めました。リリースのタイミングで、開発者やSREが見ている中でテストを通すことで、本番環境でも問題なく動くことを証明しているわけです。開発者がログを監視したり、SREがサーバーの状態を監視しながら進めていたので、安心してリリースができる試みになりました。QAチームへの信頼感が醸成されていたため、安心してリリースすることができました。
総括すると、実績がほぼゼロの状態のQAチームが取り組んだ難易度の高いプロジェクトでした。テストの手法で信頼を勝ち得たのではなく、コミュニケーションと実績を積み重ねてQAチームに対する信頼感を構築していったことが、このプロジェクトで得られた大きな成果であると考えています。
4. 【プラットフォーム開発】データテーブルの大幅な最適化プロジェクト
当社の開発組織は2016年に立ちあがり、急速に拡大しました。その過程で生まれていた幾つかの技術的負債を解消するためのプロジェクトがこちらです。これまで学んだ知見を広く生かすことができたプロジェクトですが、今回は法人向けのシステムに対する改修であり、ビジネスのワークフローを含め、さらにQAチームとして知識を蓄える必要がありました。
大規模なリグレッションテストが必要となりましたが、リリースは1ヶ月後に迫っているというタイトな状態でした。そこで、開発者の協力を得て観点出しを行い、マッピングを行いました。それで全体像を示した上で、どこを重点的にテストしてほしいか・どのくらいやれば安心感が得られるかをPOに尋ね、認識を一致させました。QAプロセスにおける「完成の定義」を決めたのです。こういった丁寧な活動を経て、POをはじめとしたスクラムチームが安心感を抱けるようにと心を砕きました。
この時期には、以前のテックブログでもお伝えしていたCodeCovの導入が行われました。このプロジェクトを実施していたスクラムチームはユニットテストでのコードカバレッジが高いことが示されました。既知の問題を除いたバグがほとんど検出されなかったのは、開発者がしっかりとユニットテストを行っているためだったのです。E2Eテストでの不具合が多くて困っているというケースをよくQA界隈で見聞きしますが、やはり開発者によるテストが解決の光なのだと改めて認識しました。
5. 【Scrum@Scale】SDS・SBRへの参加と動き
開発の現場以外の側面に関わる取り組みのお話も加えておこうと思います。当社の開発組織では大規模スクラムの手法の1つである「Scrum@Scale（以下、S@S）」を取り入れています。SDS（Scaled Daily Scrum）とSBR（Scaled Backlog Refinement）は、それぞれS@Sで定義されているイベントです。この両方にQAチームから1人、まぁ、私なんですけども、参加しています。
SDSは各スクラムチームのSMが集まるデイリーイベントです。自チームのゴールの達成を妨害する要因を特定し、解消に向けたアクションを取ることが目的です。各スクラムチームの状態を横断で把握できる有用な場であると同時に、組織共通の完成の定義（Definition of Done）の設定やステージング環境不足といった問題解消に取り組んでいます。QA視点で貢献できる割合が大きいイベントです。
SBRは、POとステークホルダーが集まってPBI（Product Backlog Item）の紹介と承認を受ける週次のイベントです。S@Sのガイドでは、バージョン1.02でPOサイクルのイベントとして記述されていますが、執筆時点で最新のバージョン2.1では取り上げられなくなっています。新版で強調されるようになったPOのチーム・会議体も運用していますが、SBRも引き続き重要であると当社では判断し、開催しています。ビジネス側の要望（Requirement）に対し、スクラムチームからの答えがユーザーストーリーの形でPOから説明されます。QAチームの立場からは、ユーザー導線や条件など、考慮漏れがないかを確認します。早期にこの活動ができると、スクラムチームが品質を高める活動をしやすくなります。
大規模スクラムにおけるQAチームはどう動くべきでしょうか。明確な答えはありませんが、日々の業務の中で模索しており、今後もずっと続いていく取り組みだと考えています。
6.【アプリ開発】iOSアプリ開発 フェーズ2
このプロジェクトは波乱万丈で、当初1ヶ月半くらいの見込みで8月スタートしたものの、止むをえない差込リリースが相次いだことと、Sandboxの仕様に翻弄される中で品質を担保する必要があったことから、最終的なリリースは12月になりました。リリース後にはAppStoreでも好意的なコメントが寄せられ、ビジネス価値への貢献を強く感じられるプロジェクトでした。
経験のある方にとっては先刻承知のことですが、iOSアプリの課金実装なのでAppleが提供するSandboxを使いました。Appleから提供されている機能が圧倒的に不足していることに加え、Sandboxの仕様はたいへん複雑でした。加えて、時期が悪くiOSのバージョン（当時は14βと13以前）によって挙動が大きく異なったことも相まって、極めて苦戦しました。以前実施した課金プラットフォーム切り替えでの経験が生かせるはずだという当初の目論見はあっさりと崩れ去り、苦難の道を3ヶ月以上も歩むハメに陥ったのです。
QAチームがここでも最も重要視したのは、開発チームとの関係性でした。困難な課題に対して、QAと開発が一丸となって取り組む構図を作ることができました。今回の体制では、主にSMとのコミュニケーションを行なっていました。サンドボックスでできなかったことの報告をSMに毎日報告し、一緒に判断していくというやり方を取りました。ありがたいことに、おおむねSMやPOから好評で、スクラムチームのスピードを極力落とさずに高品質なプロダクトをリリースするという姿勢が取れました。
スクラムに入るか入らないかという議論が多いですが、そこに眠る真のイシューは「コミュニケーション不足のため、距離感が遠いこと」であると、当社QAチームでは考えています。
7. 【Web開発】更改プロジェクト
「QAチームはテストだけが仕事ではない、品質の門番ではない」という認識が組織内に浸透してきた秋口から参画しているのが、こちらのプロジェクトです。国際展開を見据えている開発組織として、技術的負債の解消も兼ねて、更改を進めています。POやSMからご相談くださり、組織のビジネスにとっても重要であることから、QAチームが早い段階から参画しています。
このプロジェクトでは、目線を「The Whole Team Approach」すなわち品質はQAチームに頼るのではなく、スクラムチームが高めるものであることに置いて進めています。「QAチームもテストはやるけれど、スクラムチームが自分たちでできるようになること」を目標とし、そのための打ち手をPO・SM・開発者を交えて打っています。
「テストが自分たちでできるようになる」ためには、どういうことができるようになる必要があるでしょうか。たとえば、経験のあるQAエンジニア・テストエンジニアにとって、テスト設計をする（テストケースを書く）ことは、そんなに難しく感じないかもしれません。しかし、今までテストのスペシャリストとしての道を歩んでこなかったスクラムチームのPOや開発者には、とても大変なことです。スプリントプランニングの時点でテストまで考慮して計画を立てることができるようになる必要もあります。
品質の側面からスクラムチームと共に歩み、ゆくゆくはテックブログで述べたようにQAチームがいなくても自立して歩んでいけるような状態につなげることが、QAチームの役割になっています。
◉気になるポイントに答えてみる
ここでは最初から順次お読みくださっている皆さまが疑問に思う……かもしれないポイントに触れておきます。
1. テスト自動化は進めていたのか
当社では「QA自動化プラットフォーム」であるAutifyで自動テストを作成・実施・メンテナンスしています。Autify社には当社QAチームの草創期からお世話になっており、第1回ユーザーイベントでは「Autify、君に決めた」という著作権に引っかかりそうなタイトルで、QAチームリーダーがLT登壇させていただきました。ここで語られている通り、スタートしたばかりのQAチームが自動テストを取り入れるには、スクラッチで開発するよりも、Autifyを使った方が安定感が高いと考えています。
個人的にも、Autifyのテスト自動化スペシャリストである末村さんは友人で、Autify Podcastにも出演したほか、イベントも共催しました。
2. 探索的テストはどうやっているのか
当社QAチームが取り組んでいる「探索的テスト」は、皆さんが考えるやり方とは少し異なるかもしれません。
品質とスピードの両立が求められるアジャイル開発では、探索的テストは必須であると当社QAチームは考えています。方法論はインターネット上でいくらでも調べられますが「実際の業務でその通りできるか？」まで踏み込むと「なかなかうまくできない」「（探索的テストをそもそも）求められていない」という答えが多いです。
そこで、自分たちで「探索的テストの再定義」とはいかないまでも、素早く効果を挙げるための洗練化を行わなければなりませんでした。流布している方法論に頼るのではなく、現場のメンバーが絶えず自分たちで考え工夫を重ねたことが、当社QAチームの探索的テストをレベルアップさせています。
探索的テストのすべてをここで述べるのは大変ですから、別の機会に譲りましょう。もしくは、カジュアル面談でお話ししましょう。
3. 形式的テストとは何か
Formal Testingの訳語で、おおよそISTQBでいう「スクリプトテスト （Scripted Testing）」に相当するものです。QAチーム内の共通認識として「探索的テスト」の反対語として「形式的テスト」と表現した方が収まりがよいよね、ということになり、採用している呼び方です。
たまに「形式的テストってヨソで言ったら『なにそれ？』って言われるから気をつけてね」ってメンバーには呼びかけています。むしろ「形式的テスト」という言い方が広まればいいのに、と個人的には思っています。
（そういえば「形式手法」も世の中に存在しますが「形式的テスト」とは全く関係がありません。「形式手法と混同する人がいるかも〜〜」というご意見をいただくことがありますが、今のところそういう事例はありません。）
4. コミュニケーションの話を詳しくしてくれないか
独立したQAチームとして動いている以上、コミュニケーションは最も課題になりやすいポイントです。いくつか取り組みがあり、効果があったものも、あまり効果的ではなかったものもあります。少し挙げてみましょう。
参画するプロダクトの決定
少数精鋭を旨とするQAチームとはいえ、QAエンジニアの数がプロダクトの数よりも少ないとあっては、すべてのプロダクトに対してコミットすることは不可能です。また「1人アサインはしない」ということを意思決定していますので、いきおい、参画できるプロダクトには限界があります。
この課題に対し、リスクベースの発想で取り組むことにしました。それぞれのプロダクトのリスクの大きさと、発生しやすさを加味して、上位2つのプロダクトに対してQA活動を行うことにしました。
予想がつくと思いますが、この方法だと、お金が関わるプロダクト、特に課金実装のプロジェクトに自然と決まってしまいます。それもあり、2020年は課金に関わる業務が多かったです。
QA依頼フォーム
ほぼ初期に導入したのが「依頼フォーム」です。
（微妙に言い回しが違うのは更新漏れですねぇ）
**「QAチームに依頼したいけれど、誰に話しかけていいか・何を伝えればいいかわからない！」**という課題をヒアリングした結果、捻り出したのがこの依頼フォーム。QAチームとして提供できるメニューを整理して表示し、合わせてスクラムチームの目線からの優先度や課題感をちゃんと汲み取ることを目的としていました。
このフォームのURLをSlackのQAチームチャンネルに提示したものの、数ヶ月間全く使われませんでした。まぁ、そうですよね。「QAの話だから、自分の知っているQAチームの人や、組織横断で動いていて目立つMarkに個別に話しかければ済むじゃん」と考えるのが人情でしょう。それに「向こうから依頼があるだろう」とQAチームがコミュニケーションに対して消極的な姿勢でいたことも、このフォームがあまり使われなかった理由だと考えています。
しかし粘り強く「QAチームとしても業務の整理とアサインの検討をしたいので、こちらのフォーム経由でご依頼くださいー」と発信し続け、今ではPO中心に活用してもらえるようになりました。
もちろん、参画・メンバーアサインの後は、もっとスクラムチームに近い位置で、一緒にプロジェクトに取り組んでいます。
エンジニアLTでの登壇
当社では月に2回くらいのペースでランチタイムにエンジニアLTの時間を設けています。発表者は開発エンジニアが多いですが、QAチームからも何人かが手を挙げて、それなりに頻繁に登壇しました。「QAチームがどんなことを考えていて、どんなことをやっているかを広く知ってほしい」という思いで入れ替わり立ち替わり登壇していたら「QAエンジニアも色々なことを知っている」と思ってもらえたようで、リクエストをもらうようにもなりました。
もちろん、Kent Beckの著作で和田卓人さんが2017年に訳された『テスト駆動開発』（オーム社）の付録Cのことです。結構な大仕事で、かなり真面目に資料を作って発表しました。
また、うれしいことに、
というリクエストもいただいたので、テスト技法の実践レクチャーの形でお応えしました。「ブラックボックステストの設計をどんなふうにやるかお伝えしても、あまり響かないだろうなぁ」と思っていましたが、テストの世界で当たり前に使っている言葉や概念でも、開発エンジニアにとっては新鮮な学び・気づきにつながったようで、たいへん好評でホッとしました。
Slackでの日常コミュニケーション
ビジネスチャットツールを使っている会社は多いと思いますが、当社QAチームでは自分が関わるプロジェクト中心にSlackでのコミュニケーションを推し進めています。QA用のチャンネルを作って開発側と非同期の動きを取るのはもちろんですが、むしろ、単にそこに閉じこもるのではなく、どんどん出ていくようにしています。
仕事がうまくいくかどうかのポイントは、いくつかあると思いますが、普段のコミュニケーションが活発に行われていることで信頼関係の構築が進められる点は、考慮していいかもしれません。開発とQAは対等です。どちらも素晴らしい仕事をしますし、どちらもプロダクトとビジネスと顧客のことを考えています。
アイスブレイク職人
2020年は世界規模の新型コロナウイルス感染症（COVID-19）により、業務のデジタル化・オンライン化が一気に進みました。当社では以前よりリモートワークができる環境ではありましたが、物理的に会議室に集まってミーティングをしていたものがすべてオンライン会議になり、戸惑いややりにくさを感じていたことは否めません。
オンライン会議をやったことがある方はわかると思いますが、時間になって参加者がばらばら集まってくるような会議では、最初みんなミュートしていて、誰も何も喋りません。そんな状態から会議を進行する司会役（ファシリテーター）は大変そうでした。そこで、積極的にアイスブレイク代わりの雑談を勝手にするようになりました。参加者の部屋やバーチャル背景にツッコミを入れてみたり、髪型を変えた人をいじってみたり、最近あったおもしろ話をしてみたりと、自分の興味の赴くままに喋りました。ミーティングが始まる前の数分だけの雑談ですが、思いのほか好評でした。
こういう声、とてもうれしいです。
コロナ禍の慣れない環境で、誰もがストレスを抱えやすい状態ですから、ちょっとした雑談がとても前向きな効果を与えられるのかな、と思っています。皆さんの職場でもオンライン会議のときにトライしてみると良いかもしれません。
QAエンジニアが対象とするのは、ソフトウェアの品質だけではありません。ソフトウェアを作るのは人であり、人々が集まっているのが組織ですから「人と組織の高品質化」もまた、重要なミッションです。知識が明らかに不足しているエンジニアや業務フローを把握していないステークホルダー、全体としてモチベーションが低いような組織では、良いソフトウェアなど開発できるはずがありません。目の前の「人」に接し、いろいろな「不足」を上手に補うことは、QAエンジニアに必要なスキルだと考えます。皆さんはどう思いますか？
◉結論ラスト
それではこの記事の結論です。最初に提示した結論ファーストから大幅に言葉を増やしていますが意味は変えていません。
実績ゼロ・信用度ゼロからスタートしたQAチームが、スクラムチームとプロダクトに寄り添って成果を少しずつ上げていくことができた鍵はなんでしょうか。卓越したテスト技法などではありません。優れたテスト設計でもありません。アジャイル開発におけるテストをどう進めるべきかの知見ですらありません。それは「コミュニケーション」でした。スクラムチーム、すなわち、PO・SM・開発者と目線を合わせ、スクラムがどういうものかを学び、品質にまつわる難問に対して一体となって立ち向かっていく体制を構築したことで、結果として、実績や信用も積み重ねることができた1年でした。
「関係者とのコミュニケーションが円滑に取れていれば、うまくやれる」というのが、2020年に当社QAチームが業務の中で得た学びだった、ということです。
「コミュニケーション」というキーワードを頭に置いて、この記事全体を再度読み返してくださると、さらなる発見があるかもしれません。
◉おわりに
2020年はチームとして形ができたばかりで、アルバイトを入れても5人しかいないのに「QAチームは品質を通じてビジネス価値の向上に貢献するべきであって、テストをこなすだけの存在ではない」とリーダー以下一同、大それた青写真を描いてスタートしました。「品質を向上させる方法はテストだけではない、いや、むしろ金銭的・時間的コストがかかるテストより効果的なアプローチはいろいろあるんだ」という考え方は、QA界隈ですら浸透しているとはいえませんが、幸い当社では「やってみろ」と言っていただけました。これまで述べてきたように「コミュニケーション」を軸に、関係各位のご協力とQAチームメンバーの奮闘により、この1年間で見られる成果も出てきています。その一方で、全体的に課題の方が圧倒的に多いのも確かです。これをどう未来に向けて解決していくかが大事になってくると思います。いよいよ正念場を迎えるのだという気持ちです。
ここまでの雑文でお目にかけたのは、そんな若いQAチームが悩みながら進んできた等身大の戦いの記録です。なるべく詳しくお伝えしましたが、不明瞭な点も多いかもしれません。ひとえに執筆者の文章力が責めを負うべきものです。併せて、足りない部分は皆さまの想像力・課題認識力にて補ってくだされば幸いです。
そんな当社QAチームでは、優秀なQAエンジニア・テストエンジニアの皆さんと仕事がしたいと切実に考えています。転職するかしないか・応募するかしないかを一切問わないカジュアル面談で包み隠さずお話ししておりますので、ぜひ当方にお声がけください。
この1年、また元気に過ごして、2021年の暮れにもふりかえり記事を書けたらいいなと思います。
メリー・クリスマス。