上流工程から“俯瞰して考える”ことを意識する　LINEのプロダクトを支えるQAエンジニアのかたち

QAチームが上流工程で品質活動を行うようになるまで

後藤瑞希氏（以下、後藤）：LINE FukuokaのQA Engineering室 後藤と申します。本日は「LINEリサーチ/LINEアンケートにおける上流工程でのQA実践とその先にあったもの」についてお話いたします。

このセッションでは、LINEリサーチのQAチームが上流工程で実践している品質活動の共有と、その活動を通して感じたことについてお話しします。本セッションを通して私がみなさんにお伝えしたいのは、QAエンジニアはテストだけをする役割ではなく、プロセス品質を向上させることもQAエンジニアの大事な役割であるということです。

そして事前に1つ説明したいのが、このセッションに登場する「スクラム」という言葉についてです。私たちのチームでは、アジャイル開発の手法であるスクラムに則った開発に取り組んでいますが、もしかするとみなさんが認識されているスクラムと少し違うかもしれません。

と言いますのも、今お見せしているスライドのとおり、複数のチームからなるプロジェクトの中で、100パーセント教科書どおりに当てはめられない部分があるため、無理なく実践できるように、試行錯誤しながら取り組んでいます。違和感を覚える方もいるかもしれませんが、こちらを承知の上で視聴してもらえるとうれしいです。それではさっそくセッションを始めていきたいと思います。

本日は、始めに私の自己紹介や担当しているプロダクトについてお話し、2つ目にこれまでの道のりとして、私が参加しているQAチームが上流工程で品質活動を行うようになるまでの過程や背景をお話しします。そしてここからが本題となります。実際に私たちが取り組んでいる上流工程での実践内容と、その先にあったものについてお伝えする、という流れで進行していきたいと思います。

では自己紹介です。あらためまして後藤と申します。LINE FukuokaでLINEリサーチ、LINEアンケートのQAを担当しています。前職はケーキ屋さんやお肉屋さんなど、接客販売系の仕事に従事していました。2019年にIT業界未経験からLINE Fukuokaに入社し、テストエンジニアとなりました。

入社した当時から現在に至るまで、LINEリサーチとLINEアンケートを担当しており、2020年5月からQAエンジニアになりました。

次に私が担当している、LINEリサーチというサービスについて簡単に説明します。LINEリサーチとは企業における事業開発・マーケティング活動の最大化を目的にした、スマートフォン時代のリサーチプラットフォームです。LINEアプリ上でアンケートに回答できる「LINEアンケート」と、その約540万人（2021年2月時点）のLINEアンケート会員向けにリサーチを実施できるBtoB向けプラットフォームである「LINEリサーチ」を提供しているサービスです。皆さんの中にはLINEアンケートに登録、回答してLINEポイントを貯めている方もいるかもしれませんね。

チームを一体化することが必要

それでは、上流工程で品質活動を行うようになるまでの道のりについてお話ししていきます。まずは、以前の開発プロセスについて説明します。以前の開発プロセスでは、企画、開発チームでのみスクラムが取り入れられていました。企画、開発チームはスプリント内で要件定義から実装まで行い、実装が完了するまでを完了の定義として次のスプリントに移り、新たな要件に着手していました。

一方で、QAチームは実装が完了した要件について、次のスプリントでテストを行い、テストフェーズがスクラムとは別軸に進行するかたちで稼働していました。このような開発プロセスで作業を進めていくうちに、QAチームは、今からお話しする3つの問題点を感じるようになりました。

まず軽微なバグやUXに対する改善を登録しても、開発チームのリソースが足りず、後回しになってしまうということです。これはテストを進行しているとき、開発は次の要件に着手しているため、それぞれのチームで集中したいスコープがずれていて、「時間があるときに修正しましょう」と伝えても、“時間があるとき”がいつまで経ってもやってきませんでした。

2つ目の問題点は、実装が完了したすべての機能をまとめてテストするため、テストフェーズの進捗によって、リリース日を後ろにずらすなどスケジュールを調節することが多くありました。

また、3つ目として、QAチームが企画、開発チームとのミーティングに参加しても、QAチームが着手するのは開発チームが実装を終えたあとからになるので、着手前に企画チームへ仕様の再確認をするなど、効果的に関われないという問題がありました。

その当時の開発プロセスでこのような問題が浮き彫りになったことで、「ユーザーにより価値があるものを届ける必要があるのでは？」と、私たちQAチームは思うようになり、開発チームに相談したところ、同じ問題認識を開発チームも感じていたことから、LINEリサーチプロジェクトは企画、開発、QAといった役割を超えてチームを一体化することが必要だということに気づきました。

QAチームにできることがもっとあるのでは？

