Monthly Archives: 12月, 2016

12月
14

商品開発における品質管理とデバッグの重要性

posted on 12月 14th 2016 in System&Game with 0 Comments

はじめまして。今回のブログ記事を担当いたします田中です。
東京オフィスでゲームプランナー、バナー制作、Flash/AnimateCCのアニメーション制作、といった業務を担当しております。

今回は新山からバトンを受けまして、品質管理とデバッグのお話です。

商品開発には、品質管理「QA」や不具合を取り除く作業「デバッグ」が必ず行われます。
デバッグと言うとPCを使った開発が主に頭に浮かぶ方が多いのではないかと思われますが、ゲームやWeb、アプリ開発以外でも開発と名のつくものであれば、リリース、商品化する前には必ず必要になる作業です。
私は開発側の人間ではありますが、必ずと言っていいほどデバッグに携わっております。(デバッグという言葉は広義で様々な意味を持ちますが、今回は単純に「不具合を取り除く作業」、という意味でお話しいたします)

不具合が起きた時--例えばオンラインゲームアプリのリリース時を例にあげますと、

「アイテムが消えた!」
「ログインできねーじゃん!」
「いきなり強制終了した!」
「友達登録ができない!」

……といった苦情をアプリレビューやSNSなどで多数見かけたり、あるいは実際に体験された方も多いのではないでしょうか。
しかし、どんな開発においても不具合というものは付きものなのです。だからこそ、デバッグという作業が発生します。

私は過去に様々なジャンルのゲーム開発においてデバッグに携わりましたが、どの会社でも、同じチームの方は必ず口を揃えてこう言います。

「バグがゼロの時ほど怖いものはない」……と。

開発においてデバッグに費やせる時間と予算はほんの一握りです。会社によってはデバッグチームがなく、開発者が自らデバッグを行うこともあります。
だからこそ、デバッグの際には短時間で効率良くチェックをする方法が必要になります。
デバッグや開発未経験者に何も説明せずにデバッグをお願いするとかなりの量で報告が来ますが、そのほとんどが仕様だったり、今の段階では見なくても良いような箇所だったりします。これでは時間の浪費(ロス)につながります。

 

では、どのようにして短期間でチェックを行うのでしょうか。
以下は開発環境でのデバッグ方法です。

はじめに理解しなくてはならないのは、「今回チェックすべき範囲」です。これは、その時実装するものに限られます。
初めて商品をリリースする場合は全体的なチェックが必要になりますし、既にリリースされていて新機能(オンラインゲームなら期間限定イベント、新キャラ・新ステージなど)を追加する際は、その辺りを重点的に見ることになります。

チェックを行う人は、まず実装物の仕様を仕様書や口頭などでしっかりと確認し、チェック項目の目処を付けます。
その後、実装前に一度、チェックシートをExcelシートなどで作成します。出来れば、重要度に応じてS、A、B、Cといったランク付けを行うと良いでしょう。
一例をあげますと、項目には「街で主人公のグラフィックが表示されていること」のように、どのようになっていれば正しいのかを記載します。チェック内容が明確な時は「街:主人公の表示」といった風に簡略化することもありますが、他のチェック者にも理解出来る内容を記載し、注意点は備考欄に記載します。

そうしてチェックシートが出来ましたら、特に重要なものや外せないものを再度リストアップし、一項目辺りにかかる時間から総チェックにかかる工数を決めます。
特にメンテナンス時は1時間中の30分だけ、といった短い時間で行うことがほとんどですので、特に重要度の低いチェックは開発環境でのチェック時に全て済ませておきます。

チェックは修正に時間のかかるものから順番に行います。動作に関わるようなシステム、グラフィックなどが特にそれに当たりますね。
テキストの誤字などは動作には関わらないバグですので、こちらは修正が後回しになることが多いです。(ノベルゲームではむしろ最優先となりますが)

チェックが終わったら(或いは随時)、発生した不具合をまとめ、それぞれの担当者に報告して修正依頼を出します。
後ほど修正された時にその項目だけをチェックし、バグがなくなったところで再度全体的なチェックを一度行い、これで開発環境のチェックが完了します。

つまり、リリース直前は既にチェックと修正を行い、バグがなくなった状態(これらの作業工程をまとめてデバッグと言います)なので、メンテナンスではそこまでのチェックをしなくても良いわけです。
メンテナンスで行うのは「本番環境に正しく開発環境の状態が反映されているか」です。特に画像の反映を忘れていたりすると、しょっぱなから何も表示されなかったりします。もちろん、デバッグモード(RPGだと倍速移動やエリア移動コマンドなどのチェック用機能)の封印も忘れずに行い、そのチェックも行います。

以上が大まかなデバッグの流れとなりますが、それでも本番に不具合を洩らしてしまうケースはよく見かけます。こうしたものはお客様からのお問い合わせによって運営へ、さらにデバッグ担当者や開発者へと伝えられます。特に、大勢のユーザーに影響するような重大な不具合を見つけた場合は、すぐに緊急メンテナンスを開くことになるでしょう。

オンラインゲームにおいては、不具合を修正した際に大抵「補填」が行われます。ゲームによって内容や条件は様々ですが、もらえるものは有料アイテムだったり、ガチャを回すための宝石(詫び石とか言われていますね)だったりします。

しかし、それらはデータでいくらでも渡せるとはいえ、決してタダではありません。補填には有料アイテム分の損失があり、ひいてはゲームの寿命を浪費する結果となるのです。時には数十〜数百万円もの損失になることもあります。
ただでさえ基本無料で提供することの多いオンラインゲームでは、サーバー設備費や多くの人件費などで資金がカツカツになりますし、ギッシリと詰まったイベントの準備もあって開発期間に余裕がありません。このようなミスで資金を浪費するのは、なるべくして避けなければならないのです。

開発においてデバッグはかなり後回しにされがちな工程ですが、ここまでの話でどれだけ重要な作業であるか伝わりましたでしょうか。
はじめにも述べましたが、上述の内容は決してゲームやアプリ開発に限ったことではありません。開発とつくものがあれば、どんな商品にも品質管理があり、不具合(不良品)のチェックがあります。

我々開発者の前には必ずお客様がいらっしゃる--そのことを常に念頭におき、極力不具合をなくすよう努めながら開発していきたいものです。

Read Article