【イベントレポート】Developers Summit2020に登壇いたしました。
2月19日に行われたDevelopers Summit（デブサミ）2021に、Buildサービス推進チームに所属するクオリティエンジニア(以下、QE)、日野杉が登壇いたしました。
デブサミは、2003年から毎年開催する、日本最大級のソフトウェア開発者のためのカンファレンスです。今年は初のオンライン開催となりました。Twitter上でも #devsumi で当日の様子が発信されています。今年のテーマは「We are New Normal」。
本編では、日野杉がイベントで語った内容を抜粋してお届けいたします。
日野杉：私は、伊藤忠テクノソリューションズのBuildサービス推進チームでQEをしています。キャリアのスタートはテスターで、デバッガー、PGなどを経験、その後は品質管理というキャリアを積み、今に至ります。
私の名前は「賢祥（けんしょう）」なので、品質に携わるために付けられた名前かなと思っており、個人的には、QEという職種を多くの人に知ってもらう使命もあるのかなと思っています。（笑）
本セクションでは、品質に関わるエンジニア、QEの魅力を皆様にお伝えさせていただきます。
Buildサービス推進チームの紹介
日野杉：私の所属しているBuildサービス推進チームは2020年4月に結成され、DXに踏み出す大手企業をお客様として、最新技術、手法を用いて、プロダクト開発を支援しております。最終的にはお客様が独り立ちし、自らの手で内製・DX推進できるように技術移転することを目的としております。
「考えると作るを共に」をテーマに掲げ、UXデザイン×クラウドネイティブ×アジャイルに、一気通貫でプロダクト支援をするサービスを提供しております。ポイントは、請負ではなく、お客様に伴走（クライアントとの共創）する形で、DX支援をしているところです。
私たちは、上図のように、クライアントチームとBuildサービス推進チームのメンバーで一つのチームとなり、プロダクトの実現にコミットしていきます。各ロールが共創することで、お客様自身が新たなスキルやマインドセットを獲得し、変革が実現できる組織へと成長していただくことをミッションとして活動しています。
本日は、私が担当しているロール「QE」についてお話させていただきます。
一般的な品質に関わるエンジニア ≒ QAとは
日野杉：まずは、一般的な品質に関わるエンジニア「QA」についてお話しさせていただきます。QAは、品質保証のために、仕様に沿った動作の確認や、製品の品質管理を行う、エンジニアを指します。また、不具合によるシステム障害の回避、不具合修正の確認なども担当したり、第三者目線、ユーザー目線も重要で、品質テストや仕様のレビューなども行います。
このように実際のQAの仕事は、会社によって求められるものが違うことも多く、何でも屋さんであるのが現状です。
また、QEの仕事をご説明する前に、品質管理に関わるの様々な職種とそれぞれの仕事内容についてもご紹介させていただきます。
（個人的に見てきたものや体感したもの、人から聞いたものも含まれているため、少し違和感があるかもしれませんが、ご容赦ください。）
QAコンサルタント
第三者検証で有名な会社などに存在。社内製品の品質戦略を打ち出す。各部署と連携し、現状のプロジェクト品質リスクなどをヒアリング。また、PMOとしてテストプロジェクトの立案や課題・リスクの報告、予算管理を担当する。社外向けQAコンサルタントの場合、QAがいない顧客のプロダクトやプロジェクトのプロジェクト品質リスクなどをヒアリングし、品質戦略、テスト計画を提案・提供。
QAディレクター
品質に対して指揮する人・監督する人。仕様についての改善要望（UIやUX）や、作業品質、仕様バグをQA視点で共有。QAコンサルタントやPMの提案したテスト戦略やテスト計画を実際に推進していく。
QAマネージャー
品質保証、テスト戦略、立案を行い、業務フローの立案と改善。プロジェクトマネージャーのQA版。
QAエンジニア
第三者の視点に立って品質測定、テスト設計、テストケース作成、仕様の把握、仕様に対する改善要望や指摘など（UXやUIの改善要望含む）。
テストマネージャー
検証会社のテスト・テスターの管理業務、顧客との折衝、エンジニアやテスターとの情報共有、テスターの教育、テスターの稼働調整など。
会社によってはテストケース作成なども行う。またQAエンジニアが兼務する場合もある。
テスター
テストケースを実行、スモークテスト実行、アドホックテスト実行など。
日本ではウォーターフォールモデルの下流工程要員扱いの場合が多く、クリエイティブな仕事ではないという印象を持っている人が多い印象。海外では優秀なテスターは高額報酬をもらっているケースも多く、決して下流工程要員ではないと個人的には思っている。
テスト自動化エンジニア（SET）
Selenium やAppiumなどを駆使し、CIの「Jenkins」でテスト自動化の仕組作りなど。detox e2e やCyPressやTestCafeなども駆使する。
求人ではSET（Software Engineer in Test）とも呼ばれている。
このように品質管理に関わる職種は多様であり、品質に関する価値観や姿勢も立場によって異なります。また、一般的には、QAのスペシャリストとしてQAマネージャーを目指すキャリアプランを描く方が多いと認識していますが、私はこれまで、自分が歩みたいキャリアがわからずにいました。しかし昨年「QE」という職種に出会い、これを目指したいと思うようになりました。
QEとは
日野杉：これら様々な職種や役割を踏まえた上で、QE＝「テスト戦略や自動化といった、品質への焦点をアジャイルに組み込む役割」だと考えています。具体的には、ステークホルダーや顧客、開発チームへの品質戦略の立案と啓蒙活動、またテスト領域に対する詳細なテスト方法の計画を立て実行、自動化などを行います。
ここまで聞くと、既存のQAと同じように聞こえるかもしれません。
（QEは、これまでご紹介した、品質に関わる職種のそれぞれの要素を複合した「テスト自動化エンジニア」と呼ぶとイメージしやすいかと思います。）
QEは、QA+「エンジニア」の経験スキルが求められる職種であり、エンジニアチームの一員として、品質向上を進めていく役割が求められます。既存のQAのように、実装完了後にテストをするのではなく、「実装の開始と同時に、品質に責任を持って行動する」のが、QEの必要性であると考えています。
また、SETは、「仕様」や「機能」に対する品質維持・向上がメインである一方、QEは、「プロダクト開発」に対してアプローチしていくため、立ち位置や見る部分が異なります。
QEのテスト戦略
日野杉：Buildサービス推進チームでは、開発とテスト活動が密接に関わり合うと考えており、（理想としては）テスト自動化が高品質、迅速な納品に必要不可欠と考えています。そして私たちは、完了の定義を「全ての機能検証を完了し、不具合が修正されていること」としているため、テスト自動化のベストプラクティスは、一つの機能が出るたびに全て自動化され、全ての不具合修正がされている状態です。そのため私たちQEの具体的な品質活動は、独自のセオリーに基づいて、実装準備段階で受入基準の設定やレビュー、開発中には設計などのレビュー、単体テストの実装、API UIテストの実装と、アジャイルで反復的に組み込んで進めます。
しかしQEは、プロダクトやストーリー（機能）の内容によっては、E2Eテスト自動化をしない、という選択をする場合があります。自動化を推進するのが目的ではなく、品質を測定向上、維持を目的としているからです。私たちは、プロダクトや仕組みを最終的に全てお客様にお渡しする前提で進めるため、お客様の方での取り扱いが困難であることが目に見えてわかるようであれば、そのような選択を取っていきます。
テスト自動化をする基準は、一番難しいポイントでも有りますが、プロダクトやストーリーによって変わってくる部分なので、QCDを意識し、状況に応じて進めていきます。
また、プロジェクトやプロダクトに関わる全員が、品質に対するオーナーシップを持っていただくことが前提としてあるため、テスト自動化の環境が全くない状態で、QEというロールを突然設けることは難しく、まずは啓蒙活動が必須だと思っています。
「とりあえず流行っているから」という理由でテスト自動化を始めると、途中からその必要性があまり理解されなくなり、最終的には、「壊れたのでそのまま破棄します」となるのをたびたび目にしてきました。こうならないためにも、事前に啓蒙活動を行い、品質に関する理解を得ることは重要であると感じます。
そして個人的には「バグを見つけてくれてありがとう」とチーム内で言える関係性を構築していくことも、同時に必要であると思います。
日野杉：まだまだQEの詳しいアプローチ方法を伝えきれていません。この話を聞いて、少しでもQEに興味を持った方がいらっしゃいましたら、Buildサービス推進チームにぜひお気軽にお声がけください！
※現在、Buildサービス推進チームでは、下記ポジションを募集中です。ご興味のある方は、ぜひこちらもご覧ください。
・クオリティエンジニア
・ソフトウェア開発エンジニア
・ソリューションオーナー
・アーキテクト