ビジョナリー・QA 1年戦記 2020

この記事はGLOBIS Advent Calendar 2020の24日目の記事です。

ゼロから始まった「ビジョナリー・QA」の1年間の業務と成果を等身大で記しました。

当社グロービスのQAチームは9月のテックブログで「ビジョナリー・QA」と自分たちを表現し、ありがたいことにアジャイル開発、特にスクラム実践者を中心に、多くの皆さまから反応を頂戴しました。

そんな「ビジョナリー・QA」が2020年、一体どんなことをしてきたのかを、この記事では主に業務面から振り返っています。チームの理念がどうやって作られたのかなどの背景は、ぜひこちらの記事をご一読くだされば幸いです。

◉結論ファースト

「よーし、クリスマスイブのAdvent Calendarだし、パパ張り切っちゃうぞー！」と独り身なのにやる気を出して書いたら、トータルで12,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チームが取ったアプローチとして、テストの見通しを立てて計画し、設計し、実行するというオーソドックスなやり方に加え、アジャイル開発に適したテスト技法である（と当時から考えていた）探索的テストを取り入れました。加えて、アプリチームのスプリントプランニングに参加し、常に開発の状況と計画をキャッチしていたことが特徴的な取り組みかもしれません。キャッチにとどまっていた部分は反省点であり、この先で進歩していきます。
いくつか改善ポイントはありつつも、アプリチームとは歩調を合わせることができるとお互いに認識したことで、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チームに対する信頼感を構築していったことが、このプロジェクトで得られた大きな成果であると考えています。

4. 【プラットフォーム開発】データテーブルの大幅な最適化プロジェクト

当社の開発組織は2016年に立ちあがり、急速に拡大しました。その過程で生まれていた技術的負債を多少なり解消するためのプロジェクトがこちらです。これまで学んだ知見を広く生かすことができたプロジェクトですが、今回は法人向けのシステムに対する改修であり、ビジネスのワークフローを含め、さらなる知識を蓄える必要がありました。

大規模なリグレッションテストが求められつつ、リリースは1ヶ月後に迫っているという極めてタイトな状態でした。そこで、開発者の協力を得て観点出しを行い、マッピングして全体像を示すところから始めました。そのマッピングを見ながら、どこを重点的にテストしてほしいか・どのくらいやれば安心感が得られるかをPOに尋ね、認識を一致させました。スクラム風に表現すれば、QAプロセスにおける「完成の定義」を決めたのです。こういった活動を通じて、POをはじめとしたスクラムチームが安心感を抱けるようにと心を砕き、無事リリースにたどり着くことができました。

この時期には、以前のテックブログでもお伝えしていたCodeCovの導入が行われました。CodeCovで分析したところ、このプロジェクトを実施していたスクラムチームはユニットテストでのコードカバレッジが高いことが示されました。既知の問題を除いたバグがほとんど検出されなかったのは、開発者がしっかりとユニットテストを行っているためだったのです。E2Eテストでの不具合が多くて困っているというケースをよくQA界隈で見聞きしますが、やはり開発者によるテストが解決への王道なのだと改めて認識しました。

5. 【アプリ開発】iOSアプリ開発 フェーズ2

このプロジェクトは波乱万丈で、当初1ヶ月半くらいの見込みで8月スタートしたものの、やむをえない差込リリースが相次いだことと、Sandboxの仕様に翻弄される中で品質を担保する必要があったことから、最終的なリリースは12月になりました。リリース後にはAppStoreでも好意的なコメントが寄せられ、ビジネス価値への貢献を強く感じられるプロジェクトでした。

経験のある方にとっては先刻承知のことですが、iOSアプリの課金実装なのでAppleが提供するSandboxを使いました。Appleから提供されている機能が圧倒的に不足していることに加え、Sandboxの仕様がたいへん複雑でした。加えて、時期が悪くiOSのバージョン（当時は14βと13以前）によって挙動が大きく異なったことも相まって、極めて苦戦しました。以前実施した課金プラットフォーム切り替えでの経験が生かせるはずだという当初の目論見はあっさりと崩れ去り、苦難の道を3ヶ月以上も歩むハメに陥ったのです。

