LINEのQAは開発に積極的に入っている　開発品質を支えるエンジニアの役割と働き方

改善活動ができないことにモヤモヤしてた

中川勝樹氏（以下、中川）：実は今日最初にみなさんに聞こうと思っていた話が、さっそく質問で上がっていて、「みなさんの仕事のやりがいについてお聞きしたいです」と来ています。具体的に、みなさんQAエンジニア、SETエンジニアとして仕事をされている中でのやりがいはどういうところに感じるかというお話をそれぞれお聞きできればと思いますけど、どなたからいきましょうか？では鳥越さんから聞いてみていいですか？

鳥越健太氏（以下、鳥越）：はい。ちょっと先ほども紹介したんですけど、私は前職で開発をやっていまして、そのときはだいたい納期だったりマルチタスクだったり、タスクをいっぱい抱えている状態でやっていたので、開発のプロセスやテストに関する内容にあまり注力できなかった部分がありまして。モノを完成させるためだけにがむしゃらにやっていて、改善活動に対するモヤモヤがあったと。やりたいけどできなかったと。

こういった部分を、こういう立場、QAという役割を与えていただいて、そこに注力できるといったところが一番楽しいかなと。解決していくというとか、開発のときに思っていた、こういう人がいたら進めやすいのになぁとか、うまく回るのになといったところにも注力できるところに、今はやりがいを感じていますね。それに伴って、バグが減ったりとか目に見えるかたちで見えた時に、達成感を感じたりします。

毎日「品質とは何か」を考えさせられる

中川：ありがとうございます。他の人にも聞いてみようかな。池之上さん、いいですか？

池之上あかり氏（以下、池之上）：はい。そうですね。私が今いるプロジェクトはニュースというタイムリーな情報を扱っているため、非常にQCDのバランスというか、デリバリーに対して非常に早く出したいとか、今この時点でこのプロダクトを提供しないとユーザーへの価値が減ってしまう、みたいなそういうものと日々せめぎ合いですね。

そういうのもありまして、非常に毎日「品質とは何か」を考えさせられるというか、この時このタイミングで今このニュースを必要としているユーザーが求めている品質というのは何だろうというのをいつも考えさせられるので、非常にQAとしては成長させてもらっているなという気持ちでいます。

さらに言いますと、先ほどお話ししたとおり、開発体制が多岐に渡っていまして、開発拠点だけでも、日本だけではなく韓国でも作っていますし、ベトナムのオフィスでも作られていたり。QAも日本とベトナムで分かれていたりするので、その中で一定の品質基準みたいなものをパッと作って、それを守ってもらうみたいなことがなかなか難しいわけですね。

先ほどの求められる品質がいつも変わっていくということと、なかなか作っている人たちもいろいろ個性がありますので、一定に決めることは難しい。だからそのよくある品質基準を決めて、それを守っていくやり方以外に、品質をできるだけバラつきなく、ユーザーの体験を損なわない範囲で揺らぎをもたせて品質を形作っていくという必要性も出てきています。そちらについても、またQAとしての成長を日々求められているという感じで、成長できることが一番やりがいがありますね、という感じです。以上になります。

中川：自身の成長につながる経験が大きいところが、やりがいにつながるという話でしょうか。

池之上：そうですね。

中川：なるほど。ありがとうございます。

ステージング環境にバグが入り込むのを防げた

じゃあ金子さんにも聞いてみたいと思います。

金子茉以氏（以下、金子）：はい。私がやりがいを感じているのはやっぱりあの「Developer Experienceの向上!!」を目標にやっているので、それを感じることができたときですね。現在、PRドリブンE2Eテストという、PR上でE2Eテストを動かす仕組みをやっていまして、それをやることで、開発者により早いフィードバックをしようということで、その仕組みを導入しています。

リファクタリングをしたときに、それを導入したあとすぐにリファクタリングがあったのでそれを活用できて、PR上で早めにissueを発見して、開発者にフィードバックでき、かつQAチームが確認をしているステージング環境にバグが入り込むのを防げたことがありまして。そういうときに役立ったなと思って、やりがいをすごく感じることができました。

中川：ありがとうございます。今のPRドリブンテストの話は、LINE DEVELOPER DAY 2020で実際に具体例を発表したものが、今アーカイブの動画が見れると思いますので、具体的な内容に興味のある方は、こちらを見ていただけるといいかなと思います。

開発プロセスに入って一緒に作り上げたい

ちょっとやりがいのところで、もう少し具体的というか、ちょっと掘り下げてみたいかなと思ったんですけど。鳥越さん、先ほどもともと以前に自分が「こういう人がいたらいいのになと思っていた」ということを目指して、今自分がそういうところをやっている、やろうとして動いているみたいなお話があったと思うんですけど、やりたいと思っていたことはどれぐらいできてますか？

鳥越：そうですね。本当にやりたいことというと、設計の最初から本当に携わって、いろいろ課題を見つけていくというところなんですけど、ちょっと私がまだそこまでできていなくて。開発を中心とした動きのところは挑戦できているかな、といったところですね。まぁ、半分ぐらいやっていますという感じですかね。

