20年の歴史があるシステムにどう切り込む？　出前館プロジェクトにおけるLINE QAチームの取り組み

出前館プロジェクトにおけるLINE QAチームの取り組み

鈴木里惇氏（以下、鈴木）：さっそくトークを始めたいと思います。今日は『出前館プロジェクトにおけるLINE QAチームの取り組み』という話をします。

まず簡単に自己紹介です。LINEの開発3センターサービスQA室に所属している鈴木里惇と言います。所属はQA1チームとQA4チームという2つのチームで、マネージャーをしています。

それぞれのチームの役割としては、QA1チームがLINEファミリーサービスを担当していて、QA4チームは今回お話しする出前館を担当しているチームです。

我々のLINEのQAチームが出前館にジョインしたのが2020年10月くらいです。QA4チーム自体は2021年3月にちょうど発足されたチームなので、最近はチームとしても出前館へのコミットメントを強くしていて、今日は特にこの部分の話ができればと思います。

まず、本日話すことと話さないことを先にお伝えしますと、今日のミートアップのテーマでもある、開発のプロセス全般における品質向上に関係する部分をメインに話していこうと思っています。

LINEのQAチームが出前館に参画してちょうど半年が経ちますが、この半年間何をやってきたかという実績を話したいと思っています。また、テストプロセスの中の細かいことは、本日はあまり話さない予定です。

まず前提として出前館のプロジェクト、出前館サービスについて話したいと思います。出前館とLINEの関係はご存知でない方もいると思いますので、なぜ出前館とLINEが一緒に仕事をしているのかをお話します。

ちょうど1年前の2020年3月、LINEグループと出前館で資本業務提携をしました。今は出前館のサービスを、出前館とLINEのメンバーで一緒に作っています。

直近のKPIの実績です。この資料は2020年8月決算期の説明資料です。スライドに書いてある主要KPIは、アクティブユーザー数や加盟店舗数や年間オーダー数としています。

2020年の8月時点の実績だと右肩上がりで、コロナの状況下も関連して、フードデリバリー事業が非常に伸びてきています。これは出前館だけではありませんが、非常に追い風の事業となっており、LINEとしても特に力を入れているサービスとなっています。

次に、出前館のプロジェクトについてお話しします。こちらは出前館の開発についてインタビューを受けた記事です。出前館は2000年からWebサービスを開始していますが、20年以上も続いているWebサービスはなかなかないと思います。そういう歴史の長いサービスの中に我々は2020年からコミットしました。

この記事は開発の取り組みを中心に取り上げてもらっていて、どういう切り口で開発チームがサービス改善しているかという内容になっているので、ぜひ見ていただければと思います。以上が前提です。

出前館が抱えていた開発上の問題

鈴木：今日のアジェンダですが、ここにある3つを話していこうと思っています。

まず1つ目ですが、QA組織の立ち上げと役割定義について話します。

我々が出前館のプロジェクトにジョインしたのは2020年の10月だったのですが、その時まで出前館には内部のQA組織がありませんでした。

テストは業務委託の開発組織を中心に実施していて、開発によりシステムテストまで行った上で納品してくれていた、ということでした。リグレッションテストなどのテストの一部は、テストベンダーさんに委託する形態になっていました。

20年続いているプロダクトなので、システム構成要素も多岐にわたりますし、レガシーな技術やシステムもあります。

我々がジョインして感じた課題としては大きく2つありました。1つ目は、テストプロセスの偏りとテスト品質評価についてです。

テストは開発組織でメインに行われていましたが、本来はテストの組織でやったほうが効率が良いテストもあって、バランスが良い状況ではないと感じました。また、テストベンダーさんに委託したテストについても、効率的なテストを実施できているかなど、テスト品質をもっと評価できる部分があると感じました。

2つ目は、プロジェクト進行や開発プロセスに見直せる部分があるところでした。これは今までのプロジェクトの長い経緯などによって、現在では形骸化してしまったプロセスも残っている、といったことが挙げられます。

QAチームのミッションと期待値を設定

鈴木：我々は最初に、これらの課題に対して、QAのミッションと期待値を設定しました。まずQAが何をしてくれる存在なのかを組織に知ってもらう必要がありました。前提として、LINEには社内にQA組織があるので、LINEの社員はQAが何をやってくれるか、期待値をしっかりわかっているんですね。