QAチームがここでも最も重要視したのは開発チームとの関係性でした。困難な課題に対して、QAと開発が一丸となって取り組む構図を作ることができました。今回の体制では、主にSMとのコミュニケーションを密にしました。Sandboxでできなかったことの報告をSMに毎日報告し、一緒に判断していくようにしました。ありがたいことに、SMやPOからは好評で、スクラムチームのスピードを極力落とさずに高品質なプロダクトをリリースする姿勢が取れました。

スクラムに入るか入らないかという議論が多いですが、そこに眠る真のイシュー（課題）は「コミュニケーション不足のため、距離感が遠いこと」であると、当社QAチームでは考えています。

6. 【Web開発】更改プロジェクト

「QAチームはテストだけが仕事ではない、品質の門番ではない」という認識が組織内に浸透してきた秋口から参画しているのが、こちらのプロジェクトです。国際展開を見据えている開発組織として、技術的負債の解消も兼ねた更改を進めています。POやSMがいち早く進め方などをQAチームに相談してくれたプロジェクトで、組織のビジネスにとっても重要であることから、いわゆる「上流」の段階から参画しています（アジャイル開発なので「上下」という表現には疑問符が付きますが）。

このプロジェクトでは、「Whole-Team Approach」すなわち、品質はQAチームに頼るのではなく、スクラムチームが高めるものであることだと捉えて進めています。「QAチームもテストはやるけれど、スクラムチームが自分たちでできるようになることが大事だよね」という目標を共有し、そのための打ち手をPO・SM・開発者と相談して進めています。
「テストが自分たちでできるようになる」ためには、どんなことができるようになる必要があるでしょうか。たとえば、経験のあるQAエンジニア・テストエンジニアにとって、テスト設計をする（テストケースを書く）ことは、そんなに難しく感じないかもしれません。しかし、今までテストのスペシャリストとしての道を歩んでこなかったスクラムチームのPOや開発者には、新しいことだらけで、とても大変なことです。さらに、スプリントプランニングの時点でテストまで考慮して計画を立てることができるようにならなくてはなりません。他にもまだまだありますが、一歩ずつ進むべき道のりなのです。
QAチームは品質の側面からスクラムチームと共に進んでいます。ゆくゆくはテックブログで述べたようにQAチームがいなくても自立して歩んでいけるような状態につなげることが、QAチームに期待される役割となっています。

7. 【横断組織貢献】SDS・SBR

せっかくなので、開発の現場以外の側面に関わる取り組みのお話も加えておこうと思います。当社開発組織で取り入れている「Scrum@Scale」という大規模スクラムの手法では、SDS（Scaled Daily Scrum）とSBR（Scaled Backlog Refinement）というイベントを定義しています。この両方にQAチームから1人、まぁ、私なんですけども、参加しています。

SDSは各スクラムチームのSMが集まるデイリーイベントです。自チームのゴールの達成を妨害する要因を特定し、解消に向けたアクションを取ることが目的です。各スクラムチームの状態を横断で把握できる有用な場であると同時に、組織共通の完成の定義（Definition of Done）の設定やステージング環境不足といった横串で取り組むべき問題解消に動きます。QA視点で貢献できる割合が大きいイベントです。

SBRは、POとステークホルダーが集まってPBI（Product Backlog Item）の紹介と承認を受ける週次のイベントです。S@Sのガイドでは、バージョン1.02でPOサイクルのイベントとして記述されていますが、執筆時点で最新のバージョン2.1では取り上げられなくなっています。新版で強調されるようになったPOのチーム・会議体も運用し始めていますが、一方でSBRも引き続き重要であると当社では判断し、継続開催しています。
SBRではビジネス側の要望（Requirement）に対するユーザーストーリーが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チームとして動いている以上、コミュニケーションは最も課題になりやすいポイントです。いくつか取り組みがあり、効果があったものも、あまり効果的ではなかったものもあります。少し挙げてみましょう。

その1. 参画するプロダクトの決定

少数精鋭を旨とするQAチームとはいえ、QAエンジニアの数がプロダクトの数よりも少ないとあっては、すべてのプロダクトに対してコミットすることは不可能です。また「1人アサインはしない」ということを意思決定していますので、いきおい、参画できるプロダクトには限界があります。
QAチームでは参画するプロジェクトをリスクベースの発想で評価し、選択しました。それぞれのプロダクトのリスクの大きさと、発生しやすさを加味して、上位2つのプロダクトに対してQA活動を行うことにしました。
予想できると思いますが、この方法だと、お金が関わるプロダクト、特に課金実装のプロジェクトに自然と決まってしまいます。それもあり、2020年は課金に関わる業務が多かったです。

