QAエンジニアに聞く、LINEプロダクトの品質管理

2017-10-26

LINEで働くエンジニアに色々と話を聞いていく「LINE Engineer Insights」の第7弾です。当コーナーでは、インタビュアーにLINEで働くエンジニア tokuhiromを迎え、エンジニア同士でざっくばらんに話を聞くという形で進めています。今回も、LINEのエンジニアは一体どんな人達なのか、その内面に迫っていきたいと思います。

第7弾は開発3センターサービスQAチームの鈴木里惇（りじゅん）さんに、LINEプロダクトの品質を支えるQAという仕事について実際の仕事の流れやこだわり、今後の展望などについて聞いてきました。あらかじめ説明しておきますと、QAとはQuality assuranceの略で品質保証のための検証作業などを指します。

ざっくり言うと

QAの仕事は企画段階から始まりリリース後まで広範囲に及ぶ
テストケースの管理はTestRailを導入
品質・時間・お金の3つは全てトレードオフ

LINEプロダクトに対するQAの進め方

―― tokuhirom
こんにちは、よろしくお願いします。現在はどのような仕事を担当しているのでしょうか？

―― rijun
社内の品質管理をするQAチームのマネージャーをやっています。管理職である傍ら、僕自身も担当プロジェクトの品質管理業務に携わっているので、今はいわゆるプレイングマネージャーという感じですね。
直近の担当プロジェクトでいうとLINE LIVEをサービス立ち上げから担当しているのですが、現在は新規開発案件の立ち上げにも関わっています。

―― tokuhirom
歴史があるものでいうと、NAVERまとめにも関わっていたんですよね？

―― rijun
はい。2012年の1月に入社して現在6年目ですが、入社してから3年くらいはNAVERまとめやその関連事業のサービスを担当して、その後はさまざまなLINEファミリーサービスを転々としてきました。

―― tokuhirom
実際LINEでのQAはどのように進めているのでしょうか？

―― rijun
まずQAがどのような業務をしているかというところから説明すると、サービスの企画が始まる上流工程からリリース後の保守である下流工程にわたり、サービスのテストや品質管理業務全般を行っています。
具体的には、上流工程では仕様検討の段階からインスペクション（仕様のレビュー、欠陥を見つけるプロセス）を、その後はテストの設計から実装、テストの実施からリリース後の保守までを行います。基本的には品質に関わることであればテスト以外でも、プロセス全体に関わっていくのがLINEのQAだと思っています。

―― tokuhirom
たしかに、仕様の検討などの早い段階からQAとの連携が始まりますよね。企画者が上げてきた仕様が曖昧なとき、QAの人が「企画書にあるこの部分はどうやって動くんですか」と質問していった結果、仕様が固まっていくことが多い気がします。

―― rijun
もちろん、テスト実施工程で動いているものを触って初めて要件の抜けに気づくということも多いですが、企画者によって仕様書の精度や質が違うので、実装前の上流工程で指摘できれば、手戻りのコストを下げる効果が見込めます。

―― tokuhirom
エラー時の挙動から実際の動きが決まっていくので、実装するエンジニアからしても仕様を詰めてくれるQAの方がいてくれるのは助かります。QAの人がやり取りするのは、最初は企画の人が中心ですか？

―― rijun
そうですね。開発工程に入って実際どういう風に作っていくかという段階になると、エンジニアともやり取りが始まります。

LINEのQAの面白さ

―― tokuhirom
LINEのQAが面白いのはどんなところですか？

―― rijun
テストというのは地道な作業がすごく多いと思いますが、やりがいといえば、どのサービスも利用者が多いので、リリース後のユーザーからのフィードバックが楽しみですね。

―― tokuhirom
LINEという括りだと、使ってもらえる人数が多いということが魅力かなという気がします。

―― rijun
そうですね、これほどトラフィックが多いサービスの面倒を見られることってあまりないと思うので。UXの細かい改修1つで中高生に騒がれたり、記事になったりするくらいのサービスになっていますよね。そういう点で、品質に対して責任意識ややりがいを持てると思います。

―― tokuhirom
LINE TAXIというサービスのQAは大変だったんじゃないですか？開発したのは私ですが（笑）。