中川：実際に鳥越さんのプロジェクトの具体的な話だと、本当にただテストをするとかではなくて、開発プロセスに一緒に入って、開発しているプロダクトコードのコードレビューにも参加したり、プルリクエストを上げて、鳥越さん自身がプロダクトコードに手を入れるという局面もあるかと思うんですけど。そういうのは、以前に鳥越さん自身が開発をしていたときに、携わるQAの人にも一緒に入ってもらいたい、と強く思っていたからですか？

鳥越：そうですね。（以前の職場では）やはり作る側とユーザー側だと、どうしてもユーザー側の声はなかなか優先度が低くなって、使い勝手の部分はどうしても優先度が低くなってしまうので、そこら辺を一緒にやってくれる人がいたらすごいありがたいと思っていました。なので、そういった面をちょっと手伝うというか、協力してできるのは、僕としては楽しいです。

中川：一緒に開発、いわゆるプロダクトコードをメインで書くエンジニアとQAエンジニアと、変に縦割りにするんじゃなくて、一緒にプロジェクトに入ってやるところがけっこう理想的な話だと思いますし、そういうところに鳥越さんのやりがいみたいな話もあるかなと思います。

プロジェクトで積極的に入っていく

金子さんのプロジェクトだと、具体的にどういった動き方をされていますか？

金子：私は、QAチーム側のリグレッションテストをカバーするために、自動テストをやっています。スタートはそちらから始まりました。ですが、今は開発メンバーの中に入って、より開発者が開発しやすい環境を作れるように、PRドリブンを、もうすでに今動く環境はあるんですけど、それをもっとよりよくしたり、あとはカバーできていない部分のテストを追加したりとかしています。

あとは、開発やQAチームも確認する環境などを、よりやりやすい環境にできるようにサポートしたりとか、自動テストがメインなんですけど、それだけじゃなくて、できることはいろいろ手を上げてサポートしていきたいですね。

中川：なるほど。ありがとうございます。やはりいろいろなプロジェクトで積極的に入っていけるところが、おもしろいところの1つかなということが、みなさんのお話からもうかがえますね。

テレビ会議で顔を合わせて話す時間を可能な限り取るようにする

質問が他にも来ていて、次のテーマに行く前に、ちょっとみなさんに聞いてみたいかなと思ったんですけど、「みなさんオフィスが違うと思いますが、開発におけるコミュニケーションの取り方の工夫とかありますか？」ときています。

3人の中で関わっているプロジェクトのメンバーが、本当に拠点がバラバラなのは、池之上さんのところはまさしくそうですね。先ほど自己紹介のところでも話していたと思うんですけど、実際に池之上さん自身は東京で、ベトナムとかそういった拠点の話とかも出てきましたよね。ちょっと池之上さんにこのあたりのお話を聞いてみたいかなと思うんですけど、拠点が違う、関わっているプロジェクトのメンバーの拠点がバラバラという中で、コミュニケーションで何か工夫していることなどありますか？

池之上：そうですね。基本的に通訳さんがいたり、あるいは翻訳ツールがあったりとかということで、拠点が違うというか言語が違ってもという意味では、だいぶやりやすい環境があるとは思います。

工夫はそうですね。やたらめったらなわけじゃないですけど、できるだけテレビ会議を使って、顔を合わせて話す時間を可能な限り取るようにしていくことで、信頼関係の構築には気を使っていると思いますね。

あとは簡単な言葉でもいいので、言語が違う方にはその方の国の言語で挨拶をしてみるとか、そういうことをしていますね。なので、ちょっと拠点が物理的に離れていることで、どうしても心というか信頼関係が構築しづらいので、その点についてはそういう細やかな工夫をしてやっています、というのが回答になります。

中川：なるほど。ありがとうございます。

拠点間のコミュニケーションは昔よりも取りやすい

金子さんとか鳥越さんは、何か、今プロジェクトのメンバーで物理的に離れているというのはありますか？

金子：LINE Creators Marketだと、企画チームだけは東京です。開発、QAはみんな福岡メンバーですね。だけど、今はほとんどみんなリモートワークをしているので、基本すべて会議はオンラインになっていますし、リモートに入ってからも、特段何か障害が起きているとかはないですし、あと定期的にミーティングもやっているので、障壁とかは特にないですけどね。

中川：そうですよね。実際に今このパネルディスカッションも東京2名、福岡2名でお送りしていますが、これは物理的にやるんだったら、どちらかに集まるみたいな話になるわけですけど、逆にオンラインで気軽にできるようになっているというのもあって。

最近は、自分もやっぱりオンラインでやるのがほとんど当たり前になってきているので、逆に拠点間のコミュニケーションは、昔よりも取りやすくなっている部分もあるんじゃないかな、と思うところもありますね。鳥越さんは、何かありますか？

鳥越：私のところも一緒で、金子さんのプロジェクトと同じような感じで、企画の方だけ東京で、あとは福岡でという感じでやっています。本当にバーチャルでオンライン会議とかを頻繁にやっているので、離れているから何というのはあまり感じたことはないですね。弊害も、特に思い当たるところはないです。