ただ、出前館にはQA組織がなかったので、内部にQA組織を作ることで、どのような良いことがあるのかをわかってもらうために、その定義をしっかりしました。

期待値の設定としては、LINEの標準的な方法をそのまま持ち込むのではなく、見えている課題を解決する観点で、しっかりコミットできる期待値を作るように考えました。

そして、期待役割を大きく2つを設定しました。1つ目はテスト活動の質を向上すること。「質」と言うと抽象的ですが、内部でのテストプロセスをより良くすることにコミットしよう、となりました。

具体的には、開発組織とテスト組織のどちらがテストをやるか、バランスを取りました。また、テストを外部に委託しているところは、成果物をしっかり検収してテストのクオリティを上げることを目指しました。

2つ目がプロジェクトの品質向上活動ですね。開発やプロジェクト全体のプロセスなどの見直しを進めました。

以上がスライド1番目の役割定義の部分です。

スライド2番目が組織との関わり方になります。ここは、設定した期待値を実現するために具体的にどうやって進めていったのかを話していきたいと思います。

まず1つ目のテスト活動の質の向上についてです。進め方がいくつかあったので、順番に話していきたいと思います。最初は、QAで見るべきシステムを絞るというアプローチです。

開発のテストとテスト組織のテストのバランスを適正化したかったんですね。前提として、システムテストも含めて開発組織への偏りがあったので、徐々にQAやテストの組織に寄せていくことを考えました。

ただ、すべてのシステムに対するテストをQAで見るのは、コンポーネントやシステムの多さから難しかったんです。そこで、システムごとに優先づけをして対応を進めることにしました。

対象の多さから、すべてのテストをQAで見ることは、コストやデリバリーの観点から現実的ではありませんでした。例えば、すべての開発にQAフェーズを入れていくとコストがかかりすぎるし、当然デリバリーも遅くなる。現状でクオリティが保てているところには過剰に手を入れない、という考えに至りました。

優先度をどうやって決めていったかというと、対象システムを絞るために品質分析を行いました。具体的な方法としては、Outage Reportや不具合数やリリース頻度をもとに品質を分析していきました。

Outage Reportとは、LINEの標準的な開発プロセスにその作成が組み込まれていて、障害が出た時に障害の内容や原因、再発防止策などを記載する障害報のことです。このレポートなどをもとに品質分析を行いました。

具体的にどういうことをしているかと言うと、左が品質分析のレポートのサマリーを抜粋したものです。システムごとに何件リリースしていて、障害がどのシステムでどれくらい起きているか、またQAフェーズで検出できた可能性がある障害はどれくらいあったのか、などの情報を集計しました。

こういった情報を集計して、リリースや障害、不具合の数などからQAチームで重点的に見る部分を絞り込んでいきました。

右の図の緑のセルのところは、全体のシステム数に対して、リスクが高そうと判断してQAチームで担当した部分です。集中的に見るところをまとめ、プロジェクト責任者の承認を取って、こういう体制を組むことにしました。

長い歴史や暗黙知を埋める取り組み

次は、案件ごとに開発・企画とQA実施判断を行った話です。QAで見るシステムを絞ったうえで、そもそもこの案件ではQAチームでテストをやるかやらないかをプロジェクトのみんなで判断する方法を今は取っています。

ここはシステムがそもそも複雑だったりと、しっかりテストしたほうがよいものはQAチームで見る判断をしました。その他の部分は、開発や企画でテストをするようにして、役割の全体最適を考えました。

速いデリバリーを実現するためには、QAの工数が取れないことを理由にリリースを後回しにするのではなく、みんなでテストをできる文化を作りたいと思っているんですよね。

次につながる話ですが、開発とQAはお互い専門職なので、しっかり分業はするんですけど、役割の分断はしないことを心掛けています。QAがテストをする場合も、しっかり開発でテスト設計のレビューはしてもらう。逆もまた然りで、開発がテストをする時にQAでどういう内容でテストするかを監修しています。

「あとはQAフェーズでQAさんお願いします」みたいな状況はなるべく作らないように、そこは密に連携するかたちで、今はプロジェクト全体で品質について考えられる組織を作りたいと思っています。

このスライドはテスト設計レビューの様子を一部切り取ったものです。QAがテスト設計したものをSlackやConfluenceで非同期でレビューをしてもらったり、込み入った話はZoomなどでクイックにコミュニケーションを取っています。