その2. QA依頼フォーム

ほぼ初期に導入したのが依頼フォームです。

（微妙に言い回しが違うのは更新漏れですねぇ）

「QAチームに依頼したいけれど、誰に話しかけていいか・何を伝えればいいかわからない！」という課題に対する打ち手として捻り出したのがこの依頼フォームです。QAチームが提供できるメニューを整理して表示し、合わせてスクラムチームの目線からの優先度や課題感を汲み取ることを目的としていました。

このフォームはどのくらい使われたと思いますか？　なんと、数ヶ月間全く使われませんでした。URLをSlackのQAチームチャンネルに提示したものの「QAの話だから、自分の知っているQAチームの人に個別に話しかければ済むじゃん」と思われてしまいました。それに「向こうから依頼があるだろう」とQAチームがコミュニケーションに対して消極的な姿勢でいたことも、このフォームがあまり使われなかった理由でしょう。
しかし、粘り強く「QAチームとしても業務の整理とアサインの検討をしたいので、こちらのフォーム経由でご依頼くださいー」と発信し続け、今ではPO中心に活用してもらえるようになりました。
もちろん、参画・メンバーアサインの後は、もっとスクラムチームに近い位置で、一緒にプロジェクトに取り組んでいます。

その3. 社内エンジニアLTでの登壇

当社では月に2回くらいのペースでランチタイムにエンジニアLTの時間を設けています。発表者は開発エンジニアが多いですが、QAチームからも何人かが手を挙げて、それなりに頻繁に登壇しました。「QAチームがどんなことを考えていて、どんなことをやっているかを広く知ってほしい」という思いで入れ替わり立ち替わり登壇していたら「QAエンジニアも色々なことを知っている」と思ってもらえたようで、リクエストをもらうようにもなりました。

もちろん、Kent Beckの著作で和田卓人さんが2017年に訳された『テスト駆動開発』（オーム社）の付録Cのことです。結構な大仕事で、かなり真面目に資料を作って発表しました。

また、うれしいことに、

というリクエストもいただいたので、テスト技法の実践レクチャーの形でお応えしました（参加者の方を指名して、簡単なディシジョンテーブルやテストケースをスプレッドシートで作成してもらったりしました）。当初は「ブラックボックステストの設計をどんなふうにやるかお伝えしても、あまり響かないだろうなぁ」と思っていましたが、テストの世界で当たり前に使っている言葉や概念でも、開発エンジニアにとっては新鮮な学び・気づきにつながったようで、たいへん好評でホッとしました。

その4. Slackでの日常コミュニケーション

ビジネスチャットツールを使っている会社は多いと思いますが、当社QAチームでは自分が関わるプロジェクトを中心にSlackでのコミュニケーションを推し進めています。各プロジェクトでQAプロセスのためのチャンネルを作って開発側と非同期の動きを取るのはもちろんですが、むしろ、単にそこに閉じこもるのではなく、どんどん出ていくようにしています。

仕事がうまくいくかどうかのポイントはいくつかあると思いますが、普段のコミュニケーションが活発に行われていることで信頼関係の構築が進められる点は、当たり前のことながら、もっと主張されてもいいことかもしれません。開発とQAは対等な仲間です。どちらも素晴らしい仕事をしますし、どちらもプロダクトとビジネスと顧客のことを考えています。仲間同士が密にコミュニケーションを取るのは当然のことです。

その5. アイスブレイク職人

2020年は世界規模の新型コロナウイルス感染症（COVID-19）により、業務のデジタル化・オンライン化が一気に進みました。当社では以前よりリモートワークができる環境ではありましたが、物理的に会議室に集まってミーティングをしていたものがすべてオンライン会議になり、戸惑いややりにくさを感じていたことは否めません。
オンライン会議をやったことがある方はわかると思いますが、時間になって参加者がばらばら集まってくるような会議では、最初みんなミュートしていて、誰も何も喋りません。そんな状態から会議を進行する司会役（ファシリテーター）は大変そうでした。そこで、積極的にアイスブレイク代わりの雑談を勝手にするようになりました。参加者の部屋やバーチャル背景にツッコミを入れてみたり、髪型を変えた人をいじってみたり、最近あったおもしろ話をしてみたりと、自分の興味の赴くままに喋りました。ミーティングが始まる前の数分だけの雑談ですが、思いのほか好評でした。

