開発におけるQA貢献価値はどこにある？　LINE QAエンジニアたちが考える上流から関わることの大切さ

QAの貢献価値を最大化するために

中川勝樹氏（以下、中川）：このセッションの進行をします、LINEの中川です。それではトークセッションにさっそく入っていきます。パネリストのみなさんに登場していただきます。最初にこのセッションからご登場いただくお二人に簡単に自己紹介していただきます。門谷さん、お願いします。

門谷篤氏（以下、門谷）：LINE Fukuoka株式会社・開発2室で「LINEリサーチ」「LINEアンケート」の開発担当エンジニアの門谷と申します。よろしくお願いします。

中川：よろしくお願いします。では、豊留さんもお願いします。

豊留武氏（以下、豊留）：LINEの開発グループ2チームに所属している豊留といいます。今は「出前館」でサーバサイドのエンジニアとして開発を担当しております。今日はよろしくお願いします。

中川：よろしくお願いします。このトークセッションでは、先ほどの2つのセッションで来ていた質問も合わせて、いろいろお話できればと思っています。

和田さん、さっそくですけど、聞いてみたい質問はありますか？

和田卓人氏（以下、和田）：いきましょうか。いきなり、（前のセッションで）延期した質問をぶつけていきましょう。

聞き方が難しいですけど、例えば、上流工程やQAエンジニアの方々が別チームから同じチームに入ってきたことによって、最初にやりにくいなと感じたことや、やりやすかったことも含めて正直ベースで答えていただければと思います。

「チームに入ってきた当初はいかがでしたか？」というところをまずうかがいたいです。門谷さんに聞いてみましょう。

門谷：そうですね……これ、裏で見ながらどう答えようかなとずっと考えていました（笑）。

（一同笑）

前提をお話ししておくと、僕が「LINEリサーチ」「LINEアンケート」に関わって6年ぐらい経つと思います。後藤（瑞希）さんが入られたのはちょうど2年ぐらい前で、それぐらいからこういった「QAにスクラムチームに入ってもらおう」「上流工程に入ってもらおう」みたいなことを言い始めたんですけど、ぶっちゃけ、これを言い始めたのは僕なんですね。

一緒にQAのみなさんともお話しして、そこで開発とQAでいろいろ話して、まとめて企画がいる東京の事業側のチームに持っていって、「こういう理由でやりたいですよ」と話した。なので、開発としては煙たがるよりは、むしろ入ってほしいなと前から思っていました。

最近は事業部側のリーダー、プロダクトオーナーとも前々から話していました。バグをすごくがんばって検出してくれるのは前からやってくださっていたので、そういった面の品質としては、すごく感謝というか貢献いただいていると思っていました。

ただ、それ以外のユーザビリティやUXなどの面でも、QAチームにもっと貢献してもらえる部分があるんじゃないかと、お互いに話して思っていたところなので、それを具体的にやり始めたのがちょうど2年前ぐらいだったと思います。なので、もともと課題感としては自分だけでもなくプロジェクト内の一定数のメンバーがもっている状況でした。

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

QAと開発の距離はどうやって近くなったか

和田：端的に言って、一つのチームになる前と後で一番変わったことや印象的なことは何ですか？

後藤瑞希氏（以下、後藤）：変わったこと……企画の方とも開発の方とも距離はすごく近くなりました。

以前だと実装されたものにすごく軽微なバグを見つけて指摘をして直してもらうのは、なんかこっちが気を弱くしてしまうというか。「いいかな、いいかな？　報告しようかな？」みたいに弱気になるところがあったんですけど、「こういう現象が起きるんですけど、これ直したいんですよね」みたいなことを軽く相談できるようになったりしました。

テストの方法も「どうやったら、もうちょっと影響範囲を狭めてやれますかね？」のような相談をする機会がすごく増えましたね。距離が近くなったことで、相談しやすくなったので、そこがすごく大きかったなと思っています。

和田：いい話ですね。ありがとうございます。

後藤：（笑）。

和田：というような感じでいろいろ聞いていければというところです。

メンバーのスキルギャップはあったか？

和田：基本的にはこのパネルでは、せっかく開発エンジニアの方々が参加しているので、エンジニアから見たQAという視点を入れていきたいと思うので、開発エンジニアの方々に向けた質問を積極的に引っ張っていきたいと思っています。中川さんも裏でおもしろいのあったら、どんどんピックアップしてきてください。

中川：はい。

