【メンバー紹介 Vol.4】私がQA エンジニアへのトランスフォーメーションを果たすことになった理由

今回のメンバー紹介はエンジニアリング事業部の24601（仮称）さんです。
24601さんがQA エンジニアへのトランスフォーメーションを果たすことになった経緯やエンジニアとしての興味の方向性について語ってくれています。

※個人情報保護のために仮名表示をしています。

＜メンバープロフィール＞
仮称／24601
入社年／2006年
出身地／山口県
所属／CPS事業部　東京ユニット（エンジニアリング領域）
経歴／Android アプリケーションや Web サービスについて、テストや品質保証などを担当してきました。
コメント／
・趣味：自転車での散策
・休日の過ごし方：Web小説の乱読

はじめに

みなさま、はじめまして。株式会社管理工学研究所の24601です。

私は CPS 事業部東京ユニットに所属しており、普段は QA エンジニア（Quality Assurance engineer）として、お客様のサイトで業務を行なっています。

今回は、私がなぜ、コードを書くエンジニアから QA エンジニアへのトランスフォーメーションを果たすことになったのか、ご紹介させていただきたいと思います。

QA エンジニアに至った経緯

ソフトウェアエンジニアリング部門に配属されて幾星霜、社内外問わずいろいろな案件のプロジェクトに関わってきましたが、どの現場でもテスト周りの業務を担当する機会がありました。

アプリケーションの刷新に伴う、機能仕様書および機能試験書の更新
試験用対抗 Web サーバの作成
Verification Test (Stability Test, Performance Test, Compatibility Test) の自動化や運用

場数を踏むにつれてテスト業務に関する知見も増えてくるなかで、テスト周りの業務では、一歩先をいく存在でありたい、そう感じるようになっていました。

そして折しも数年関わっていたプロジェクトが終わる頃、プロジェクトのリーダーと他愛のない立ち話をしている中でテスト業務に話題が及び、そこでテストに対する自分の気持ちを大いに語るというイベントが発生しました。

その時の対話も一因となったようで、任期が終わったタイミングで、別プロジェクトに新しく立ち上がった QA チームの一員として参加することになりました。

実を言うと、当時の私は品質保証というものを正しく理解できておらず、「テストの周辺作業がメインとなるだろうし、これまでの経験がそのまま活かせるはず」くらいに考えていました。実際、join してしばらくの間は、機能試験の仕様書を書いて、機能試験を実施して、回帰テストを自動化して、以前と特に変わらず、与えられたタスクをこなしていました。

そんなある日の 1on1 で、テスト業務について話していた時に、「自分の作ったテスト仕様書が対象プログラムの弱い部分を浮き彫りにする、そんなテスト仕様書が作れる「神の手」のような、「門番（Gatekeeper）」のような存在を目指しています。」と語ったのですが、相手の方に、「なるほど。その方法でも、市場バグは抑えられるね。でも、修正や再テストなどの手戻りは依然として残るよね。もっと前段階で潰せるなら、そこで潰したほうが良くない？」と言われました。そこで、初めて「シフトレフト」という概念を教えてもらいました。

この「シフトレフト」というキーワードを契機として、自分がテスト業務というものを局所的にしか捉えていなかったことに気付くことができて、テスト業務の深淵をいろいろな角度から見ることができるようになりました。

バグの発見よりもバグの防止
最後にテストするよりもずっとテストし続ける
チーム全体で対応する（ここまでは開発側でここからは QA 側で、と分けて考えることはやめる）

この時、QA エンジニアとして歩み始めたのだと思います。

QA エンジニアとは何者か

QA エンジニアとは何をする人なのか、業界有志が考案した「QM (Quality Management) ファンネル」と呼ばれるモデルを利用して説明するとわかりやすいかと思います。

このモデルでは、 QA (Quality Assurance) の専門性は3つの軸（3面）と実業務への関与度合いで整理され、三角錐の形で表現しています。

下記より引用

https://www.slideshare.net/YasuharuNishi/quality-management-funnel-3d-how-to-organize-qarelated-roles-and-specialties

端的にいうと、QA (Quality Assurance) に関する 3 つの専門性は、下記のように整理できます。

TE (Test Engineer: テストエンジニア)
- テストを設計・実施して不具合を見つける人
- メトリクスを測定する人
- 製品やサービスの評価のエキスパート
• PE (Pipeline Engineer: パイプラインエンジニア)
- テストを自動化する人 (SET (Software Engineer in Test), SRE (Site Reliability Engineering) )
• QA (Quality Assurance: QA エンジニア)
- 開発チーム全体の品質を向上させる人
- 組織能力を高めるエキスパート

QA エンジニアについての一般的な定義は、以上の通りです。

自分なりの言葉で言えば、「利用者の方に喜んでもらえる製品（サービス）にするために何をすればよいか、その旗振り役を勤めるのがQA エンジニアです」、それが今現在の私の考える定義です。

QA エンジニアの対象は「品質」なので、製品のテストだけではなく、設計や、より上流である製品企画にも、そして、製品リリース後のサポートにも関わりがあります。

もちろん、どの範囲でQA活動を行うべきかについては、製品の位置付けや重要度、使用可能なリソース、そして製品を所管している組織の文化・体制によって大きく左右されます。それらを考えながら、プロジェクトに適した具体的な進め方を提案していくことになります。

以上のようなことを念頭に置きつつ、どのチームに、どういったアプローチで、何を提案して、それが将来の何につながるのか、そして、そのために自分達は何を行うのか、製品やサービスの品質を保証し、そしてより高めていくために日夜考えるのが QA エンジニアだと自分は捉えています。

QA エンジニアとして、一番興味のあること

エンジニアとして 20 年余り働いていますが、QA エンジニアとしての活動はまだ 3 年間に過ぎません。タスクを消化することで精一杯で、まだまだ学ぶことが多い日々ですが、最近よく感じるのは、言葉や概念をどう定義すれば良いか、そのことにとても敏感になったな、という点です。

例えば、利用者の方に「品質が高い」と感じてもらえるような製品（サービス）を作りたいと考えても、想定する利用者層によって、採るべき施策は異なり、また、QA エンジニアとしてのアプローチも異なります。

処理速度が高いことを重視する利用者
機能が多いことを重視する利用者
価格が安いことを重視する利用者
サポート対応が早いことを重視する利用者

また、「品質が云々」と安易に口にしてしまいますが、「品質」という言葉は相当に多義的に使われています。それを避けるためにISOで定義されているくらいです（ISO/IEC 9126）。内輪の QA チーム内で話す時であっても常に、今議論しているテーマはどの「品質」の話なのか、確認しながら進めるよう意識しています。これは、時間をかけて繰り返し話し合った結果、当初の目的を見失ってしまったり、同じ議論をぐるぐる回ったりして失敗することがあり、そこから学んだことです。

製造品質 or お客様品質
品質管理 or 品質保証
魅力的品質 or 当たり前品質
品質改善 or 品質向上

という具合で、言葉や概念に過敏になったこともあって、「同じ製品（サービス）を扱う他企業が「品質」をどう考えているのか」「全く畑違いの製造業であっても、「品質管理」の話題から学べることがあるのではないか」と、「品質」や「品質管理」をキーワードにして、他社の取り組みやレポートを見たり読んだりするのが、今最もはまっていることです。