中川：そうですよね。ありがとうございます。

「SETって何？」と聞かれた日々

もう1個の質問は、僕がみなさんに聞きたかったことがあって。やりがいの話をしてもらったんですけど、逆にこの仕事をやっていて大変だぞ、みたいな話があったら聞きたいなと思いまして。あと、大変なだけじゃなくて、その大変な状況を具体的にどうやって乗り越えたかという話もあれば、一緒に教えてもらえるとうれしいです。頷いている金子さんに聞いてみてもいいですか（笑）？

金子：はい（笑）。私はSETというポジションでやっているんですけど、SETは比較的新しいポジションでして。最近はけっこう聞くようになったかもしれないですけど、やっぱり最初プロジェクトで開発メンバーの中に入った時は、「何それ？」という感じで、それが何をするポジションなのという雰囲気があって、やっぱり最初は働きにくいなという感じはありました。

なんですけど、その中で日々デイリーミーティングを開発メンバーとやっていると、先ほど言ったとおり、その中で私は何がやりたくてこれをやって、何の目的のために今作業をしています、ということを日々伝えたりとか。あとはデイリーのミーティングとは別に、私はこういう目標があって、そのためには今ここはできているけどここはできてないから、この部分をやるためにこういう動きをしています、というミーティングの場を設けてもらったりとか。

開発のメンバーとたくさん話すことによって、だいぶ認識もしてもらえるようになっていきました。

その結果、今では開発メンバーにPRドリブンE2Eテストを使ってもらっていますし、逆に開発メンバーから「日々ユニットテストはやっているけどE2Eテストはやったことがないからぜひやってみたい」という言葉をもらえたりして、すごくありがたいなと思っています。なので、最初は大変だったんですけど、今はだいぶ改善されてきて、働きやすい環境になってきているなと感じています。

中川：そうすると、地道にやって結果を出して、信頼関係を作っていって、本当に積み重ねた結果が、今という感じなんですね。

LINEでは失敗を責めないという文化がある

金子：そうですね。あと何だろう。LINEという会社は失敗しても、次にそれをつなげたりすると大丈夫、みたいな。失敗してもいいというわけじゃないですけど、ちょっとそういうのもあるので、私自身が不安でも、がんばって続けてこれたというところはあると思います。

中川：そうですよね。LINE STYLEという、LINEの社員が取るべき行動規範があるんですけど、そこでも言われている話で、失敗を責めない、という文化がありますよね。

もちろん、失敗しないほうがいいという話は、それはそれであるんですけど、失敗したからといって、それで何か責められるという話じゃなくて。逆になんで失敗したかを考えて、次はうまくやればいいということを取り組める文化があると思うし、実際金子さんのプロジェクトでも、そういった雰囲気があるからいろいろトライできるところにもつながっているんですよね。

金子：はい。

スクラム開発の中で品質管理は何をすればいいのかという不安

中川：鳥越さんからは、辛かったりきつかった話はありますか（笑）？

鳥越：辛いというのとはまた変わるかもしれないんですけど、スクラム開発という手法でやっている中で、品質管理って何をすればいいんだろうというのが正直あって、何をやっていけばいいのかが全然見えていない中で、本当にいろいろやって、本当にこれが貢献できているのかという不安が、かなりありました。

まだ不安は一部あるんですけど、QA＝テスターという意識がまだ根強い中で、この会社というか、LINEで立場を超えていろいろな挑戦をさせてもらえるところでも、本当にみなさんに応援してもらって。サポートも手厚くしてもらっているのもあって、何でも挑戦していこうと今やっています。ガムシャラにやっているというところですね。

なので、結果的に反省とか振り返りをしながら、結果が付いてくればいいかなと思って今やっているところです。

中川：ありがとうございます。やっぱり鳥越さんのお話も、挑戦できるということと、プロジェクトでみんながちゃんとサポートしてくれる文化があるから、いろいろできるというところが大きいですよね。

ありがとうございます。時間がほとんどなくなっちゃいましたね。まだ2つぐらいしかテーマを聞けていないですけど。

開発経験者のほうがエンジニアとして活躍できるという部分はある

質問を僕のほうで、1個だけ拾いたいと思います。「前職が開発者の方が多いですか？」というのが来ていまして、実は今日ここに来ていただいているパネリストのみなさんは開発者でしたという方、開発経験がある方に来てもらっている感じなんです。

開発者の割合という話は組織ごとに割合が違うので一概に多い・少ないというのは難しいかなと思っているんですけど、QAエンジニアとSETエンジニアという部分だけで言うと、もちろん開発経験のある方のほうが、エンジニアとして活躍できるという部分があるので、私たちも、採用活動においてそういう方を軸にしている部分ももちろんあります。

最初に鈴木からお話があったように、LINE全体のテストまで含めたQA組織の話ですと、実際にテストを実行していただく方などの比率が入ってくるので、割合はちょっと変わってくるんですけど。主にエンジニアリングを担当する我々QAエンジニア、SETエンジニアの部分においては、前職で開発をしていて、その中で品質の部分に興味をもっていて、今はそこにトライしている方が増えてきています。