こういう声、とてもうれしいです。
コロナ禍の慣れない環境で、誰もがストレスを抱えやすい状態ですから、ちょっとした雑談がとても前向きな効果を与えられるのかな、と思っています。皆さんの職場でもオンライン会議のときにトライしてみると良いかもしれません。

QAエンジニアが対象とするのは、ソフトウェアの品質だけではありません。ソフトウェアを作るのは人であり、人々が集まっているのが組織ですから「人と組織の高品質化」もまた、重要なミッションです。あえて冷たい書き方をしますが、知識が明らかに不足しているエンジニアや業務フローを把握していないステークホルダー、全体としてモチベーションが低いような組織では、良いソフトウェアなど開発できるはずがありません。エンジニアはプロフェッショナルです。目の前の「人」に接し、いろいろな「不足」を上手に補うことは、QAエンジニアに必要なスキルではないでしょうか。

◉結論ラスト

それではこの記事の結論です。最初に提示した結論ファーストから大幅に言葉を増やしていますが意味は変えていません。

実績ゼロ・信用度ゼロからスタートしたQAチームが、スクラムチームとプロダクトに寄り添って成果を少しずつ上げていくことができた鍵はなんでしょうか。卓越したテスト技法などではありません。優れたテスト設計でもメソッドでもありません。アジャイル開発におけるテストをどう進めるべきかの知見ですらありません。それは「コミュニケーション」でした。スクラムチーム、すなわち、PO・SM・開発者と目線を合わせ、スクラムがどういうものかを学び、品質にまつわる難問に対して一体となって立ち向かっていく体制を構築したことで、結果として、実績や信用も積み重ねることができた1年でした。

「関係者とのコミュニケーションが円滑に取れていれば、うまくやれる」というのが、2020年に当社QAチームが業務の中で得た学びでした。

「コミュニケーション」というキーワードを頭に置いて、この記事全体を再度読み返してくださると、さらなる発見があるかもしれません。

◉おわりに

2020年はチームとして形ができたばかりで、アルバイト社員を入れても5人しかいないのに「QAチームは品質を通じてビジネス価値の向上に貢献するべきであって、テストをこなすだけの存在ではない」「究極的にはQAチームは不要だ」とリーダー以下一同、大それた青写真を描いてスタートしました。「品質を向上させる方法はテストだけではない、いや、むしろ金銭的・時間的コストがかかるテストより効果的なアプローチはいろいろあるんだ」という考え方は、QA界隈ですら浸透しているとはいえませんし、本当に正しいか誰も保証してくれませんが、幸い当社では「やってみようよ」と言ってもらえました。これまで述べてきたように、この1年間は「コミュニケーション」を軸に、関係各位のご協力とQAチームメンバーが奮闘したことで、一定の成果を出せました。その一方で、全体的に課題の方が圧倒的に多いのも確かであり、どう未来に向けて解決していくかが大事だと思います。いよいよ正念場を迎えるのだという気持ちです。ここまでの雑文でお目にかけたのは、そんな若いQAチームが悩みながら進んできた等身大の1年戦記です。なるべく詳しく書きましたが、不明瞭な点も多いかもしれません。ひとえに執筆者の文章力が責めを負うべきものです。併せて、足りない部分は皆さまの想像力・把握力にて補ってくだされば幸いです。Twitterや各種勉強会・イベントでも議論しましょう。

そんな当社QAチームは、2020年12月現在、正社員・業務委託・アルバイト社員をすべて含めて9人となりました。しかし、ぼくらが目指す理想に向かって突き進むには、もっと多くの仲間と、優秀なQAエンジニア・テストエンジニアの皆さんと、仕事がしたいと切実に考えています。転職するかしないか・応募するかしないかを一切問わないカジュアル面談で包み隠さずお話ししておりますので、ぜひ当方にお声がけください。

この1年、また元気に過ごして、2021年の暮れにもふりかえり記事を書けたらいいなと思います。
メリー・クリスマス。