[前編]品質管理部の役割とは？
新人が経験した業務をもとにご紹介

こんにちは。Diezon品質管理部の新入社員のTです。

今回は2022年6月にDiezonに入社したばかりの私が、Diezonにてソフトウェアシステムの品質管理に
3ヶ月間取り組んで感じたことをお伝えします！
また、「品質管理ってそもそも何？」「どんなことするかイマイチ分からない」という方に向けて、
Diezonの品質管理部の業務内容や、品質管理部の業務に向いている/向いていない方の特徴についても
お伝えできればと思います。

Diezonの新人の業務や、品質管理の仕事に少しでも興味がある方は是非最後までご覧ください！

※本記事は大変長くなりましたので、前編・ 後編に分けてお送りさせていただきます。
目次は全編を通したものとなりますので、ぜひ本記事は最初から読んでいただけると嬉しいです。

• Diezon品質管理部の業務とは？
• そもそも品質管理部は何をする部署なのか
• 入社直後の品管新人の業務
• 不具合を見つけるのは楽しい！けど難しい
• 見つけやすい不具合
• 見つけ辛い不具合
• Diezonならできる！今見据えている自分の成長戦略
• 入社3ヶ月経った今感じること
• これから身につけたいこと
• Diezonのプロダクトの「品質」を高められる人材に！
• Tが思うテスト業務に向いている/向いていない人の特徴
• Diezonでのテスト業務に向いている人の特徴
• Diezonでのテスト業務に向いていない人の特徴

Diezon品質管理部の業務とは？

まずはDiezonの品質管理部が何をしている部署なのかご紹介します。

そもそも品質管理部とは何をする部署なのか

求人サイトで「品質管理」「QA」などの言葉はよく目にしますが、
具体的に品質管理部が何をする部署なのか、意外とイメージできない方も多いかと思います。
品質管理部がどういった部署であるかの説明の前に、まずはDiezonのシステム開発についてご紹介します。

現在のDiezonではECシステム（ネットショップシステム）の開発案件が多く、
今のところ私はECシステムのプロジェクトにのみ業務で携わっています。
ECシステムの開発フローは以下の通りです。

こうした開発フローの中で品質管理部が主に担当するのは「テスト設計」「テスト実施」です。
これらの品質管理部におけるテスト工程は通常、開発フローの最終工程として行われます。
つまり品質管理部の主業務であるテストとは、「要件定義〜デザイン作成で決まったこと」の通りにシステムが実装/コーディングされているかを確認するということです。
そのため、要件定義〜コーディングにおいて「どういう経緯でデザインが決定されたのか」
「何故この機能が必要なのか」などの背景を、設計書を読んだりメンバーとコミュニケーションを
とったりして理解しておくことが、質の高いテストの設計/実施に繋がります。

また、一つの案件の開発工程においては、「テスト設計」「テスト実施」として関わることが主ですが、
品質管理部の役割としてはテストに限らず、「ソフトウェアシステム（=プロダクト）の品質を向上させるための全ての業務」が当てはまります。

Diezonの品質管理部では、目指すべきプロダクトの品質基準として以下の内容を定めています。

• ・ユーザーの使い勝手が良いこと（使っている時にストレスを感じないか）
• ・運用者の業務効率性をあげられること（設計された業務フロー通りスムーズに動くか）
• ・単体機能として成立していること（各機能1つ1つが決められた仕様に沿って動くか）

上記の品質基準を高めるため、例えばリリース後にユーザーの利用状況からUI改善を提案したり、
機能やデザイン要件を決めるフェーズに参加し、運用者の業務フロー理解度を高めた上でテスト実施できるようにしたり、 開発者への不具合傾向のフィードバックやシステム開発フローの改善提案などなど…。

以上のように、テストを始めとした業務によってプロダクトの「品質」を「管理」するのが、品質管理部の役割です。

入社直後の品質管理部新人の業務

品質管理部の業務の全容は前項の通りですが、もちろん私のような新人は入社直後からいきなり全てを任されるという訳ではなく、まずは「テスト実施」業務から担当しました。
具体的には、設計されたテストの仕様（挙動の定義）に沿って期待された通りにECサイトが動くかを確認し、ユーザー目線で操作してみてエラーや表示などのおかしなところがないかをチェックします。

検出した不具合を開発者に報告して修正依頼を出し、修正されたものを再度確認し、
不具合が発生しなくなるまで見届けることがテスト実施者の役目です。

品質管理部としては「プロダクトの品質向上」を目的としているので、仮に仕様通りだとしても、
ここはもっとこうした方が使いやすいのではないか…など、
ユーザー目線での改善提案も「品質向上」につながるため、この辺りは今後積極的にできるようになっていきたいと思っていることです。

不具合を見つけるのは楽しい！けど難しい

ソフトウェア開発におけるテストの主な目的は、システムに存在する不具合をなるべく多く発見して、
開発部に報告して修正してもらうことです。
不具合を発見できた時は、「品質向上に貢献できた！」と、やりがいを感じられて楽しいのですが、
テストで全ての不具合を漏れなく見つけるのはとても困難で、 リリース後に不具合報告が出てしまうことも多くあります…。

