セミナー

【CEDEC 2020】グリーとKLabが「障害を減らす取り組み」を発表…共同研究から判明した類似点や違いとは

2020.09.10 12:04

コンピュータエンターテインメント協会（CESA）は、9月2日～4日の期間、国内最大のゲーム開発者向けカンファレンス「コンピュータ・エンターテインメント・デベロッパーズ・カンファレンス 2020」（CEDEC 2020）をオンラインで開催した。

本稿では、9月2日に行われた講演「運営タイトルの障害を減らすモバイルゲーム運営会社2社の取り組み」についてのレポートをお届けしていく。

本セッションには、グリー・Customer & Product Satisfaction部の奥泉卓也氏、KLab・品質管理部品質管理グループの筑後友恵氏が登壇。運営中の既存タイトルから発生する障害の削減と再発防止に的を絞り、「障害を減らす」「減らした状態を保つ」ことに組織的に取り組むことにチャレンジしている2社のQAチームが行っている取り組みを紹介した。

奥泉卓也氏
グリー株式会社
Customer & Product Satisfaction部

筑後友恵氏
KLab株式会社
品質管理部品質管理グループ

本セッションでは、各項目で両社の取り組みを比較できる形で公開。まずは2社のQA組織体制を紹介した。

体制としてKLabが特徴的なのは、QAの横断活動は昨年スタートしたばかりだということ。また、グリーは担当範囲ごとに「グリー」「WFS」「ポケラボ」の3チームに分かれているのが特徴となる。チーム間では合同ミーティングも行われているため、ナレッジなどは相互で共有できる環境であると説明した。

続いて、両社のモバイルオンラインゲームの運営状況を紹介。2社共に5年以上運営しているタイトルがあり、その中で新規タイトルも並行して開発を進めている。運営タイトルに関する障害対応は工数を圧迫してしまうため、できるだけ減らしていきたいという共通の想いから共同研究を進めているとの話だった。

▲"障害"とはユーザーの目に触れる市場不具合のことを指す。共同研究のきっかけは、オフィスが近いことから六本木近辺のQA組織で合同研究会を開催しており、そこで話をしたことが発端になったとのこと。

背景として共通で挙げられたのは、長期運営により属人化・複雑化しているということ。グリーでは各タイトルごとに障害分析を行っていたものの、個別で取り組んでいたため、思うような成果が出ていないという事情があったようだ。

問題点は共通していたため、アプローチや内容こそ異なるが、解決策としては次の3ステップにまとめることができたという。

▲本講演では、こちらの3ステップで両社の取り組みを紹介していく。

■Step1：障害の可視化方法を改善する

コンセプトは異なるが、ここは取り組みとしては2社共に似たような対策を実施。

KLabは定量化・数値化に重きを置き、ヒューマンエラーを可視化すれば各タイトル横並びの仕組みができるのではないかと考えた。一方、グリーは各タイトル横並びの比較や分析ができる仕組みを目指しており、既存の枠組みを変えていったという。

集計ツールの統一にあたっては、KLabでは追加コストを極力抑えることが要件に入っていたため、各タイトルごとに使っていたものは運用を変えずにQAが知りたい情報を共通項目として埋め込んだ。グリーでは先ほども話があった通り、各タイトルで自由な障害集計をしていたが、BTSで統一して開発の不具合起票などに使用した。ただ、数値を扱う際にはBTSの一覧より表計算ソフトなどに落とし込んで集計した方が使いやすいため、分析用に数値をスプレッドシートなどに引っ張れる仕組みを作っている。

▲BTSは「バグトラッキングシステム」の略で、バグやタスクをチケットで個別に起票して完了まで追跡できるシステム。

次に障害集計の基準策定のポイントとしては、全タイトル共通で「重大度」を設定したことを挙げた。KLabでも、各タイトルごとにカスタマイズされた障害ランクはそのままに、新たに作った重篤障害の基準を併用することとなった。

▲こちらは障害の基準例。分け方の粒度こそ異なるものの基準としては類似したところが見られる。

続いて粒度の統一を行う。

KLabでは、各タイトルごとに使用していた障害管理表にQAが障害分析のために必要な項目を追記。グリーは、各タイトルの既存内容をリセットして統一することで情報のルール化を図った。

以下はグリーで起票された障害チケットの記載例となる。ポイントとして、誰が後で見返しても何が起きたかが分かる記載方法を意識しているという。

■Step2：障害の分析ができるようにする
障害分析を進めるフェーズに関しては2社で毛色が異なってきたため、ここからは各社の対応を1社ずつより詳細に紹介していく。