―― rijun
あれは大変でしたね。「テストは地道な作業が多い」とお話ししましたが、まさに当てはまるエピソードがあります。リリース直前の本番環境のテストで、青山通りでタクシーを拾っては1メーターで降りる、という配車テストをひたすらやりました。なんだかカップル多いなぁと思ったらクリスマスの夜で、流石に寒さが身に染みましたね（笑）。
ただ、LINE TAXIは5人くらいのプロジェクトでみんなでわいわいやりながら作っていたので、楽しかったしいい思い出になりました。今はなかなかそんな少人数のプロジェクトがないので、あれは面白かったなあと。

QAエンジニアになったきっかけ、組み込み系とWeb系の違い

―― tokuhirom
rijunさんは前職もQAエンジニアだったんですか？

―― rijun
はい。前職はSler系の受託開発をしている会社で、そこの検証評価部署にいました。組み込み系で、Webと比べるとけっこう堅い感じ雰囲気でしたが、組み込み機器や半導体のテストをやったり、テストコードを書いたりしていましたね。
そもそもテストのキャリアに進んだのは、新卒の時に検証評価の部署がちょうど設立されたタイミングで「社内でも新しいキャリアだしせっかくのチャンスなんでやってみませんか？」という話があったからなんです。「テストってなんだろう？」とあまり深く考えずに「やります」と言ったことが始まりなんですよね。

―― tokuhirom
そうなんですね、どういう経緯でQAエンジニアになったのか気になっていました。その後どうしてNHN Japanに入ろうと思ったのですか？

―― rijun
一番の動機は、受託開発ではなく自社開発をしている会社に行きたいと思ったからです。当時は組み込みの色々な現場を転々としていて自分のサービスを作っているという意識が薄かったので。

それとWebにもともと興味があったのと、当時のNHN JapanはLINEをリリースしたばかりで、僕から見て面白そうなサービスを色々やっていたからという理由です。

―― tokuhirom
受託開発と自社開発の会社だと、QAのやることは違いますか？

―― rijun
受託と自社という違いよりは、産業ドメインの違いが大きいと思っています。Webと組み込みだと品質に対する考え方は全然違いますからね。
組み込みは開発期間が長いので、検証期間も1年とか平気でかかりますね。そして不具合の改修コストが非常に高いです。一度出荷してしまった後に深刻な不具合があると大規模なリコールに発展する可能性もあるので、テストやリスク管理の考え方が非常に厳しいですね。今でこそセキュリティパッチを提供するという考えも普及していますが。
Webは市場の移り変わりも早いですし、ファーストムーバーアドバンテージという考え方があるように、品質より納期優先になることも多いです。不具合があってもすぐに修正分をリリースできるという特性もあるので、その辺の意識の違いは大きいです。
あと思うのは、WebではいまだにQA組織やきちんとしたテストプロセスがない現場が沢山あるなと感じています。

テストケース作成のプロセス

―― tokuhirom
QAを進めていくにあたり、テストケースはどのように作っていくのですか？

―― rijun
一般的なテストケース作成までのワークフローは、分析・設計・実装の順に進んでいくのですが、チーム内でどういうプロセスで作成するかという共通ルールはあまり明文化されていません。基本原則に沿って進め、後はプロジェクトの性質や各々の経験に応じて任せている部分が多いです。
具体的に各プロセスを ISTQB（International Software Testing Qualifications Board）の定義でいうと、テスト分析でテストで検証すべき条件や要件を明らかにして、テスト設計でテスト条件を網羅するように設計して、テスト実装で実際のテストケースに落とし込んでいくイメージですね。
仕様書からそのままテストケースを作ってしまうと、テストケースが爆発的に増えたり、そもそも仕様書に記述されてない要件が抜けたりしてしまうことがあります。開発者が設計なしでいきなりコードを書いたりしないのと同じで、テストも事前に仕様を整理してテストケースを作ります。

―― tokuhirom
仕様を整理するところからテストケースの作成が始まるということですよね。QAの人が仕様を整理したドキュメントの方が、企画の人が仕様をまとめたドキュメントよりも詳細なことがよくありますね。