和田：voteの多い質問からまず拾っていきましょう。まずは6votesの「上流に活動を広げるにあたって、あるいはチームにジョインする上で、メンバーのスキルギャップは問題化しませんでしたか？　もしギャップがあった場合、そのギャップをどのように埋めていったのでしょうか？」。

メンバーのスキルギャップ。そうだな、いろいろありますよね。これまで行っていた領域よりさらに……よくテストプロセスとかの話だと「シフトレフト」という言葉で表現されたりしていますよね。

いわゆる上流工程に云々みたいな話は、最近よく「シフトレフト」と呼ばれることが多いんですけど、前の工程に行くとやることが変わってきますよね。その時にスキルギャップみたいなものはあったか、どうやって是正していったか。

これは上流に行くにあたっての質問なので、まずは後藤さんにうかがうことになるんですかね。このあたり、これまでとは違うことをやり始めるじゃないですか。

やろうと思っていたけど、最初のうちはうまくいかなかったこと、違うマインドセットやスキルセットが必要だったこと、そういったQAチームとして変わっていかなきゃいけないところや、努力しなきゃいけないところは何かありましたか？

後藤：以前だといわゆる一般のユーザーが使う部分の気持ちをすごく考えてやっていたんです。それがステークホルダーがたくさんいて、そこに対しての優先度や期待結果がについていろいろな観点を持たなきゃいけなかったんですよね。単にバグを見つけて報告するだけでなく、スケジュールなどを加味しながら影響範囲が少なくなるように改善を提案したり…。

あとは、リサーチ業界のノウハウなど、基本的な知識のようななところはつけていかないと、せっかくミーティングに参加しても、開発の方と企画の方が何をお話しされているのかが最初はわからなくて、すごく戸惑った時はありました。

門谷：補足いいですか？

和田：どうぞ、もちろん。

門谷：ユーザーと言われたのは「LINEアンケート」で実際にスマホでアンケートに回答するモニターさん、いわゆる回答者さんが一般的には一番想像しやすいユーザーだと思います。我々が作っているもう一方、「LINEリサーチ」というサービスは市場調査をするリサーチャーさんという職種の人向けのツールで、複雑なところが多いんですよね。

リサーチ業界のドメイン知識がだいぶ必要になってくる開発内容ではあります。そこも「システムがこうなっていればリサーチャーさんはより使いやすいだろうな」などを想像するのが難しかったりはしますよね。

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

和田：ありがとうございます。さまざまなステークホルダーの観点からゴールを考えていくところ、そういった意識を広げるところ、そのヒアリング、ドメイン知識の吸収などの仕事が増えるわけです。

それについていくためにチームとしていろいろ努力したというか、学びのプロセスも含めて参画していったんですね。

出前館プロジェクトにおけるLINEチームの働き

和田：では、リサーチの方々にばかりお話をしていただいているので、次は出前館の方にお話をうかがっていきたいと思います。

豊留さん、同じ質問になるのですが、まずは現状というか、QAのプロセスが入ってくる前と後でどう変わったか、最初どういうふうな印象を抱いたか、あるいは逆に期待していたことは何だった、実際に一緒に仕事を始めて大きく変わったことは何か。

そういったところをうかがっていきたいと思います。参画前後の期待値や変化などをうかがっていきたいと思います。よろしくお願いします。

豊留：私が出前館に入ったのが2020年の秋ぐらいで、出前館に関する業務の知識をぜんぜん持っていない状態で入りました。QAの方と一緒にやっていく上では、同じく未知の領域を開拓する、仕様を探るような、探求者みたいなかたちでした。

調査もしますし、調査内容に対して、QAの方が設計書のレビューいただけるので、そこで指摘いただいたりして、同じように仕様の理解、ドメインの理解を広げていく仲間という感じでずっとやっていました。

今もその気持ちは変わらないですね。なので、入っていただくことで自分だけでは調査が及ばないところまで補足をもらったりできて、すごく頼もしいなと思っています。

和田：安心感があるというか、背中を預けられるみたいな感じですね。

豊留：そうですね。常に補足してくれます。

中川：僕からも鈴木さんに聞きたいんですけど、プロジェクトに入る時に意識したことはありますか？

鈴木里惇氏（以下、鈴木）：入る時に意識したことですか？

中川：はい。QAチームが出前館の体制に入っていく時に意識していたことはありますか？

鈴木：先ほどのスライドにもありましたが、出前館というLINEじゃないプロダクトに入っていく中で、前提やQAの引き継ぐ文化がないなど、そういったところが違いました。