▲グリーはQAにフォーカスした取り組みにシフトしていく形になる。KLabはタイトルごとに個別最適にならないように注意したという。

KLabは、現状を把握するために各タイトルごとに週次で障害の振り返り会を実施。その場でQAが障害分析に必要な情報を得つつ、根本原因に対する再発防止策を話し合えるようにした。

また、障害振り返り会を2段階にして、まずはミスが発生した作業や当時の状況を企画・開発・制作・テストの各セクションリーダーが現場の担当者に確認し、その情報を持ち寄ったうえでリーダー陣とQA陣が障害振り返りを行い、再発防止策を立てていくという形にしたという。

▲なお、障害分析の前段階である振り返り会を行うだけでも大きな効果があったと紹介。それまで原因や改善点を憶測で進めてしまっていたところもあったが、各セクションの作業を把握して議論をすることで有効な再発防止策を立てることができるようになった。

▲こちらが障害分析の工程。不具合が起きたのはパターン1と2で同じマスタデータであっても、作り込みと見逃しの原因を特定することが重要となる。

▲実際の分類項目の例。複数タイトルが共通で使える仕組みが作りたかったため、傾向が把握できる粒度に調整を行った。こうして分類することで問題があるプロセスを数字で可視化することができたとの話だった。

対してグリーは、現状を把握するためにコミュニケーションラインを強化。集計した情報を週次で共有した。

障害の内容に関してはタイトルによってさまざまだったが、見逃した原因は共通の基準で分類することができた。また、対策の立て方もタイトルを横断して有用なナレッジとして利用できると考え、見逃し原因を分析の軸に設定した。ここから、グリーでは見逃し原因にフォーカスして取り組みを進めていくこととなる。

Klabでは下流工程で原因を見つけるほど手戻りが多いという理由から作り込み原因に重きを置くことが多かったため、ここは各社で対応が分かれるポイントとなった。

■Step3：再発防止ができるようにする

再発防止に関しては、KLabは作り込み原因のヒューマンエラーを防止するためにシステムやプロセスを改善するという方向に進んだ。グリーは先ほどもあった通り見逃し原因ごとに再発防止を進めた。ヒューマンエラーに関する取り組みはグリーでも行っていたが、こちらは主にQA側のヒューマンエラーに絞っていた。ただし、システムやプロセス改善で防ぐという観点はKLabと共通していたとのこと。

まずはKlabが説明。ステップ2まででどのプロセスに問題があるかが判明したので、どんな問題があるかを明らかにしていく。自由に話し合う中で原因を追究して言語化するのは困難なため、ヒューマンエラーに特化した原因究明のためのフレームワーク（A-KOMIK）を導入。こちらは製造業でよく使用されているフレームワークになるのだが、これを使用することで直接原因／間接原因を明らかにすることができる。

▲チャートを辿ることで同じ原因が多いものを抽出していく。

▲こちらが全体の流れ。直接原因／間接原因の絞り込みは、同時に具体的な再発防止策を立てる要因にもなっているという。

KLabの取り組みは、グリーから見るとかなり開発側に踏み込んだものとなっており、今後、真似していきたいポイントにもなっていると話した。

そんなグリーでは、見逃し原因の中でもQA責に関する障害に焦点を当てて取り組みを進めている。

ここでは、一例としてテストの実施漏れが挙げられた。

こうしたヒューマンエラーもシステム的に再発防止を試みているという。テストケースやマスタデータの可読性を上げるといったことを実施したほか、開発側でデータを入稿した際に担保できるよう、開発へ事前の入力値チェックの提案なども行った。

また、QA側でマスタデータと仕様書の自動比較を行うツールを作って機械的に不具合を潰していったのが特に効果があったという。

テストの設計漏れに関しても一例が挙げられた。こちらは設計者が仕様を考慮し切れずに、本来ならテストケースに入れるべき項目が漏れてしまったために検知できなかった障害の例となる。

▲横断レビューの観点や週次で各チームの情報共有を実施したことで他タイトルでも使えるナレッジを展開できるような環境を作ったということがポイントとなる。

▲今回の注力対象からは外れるものの、開発責やグレー、外的要因に関する障害に関しても対策が紹介された。

こうした努力の結果、KLabでは繰り返し15件発生していた類似障害が0件となり再発を止めることができたという効果が挙がった。グリーでも半期でQA責の障害を35％削減することに成功している。

また、副次的な効果として、プロジェクトマネージャーなど、全体のプロセス改善を担っている方からの需要があったとのこと。障害の直接原因／間接原因を定量的に把握することで、時間がない・人の入れ替わりが激しいといったこととも関連性が見えてくるのではないかという声があったという。