―― rijun
開発もそうだと思いますが仕様書がないと困るのはQAも同じなので、自分たちで仕様を整理するというのはテスト業界の現場ではたまに聞きますね。LINEでは比較的、仕様書は企画側が責任を持って書くようになっていると思いますが。

―― tokuhirom
仕様書作成については、新しい人がどんどん入ってきますし、そもそもネイバージャパンから来た人とlivedoorから来た人では書き方や精度が全然違うから大変ですよね。

―― rijun
はい、人や組織によって違うところがありますね。例えばメッセンジャーアプリを主に担当しているLINE企画チームは、テンプレートに沿った仕様書を書いてくれるなど、精度の高いドキュメントを作ってくれているイメージです。
時間が経つにつれて変わってきたところもあって、最初はパワーポイントやエクセルで仕様を書いていた組織が多かったんです。でも更新管理ができないなど、結局それらのツールは仕様書の管理に最適なツールではなかったので、ツールの移行についてはQAからも働きかけていました。最近は社内のWikiで仕様を書くのが一般化してきたと思います。
以前に比べたら仕様書の精度も良くなってきていますし、それは企画だけでなく仕様書を要求している側のQAや開発の働きかけによる部分もあるのでは、と個人的には思います。

テストケースの管理はTestRail

―― tokuhirom
テストケースはエクセルなどで管理しているんですか？

―― rijun
今はTestRailというテスト管理ツールで管理しています。テスト管理ツールを導入したのは今年になってからですが、元々、テストケースの管理方法がプロジェクトによって異なるという問題がありました。エクセル、Wiki、JIRA、とさまざまなツールが使われていたんです。そのため、QAは水平的な組織なのに、プロジェクトによってテストケースの作り方や構成、ツールが違うので、ドキュメントを共有できなかったり、ノウハウの蓄積が難しかったりという悩みがありました。
Webアプリケーションではないエクセルのようなツールでは、ドキュメントの管理に限界があるという問題もありました。テストケースやテストの実行結果は会社の資産であり、組織的に適切に管理したいと思っていたので、テスト管理ツールの導入に至りました。
その後、組織でいくつかのツールを選定したり、LINEの場合は韓国・台湾・福岡などにもQA組織があるのでそれぞれヒアリングして、今年の5月にTestRailの運用を開始しました。今は古いプロジェクトからデータを移行し、新規プロジェクトに関してはTestRailで書いてもらうようにしています。

編集部注：Testraiのイメージ画面

―― tokuhirom
TestRailというのは販売している製品なんですか？

―― rijun
はい。ドイツのGurock Softwareという会社が作っていて、海外ではApple、Microsoft、Amazonなどで使われています。国内でも何社か使っている企業を知っています。
欧米ではテスト管理ツールの利用は一般的なんですが、日本ではほとんど浸透していなくて、いまだにエクセルで管理している企業が多いと聞きますね。

―― tokuhirom
韓国や台湾のチームにも相談したということですが、今はそれぞれのQA組織でTestRailを使っているんですか？

―― rijun
組織によってはQAのプロセスが若干異なることもあり、違うツールを利用しているところもあります。

LINEの中でQAをどう分担しているのか

―― tokuhirom
現在、rijunさんのいる組織では、主にどのあたりのサービスを担当していますか？

―― rijun
僕のチームはQAエンジニアが10名弱在籍していますが、LINE LIVE、LINE NEWS、LINEマンガ、LINEデリマなど、主にファミリーサービスを担当しています。

―― tokuhirom
メッセンジャーアプリやゲームは、別の組織がQAを担当しているんですか？

―― rijun
ゲームは完全に別の組織でやっていて、大連でテストしています。
メッセンジャーアプリも主に他のチームが担当していていますが、ファミリーサービスとメッセンジャーアプリが連携して機能を提供する場合は、連携するサービス側、つまり僕たちがメッセンジャーアプリもテストしますね。

―― tokuhirom
QAエンジニアは福岡に何人くらいいるんですか？

―― rijun
福岡のQA室は200名くらいの規模で、そのうち20名弱がQAエンジニアですね。

―― tokuhirom
例えばLINE LIVEのような案件だと、何人くらいでQAを行うんですか？

―― rijun
LINE LIVEの場合は、東京が自分1人で福岡が8名なので全体で9名です。開発コンポーネントが多く、アプリやWebなどマルチプラットフォームで提供しているサービスなので、リリース時期に応じてリソースをコントロールして回しています。

