デバッグがどのような流れで行われているのか、1日の流れを通して知りたいです。
今回はこの点についてお話ししていきます。
尚、本記事では、
QAマネージャーのようなリーダー的な役務については一切含めず、
イチメンバー（比較的経験は浅めのデバッガー）の1日の内容を紹介すると共に、
作業をどのような点に注意して実施していく必要があるのか等も含めて説明しています。
※今回は10:00 – 19:00（休憩1時間）で作業をするケースで説明
こんにちは、転すけ（てんすけ）です。
IT系のフリーランスを10年以上やっています。
デバッグからIT業界に入り、スマホアプリ開発を中心にキャリアアップを重ねてきました。
そのキャリアから培った経験を基に情報を発信しています。
デバッグのやり方①：1日の始まり（10:00 – 10:15）
使用するPCを起動する
作業する環境（会社）や役割によってPCの配布状況は様々で、
・個人に専用PCが支給される場合
・共有のPCを使用する場合
などのケースがあります。
いずれにしても作業においてPCはマストなので、
まず使用するPCを朝イチで用意し起動するところから一日が始まります。
使用する機材を用意する
ここでいう機材というのはデバッグ作業で使用する以下のようなものを指します。
・スマートフォン（スマホゲームのデバッグの場合）
・ゲーム機の本体（コンシューマーゲームのデバッグの場合）
・各種ケーブル類（接続ケーブルや充電器など）
どんな機材を使用するのかは、どんな作業をするかによって決まるため、
指示に従って適切な機材を各自で用意します。
使用するアプリやROMのversionを確認し用意する
機材が準備できたら、
デバッグで使用する以下のものを準備します。
その日のデバッグに使用するアプリを準備する必要があります。
デバッグに使用するテスト用のスマートフォンにはそのアプリをインストールするための
「インストーラー」と呼ばれる類のアプリがインストールされている事が主となっています。
（deploygateと呼ばれるようなものが使われる事が主）
そのインストーラーアプリを開くと、
対象ゲームの最新versionのアプリから過去versionのものも含め大量のアプリが一覧化されており、
その中からその日に使用するverのアプリを選択してインストールする事になります。
（使用するアプリは必ずリーダーなどに確認の上インストールする必要があります）
スマホゲームの開発はかなり早いサイクルで行われるため、
1日の中で何度もverのアップデートが行われます。
そのため、朝にインストールしたアプリを1日使い続けるかというとそういう訳ではなく、
作業の途中で都度アプリを最新のものにアップデートするなどが必要となります。
デバッグにはROMと呼ばれるディスク（ゲームソフト）を使用します。
ROMはその日の頭などに配布があるのでRomのverを確認の上デバッグで使用します。
スマホゲームと比較するとコンシューマーゲームはじっくり腰を据えて長期間で開発する傾向にあるため、
1日の中で何度もアップデートがあるということは基本的にありません。
（アップデート頻度：1日1回 ～ 数日に1回程度 ※開発終了期限間近などは頻発する場合もあり）
デバッグのやり方②：デバッグ作業（10:15 – 18:00）
チェックシート（テスト項目書）で自分の担当箇所を確認
デバッグは基本的にチェックシートと呼ばれるものに沿ってテストを行っていきます。
チェックシートは数千～数万という膨大な項目数となっている事がありますが、
その項目をリーダーが分けて各メンバーに担当箇所を割り振ります。
まずは自分に割り振られた項目をザッと読んで内容を確認し、
その上で以下のあたりの点がないかをまず考えます。
・内容がわからない箇所がないか
・期限や1日の作業時間に見合ったボリュームか（割り振られた項目が異常に多い（少ない）などないか）
数百項目などの量を割り振られた時、
1つ1つの内容を先に詳細に読んでいると時間が掛かってしまうため、
まず「大まかにザッとしたレベルで」目を通します。
その上でまず「何をする項目なのかがわからない」という箇所が多いと都度つまづく事になるので、
ある程度は最初の段階で不明点をまとめてリーダーやベテランデバッガーなどに質問して、
やることを理解してからデバッグ作業を始めるとスムーズに進める事ができます。
よくやってしまがちな悪い例として以下のような点があります。
わからないところは全て飛ばして、まずわかるところだけを点々と始めに実施
↓
後々でわからないところに着手し始める
↓
実は先にやっていた作業とつながっている内容である事を理解し、やり直す必要が出た
というように、
無駄が発生する可能性もあるため、
大まかにでも全体を理解しておく事が大事になります。
また、
割り振られた内容をおおよそ理解した上で、
項目の完了期限（いつまでに終わらせれば良いものなのか）を確認する必要があります。
項目の内容と期限を踏まえて、
期限に対してボリュームが多くないか（項目数が多くて終わらないような気がするなどないか）、
または逆に、
明らかに時間が余るほどに少ないボリュームになっていないかなどを確認します。
デバッグ経験がない場合など判断が難しい場合もあると思いますが、
なんとなくでも懸念があると感じた場合は先に相談しておくと後々慌てる事がなくなるので、
ホウレンソウ（報告・連絡・相談）が重要になります。
デバッグ作業の実施
上記までが完了したら実際に作業に入っていきます。
基本的にチェックシートに書いてある事を遵守しつつ、
記載通りにテストして「OK/NG」を記載していく事がベースとなりますが、
以下の点を気に留めながらチェックを行う事が重要となります。
・とにかく「丁寧 / 慎重」に
・些細な事でも周りに確認（質問）する
まず、精度の伴わない速度は無意味です。
丁寧慎重を心がけて、見落としのないように進めることを念頭にチェックを進める事が重要です。
また、どんなに些細な事であっても確認や質問をする事がとても重要です。
デバッグは「些細な事」の繰り返しです。
その些細なことを「まあいいか、これくらい」のような考え方で進めると、
見落としが多発し、ゲームの質はどんどん下がってしまいます。
「まあいいか」として良いかどうかは企画陣や開発チーム全体で決めることなので、
個人でその判断をすることは望ましくありません。
上記までのように、
デバッグ作業は「丁寧 / 慎重 /些細な事でも確認（質問）」というマインドで作業を進める事で、
バグ（不具合）を見つける事ができるようになっていきます。
（この点が念頭にあれば必ず良い成果が望めるはずです）
不具合の報告
不具合を発見したら、その都度レポートを作成します。
レポート（報告書）書き方についての詳細はこちらの記事で紹介しています。
デバッグ作業でよくやってしまいがちな悪い例として以下があります。
バグ（不具合）を発見した
↓
検証作業にキリがつくまで進めてしまいたいので、
ひとまず不具合の報告は後回しにした
↓
結果報告を忘れてしまった
不具合の報告（レポートの作成）を忘れてしまうと、
その不具合が誰にも知られる事がないまま開発が進行し、
ゲームがリリースされた後で問題になってしまうという懸念がありますので必ず報告を挙げる必要があります。
また、「報告は忘れていないが後回しにしている」という点も好ましくなく、
スマホゲームなどは開発速度が速いという特徴があるため、
即時に不具合を報告する事で速度感早くバグを検知→修正という工程を行っていく事が重要になります。
不具合はなるべく早く報告して周知するという事が何よりも大事です。
作業進捗の確認
自分の担当箇所の作業の進み具合について、
期限までの問題なく完了できそうかを定期的に確認しつつ作業を進行します。
1日の最後になってから「終われませんでした」と報告したのではリーダーとしては打てる対策があまりないので、
「終われないかもしれない」と少しでも感じたら早い段階で相談する事で、
フォローを回してもらうなどでチームとして作業を完了させるという方法を取る事ができます。
順調に進んでいるようでも、
何か1つ躓く事があると突然ペースダウンする事もあるので、
進捗は常に意識する事が重要です。
（適度な余裕を持って終われるくらいの見込みで想定できると、何か躓く事があった場合でも時間内に終わらせる事ができます ※これをバッファを持つと言います）
休憩
デバッグ作業については基本的に休憩時間のタイミングは「自由」である事が主です。
チーム全員で足並み揃えて行いたいテストがある場合等を除いて、
基本的に1日あたり1時間程度自由に取る事が可能なので、
各自の作業のキリがついたタイミングなどで休憩に入る事が多いのが特徴です。
デバッグのやり方③：デバッグ作業のまとめ（18:00 – 18:50）
作業進捗の再確認
作業時間が残り1時間程度となってきたところで、
改めて進捗の確認をします。
この段階で始めて「やばい！終わらない！」ということを認識する事がないように、
上記までで都度進捗確認はしつつ作業進行することの重要性を記載しています。
ただ、想定より大きな問題に遭遇する事もあり、
それにより大幅に作業遅延してしまう場合もあるので、
残りの1時間でどうリカバリーするかを考えて、
場合によってはフォローを回してもらうなどの対策を打つ時間としています。
作業まとめ
作業の終了に向けての以下のような最終確認を行います。
・自分の担当箇所に見落としはないか（実施漏れ等）
・報告を忘れている不具合がないか
・その他、連絡事項がないか
担当箇所が多いほど見落としは発生しがちなので、
改めてチェックリストを見返して問題なく完了できているかを確認する必要があります。
また、せっかく発見した不具合も報告を忘れてしまっては問題なので、
報告が漏れている不具合がないか、また、記載したレポートに情報漏れがないか等を確認します。
加えて、その他連絡事項について、
例えば自分が発見した不具合がゲームの根幹に関わるような重大なものであったり、
色々な箇所に影響が考えられる場合、
デバッグチーム全体に周知する必要があったりします。
（その不具合が解消するまではこのテストは控えるべき、等のプラン変更が必要だったりするため）
何か少しモヤっとした事でも、
懸念に感じる点が少しでもあれば周りに共有する事が重要です。
デバッグのやり方④：1日の終わり（18:50 – 19:00）
使用したアプリやromを削除 / 返却
その日のデバッグ作業が終了した後、
使用したアプリやromを削除 / 返却します。
会社ごとのルールによってどこまでやるかは様々ですが、
どの現場でも「機密の保持」という観点が存在します。
機密情報が漏れないようにするための取り組みとして、
使用機材からアプリを消したり、romを毎日回収したりということを行います。
使用した機材を返却
アプリやromの返却が完了したら機材を返却します。
この点も現場によって様々で、
そのまま各自のデスクで保管する場合もあります。
使用したPCのシャットダウン
全ての作業が終了したら、
PCをシャットダウンしてその日の作業を終了します。
（現場によってはシャットダウンせずに敢えてそのままとする場合もあります）
今回はデバッガーの1日の流れに沿ってデバッグの作業内容をご紹介させていただきました。
尚、こちらの記事ではデバッグのアルバイト求人についてどういったものがあるのかを紹介させていただいています。
ご興味を持たれた場合には参考にしていただけますと幸いです。
また、週5日フルタイムでガッツリ稼ぎたいという方はこちらの記事を参考にしていただいて、
「アルバイト」という形態にこだわらず、未経験であっても最初から稼げる方法を選択することをオススメしています。