そこで、具体的なチームの一体化について開発チームと検討した結果、QAチームが開発チームの一員としてスクラムに参加する方法を取り、一緒に開発チームとして動くことで、より価値があるものを素早くリリースする体制を目指しました。

具体的な変更点としては、まず開発プロセスを1つのスプリントの中で要件定義からテストまでを行い、リリースできる状態になることを完了の定義とし、その後、次の要件に着手するように変更しました。またそのスプリント内にテストを含めることで、1スプリントあたりの案件のボリュームも見直す必要があったため、企画チームに本件の趣旨を説明のうえ検討した結果、以前より案件量をライトに1スプリントを運用する体制となりました。

このような変更で、QAチームも一体となって動くようになったことに加え、以前であれば参加できていなかった仕様検討ミーティングやスクラムイベントに参加するようになり、結果として要件定義や仕様検討など、上流工程での品質活動に取り組みやすい環境が構築されていきました。

ここまで、以前の開発体制での問題点や開発プロセスを変更した背景などを踏まえて、現在の体制にいたるまでの道のりを説明しました。開発プロセスが変更となり、多くのミーティングにQAチームが参加するようになると、上流工程で仕様の矛盾点を指摘できることが多くなりました。それをきっかけに、QAチームにできることがもっとあるのでは？　と考えるようになり、さまざまなことを実践するようになりました。

QAエンジニアは俯瞰して考えることを意識する

ではプロダクトを支えるQAのかたちとして、上流工程に範囲を広げて取り組んでいる実践例をお話ししていきます。現在のQAチームで行っている実践例をいくつかピックアップして伝えしますと、まずは企画チームが作成した要件のレビューを行っています。要望を共有されたタイミングで、その「アイデア」や「狙い」や「ユーザーに与える価値」を追求します。現行仕様との矛盾点がないかを確認し、魅力的品質を高めるとともに、レビューを通してプロジェクトメンバー全員で事前に共通認識を深めています。

その他QAチームが仕様書のレビューを行い、仕様が詳細まで記載されているか、曖昧な部分がないかを精査し、開発、QAチームで一緒に実装方法やテスト方法を検討するなど、利用から設計に落とし込むフェーズにもQAが参加しています。開発チームは具体的な設計や実装を担当するため、どう作るかという視点で考えることが重要になりますが、QAエンジニアは逆に俯瞰して考えることを意識しています。

先ほどのスライドで紹介したような実践例には、今からお話しするような狙いがありました。まず企画、開発チームだけでは気づかなかった影響範囲に気づき、実装前にクリティカルなissueの防止につなげたいということ。また、QAチームが指摘できるタイミングを早くすることで、実装後に仕様を再考することになる回数を減らし、手戻りを軽減していきたいということ。インシデントに対応する際にかかるチーム全体の工数を削減していきたい、といったようなものがありました。

その他にも設計の初期フェーズに関わり、開発チームとコミュニケーションをすることで共通ロジックを変更することによる影響範囲を事前に把握するなど、テスト設計の品質を上げていきたいという狙いもありました。このように、私たちが行っている上流工程での実践内容は、プロダクトの品質以外の部分にも良い影響を与えたいという狙いのもと、取り組んでいます。

では次に、以前の開発プロセスで抱えていた問題がどうなったのか見ていきましょう。

QAチームが上流工程から品質活動を行うことはチーム全体にとって大きな利点がある

以前の開発プロセスでは、「軽微なバグや改善が後回しになる」「テストフェーズでスケジュール遅延が発生しがち」「ミーティングに参加しても、効果的に関われない」などの問題を抱えていましたが、チームを一体化したあとは、それぞれのチームで集中したいスコープが揃っているので、登録したバグや改善はすぐに対応され、細やかな単位でテストサイクルを回せるようになり、スムーズなテストフェーズの進行が可能となりました。

QAチームがミーティングに参加し、要望段階で質問や仕様書のレビューを行うことで、チーム全体の共通認識として仕様が固まっているため、確認の手間がなく、開発やQAチームがスムーズに着手可能となりました。上流工程の品質活動だけでなく、プロセス改善というかたちでプロジェクトに貢献もできました。

また、QAチームが上流工程で品質活動を行うようになってから、企画・開発チームのメンバーに『QAチームの活動で助かっていること』についてアンケートを取ってみました。テストに関する部分で回答してくれた方ももちろん多かったのですが、なぜ現状の実装になっているのかを教えてくれる、事前レビューをしてくれるなど、テスト以外の部分で助かっていると感じてもらえていることも多いようです。

最初は課題解決をトリガーに取り組み始めたことでしたが、プロジェクトメンバー、サービスにも貢献できていることが客観的に評価されたと思っています。QAチームが各プロセスに関わり、上流工程から品質活動を行うことは、チーム全体にとって大きな利点があると言えるのではないでしょうか。

QAチームは問題、課題の捉え方が変化した

