12
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

グリー/ポケラボ品質管理Advent Calendar 2024

Day 11

QA視点でもマスタの作りを気にしてみた

Last updated at Posted at 2024-12-10

はじめに

皆さま、こんにちは。
突然ですが、QA業務に携わる方は、日々マスタデータ(以下「マスタ」)の資料を確認する機会が多いのではないでしょうか。
私自身もその一人で、実機での挙動確認と同じくらい、マスタをしっかりと確認することが重要だと感じています。

プロジェクトの早期にアサインされることが多いのですが、
その際はデータ内容そのものではなく、入力のルールやマスタの作りといった根幹の部分にまず目を向けるようにしています。
その際は以下の2点の観点で確認しています。

  1. スプレッドシートなどでツールを作成する時に作りやすい構造か
  2. 運用を考えた時に不具合が起きやすい作りになっていないか

上記を観点として確認を進める中で、異なるプロジェクトであっても似たような指摘をすることが多く、最近ではこの観点に共通性があり有効であると感じるようになりました。
そのため、これまでの経験をもとに、上記2点の観点で早期にマスタ確認をした際の、QAからよく指摘する事例をまとめた記事を書いてみました。
このまとめが少しでも役立てば幸いです。ぜひ参考にしてみてください。

前提

主に下記の前提での記述となります。

  • ゲームのQAで日々マスタデータを参照する方向け
  • マスタがスプレッドシートでの管理の前提
    ※Excelなどでも参考になる部分はあると思います

なぜマスタをQAでも事前に確認したほうがよいか

後から修正を行うとリスクが高い

入力のルールやマスタの作りにフォーカスして確認するので、修正した時の影響範囲が大きい場合が多く、運用に入ってから修正するにはリスクが高く、さらに影響確認のコストも増加します。

QA視点で検証しやすい環境が早期に作りやすい

普段の検証に使用する際に確認しやすかったり、ツールを作る際、困らない作りにすることで無駄なコストを省くことができます。

不具合の作り込みリスクが減少する

そもそもマスタの入力ミスに繋がりにくい仕様にすることで、マスタ起因の不具合の作り込みを防止することができます。

実際の事例とそのリスク

実際に共通しているなと感じた事例を下記で4つご紹介します。

①カラム名が記載される行が統一されていない

危険度 ★★☆☆☆
スクリーンショット 2024-12-05 22.38.13.png

画像のようにシート毎や各マスタ毎で、カラム名が記載されている行が統一されていないことがあります。基本的に実際の入稿時に問題になることは少ないですが、QA側でツールを作る際の関数で調整する際に、少し不便になることが多いです。(index/matchなど
個人的には上部の空白行は無い、もしくは2~3行までが良いかなと思います。

  • 防止できる可能性があるリスク
    • 統一する規則がないのでフランクに行を挿入してしまい参照ズレを起こす

②IDなどがText形式になっている

危険度 ★★★☆☆
スクリーンショット 2024-12-05 23.58.27.png

基本的にIDなどの数値部分はText形式で入力されるべきで無いと思っています。
気持ちはわからなく無いですが、「=10000+B21」のようにして数値形式を崩さずに入力されている方が良いと思います。
Text形式だとlookup系の関数を使用する際、Valueを使用するなど少し工夫が必要になります。
さらに画像のように100009から1000010のように桁が飛んでしまうこともあります。

  • 防止できる可能性があるリスク
    • IDを参照する関数を使用する際、Text形式を考慮できずErrorが出力される

③関数を使う列に一部直接入力されているものがある

危険度 ★★★★☆
スクリーンショット 2024-12-06 0.32.23.png

よくマスタの入稿担当がコピペミスを起こす時、この原因も多いと思います。
いろんな人が入力するマスタほど、起こりやすい問題と感じます。

  • 防止できる可能性があるリスク
    • 行をコピーして使用する入稿担当が見落として、IDが重複したり、意図しないIDとなる

④条件付き書式が多すぎる

危険度 ★★★☆☆
スクリーンショット 2024-12-06 1.23.11.png

目視でミスしにくいなどのメリットがあるのですが、入力量が膨大なマスタではあまりお勧めしません。
ただでさえ、関数などで少し重めなマスタに条件付き書式が大量に入ることで、シート自体の読み込みがさらに重くなり、反映のミスにつながりやすいです。
重複だけを検知する条件など、使用する条件を絞ったり、どうしても目視で見やすくしたい場合は、別のシートにチェック用として場所を作り、そこで使用するのが良いかと思います。

  • 防止できる可能性があるリスク
    • セルの入力を行ったが、反映が上手くいかずに反映ミスが起こる

まとめ

  1. スプレッドシートなどでツールを作成する時に作りやすいか
  2. 運用を考えた時に不具合が起きやすい作りになっていないか

上記の観点を確認することで、事例のような問題をより容易に発見できると考えます。

これらを踏まえ、可能であれば、ルールを作成する段階でQAが同席し、他部門と連携して共同で策定を行うことで、ルール自体の妥当性や運用のスムーズさが向上すると思います。

今回早期に確認するという名目で記載していますが、すでに運用が長期間行われているプロジェクトについても、一度見直しの機会を設けることで、現状のリスクを把握し、必要に応じて改善点を見出すことができます。たとえ修正が難しい場合であっても、潜在的なリスクを認識するだけでプロジェクト全体の安定性向上に寄与するはずです。

マスタの確認作業には多少の手間が伴いますが、その効果はプロジェクトの品質と効率性を高める上で非常に大きいと考えられます。
ぜひ、積極的に取り組んでみてください。

12
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
12
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?