Insights」の第7弾です。tokuhiromを迎え、エンジニア同士でざっくばらんに話を聞くという形で進めています。今回も、LINEのエンジニアは一体どんな人達なのか、その内面に迫っていきたいと思います。第7弾は開発3センターサービスQAチームの鈴木里惇(りじゅん)さんに、LINEプロダクトの品質を支えるQAという仕事について実際の仕事の流れやこだわり、今後の展望などについて聞いてきました。assuranceの略で品質保証のための検証作業などを指します。tokuhiromこんにちは、よろしくお願いします。rijun社内の品質管理をするQAチームのマネージャーをやっています。管理職である傍ら、僕自身も担当プロジェクトの品質管理業務に携わっているので、今はいわゆるプレイングマネージャーという感じですね。LIVEをサービス立ち上げから担当しているのですが、現在は新規開発案件の立ち上げにも関わっています。2012年の1月に入社して現在6年目ですが、入社してから3年くらいはNAVERまとめやその関連事業のサービスを担当して、その後はさまざまなLINEファミリーサービスを転々としてきました。rijunまずQAがどのような業務をしているかというところから説明すると、サービスの企画が始まる上流工程からリリース後の保守である下流工程にわたり、サービスのテストや品質管理業務全般を行っています。具体的には、上流工程では仕様検討の段階からインスペクション(仕様のレビュー、欠陥を見つけるプロセス)を、その後はテストの設計から実装、テストの実施からリリース後の保守までを行います。基本的には品質に関わることであればテスト以外でも、プロセス全体に関わっていくのがLINEのQAだと思っています。tokuhiromたしかに、仕様の検討などの早い段階からQAとの連携が始まりますよね。企画者が上げてきた仕様が曖昧なとき、QAの人が「企画書にあるこの部分はどうやって動くんですか」と質問していった結果、仕様が固まっていくことが多い気がします。rijunもちろん、テスト実施工程で動いているものを触って初めて要件の抜けに気づくということも多いですが、企画者によって仕様書の精度や質が違うので、実装前の上流工程で指摘できれば、手戻りのコストを下げる効果が見込めます。tokuhiromエラー時の挙動から実際の動きが決まっていくので、実装するエンジニアからしても仕様を詰めてくれるQAの方がいてくれるのは助かります。rijunそうですね。開発工程に入って実際どういう風に作っていくかという段階になると、エンジニアともやり取りが始まります。rijunテストというのは地道な作業がすごく多いと思いますが、やりがいといえば、どのサービスも利用者が多いので、リリース後のユーザーからのフィードバックが楽しみですね。tokuhiromLINEという括りだと、使ってもらえる人数が多いということが魅力かなという気がします。rijunそうですね、これほどトラフィックが多いサービスの面倒を見られることってあまりないと思うので。UXの細かい改修1つで中高生に騒がれたり、記事になったりするくらいのサービスになっていますよね。いう点で、品質に対して責任意識ややりがいを持てると思います。TAXIというサービスのQAは大変だったんじゃないですか?開発したのは私ですが(笑)。rijunあれは大変でしたね。「テストは地道な作業が多い」とお話ししましたが、まさに当てはまるエピソードがあります。リリース直前の本番環境のテストで、青山通りでタクシーを拾っては1メーターで降りる、という配車テストをひたすらやりました。なんだかカップル多いなぁと思ったらクリスマスの夜で、流石に寒さが身に染みましたね(笑)。TAXIは5人くらいのプロジェクトでみんなでわいわいやりながら作っていたので、楽しかったしいい思い出になりました。今はなかなかそんな少人数のプロジェクトがないので、あれは面白かったなあと。前職はSler系の受託開発をしている会社で、そこの検証評価部署にいました。組み込み系で、Webと比べるとけっこう堅い感じ雰囲気でしたが、組み込み機器や半導体のテストをやったり、テストコードを書いたりしていましたね。そもそもテストのキャリアに進んだのは、新卒の時に検証評価の部署がちょうど設立されたタイミングで「社内でも新しいキャリアだしせっかくのチャンスなんでやってみませんか?」という話があったからなんです。「テストってなんだろう?」とあまり深く考えずに「やります」と言ったことが始まりなんですよね。tokuhiromそうなんですね、どういう経緯でQAエンジニアになったのか気になっていました。rijun一番の動機は、受託開発ではなく自社開発をしている会社に行きたいと思ったからです。当時は組み込みの色々な現場を転々としていて自分のサービスを作っているという意識が薄かったので。JapanはLINEをリリースしたばかりで、僕から見て面白そうなサービスを色々やっていたからという理由です。rijun受託と自社という違いよりは、産業ドメインの違いが大きいと思っています。Webと組み込みだと品質に対する考え方は全然違いますからね。組み込みは開発期間が長いので、検証期間も1年とか平気でかかりますね。不具合の改修コストが非常に高いです。一度出荷してしまった後に深刻な不具合があると大規模なリコールに発展する可能性もあるので、テストやリスク管理の考え方が非常に厳しいですね。今でこそセキュリティパッチを提供するという考えも普及していますが。Webは市場の移り変わりも早いですし、ファーストムーバーアドバンテージという考え方があるように、品質より納期優先になることも多いです。不具合があってもすぐに修正分をリリースできるという特性もあるので、その辺の意識の違いは大きいです。あと思うのは、WebではいまだにQA組織やきちんとしたテストプロセスがない現場が沢山あるなと感じています。順に進んでいくのですが、チーム内でどういうプロセスで作成するかという共通ルールはあまり明文化されていません。基本原則に沿って進め、後はプロジェクトの性質や各々の経験に応じて任せている部分が多いです。Board)の定義でいうと、テスト分析でテストで検証すべき条件や要件を明らかにして、テスト設計でテスト条件を網羅するように設計して、テスト実装で実際のテストケースに落とし込んでいくイメージですね。仕様書からそのままテストケースを作ってしまうと、テストケースが爆発的に増えたり、そもそも仕様書に記述されてない要件が抜けたりしてしまうことがあります。開発者が設計なしでいきなりコードを書いたりしないのと同じで、テストも事前に仕様を整理してテストケースを作ります。tokuhirom仕様を整理するところからテストケースの作成が始まるということですよね。QAの人が仕様を整理したドキュメントの方が、企画の人が仕様をまとめたドキュメントよりも詳細なことがよくありますね。rijun開発もそうだと思いますが仕様書がないと困るのはQAも同じなので、自分たちで仕様を整理するというのはテスト業界の現場ではたまに聞きますね。LINEでは比較的、仕様書は企画側が責任を持って書くようになっていると思いますが。tokuhirom仕様書作成については、新しい人がどんどん入ってきますし、そもそもネイバージャパンから来た人とlivedoorから来た人では書き方や精度が全然違うから大変ですよね。rijunはい、人や組織によって違うところがありますね。メッセンジャーアプリを主に担当しているLINE企画チームは、テンプレートに沿った仕様書を書いてくれるなど、精度の高いドキュメントを作ってくれているイメージです。時間が経つにつれて変わってきたところもあって、最初はパワーポイントやエクセルで仕様を書いていた組織が多かったんです。更新管理ができないなど、結局それらのツールは仕様書の管理に最適なツールではなかったので、ツールの移行についてはQAからも働きかけていました。最近は社内のWikiで仕様を書くのが一般化してきたと思います。以前に比べたら仕様書の精度も良くなってきていますし、それは企画だけでなく仕様書を要求している側のQAや開発の働きかけによる部分もあるのでは、と個人的には思います。rijun今はTestRailというテスト管理ツールで管理しています。テスト管理ツールを導入したのは今年になってからですが、元々、テストケースの管理方法がプロジェクトによって異なるという問題がありました。エクセル、Wiki、JIRA、とさまざまなツールが使われていたんです。そのため、QAは水平的な組織なのに、プロジェクトによってテストケースの作り方や構成、ツールが違うので、ドキュメントを共有できなかったり、ノウハウの蓄積が難しかったりという悩みがありました。Webアプリケーションではないエクセルのようなツールでは、ドキュメントの管理に限界があるという問題もありました。テストケースやテストの実行結果は会社の資産であり、組織的に適切に管理したいと思っていたので、テスト管理ツールの導入に至りました。その後、組織でいくつかのツールを選定したり、LINEの場合は韓国・台湾・福岡などにもQA組織があるのでそれぞれヒアリングして、今年の5月にTestRailの運用を開始しました。今は古いプロジェクトからデータを移行し、新規プロジェクトに関してはTestRailで書いてもらうようにしています。Softwareという会社が作っていて、海外ではApple、Microsoft、Amazonなどで使われています。国内でも何社か使っている企業を知っています。欧米ではテスト管理ツールの利用は一般的なんですが、日本ではほとんど浸透していなくて、いまだにエクセルで管理している企業が多いと聞きますね。rijun組織によってはQAのプロセスが若干異なることもあり、違うツールを利用しているところもあります。NEWS、LINEマンガ、LINEデリマなど、主にファミリーサービスを担当しています。rijunゲームは完全に別の組織でやっていて、大連でテストしています。メッセンジャーアプリも主に他のチームが担当していていますが、ファミリーサービスとメッセンジャーアプリが連携して機能を提供する場合は、連携するサービス側、つまり僕たちがメッセンジャーアプリもテストしますね。rijun福岡のQA室は200名くらいの規模で、そのうち20名弱がQAエンジニアですね。LIVEの場合は、東京が自分1人で福岡が8名なので全体で9名です。開発コンポーネントが多く、アプリやWebなどマルチプラットフォームで提供しているサービスなので、リリース時期に応じてリソースをコントロールして回しています。rijun東京と福岡のQA組織を1人の室長がまとめているので東京と福岡ではやっていたんですけど、韓国や台湾とはやっていませんでした。今後は連携を深めていきたいですね、という話はしています。福岡のQAエンジニア達とは、年に1回くらいの頻度で一緒に技術交流ワークショップをやっています。rijun僕が担当したプロジェクトでは、開発でPRをレビューする文化があるのと同じように、設計や実装の段階でテストケースのレビューをするようにしています。1つのプロジェクトにQAエンジニアが1名という場合が多いんですが、テストリーダー(テスト実施者よりも上位のロール)と共同でテストケースを相互にレビューし、レビューが完了してからテストを実施してもらうようにしています。TestRailはGitHubのようにレビューのフローが確立したツールではないので、独自のレビューフローを模索しています。テストケースをレビューするプロセスはまだ組織的に確立できていないので、今後広めていきたいですね。rijunQAエンジニアは全般的にテストを管理する役割です。テストの実施もしますが、あくまでプロジェクトにおけるコミュニケーションや品質管理全体の統括が主な役割ですね。テストリーダーとテスターは福岡にいます。1つのプロジェクトに複数のテスターがアサインされます。テストリーダーは取りまとめ役として、テストの進捗管理やテストのレビューなど、テスト実施以外の役割も担います。テスターはテストケースを実施します。基本的な定義は以上ですが、組織によって任せる範囲は異なっていると思います。rijun品質と時間とお金の3つは全てトレードオフの関係にあるので、どれを守るかという話になると思うのですが、なるべくテストがボトルネックにならないようにということは考えますね。品質を良くするというQAのミッションには反してしまいますが、過剰品質に拘らないことは大事だと思っています。僕らQA担当はバグゼロの完全なプロダクトを作りたいわけではなく、早くサービスをリリースしてユーザーに価値を提供したいという思いは開発者と同じです。リリースできる品質かどうかは正しくジャッジされなければならないですが。一方で、最近は開発を外部に委託する案件も増えているので、LINEの目指す品質の基準を正しく定義してそれを担保することも重要だと考えています。rijunJIRAのチケットを修正するか否かで議論になることはありますね。「ユーザーが使いづらいのでこうしてほしい」という提案に「そもそも仕様として定義されていないのでバグではないし直さない」みたいな。バグとして登録するべきかどうか悩むことはありますね。みんなが「品質を良くする」という共通のゴールを目指して理解しあえたら良いと思っています。rijun基本的な定義は要件(仕様)にあるかないかですね。要件にあってそれが正しく動いていないものはバグですし、要件にないけれどこうあるべき、みたいなものは改善事項とか、ざっくりそれぐらいですね。tokuhirom開発のリーダーが「テストケースのレビューをしてほしい」と依頼されていることがありますが、開発担当者レベルでは見ていなかったりします。それは「そもそも俺の聞いてる要求にはない」という感じですよね。rijun要望でいうと、企画者には案件が決まったらもっと早く巻き込んでほしいと思うことはあります。急に呼ばれて、新規案件で2週間後にQAが始まるんですがと言われても、それまでにすでに1カ月くらい関連部署でやり取りがあるので、2週間でそれを全て整理してテストまで持っていくのは難しいことがありますね。QAエンジニアが忙しいので、企画者なりに気を使ってということだとは思うんですけど。tokuhiromあまり早く声をかけてしまうと実際に開発に入るまで時間がかかることもあるので、タイミングが難しいですね。rijunそうですね、逆に呼ばれるのが早すぎて半年間ずっとやることがない、みたいな場合もあるので難しいですね。rijunテストの自動化に関しては、うちのチームではプロジェクトごとに局所的に導入していましたが、今のところ組織的には推進できていないですね。E2EのUIテストをプロジェクト単位で作って運用したこともありましたが、プロジェクトごとに独自運用になってしまいました。そのため、手法が属人化してしまったり組織的な知見が共有されなかったりで、メンテナンスコストなどを考慮すると費用対効果が低く、やめてしまったという経緯があります。テストコードを書くことだけに専念できるメンバーがいないというリソースの問題もあります。Test)を採用しましたし、福岡にはテスト自動化専門のTFがあるので、そのような専門組織と協業する方法も模索しています。編集部注:LINEでは、何か解決するべき問題があった場合に期間限定のチームを作り、解決したら解散するTF(タスクフォース)という制度があります。あとは、開発エンジニアと企画担当者は東京にいることが多いので、なるべくコミュニケーションコストを下げるため、新規案件については東京でQA担当者をアサインし、運用フェーズになったら福岡に引き継ぐということをしています。東京にはQAエンジニアは10名弱いますが、リソースが足りていないのでもっと採用していきたいです。rijunQAの経験者であることは必須ですね。WebのQA市場はこれから広がっていくと思っているので、興味のある人たちに来て欲しいなと思っています。rijun個人的には、もっとチームの生産性を良くしていきたいですね。現状は同じチームでもそれぞれ担当プロジェクトも異なっていて、横のつながりが希薄なんです。チームであることの強みを最大化できていない気がしています。チームである以上は会社の品質管理の知見やノウハウをもっと活かせる環境にしていきたいと思っていて。共通のテスト管理ツールを導入したのはその第一歩ですね。rijunそうですね。今までは開発側も見ている室長がマネージャーを兼任していたんですけど、現場の細かいところやそもそもテストのことはわからない部分もあって、QAを経験してきた管理職が不在でした。自分はテストをしてきた人間なので、テスター視点でテスト業務を見て、効率化したり活性化したりしていきたいなと思っています。tokuhiromなるほど。rijun3年くらい前から「チームの業務についてもっと色々見てほしい」と室長からは言われていて、今期になって「そろそろやってみてください」という話になって。担当プロジェクトだけじゃなくて、社内のQAプロセスの効率化を率先して考えていたところが評価されたのでは、と思っています。rijunそういう気持ちもありますが、現場にいると実務にとらわれて、他のメンバーやプロジェクトまで見る余裕がなかなかないものだなと実感していて。チームメンバーを評価しなきゃいけない立場になってみると、そこは難しいです。rijun今後もっと多くのユーザーの皆さんに気持ちよく使ってもらえるように、品質改善活動に取り組んでいきたいですね。協賛レポートLINE初のエンジニアフェロー並川淳さんは、どんな仕事をしているのか。Developers。