はじめに
みなさま、こんにちは。
グリーでCS/QA/審査/監査などの組織を統括しております、しゅうまい姫です。
そろそろこの適当につけたHNがつらくなってまいりました。
今年もアドベントカレンダーの季節がきましたね！
去年はQAの一年間の取り組みを総括させていただきました。
(冒頭に簡単な自己紹介のせておりますので今回は割愛します！）
2020年12月24日記事 グリーQA 2020年の振り返り
今年もそうしようと思っていたところ、あっさりと初日にまとめを書かれてしまいました！
12月1日記事 モバイルゲームのQA現場の変化～2021年編～
万策つきましたので、開き直りまして、最終日ですし少し生々しいことを書きたいと思います！
早速ですが、今、この記事を読んでくださっている稀有なそこのあなた。
きっとQAの方、もしくはQA業務に携わるメンバーが身近にいる方だと拝察いたします。
自分はQAではないけれども、組織の都合上、そういったメンバーを評価しないといけない、という立場の方もいらっしゃるのではないでしょうか！(いてください）
会社によっては、組織の構成上プロダクト(プロジェクト)内にQAがいて、各プロごとに評価する場合や、規模的に専門の管理職がつかず兼務で管理される場合もあるかと思います。
今回は、適切に評価してあげてくださいね、ということを伝えるのが主旨ではなく、
適切な目標設定をすることで本人達の視座があがり、そのメンバーたちがキャリアアップする助けに少しでもなれば、ということを願いながら書かせていただきます。
目標と評価
1．目標とはかくあるべきか
言わずもがな、評価をするためには、どのように目標を設定するかが重要です。
ドラッカーは、
『目標は自らの率いる部門があげるべき成果を明らかにしなければならない。他部門の目標達成の助けとなるべき貢献を明らかにしなければならない。他部門に期待できる貢献を明らかにしなければならない』
『目標は組織への貢献によって規定しなければならない。プロジェクト・エンジニアの目標は、技術部門に対して果たすべき貢献によって規定される』
と言っています。
つまり、大前提として、自分の組織が何を目指すかによって目標の方向性は変わってきます。
一般的に組織としての目標の方向性は開発に反映されていくので、ここは開発フェーズごとにQAとして目標を達成するために参考になりそうな要素をまとめてみました。
（ゲーム開発前提でのお話となります。ドメインが違う場合は多少読み替えてください！)
2. 具体的なKPI/KGI
昨今KPIという言葉は一般的に使われるようになってきましたが、改めて用語の説明を最初に載せておきます！
・KPI:Key Performance Indicator(重要業績評価指標)
事業目標を達成するために実行すべきプロセスが、適切に実施されているかを数値化して評価するもの
・KGI:Key Goal Indicator(重要目標達成指標)
最終目標が達成されているかを計測する指標。
KPIが業務プロセスを評価基準とするのに対し、KGIは最終的に達成する必要がある目標を、定量的に評価する指標
以下がゲーム開発の各工程において、QAとして達成すべきことの例となります。
まず、開発フェーズと運用フェーズで着目するポイントが少し変わってくることと、開発フェーズの中でもさらにポイントが変わるので、小フェーズにも分けて考えてみました。
KPI/KGI例の各要素については分類ごとに具体的に記載するため、
①品質に関するKPI/KGI
②QA費に関するKPI
③テストカバレッジ
④プロセス改善
に分け、番号を振っています。
| 大フェーズ | 小フェーズ | KPI/KGI例 |
|---|---|---|
| 開発フェーズ | α（主要機能実装） | ・α向けに計画したテストの進捗③ ・テスト範囲内の不具合検知状況① |
| β（全機能実装） | ・β向けに計画したテストの進捗③ ・全体の不具合検知状況① |
|
| ブラッシュアップ期間 | ・リリース時の残不具合数① ・QAで検知した高ランク不具合数① |
|
| 運用フェーズ | リリース初期 | ・リリース時の市場不具合① ・テスト費用（内製工数、外部発注費用）② ・運用向けテスト最適化進捗④ |
| 長期運用期間 | ・月間の市場不具合数① ・テスト費用（内製工数、外部発注費用）② ・改善タスク進捗④ |
※最近だとクローズドβテスト(CBT)を実施するサービスも増えているので
そこも一つのチェックポイントにするとよいかと思います。
(サービスのクオリティ面だけでなく、それを実現できたかどうかの評価ポイントとして)
①品質に関するKPI/KGI
開発と同じ組織内にCSやQAがある場合は、『チームとして障害を〇件落とす』という粒度の目標を設定できるのは良いと思います（それに対して各職掌が何をするかは別途検討が必要ですが)。
障害はQAだけで減らせるものばかりではないので、より大きな動きがとれるという意味で理想的です。
では、個人レベルで設定するにはどうしたらよいのかについてですが、例えば「一年(半年)の障害数を〇〇件までにする」という目標はシンプルでわかりやすいものの、設定するには慎重に検討が必要です。
不具合数/障害数をKPIに設定するには、まずは現状の障害数がどの程度なのか、そこから何割減らすか、どのような対策をして障害を減らしていくか、具体的なアクションプランを踏まえて設定するほうが、より成長に繋がります。
そのため、
・前期比〇％にする
・特定の障害種別(『テスト設計漏れ』等)を何割減らす
など前提条件を決めた上で設定をすることをお薦めします。
もう少し具体的な例をあげて補足すると、上記表内でブラッシュアップ期間の『リリース時の残不具合数①』ですが
目標：リリース時の残不具合数は高ランク不具合は0件、中ランク不具合は3件までに着地させる
アクションプラン①テストスケジュールをデグレの修正確認なども考慮して調整する
アクションプラン②不具合優先度を可視化し、各々の修正の期日を切る
などが考えられます。
②QA費に関するKPI
費用についても障害同様です。
単に〇〇円にする、というよりは根拠をもった数値の設定をお薦めします。
QA費用がかからないに越したことはありませんが、それで障害が発生して返金などにつながったり、お客さまの満足度が下がって離脱に繋がっては中長期視点で見たときに損失につながります。
では、妥当なQA費はいかほどなのか。
すみません、こちらはなんとか算出できないか数年色々と苦戦しているのですが、開発体制や会社としてのサービス品質の方針に左右されすぎることもあり、きれいな数式は作れていない状況です。
そのため、やはりそのアプリ(サービス)自体との比較にて設定することが多いです。
テスト費用（内製工数、外部発注費用）がベーシックなKGIではありつつ、これを踏まえて
・(パートナー会社や派遣さんと連携する等で)社員関与工数を昨年比〇割減らす
・テストを一部自動化/効率化することで、一施策のQA費用を〇割削減する
・問い合わせに対して内部ナレッジを強化することで、社内でのやりとりを〇割削減する
・お客さまのステータス確認を自動化にすることで、平均〇件対応していたものを〇割削減する
などが目標として設定できそうです。
③テストカバレッジ
より精度の高いテストを実施するために、テストカバレッジを目標に入れるのも一つだと思います。
テスト対象を踏まえ、テスト範囲を適切に設定し、テスト観点を抽出することは、抜け漏れのないテストを実施する上で非常に重要となります。
ただし、テストカバレッジだけだと定量的な目標とするには難しいので、それを踏まえたテストの進捗を見るのが良いかと思います。
表に記載した例を補足すると
・α向けに計画したテストの進捗
・バトル機能のテスト設計及びαフェーズ時点で完了が必要なテストの完遂
(完遂が難しい場合は、完了が必要な％の記載もあり)
・バトル機能の汎用的なテストに使用可能なテスト観点リストの作成
といったことを目標に設定することも有用かもしれません。
また、開発当初にテスト設計をしても、エンバグやデグレが発生することを考慮し、
再テストも含めたテストカバレッジを検討できると、よりクオリティがあがってきます。
④プロセス改善
アプリのゲーム開発においては、運用フェーズに入るとイベントやガチャなどの施策が一か月に何度も発生するため、いかに品質/効率よく運用できるかはサービスを長く続けるために看過できません。
そのため、QAのメンバーも開発サイクル全体、もしくはQA領域における大小のプロセス改善を進める必要があります。
何のためにプロセス改善するのかというと、最終的には障害抑制などのリスクマネジメントや効率化が目的になりますが、途中経過でのチェックポイントという意味でも目標に設定することは十分ありだと思います。
プロセス全体の改善のKPIはPMBOK等にあるものを参考にいただくとより良いかと思いますが、テストプロセスに関係する点に絞った話ですると以下をKPIに設定するのもありかと考えます。
| 目的 | 小目的 | アクション | KPI |
|---|---|---|---|
| 品質向上 | 各工程での作業の抜け漏れ削減 | リスト作成による工程毎の作業の可視化と チェックフロー構築 |
‐ |
| 各工程でのinput/outputの定義 | 必要事項を網羅したテスト計画書、 テスト設計書等の作成 |
‐ | |
| QA前品質の向上 | QA前実装完了の徹底 | テストブロッカ―数 | |
| 費用適正化 | QA前品質の向上 | QA前仕様FIXの徹底 | 仕様変更による再テスト数 |
| 見積と実績の乖離防止 | 見積プロセスの見直し (見積時の情報の精緻化) |
見積/実績の乖離比率 | |
| 上流工程での不具合検知 | 仕様書レビュー等静的テストの強化 | 工程別不具合検出率 |
（一旦、目的を品質向上/費用適正化にわけて記載してみましたが、どちらにも寄与するものがほとんどです）
『各工程での作業の抜け漏れ削』や『各工程でのinput/outputの定義』については、KPIで追うというよりも、成果物でを設定して進めるほうがよさそうです。
3.これはやめよう
ここまでは、こういうKPI/KGIを用いて目標設定するとよいのでは、という話をしてきましたが、逆に気を付けたほうがよいことを記載します。
QAの例としては、「障害削減を徹底して、可能な限り市場不具合を0件にする」などがあげられます。
この場合、徹底することで何を実現するのか（テストケースを詳細化するのか、仕様レビューで初期不具合リスクを下げるのか、など）が不明瞭ですし、市場不具合が1件なら達成なのか、2件なら未達成なのかも曖昧です。
そのため、こうしたワードは避けて具体的にどういう取り組みをするのか、どういうKPIとするのかを明確にしていきましょう。
これはQAに限らず一般的な話にはなりますが、曖昧な目標とならないよう『使ってはいけないNGワード』と言われているものがあるので記載しておきます。
大事なことだと思うので必要事項とあわせてセットでご認識ください。
・努力する、努める、徹底する、頑張る、目指す
・支援する、助言する、協力する、調整する
・極力、可能な限り、できるだけ、なるべく、必要に応じて
・積極的に、強調して、臨機応変に、迅速に
・効率化する、明確化する、安定化する、共有化する、評価する、向上する、推進する、図る、検討する など
参考サイト：あしたの人事
目標設定の季節、上司との面談で避けておきたいNGワードとは？
さいごに
冒頭に
規模的に専門の管理職がつかず兼務で管理される場合もあるかと思います。
と書きましたが、実は、配下にQAエンジニアの方がいて、当初どういう目標で合意すれば良いのか悩んだことが今回のアドベントカレンダーのきっかけでした。
少なからず自分がやっていた仕事ならあたりがつきますが、エンジニアリングがわかるわけでもないのに、どういう目標にして、どういう評価とすればよいのか。
QAエンジニアとなると、プロダクトのエンジニアと求められるものは少し違うものの、QA的な要素/エンジニア的な要素をうまく融合させたいものの、後者がよくわからない。誰か教えてくれないかな、と思ったものでした。（今でもまだわからないところが多々ありますが…！)
仕事の関係で各社のQAの方とお会いしますが、QAという独立した組織に所属しない方もたくさんいます。となると、その方の上司は自分と同じ悩みをもつのではないか、と予想しています。
評価のために組織があるわけではないので、色々な形があってしかるべきだとは思いますが、一人一人がよりやりがいを感じながら働いて成長できることは、QAの業界にとって大事なことだと考えてます。
今年のアドベントカレンダーは、QAに限らず良いサービスを届けるうえでCSや審査、監査様々な観点でメンバー一同でお送りさせていただきました。
観点がぼやけることを回避するために本記事はQAに特化して書かせていただきましたが、どの職種においても、適切な目標をもって日々仕事ができるよう、意識していきたいと考えています。
その積み上げがより良いサービスの提供に繋がると信じて。
最後までお読みいただきありがとうございます。
2022年は2021年よりも成長していますように！
それではみなさま、メリークリスマス！