QAチームの内部での動き方をお話しします。テストの質を向上することについてはまず、外部のテストベンダーで実施したテスト成果物は、しっかり内部で検収するプロセスをとっています。いわゆる「設計はこっちでやるけど、あとはお任せ」とはせず、最後までしっかりレビューをするようにしています。

また、検収するだけではなく、QAチームでもテストを実施しています。よくQAにある「このプロジェクトで仕様に一番詳しいのはQAさんですよね」みたいな状況にはまだなく、20年やってきたところに入ってきた中で、開発のほうが仕様について当然詳しくて、そういったメリットを出すことができない状況でした。

そのため、長い歴史や暗黙知を埋めるために、チームでの相互学習が不可欠でした。仕様の共有会など、チームで作った取り組みを頻繁に実施しています。

プロジェクトの品質向上について

2番目はプロジェクトの品質向上活動の話です。これはどうやって進めたかというと、まずはチームで課題分析をしました。

「miro」というビジュアライゼーションツールがあるのですが、それを使ってチームでプロジェクトやプロダクトの課題分析をまず行いました。QAチームが困っていることや、外から客観的に見て困っている課題を挙げてカテゴライズしました。

次に、改善された時のインパクトだったり、改善の大変さ、不確実性の高さをマッピングしました。その優先順位が決まったら、具体的なアクションプランを設定する方法で進めました。

スライド左上は課題出しの部分です。チームの問題をバーッと付箋で書いて、問題の性質をグルーピングして、「ここをまず改善したほうがいいんじゃない？」という当たりを付けます。

右上のスライドは縦軸がインパクトで横軸が不確実性の高さです。まずはできるところから実績を積み上げたかったんですよね。改善の大変さが右に振れているものは、ステークホルダーが多いものになってきます。それよりも、最初は小さい成果を1つずつ作ることを考えて、効果は小さくてもそういったところを進めることにしました。

優先順位を決めたら、課題に対して細かいアクションプランを考えていきました。

次に実際にどういう改善をするかが決まったら、ステークホルダーと実際に改善を進めました。アクションプランに対して、ステークホルダーと現状把握をすることです。

実際に課題を解決していくには、QAチームのみならずプロジェクトのステークホルダーを巻き込んで進めることが大事で、「こういうことが課題だと思っているんですけど、実際はどうなっていますか？」というように、認識と課題を互いに共有しながら進めていきました。

LINEの組織にEffective Team and Delivery室という、プロジェクトの改善に一緒に取り組んでくれる部署があるのですが、最近ではそのような部署とも協力して取り組んでいます。

今までやってきたところは細かい改善がまだ多くて、開発タスクのスケジュールの見える化や、BTSの構成管理の見直しなどをやってきました。もちろん、開発もプロジェクト改善ではいろいろなことにコミットしてくれており、QAチームと一緒に改善にとりくんでもらえる体制になっています。いまはまだやりきれていない部分も多くあって、これからも引き続きプロジェクト品質向上につながる改善を進めていこう、というのがここまでの総括になります。

QAのみならず出前館プロジェクトの品質向上を目指す

鈴木：次が最後ですね。まとめとして課題と展望になります。我々が出前館に参画して半年間で行ったこととして、まずはプロジェクトの課題に沿ったQAやQCのプロセスを作ってきました。そしてプロジェクト改善の土台づくりも進めてきました。

今後は、QAだけじゃなくてプロジェクトに関わる全員が品質について考え、継続的に改善していける体制をよりしっかりと作りたいと思っています。QAだけが品質に責任をもつのではなくて、開発者や企画という、すべてのステークホルダーがしっかり品質について考え向き合うプロジェクト、およびプロダクトにしていきたいです。

今日は、このあとのトークセッションで出前館プロジェクトの開発を担当する豊留さんにもご登壇いただきます。豊留さんの所属している開発チームをはじめ、出前館の開発者や企画者は非常に優秀な方が多いですし、品質に意識をもってくれている方もたくさんいるので、QAチームの取り組みもすごく進めやすい環境だと思っています。

QAとしてはまだまだやれることが多いですし、もちろん20年の歴史で我々にはまだ見えていないところが多くあります。これからもプロジェクトの課題と向き合い、継続的に解決していきたいなと思っています。以上で私のトークは終わりになります。ありがとうございました。

司会者：ありがとうございます。それでは、和田さんにQ&Aセッションのこともいろいろと聞いていただければと思います。