そこはスライドにも書きましたが、LINEでのQAの経験やいままでのやり方を持ち込むんじゃなくて、出前館プロジェクトとしてどういうことが問題で何を解決していくべきか、単純にプロジェクトの困っているところを改善・解決していくことに目を向けるべきかなと思いました。

そういった、自分たちの役割を制限しないところを意識したかなと思います。

和田：役割を制限しない。いいですね。

出前館×LINEの地道なコミュニケーション

和田：sli.doの質問もいくつか拾っていこうと思います。実際に出前館の案件でも仕様書レビューの話が出てきました。

（質問を見て）仕様書レビューというかドキュメントを読み解いていく話ですかね。こういう時に、仕様書自体の品質を上げる工夫……ただ読むだけじゃなくて改善して変えることを含めて、特に仕様をひもといていって実際にそれを立体化していく際にドキュメントの質を上げる工夫で、何か取り組まれていることはありますか？　これは鈴木さんからうかがっていきましょうか。

鈴木：まずは作成者に単純に読みづらい部分はフィードバックはしていると思います。そこはシステムや担当者でぜんぜんクオリティが違うところだと思います。

仕様書もWikiに書いたりするんですが、読みづらいことだったり、単純に内容がわからないところは、フィードバックして反映してもらう、その積み重ねかなと思っています。こちらで「こういうテンプレートを使って書いてください」ということは特にしていないです。

和田：どちらかというと、フィードバックベースで地道にやっているみたいな印象になるわけですね。

鈴木：はい。

和田：後藤さんはいかがですか？　そのあたりの仕様書やドキュメントの質を上げる工夫や、レビューしながら質を上げていく工夫のようなことで、何か取り組まれていることはありますか？

後藤：チェックリストを作っています。観点チェックリストのような感じで、この前までは後藤の秘伝のリストだったんですけど、最近メンバーにも共有したチェックリストがあります。

LINEリサーチの中で、「ここに実装が入るんだったらこっちはどうなのか？」「使う権限が違ったらそっちはどうなるのか？」など、観点漏れが多かったりすると、テストを進行する時に「こっちってどうなるんだっけ？」という、そこで観点が出てきてしまうと、また実装してもらってバグを登録して改善してと手間が発生してしまいます。

仕様書の段階で、少しでも観点漏れがなくなるように、チェックリストを使って、仕様書のレビュー時にチェックする感じですね。

和田：なるほど、ありがとうございます。その秘伝のタレがだんだんチームの共有の財産みたいな感じなんですね。

後藤：そうなればいいなと思っています（笑）。

和田：そうですね。ありがとうございます。

開発とQAのギャップをどう埋めるか

和田：どんどん回していきますね。この観点でもっとしゃべることがあると思ったら、ミュートを解いていただいてガンガンしゃべっていただければと、割り込んできていただければと思います。

質問がバンバン上がってきていますね。スキル差の話、お互いに求めることみたいな質問が増えてきたので、そのあたりを聞いていきます。

「開発とQAとでは知識やスキルに差があって、同じレベルで議論するのが難しいこともあると思います。そのギャップを埋めるためにQA側は具体的にどういうことを勉強していますか？　また、開発側から見て、QAに身につけてほしい知識・スキルはありますか？」。

「開発チームの立場から、QAチームに持ってほしい資質とかスキルセットはありますか？」みたいな質問もありました。要するに「開発チームにとって、QAのスキルセットを持ったみなさんに期待することとか、身につけてほしい知識・スキルというものはどういうものがありますか？」というのお話から最初にうかがっていこうと思っています。

誰にうかがおうかな？　門谷さんにうかがいましょうかね。「QAの人たちとギャップを埋めるためにどういったことを期待するかとか、開発チームから見てQAの人たちに身につけてほしい知識やスキルはありますか？」というところです。

門谷：一言で言うと、エンジニアリングになるのかな？

中川さんも参加した、2020年12月のLINEのイベントで話されていたり、LINEのテスト自動化チームがよく発表していたりしています。自動テスト、E2Eテストをうちのプロジェクトでもどんどん取り入れていきたいと思っているんですが、どうしてもプログラミング経験者でなければ取っかかりが難しいところがあります。

リソースの問題もあって、LINEでもすべてのプロジェクトでできているわけではないですが、会社としても自動テストによってもっと品質や開発効率の向上を目指す方向だと認識してます。

未経験であっても、そういったところを勉強して身につけてもらって、よそのプロジェクトでの事例から学んで導入することは可能だと思います。ぜひチャレンジしていただければ、さらに品質・効率向上につながっていくと思っています。

