QAエンジニア集団がつくる「プロジェクトの品質」とは？これでわかる！QA Engineering室10の事実

みなさんは「QAエンジニア」という職種をご存知ですか？

「QA」や「エンジニア」は聞いたことあるけれど……という方も、いらっしゃるのではないでしょうか？

今回のテーマ「QA Engineering室」には、プロジェクトの品質という観点からサービス成長を支える「QAエンジニア」が所属しています。

企画・開発・リリース・運用など、いくつもの段階を経てユーザーの手元に届く新しいサービスや機能。それらのどこに、どのように関わるのか。QA Engineering室の3名に聞いてきました。

お話するのは…

上田：安心安全で魅力的なサービスを生み出すために必要な「プロジェクトの品質」を、プロジェクトメンバーと一緒につくっています。

安心安全で魅力的なサービスが「健康で魅力的な体」だとすると、プロジェクトは体の部位や臓器ですかね。

医療の専門知識はないのであくまでイメージですが、体の部位や臓器に、脂肪がつきすぎている状態だったとします。体の状態を分析して、それを見つけるのがQA Engineering室に所属するQAエンジニアです。

そこからさらに原因を探って、運動不足や食事内容が問題だと分かれば、トレーニングや食事など、適した改善方法を提案します。

結果として、「健康で魅力的な体」が病気にかかったり、理想からかけ離れた状態になったりしないための活動になるので、「予防」ですね。

上田：プロジェクトのどこに関わるのかと言うと。

まず、私たちは、サービスの品質に関わる動きを「品質保証活動」と呼んでいて、企画からリリース・運用までの工程にある「品質保証活動」をQuality Management、Quality Assurance、Quality Control（Test）に整理しています。

その中でQA Engineering室は、Quality Assurance （以下QA）を中心に担っています。 

  

 

多くの方は、QAという言葉から、開発されたサービスを触って不具合がないかを確認する業務を想像されているかもしれませんが、それは「Quality Control（Test）」（以下QC）の活動の一部にあたります。 

QCは、発生してしまった病気への対応なので、「治療」だと思っていただけると分かりやすいかと思います。

上田：もとを辿れば、QA Engineering室の組織としての始まりはQCです。

LINE Fukuokaでは、2011年からサービスのテスト業務を担っており、現在では、LINEグループの中でも最大規模の組織です。

▼LINE FukuokaでQuality Control（Test）を担うテストセンターについてはこちら

品質活動において、QCが対象にするのは「プロダクト」なので、そのプロダクトを作る「プロジェクト」の品質を向上させることで、よりサービスに貢献できると考え、まずはQCと同じ組織の中で、QA エンジニアとしての活動領域を広げました。

そして、QA Engineering室として独立したのが2020年です。

役割を明確にして組織もわかれましたが、QC活動はQA活動の中に内包されており、分けて考えることはできないので、分業はしますが分断はしません。

上田：  LINEプラットフォームやO2O、Fintech、エンタメなど、領域の異なる10程度のプロジェクトに関わっています。

中川： QAエンジニアの役割を担う組織は、東京のLINE株式会社と韓国のLINE Plusにもあります。

LINEのサービスには複数の拠点から開発エンジニアが参加しているのと同様に、QAエンジニアも複数の拠点からプロジェクトに参加しています。

特に、LINE Fukuokaの開発エンジニアが関わっているサービスには、LINE Fukuoka所属のQAエンジニアが入ることが多いです。

池田：うーん。実は「QAエンジニアの業務はこれです」って簡単にお伝えできないんですよね……

サービス開発をするエンジニアであれば設計やプログラミングなどと言えるのですが、QAエンジニアの明確な業務内容を示すことってなかなか難しいものなんです。

LINEグループ内には、たくさんのサービスと、そのサービスを生み出すプロジェクトがあります。

リリース前のサービスを扱っているプロジェクトもあれば、リリースから数年経ったサービスを扱っているプロジェクトもあり、抱えている課題の種類も優先度も、紐づく事情もそれぞれ異なります。

 

その中で、QAエンジニアはそのプロジェクト内にある「課題解決」をする。