そもそもテストには、「不具合があること」は示せても「不具合がないこと」は示せないという特徴があります。
本来は一切の漏れがないテストを設計することが理想ですが、開発の予算/時間は限られており無限にテストすることはでません。
そのため、どうしてもテストケースでカバーしきれないケースが出てきてしまいます。

このようにテストケースの漏れから、結果として検出の漏れを経験した不具合の中で、
私が感じた「見つけやすい不具合」「見つけ辛い不具合」が潜む機能の特徴をそれぞれご紹介します。

見つけやすい不具合

テストケースに漏れがあっても、私が不具合を見つけやすいと感じた機能の特徴は以下の２つです。

• 利用者の用途を想定できる機能
• 普段の生活でも良く使う機能

【利用者の用途を想定できる機能】
上述した通り、テストケースも完璧ではないので、不具合をできるだけ多く検知するには、ユーザー行動を想定してテストを実施するのが有効です。
ユーザー行動が想定できていれば、テストケースに具体的な記載がなくても、テストすべきだ！とすぐに判断できるので、割と簡単に見つけられると感じました。

【普段の生活でもよく使う機能】
ここをこう操作したらこうなる！といったように、動作を正しく理解できているシステムに関する不具合は発見しやすいです。
例えばAmazonを日常的に使っていて機能を理解していれば、「ほしい物リスト」ボタンを押したのに「カート」画面に移動したら、少なからず違和感や疑問を抱くかと思います。
「このボタンを押すとほしい物リストの画面が開く」といつもの機能動作を知っていることにより、カート画面に移動することはいつもの動作（=この場合本来の期待値）に反している！と、すぐに不具合を検知できるということです。

見つけ辛い不具合

続いて、テストケースに漏れがあると、不具合を見つけ辛い機能の特徴は以下の２つです。

• 使い方は知っていても、仕様と異なる使い方ができる機能
• 使い方がイメージできない機能

【使い方は知っていても、仕様と異なる使い方ができる機能】
使い方は知っている機能だとしても、テスターの期待とは異なる使い方によって生じる不具合は、検知が難しいです。

例えば、ECサイトの注文個数が「0~999までの数字を入力可能」という仕様なのに、コーディングミスで、マイナスの値を入力してもエラーが出ず、注文金額もそのまま計算されてしまう実装になっていたとしましょう。
もし１,000円の商品を-5個購入されたとすると、合計は-5,000円。
つまり商品購入が会計上は５,000円の値引きになっていた！という事になるかもしれません…。

注文個数にマイナスの値が入力されるのは想像しづらいケースかもしれませんが、そういった箇所にこそ、ECサイトにおいて重大な問題に繋がる不具合が潜んでいる可能性があります。

では、このような不具合を検知するためにはどうすれば良いでしょうか。
すぐ思いつく答えとして「入力可能な値を全てテストする」方法があるかもしれません。
確かに上記例では、注文個数10個の場合、９個の場合、8個…0個、-１個…と入力すれば、注文-1個の確認時に不具合を検知できます。
しかし入力可能な数値の上限/下限が決まっていなければ、どの値まで確認すればいいのか分からず（999まで全て確認する？マイナスはどこまで確認？など）、
限りある予算・時間の中でテスト範囲が無限に広がってしまいます。

このような場合に有効なのが、「閾値」を活用することです。
閾値とは、動作条件・判定などが変化する境目となる値のことです。
判定の境目の誤解やコーディング時の条件記述の誤りなどにより、閾値付近では不具合が起こりやすいため、テストにおいて効果的な値と言えます。

ここでは仕様が「0~999までの数字を入力可能」なので、閾値は「0」と「999」です。閾値で正常に入力できるか、閾値から±1となる値でエラーが起こらないことを確認すれば、-1の時に不具合（エラーが起こらない）が起こることを効率的に検知できます。

このように、不具合が起こりやすそうな箇所を効率的に確認する切り口（＝観点）は他にもたくさんあり、実務・勉強を通して身につけることができるので、 テストケースから漏れてしまう不具合があったとしても、知識でカバーして検知することが可能です。

【使い方がイメージできない機能】
システムの使い方をイメージできないと、何らかの事象が起きたとしても、それが元々そういう仕様なのか不具合なのか判断しづらくなります。
初めて使ったECサイトで、機能に対する違和感や疑問を感じることは難しいですよね…。

先述のAmazonの例だと、Amazonを一度も使ったことがない人が「ほしい物リスト」ボタンを押して本来移動するはずではない「カート」画面に移動しても、 Amazonではカート画面のことを「ほしい物リスト」とも呼ぶのかも…と思い、不具合であってもそのことに気付くことはないかもしれません。

単純にテスト仕様書に則ってテストするだけであれば特に必要ありませんが、テスト仕様書を作ったり、テスト仕様書に漏れた不具合を見つけたりするためには、 設計書やメンバーとのコミュニケーションを通してシステムの機能/仕様を正しく理解し、「どういう操作をしたらどのように動作するのか」を把握しておくことが重要です。

---

長くなってまいりましたので、この続きは後編記事にて！