和田：ありがとうございます。ということで、開発チームから特にQAのスキルセットを持っているみなさんにさらに期待すること、またギャップを感じることとしては、エンジニアリングスキルということでした。端的に言えば、コードを書いて設計するスキルがもっとあれば、もっとコラボできるという期待があるわけですよね。

というところで、今度は後藤さんにおうかがいするのは、具体的にそういうギャップを埋めるために、何か努力していること、工夫していること、ジョインしたQAチームとしてやっていることはありますか？

後藤：私は未経験で入社して2年経ったぐらいなんですけど、コードも書けないですし読めないですし、そのあたりを開発の方とお手伝いするみたいなことができていないのがすごくもどかしいところでもあったりします。

逆にそれ以外のところで、全体の進捗を確認したり、便利なツールがあったら導入してみたり…など、「みなさんが仕事をしやすく、よいプロダクトにできるように」みたいなマインドセットで仕事をしている感はとてもあります。

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

リモート時代における協働の具体的方法

和田：今は状況が状況なので、たぶんリモートワークをされていると思うんですよね。ただ、時期的にはリモートワークじゃなかった時期もありますよね。1年以上前から参加されていたので。

そういった時の働き方として、QAが得意な人と開発が得意な人でペアプログラミングやモブプログラミングみたいな、スクラムの中でやるペアワークをする試みはやっていましたか？　それがコロナ禍の状況において何か変わりましたか？　この2つをうかがいたくてですね。

これは2チームともにうかがいたいんですけど、僕の見ているいくつかのチームだと実際によくやるのが、テストが得意なテストエンジニアとプログラマでペアプログラミングをよくやるんですけど、そういった取り組みはやっていましたか？　それがここ1年ぐらいはどんな仕事のスタイルになっています？

「うちのチームはペア設計やペア作業をやっているよ」というところはありますか？　出前館さんとかは協働の部分ではいかがですか？

豊留：出前館では今のところあまりやっていませんね。最初に参画した時からリアルで会って対面でお話しすることはないです。機会があればたしかにやってみたいなとは思いますね。

和田：ありがとうございます。LINEリサーチはいかがですか？　働き方はどんな感じで、ペア作業などはやっているんでしょうか？　あるいは、開発メンバーとテストのメンバーで一緒のコードに対して、集中しての取り組みはスプリントの中でやったりしていますか？

門谷：コーディングはやっていないですね。テストコードについても、エンジニアしか見ていない状況です。もちろん、今お話をうかがっていてすごくいいと思ったので、ぜひ何か取り入れていきたいなという気持ちにはなりましたね。

ただ、設計についてはそれに近い作業をしていると思います。開発とQAと合わせたストーリーポイントを見積もる場を設けているのですが、その場で開発エンジニアの細かい設計の話をすることも多いです。

一見効率が悪く感じられるかもしれませんが、QAメンバーにそれを聞いてもらっていて、「これとこれが同じ部品使っているんだったら、こういうところに影響あるんじゃないかな？」みたいな意見をもらえることもあります。

和田：お互い見ているところが違うんですよね。なので、仕様と仕様の間の矛盾する関係などをテストが得意なメンバーは見てくれているみたいに、背中を預けるというか、期待してガンガン前に進んでいるところはある程度あるんじゃないかと思いました。ありがとうございます。

エンジニアのスキルによってコミット度も異なる

鈴木：今の話でカットインしていいですか？

和田：はい。もちろん。

鈴木：出前館プロジェクトで、僕は豊留さんと働き始めて半年経つのですが、実際には1回も物理的に会ったことはなくて。出前館が始まって、みんなのオンラインの働き方が既に当たり前になっていたので、出前館は北海道、京都、東京など、いろいろなところに拠点があって、そこでオンラインでコラボレーションして働いています。

設計やテストのレビューみたいな活動はZoomで文書を映しながらギャップがないようにすり合わせています。お互いのオンラインの働き方が発達してきたので、そういったところは埋められるアプローチがお互いできているかなという気がしていますね。

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

中川：すみません、僕も割り込みます。協働に関連して「QAチームも開発タスクをお願いされることはありますか？」という質問が来ています。出前館とLINEリサーチの事例ではありませんが、門谷さんが先ほど言っていたTECH@LINEという2020年末の弊社のイベントで発表した事例があって、QAエンジニアが実際に見つけたバグについて、コードを修正してPull Requestも出して、プロダクトにコミットしているという事例もあります。

もちろん、QAエンジニアが開発スキルを持っているか、という本人のスキルセットに依存するところはありますが、コードの修正が可能なQAエンジニアは、担当プロジェクトでの開発に一部参画しているという実績はあります。