まずは、担当するプロジェクトの問題点や解決すべき課題をQAエンジニアが自ら洗い出して、いつ何に取り組んで、どういう状態を目指すか改善計画を立てる。これが最初のステップです。

あとは、その課題に対してプロジェクトで取り組んでいきます。

 

プロジェクト毎に課題や事情が異なれば、QAエンジニアが取り組む業務内容も当然異なる。具体的な業務をお伝えするのは難しいと言ったのは、このことからです。

QAエンジニアのターゲットは、サービスを生み出す「プロジェクトの品質」。品質に関わることなら何でもやります。

それぞれ業務内容は異なりますが、根本的な部分は私たちに共通しているものだと思っています。

 

池田： 10のプロジェクトがあれば、10通りのQAエンジニアのタスクがある。と言えるくらい様々なので、一例を挙げたいと思います。

 

まず、開発作業の流れを大まかにお伝えすると、要件として定めた内容は仕様書や設計書などのドキュメントに落とし込まれ、徐々に細かく具体化されていきます。

そして、作成者とは異なるメンバーがドキュメントをレビューし、必要に応じて修正を繰り返しながら完成させ、その後の製造工程やテスト工程に入っていく。といった流れです。

 

とあるプロジェクトの例ですが、テスト工程で不具合が多発し、プログラム改修や再テストに想定以上の時間を要し、リリース時期の見直しをしなくてはならない状況でした。

その原因を紐解くと、設計書のレビューが不十分なまま作業が進んでいたことが分かったので、レビューの全体的な改善という課題の解決に向けて取り組みました。

そこでは、プロジェクトメンバーに同じ課題認識を持ってもらうための問題提起から始まり、レビューの対象物や実施タイミング、レビュアーを改めて整理しました。

その後、レビュアーとしても、積極的に質問することでコミュニケーションの糸口を作ったり、品質観点でのチェックや強化を図ったりすることで、プロジェクトの品質向上を試みました。

例に挙げたレビューを含む品質活動は、プロジェクト全体で取り組むことが重要です。

そのため、全体の意識を醸成することや環境を構築していくための働きかけも欠かせませんし、大前提として、私たちQAエンジニアがサービス・事業をよく理解しておく必要があります。

スピード感など、事業・サービスに関する様々なものを考慮した上で、より良い品質活動を模索・実践し形を作っていくことが、QAエンジニアのミッションだと思っています。 

中川：違いは、目線と立ち位置だと思います。

サービス企画者や事業担当者は、それぞれミッションが明確で何をするかが決まっている。

だから、売上やサービスの理想など、自分がコミットするべき方向に全振りすることができます。

プロジェクトを推し進める必要があるので、時には攻めの姿勢になりすぎるかもしれません。

もしかすると、守りがおろそかになり、安全性を犠牲にしてしまうかもしれません。

プロジェクトの前へ進んでいくスピードはできる限り落とさずに、最低限の守りは維持してサービスを壊さないように、上手く全体のバランスを取りに行くのがQAエンジニアの仕事だと思います。

もちろん、売上やサービスの理想を追求する視点も必要ですが、「品質活動を通して、サービスをより良くする・より安全にする」という視点は外せません。

 

上田：中川さんの言う「バランスを取りに行く」はその通りだと思います。

私の好きなゲームのジョブで例えると、サービス企画者や開発エンジニアは、敵を倒すために、特化したスキルがあるモンク（格闘士）や黒魔道士。QAエンジニアは、赤魔道士かな。

中川：上田さん、理解されていない！笑

上田：ある程度の魔法が使えて戦士としても能力のある万能なジョブです。

ただ、特化した能力はなく、赤魔道士がいなくても、他のジョブで敵を倒すことはできます。実際に、QAエンジニアがいない会社もありますよね。

でも、赤魔道士がいれば味方にヘイスト（能力値を上昇させる魔法）をかけることができるし、支援的な行動が取れる。

全体的なバランスを取りながら、パーティーの底上げをしていくジョブだと思っています。

 

池田：やるべきことは、本当にさまざまなので、何かに秀でたスペシャリストというよりも色々なことに理解を持ったゼネラリストとして幅広い知識が求められます。

 