ここまでいろいろと取り組んだ活動とその結果を紹介しましたが、ここからはその取り組みを行った先にあったものについてお話ししていきます。現在の体制になり、開発チームは実装機能に対して、全員が最後まで責任を感じるようになったとということでした。以前の体制では実装フェーズを終えることが、完了の定義だったこともあり、自分たちの実装とユニットテストを終わらせることに集中していたので、そのあとの工程であるテストフェーズのスケジュールに関心が低かったそうです。

そして現状の体制は、いつまでに実装やテストが終わっていないとスケジュールに間に合わないのかを意識するなど、リリースで品質を確保するためにテストスケジュールまで踏まえた実現可能性を一緒に考えるようになりました。

一方でQAチームは問題、課題の捉え方が変化したと感じています。例えば以前のQAチームが問題を抱えていても企画、開発チームに相談しても忙しいだろうとか、手が空いたときにチーム内でやろうと考えていましたが、現在は各チームの問題はプロジェクトメンバー全員の問題であり、全員で立ち向かったほうがいろいろな解決策が見えると考えるようになりました。

その具体例として、2020年に私がJaSST九州と呼ばれるソフトウェアテストのシンポジウムにて、本日ゲストでいらしている和田さんの講演を受けたときの話をしたいと思います。

私が受講した和田さんの講演内容は「質とスピード　〜ソフトウェア開発の典型的な誤解を解く〜」というタイトルで、内容をすごくざっくりとお話ししますと、開発スピードを優先して質を犠牲にする際、ソフトウェアの内部品質、保守性が犠牲にされがち。しかし内部品質が下がると結果的に開発のスピードが下がってしまうので、コードの品質を高く保つからこそスピードが上がりリードタイムの短縮につながる。質とスピードの関係はトレードオフではないということでした。

その話を聞いて私は、「QAチームにおける内部品質って何だろう？」と思いました。私たちQAチームは開発プロセスの中で行われるテストフェーズでも活動しています。そこではテスト計画やテストケースを作成するのですが、更新が漏れていた既存のテストケースを流用したために期待結果が古かったり、急いで間違った画像を使っていたりなど、テストケースを進行しているときに、余計に時間がかかってしまうことがあるなと思い出しました。

「内部品質」という言葉をプロジェクトに関わる1つのチームとして捉えてみる

他にも作業の品質として繰り返して使うテストデータの準備などといった単純作業を毎回手作業で行っていたり、手作業が必要な場面において誤って設定したり、勘違いしたりといったことがありました。ですから、単純で簡単な作業を自動化、機械化したり、またミスや勘違いを引き起こす原因を排除して改善すれば、よりスピーディで、より正確で効率的なものになるのではと思うようになりました。

このように、「内部品質」という言葉をソフトウェアだけでなく、プロジェクトに関わる1つのチームとして捉えてみると、もしかして私たちQAチームの内部品質を改善することもリードタイムの短縮につながるのでは？　と思いました。そこで企画、開発チームに受講した内容の共有と合わせて私が思っていることを相談したところ、「ぜひそれはやっていこう！」となり、各チームと協力しながらQAチームの内部品質の改善を対応する取り組みを行うことになりました。

そしてこれから先は、企画、開発チームの内部品質改善についても、プロジェクトメンバー全員で考えていきたいと思っています。この活動については、2021年に入ってから走り始めたばかりなので、ここでお伝えできる結果がないのが残念ですが、それはまたどこか別の機会で発表したいなと思います。

そして、QAチームが別軸で活動していたときを振り返ってみると、その当時はユーザー目線のプロダクト品質しか見えていませんでしたが、チームが一体化してからはチームのために何ができるのかに意識が向くようになりました。QAチームの課題は、チーム全員の課題であり、チームが一体化したことでお互いに相談や悩みを共有しやすい1つのチームとなれました。

ちなみにスクラムでは、テスト専門のメンバーがいることは想定していません。私たちの事例はスクラムとしてよい事例なのかわかりませんが、自分たちの現状を見つめて、今の自分たちにはこれが最良だということを考えて取り組んでいます。

開発プロセス全体が、QAエンジニアが力を注ぐべきターゲット

それではこのセッションを締めくくりたいと思います。私たちQAチームは、これまでお伝えしたように上流工程で品質活動を行っていますが、その他にソフトウェアテストという手段を用いて、プロダクト品質に直接的に貢献するという活動を行っています。

そのプロダクト品質は、プロセス品質の上に成り立つものになります。そのためQAチームが開発プロセス全体に関わり、さまざまな工程で品質活動を行うことで、その土台となるプロセス品質を向上させることが品質保証を専門的に担うQAエンジニアの本質であり、結果としてプロダクト品質を支えることに結びついてくると、私は思います。