―― tokuhirom
組織をまたいで情報を共有する取り組みはやっていますか？

―― rijun
東京と福岡のQA組織を1人の室長がまとめているので東京と福岡ではやっていたんですけど、韓国や台湾とはやっていませんでした。今後は連携を深めていきたいですね、という話はしています。
福岡のQAエンジニア達とは、年に1回くらいの頻度で一緒に技術交流ワークショップをやっています。

テストケース作成から実施までのフロー

―― tokuhirom
テストケースを作る際にrijunさんがメインでテストケースを作ったとして、実際にテストケースをこなしていくときはどのようにやっているんですか？

―― rijun
僕が担当したプロジェクトでは、開発でPRをレビューする文化があるのと同じように、設計や実装の段階でテストケースのレビューをするようにしています。1つのプロジェクトにQAエンジニアが1名という場合が多いんですが、テストリーダー（テスト実施者よりも上位のロール）と共同でテストケースを相互にレビューし、レビューが完了してからテストを実施してもらうようにしています。
TestRailはGitHubのようにレビューのフローが確立したツールではないので、独自のレビューフローを模索しています。テストケースをレビューするプロセスはまだ組織的に確立できていないので、今後広めていきたいですね。

―― tokuhirom
QAエンジニア、テストリーダー、テスターの役割について、もう少し詳しく教えてもらえますか？

―― rijun
QAエンジニアは全般的にテストを管理する役割です。もちろんテストの実施もしますが、あくまでプロジェクトにおけるコミュニケーションや品質管理全体の統括が主な役割ですね。
テストリーダーとテスターは福岡にいます。たいていは1つのプロジェクトに複数のテスターがアサインされます。テストリーダーは取りまとめ役として、テストの進捗管理やテストのレビューなど、テスト実施以外の役割も担います。
テスターはテストケースを実施します。基本的な定義は以上ですが、組織によって任せる範囲は異なっていると思います。

品質・時間・お金の3つは全てトレードオフ

―― tokuhirom
QAが入ることによって開発全体のスピードが落ちるということはないですか？

―― rijun
品質と時間とお金の3つは全てトレードオフの関係にあるので、どれを守るかという話になると思うのですが、なるべくテストがボトルネックにならないようにということは考えますね。品質を良くするというQAのミッションには反してしまいますが、過剰品質に拘らないことは大事だと思っています。
僕らQA担当はバグゼロの完全なプロダクトを作りたいわけではなく、早くサービスをリリースしてユーザーに価値を提供したいという思いは開発者と同じです。もちろん、リリースできる品質かどうかは正しくジャッジされなければならないですが。
一方で、最近は開発を外部に委託する案件も増えているので、LINEの目指す品質の基準を正しく定義してそれを担保することも重要だと考えています。

QAから他部署への要望は「理解しあうこと」

―― tokuhirom
開発や企画の人に対して「こうしてくれたらいいのに」ということはありますか？

―― rijun
JIRAのチケットを修正するか否かで議論になることはありますね。例えば「ユーザーが使いづらいのでこうしてほしい」という提案に「そもそも仕様として定義されていないのでバグではないし直さない」みたいな。バグとして登録するべきかどうか悩むことはありますね。
みんなが「品質を良くする」という共通のゴールを目指して理解しあえたら良いと思っています。

―― tokuhirom
案件によって対応の仕方を変えたりするんですか？

―― rijun
基本的な定義は要件（仕様）にあるかないかですね。要件にあってそれが正しく動いていないものはバグですし、要件にないけれどこうあるべき、みたいなものは改善事項とか、ざっくりそれぐらいですね。

―― tokuhirom
開発のリーダーが「テストケースのレビューをしてほしい」と依頼されていることがありますが、開発担当者レベルでは見ていなかったりします。それは「そもそも俺の聞いてる要求にはない」という感じですよね。

―― rijun
要望でいうと、企画者には案件が決まったらもっと早く巻き込んでほしいと思うことはあります。
急に呼ばれて、新規案件で2週間後にQAが始まるんですがと言われても、それまでにすでに1カ月くらい関連部署でやり取りがあるので、2週間でそれを全て整理してテストまで持っていくのは難しいことがありますね。QAエンジニアが忙しいので、企画者なりに気を使ってということだとは思うんですけど。