例えば技術面でいうと、特定の言語を深く理解してコードが書けることよりも、コードをどう書けばどう動くかを把握していたり、サーバーやネットワーク機器の役割や仕組みを把握していたり、開発ライフサイクル全体のフローや関連などを理解していたり、挙げだすとキリがないです。

もちろん、開発技術の知識に加えて、テストの知識も必要です。

中川：そうですね、開発技術という観点では、自分でサービス開発そのものができなくてもいいけど知識としては必要。

LINEのサービス開発において押さえておいたほうが良い技術はたくさんあるので、そのような開発技術の知識をたくさん持っているQAエンジニアが、より強いというイメージです。

プロジェクトマネジメントのスキルも必要です。

例えば、プロジェクト内で課題を見つけて、それを解決する場合に、全ての課題を自分だけで解決するのは難しいですよね。そうなると、プロジェクトメンバーの理解を得て、一緒に動いてもらわないといけませんが、そのためには、ただ課題を言うだけではダメで、まず自分自身で課題を理解した上で、相手にもしっかり説明して納得してもらうことが必要になります。そのためには、技術の知識というバックグラウンドに加えて、周りのメンバーを巻き込んで動かしていくプロジェクトマネジメントスキルが重要になってきます。

─ QA Engineering室のみなさんはどのような経歴をお持ちの方が多いですか？ 

上田：SIerで開発エンジニアとして経験を積んだメンバーもいれば、QCでテスターから経験を積んだメンバーもいます。

組織立ち上げから日が浅いこともあり、バックボーンに偏りはないですが、我々は技術集団なので、エンジニアリングスキルや、テストエンジニアリングスキル、プロジェクトマネジメントスキルを強みにしているメンバーが多いですね。

中川：やはり、エンジニアリングスキルを求められる場面が多いので、エンジニア経験とプロジェクトマネージャー経験のどちらも持っているような方を、今後は積極的に採用していきたいと思っています。

現在はサービスの一部分を専門的に開発しているけれど、もっとサービスや事業全体に関わりたい方、プロジェクトのプロセス改善や基盤・仕組みの構築に強く興味を持たれている方などは、幅広くサービスに関わるQAエンジニアの動き方に、やりがいを感じていただけると思います。

 

上田：誰かのサポートをすることが好きであれば、縁の下の力持ちとして、プロジェクトが良い方向に進むことに面白さややりがいを感じると思います。

難しさ……。難しいことしかないですね。

プロジェクト全体を巻き込んでいかなければいけないので、ネゴシエーションなど、あらゆる角度から、関係者とコミュニケーションを取るのは大変だと思いますし。コミュニケーションスキルだけじゃなくて、テクニカルスキルも幅広く学びつづけなくてはいけない。

IT業界の技術は日進月歩なので、日頃からいろんなアンテナを張って知識や情報を収集しなくてはいけません。

探究心を持って、「ここは、どうしてこうなっているんだろう？」とか、気になって気になって仕方ない性分の人は合っているんじゃないですかね？僕はそういうのが好きなので。

 

池田：「総合力を試される」ことが、面白さであり難しさだと思います。

お伝えしている通り、QAエンジニアは活動領域も求められる知識も幅広い。

ひとりでいくつものエンジニア業務をこなせる「フルスタックエンジニア」のように、企画・開発・テスト・リリース後の運用・サービス成長など、それぞれのフェーズで、幅広い知識を活用して、品質活動をベースにプロジェクトの改善を行っていきます。

プロジェクトの事情を汲みながらも、あらゆる状況の中で課題解決を遂行する。

すごく大変なんですけど、面白さと表裏一体になっているなって思います。

中川：池田さんのお話に近いのですが、面白いところも難しさも「幅の広さ」かな。

とにかく見るべきところが多いので、何か一つがずば抜けてできるだけでは足りないです。

幅が広かったとしても、その深さが浅すぎると、まだ足りません。

ある程度のところまで、自分自身で手を動かしてできることが要求されるので、常日頃から、自分の知識やスキルの幅を広げなくてはいけません。

反面、主体性があれば、やりたいこと全てに関われます。

「この仕事しかしなくていいです」と言われることがないので、「事業を広く見たい」「サービス全体に関わりたい」と主体的に動ける方は、本当に幅広くいろんなものを見て動いていただけると思います。