また、QAチームはテストだけをする人たちだというイメージの強さが、プロセス品質に貢献する活動の最初の一歩を邪魔しているかもしれないということと、そのようなイメージを取り払っていくことが必要だと感じました。

私たちのチームにはチャレンジングなマインドをもったメンバーが多くいます。そこに影響を受けたことと、LINE STYLEと呼ばれるLINEらしいやり方や考え方が記された行動規範のようなものの後押しもありましたが、私自身が未経験で入社したことも相まって、「QAはこうあるべきだ」というイメージを自分自身がもっていなかったことで、最初の一歩を踏み出しやすくここまで活動できたのではないかと感じています。

QAエンジニアは品質を保証するためにユーザー目線の提案やバグの検出を行います。それももちろんお仕事の一部だとは思いますが、プロダクトを作るチームの品質にももっと貢献していけるのではないかと思います。

今回の発表で、LINE FukuokaのQAエンジニアがどのような考えで業務に取り組んでいるのか知っていただければと思います。また、本セッションでは上流工程での実践を例に挙げてお話ししましたが、本来の品質保証の意味としてQAチームの果たすべき役割や責務はさまざまなプロセスで行う品質活動も含まれるので、上流工程を含む開発プロセス全体が、QAエンジニアが力を注ぐべきターゲットなのだというイメージをみなさんの中に少しでももってもらえればうれしいです。

以上で私からの話は終わりです。ご清聴ありがとうございました。

増えることを見える化する

司会者：ありがとうございます。質問がメチャクチャきていますね。

和田卓人氏（以下、和田）：メチャクチャ来ています。

後藤：えー!?

和田：いい話でしたね。

司会者：はい。

和田：質問などがありますが、その前提として、まず輪郭をなぞるために規模感を一度伺っておきたいです。「スプリントの長さはどれくらいですか？」とか、「企画、開発、QAチーム。チーム全員だと何人で、QAチームはその内何人ですか」といった、数とか大きさに関するところをみなさん想像できていないので、まずはそこからお願いします。

後藤：はい。スプリントは2週間で1スプリントで、そのスプリントの中にリリースが1回入ります。プロジェクトメンバーは、企画の方が5名か6名ぐらい。開発の方が今7名ぐらいいるのかな？　QAが4名、QAエンジニアが私1人とテストエンジニアが3名います。

和田：5名、7名、4名ですね。規模感の質問が参加者の皆様から多く来ていたのです。

後藤：なるほど。

和田：次に、一番多い質問はこのあたりかな。「上流工程に入り込んでいくとQAチームの仕事は増えていきますが、テストフェーズに影響はなかったでしょうか？」。

後藤：なるほど。たぶんそこも、ストーリーポイントとかに影響すると、ベロシティに影響すると思っています。そこを踏まえた上で、テストの工数がどれくらいなのか。例えばテストケースを進行するにはどれくらいかかるのか、作るにはどれくらいかかるのかをチーム全体の認識として、ストーリーポイントを取ることで理解をいただくというのが強いかもしれないですね。増えるというよりは増えることを理解してもらうというか、見える化するところが大きいかなと思います。

1チームになって1つのDoneの定義を共有するようになった

和田：というと、ベロシティはだんだんスプリントを繰り返すと、自分たちがどのくらいできるか精度が上がってくるものじゃないですか。

ですから、スプリントが回ってくるとうまく回るんですけど、最初は信頼貯金を使うというか、「私たちを信じてください」みたいな感じになるのではないかと思います。講演の中で「QAも含めてスプリントに入るから、全体のストーリーというかスプリントのバックログとしては、いつも開発しか行わないスプリントより機能数は少なくなりますよ」みたいなことをチラッとおっしゃっていましたよね。

後藤：そうですね。

和田：そのあたりは最初チーム全員で了解を取ったというか、プロダクトオーナーも含めて全員である程度認識合わせをしましたか？

後藤：そうですね。以前の体制だと、開発チームが実装に掛かるストリーポイントはわかりやすく可視化されていました。

ですが、開発ボリュームはコード１行修正するだけのすごく小さなものだけど、QAチームのテストは全部リグレッションテストをかけなきゃいけないような、温度感が違っていたものを事前に認識を合わせることで、タスクごとのストーリーポイントにテストを含んだ実態を反映させやすくなって、リリースまでに必要なベロシティにブレが少なくなり、ここはすごく大きいかなと思います。

和田：スクラムでいうところのDoneの定義ですかね。

後藤：そうですね。

和田：つまりDoneの定義が2種類あって、2つのチームが別々のDoneの定義を持っていたのが、1チームになって1つのDoneの定義を共有するようになった。そういう感じですかね。

後藤：そうですね。

和田：僕が勝手にまとめてしまって申し訳ないですけど。

後藤：ありがとうございます。

（一同笑）