QA・開発・テスト担当のバランス問題

和田卓人氏（以下、和田）：オンライン参加者のみなさん、sli.doには投票できるサムズアップのいいねボタンがあるので、それを押していただけるとアップボートできます。ダントツで5票入っている質問がありますね。プレゼン内容と繰り返しになってしまうところはあると思うんですけど、もう一度明確化するということで、5票入っている質問を見てみましょう。

「テスト担当組織の偏重・開発が行うテスト、QAが行うテストのバランスとはどういった状態が理想だと考えていて、何が問題だったのかを具体的に知りたい」。

ある程度本編でもお話しされたと思うんですけど、例えばどういうものが理想かをお話しいただければと思います。

鈴木：わかりました。具体的に我々が入った時は、テストのリソースが十分にないので、出前館や業務委託の開発組織が手を動かしてシステムテストを実施している状態でした。そこで本来やるべき開発作業になかなか時間がとれなかったり、集中できない状況が多くありました。

開発者が開発からテストをすべて担当することで、全体的に長時間労働というか、ハードワークにになりがちな状況でした。

そのような、開発がテストにかける時間は、専門性をもってテストを効率よく進めてくれる適切な組織やテストベンダーで受け持つというのが1つの解決方法だと思っています。全体的なバランスというのはそういう話ですね。

開発がやるべきテストとQAがやるべきテストについては、スコープが違っていることもあると思います。そこを適切なかたちに見直しました。なんか回答の仕方があまり上手じゃなくて（笑）。

和田：いえいえ、明解になったと思います。ありがとうございます。

出前館ジョイン後の泥臭い苦労

和田：もう1点、みんなが気になるところがあると思っています。LINEはあとから出前館に入っているじゃないですか。

あとからコラボしてジョインする意味で……いま3票入っている質問で「立ち上げ時に、仕様把握やシステムの内部設計などの基本部分は、QAとしてどうやって把握されていったのかを知りたい」とあります。

つまり、あとから入っていったQAチームが、20年歴史のあるシステムに対してどこからどう切り込んでいったか。最初のステップはどうなのかなどを伺いたいです。QA専門チームとして立て直すところに入っていく時に、どこから切り込んでいくかです。お願いします。

鈴木：これはベストプラクティスが本当にあるかわからないんですけど。和田さんがインタビューされた記事でも、開発の方が言っていたところもあったんですけど、「本当に泥臭く見ていかなきゃいけない」と。

そこはテストをしながら、並行して何がどういう作りになっているのか設計文書などを見ながら理解を進めるなどです。あとはわからないことはドメインエキスパートに聞くのは、確実で早い方法なので、一番知っている人に聞くこともやりました。

テストの観点から言うと、どのようなシステムがどれだけあって、それらのテストフェーズは誰がどのようなプロセスでテストしているのかを洗い出したのは、最初にやったところかなと思っています。そこはシステムごとに作っている開発のパートナーや担当者も違うので、テストの方法もまったく違ったんですね。

そこでどういうテストの成果物を作っているのか、どれくらいテストに時間とお金をかけているのか、テストの成果物や方法をひもといていきました。

和田さんのインタビュー記事にもあったんですけど、開発でいう設計文書やソースコードなどのドキュメントをひもといていくのと同じく、泥臭くやるしかないかなと思っています。

知見などはできるだけConfluenceに貯める

和田：基本に忠実というか、泥臭く、まずは現状分析を全面的に推し進めたのですね。人に聞いたり、あるいはドメインエキスパートが誰かを調べたり、聞くところも含めて、読む・聞くプロセスを愚直に進めていった。その結果、わかったことはどこにどうまとめていましたか？

企業ごとに色が出るところですけど、wikiなどにまとめたのでしょうか？聞き取ってわかってきたものは、どこにどうまとめていましたか？

鈴木：我々が見ていくシステムの最低限の使い方や環境といった情報は、Confluenceに基本的にまとめていました。

担当者によって見ている案件やシステムが違うので、その担当者だけの知識にならないように、週次で知見共有会などをしています。たとえば、どのシステムにどういう機能が追加されてリリースされたとか、横断的にナレッジを共有しています。

「その情報って、あなたがもっているだけの情報だよね」ということがあったら、それはwikiに書いてもらっています。あとから誰でも同じ情報を参照できるように、知見などはできるだけConfluenceに貯めるようにしていますね。

和田：ありがとうございました。