―― tokuhirom
あまり早く声をかけてしまうと実際に開発に入るまで時間がかかることもあるので、タイミングが難しいですね。

―― rijun
そうですね、逆に呼ばれるのが早すぎて半年間ずっとやることがない、みたいな場合もあるので難しいですね。

QAの自動化プロジェクトとQAエンジニアの採用

―― tokuhirom

QAの自動化プロジェクトが進んでいると聞きましたが、現在どんな状況ですか？

―― rijun
テストの自動化に関しては、うちのチームではプロジェクトごとに局所的に導入していましたが、今のところ組織的には推進できていないですね。
E2EのUIテストをプロジェクト単位で作って運用したこともありましたが、プロジェクトごとに独自運用になってしまいました。そのため、手法が属人化してしまったり組織的な知見が共有されなかったりで、メンテナンスコストなどを考慮すると費用対効果が低く、やめてしまったという経緯があります。
テストコードを書くことだけに専念できるメンバーがいないというリソースの問題もあります。
会社としては、最近SET（Software Engineer in Test）を採用しましたし、福岡にはテスト自動化専門のTFがあるので、そのような専門組織と協業する方法も模索しています。
編集部注：LINEでは、何か解決するべき問題があった場合に期間限定のチームを作り、解決したら解散するTF（タスクフォース）という制度があります。

あとは、開発エンジニアと企画担当者は東京にいることが多いので、なるべくコミュニケーションコストを下げるため、新規案件については東京でQA担当者をアサインし、運用フェーズになったら福岡に引き継ぐということをしています。東京にはQAエンジニアは10名弱いますが、リソースが足りていないのでもっと採用していきたいです。

―― tokuhirom
どういう募集なんですか？経験者ですか？

―― rijun
QAの経験者であることは必須ですね。WebのQA市場はこれから広がっていくと思っているので、興味のある人たちに来て欲しいなと思っています。
編集部注：インタビュー後に採用募集が始まりました！
▼QAエンジニア【LINE NEWS、LINE LIVE等】

QAとして目指している姿と今後の展望

―― tokuhirom
QAをやっていて、もっとこうだったらいいのにな、ということはありますか？

―― rijun
個人的には、もっとチームの生産性を良くしていきたいですね。現状は同じチームでもそれぞれ担当プロジェクトも異なっていて、横のつながりが希薄なんです。ですから、チームであることの強みを最大化できていない気がしています。
チームである以上は会社の品質管理の知見やノウハウをもっと活かせる環境にしていきたいと思っていて。共通のテスト管理ツールを導入したのはその第一歩ですね。

―― tokuhirom
rijunさんは最近マネージャーになりましたが、その辺を改善していきたいという気持ちですか？

―― rijun
そうですね。今までは開発側も見ている室長がマネージャーを兼任していたんですけど、現場の細かいところやそもそもテストのことはわからない部分もあって、QAを経験してきた管理職が不在でした。自分はテストをしてきた人間なので、テスター視点でテスト業務を見て、効率化したり活性化したりしていきたいなと思っています。

―― tokuhirom
なるほど。 QAは人数がそこそこいて、rijunさんは若い方だと思うんですけど、どうしてrijunさんがマネージャーになることになったんですか？

―― rijun
3年くらい前から「チームの業務についてもっと色々見てほしい」と室長からは言われていて、今期になって「そろそろやってみてください」という話になって。おそらく、担当プロジェクトだけじゃなくて、社内のQAプロセスの効率化を率先して考えていたところが評価されたのでは、と思っています。

―― tokuhirom
もっと現場でやっていたかったという気持ちはありますか？

―― rijun
そういう気持ちもありますが、現場にいると実務にとらわれて、他のメンバーやプロジェクトまで見る余裕がなかなかないものだなと実感していて。チームメンバーを評価しなきゃいけない立場になってみると、そこは難しいです。

―― tokuhirom
今後の展望はいかがですか？

―― rijun
今後もっと多くのユーザーの皆さんに気持ちよく使ってもらえるように、品質改善活動に取り組んでいきたいですね。