目が回るほど忙しかった先月に比べ、
プロジェクトもようやく一段落してきました。
とはいっても、まだマスターアップしたわけではなく、
オール・イン（※）が終わっただけです。
（※）予定していたすべての要素を入れ終わること。
ゲームとしてひと通り遊ぶことができるが、
まだまだ不具合は取り切れていない。
現在はデバッグ期間として、テストプレイヤーから
あがってきた報告に従って不具合を修正したり、
自身もテストプレイを繰り返したりしています。
Ｘ Ｘ Ｘ Ｘ
ところで、一口にデバッグ期間といっても、
マスター納品日に近づいていくにつれて、
その対応の仕方は変わっていきます。
ハッキリと定義があるわけではありませんが、
個人的な感覚では、大体以下の３段階くらいあると思っています。
＜第１段階＞ ～調整期間～
不具合修正のみならず、
バランスの調整や演出の強化なども積極的に行なっていく期間。
実際にプレイを繰り返すことで見えてくる欠点も多いので、
この段階の時間をいかに多く確保できるかが作品の品質に大きく関わる。
＜第２段階＞ ～不具合対応のみ～ （←今、私はココ）
よっぽど気になる箇所を除き、不具合修正以外の対応は行わない。
その不具合修正についても、修正による危険性を個別に吟味し、
危険度の大きな修正・大掛かりな修正は極力行わない。
＜第３段階＞ ～ノータッチデバッグ～
マスターまで残り数日というくらいの、本当の直前期間。
致命的なバグでない限り、不具合が見つかってもあえてスルーする。
このように「不具合発見→修正」を単純に繰り返し続けるだけでなく、
開発終盤では「わかっていてもあえて直さない」という判断が出てきます。
なぜそんな判断をするのかというと、
「不具合を直したことが原因で、別の場所に新たな不具合が発生する」
ということが、ゲーム制作を含むＩＴ業界では割と頻繁に起こるからです。
（このように、新たにバグを仕込んでしまうことを
「デバッグ」の対義語で「エンバグ」と言います）
マスターまで間があれば、仮にエンバグしてしまったとしても
高い確率でそれを見つけることができます。
しかし、開発が終盤になればなるほど、エンバグしたことに気づかず、
そのままマスターを迎えてしまうリスクが高くなっていきます。
エンバグによって生まれた不具合が、元のバグよりひどい結果を引き起こし、
最悪の場合、回収騒ぎに発展……なんてことも絶対にないとは限りません。
ですから、本当の終盤になって見つけてしまったバグは、
よほど致命的か、逆によほどエンバグリスクが低そうな修正を除いて
スルーしていく、というのが基本になります。
（この辺の線引きは、通常ディレクターが行なっていきます）
もちろん、見つけてしまった以上、スタッフ全員本音では
「恥ずかしいよー！！ 直したいよー！！」
と心底思っています。
自分たちが丹精込めて作ってきた作品に欠陥があることを知り、
知りながらスルーするというのは、正直、かなりつらいことです。
しかしこれは、第３段階に至る前に見つけられなかった
自分たちが悪いと思って、自らの不徳を責めるほかありません。
「マスター直前はいじらない」
これは、プロなら守るべき鉄則です。
プロジェクトもようやく一段落してきました。
とはいっても、まだマスターアップしたわけではなく、
オール・イン（※）が終わっただけです。
（※）予定していたすべての要素を入れ終わること。
ゲームとしてひと通り遊ぶことができるが、
まだまだ不具合は取り切れていない。
現在はデバッグ期間として、テストプレイヤーから
あがってきた報告に従って不具合を修正したり、
自身もテストプレイを繰り返したりしています。
Ｘ Ｘ Ｘ Ｘ
ところで、一口にデバッグ期間といっても、
マスター納品日に近づいていくにつれて、
その対応の仕方は変わっていきます。
ハッキリと定義があるわけではありませんが、
個人的な感覚では、大体以下の３段階くらいあると思っています。
＜第１段階＞ ～調整期間～
不具合修正のみならず、
バランスの調整や演出の強化なども積極的に行なっていく期間。
実際にプレイを繰り返すことで見えてくる欠点も多いので、
この段階の時間をいかに多く確保できるかが作品の品質に大きく関わる。
＜第２段階＞ ～不具合対応のみ～ （←今、私はココ）
よっぽど気になる箇所を除き、不具合修正以外の対応は行わない。
その不具合修正についても、修正による危険性を個別に吟味し、
危険度の大きな修正・大掛かりな修正は極力行わない。
＜第３段階＞ ～ノータッチデバッグ～
マスターまで残り数日というくらいの、本当の直前期間。
致命的なバグでない限り、不具合が見つかってもあえてスルーする。
このように「不具合発見→修正」を単純に繰り返し続けるだけでなく、
開発終盤では「わかっていてもあえて直さない」という判断が出てきます。
なぜそんな判断をするのかというと、
「不具合を直したことが原因で、別の場所に新たな不具合が発生する」
ということが、ゲーム制作を含むＩＴ業界では割と頻繁に起こるからです。
（このように、新たにバグを仕込んでしまうことを
「デバッグ」の対義語で「エンバグ」と言います）
マスターまで間があれば、仮にエンバグしてしまったとしても
高い確率でそれを見つけることができます。
しかし、開発が終盤になればなるほど、エンバグしたことに気づかず、
そのままマスターを迎えてしまうリスクが高くなっていきます。
エンバグによって生まれた不具合が、元のバグよりひどい結果を引き起こし、
最悪の場合、回収騒ぎに発展……なんてことも絶対にないとは限りません。
ですから、本当の終盤になって見つけてしまったバグは、
よほど致命的か、逆によほどエンバグリスクが低そうな修正を除いて
スルーしていく、というのが基本になります。
（この辺の線引きは、通常ディレクターが行なっていきます）
もちろん、見つけてしまった以上、スタッフ全員本音では
「恥ずかしいよー！！ 直したいよー！！」
と心底思っています。
自分たちが丹精込めて作ってきた作品に欠陥があることを知り、
知りながらスルーするというのは、正直、かなりつらいことです。
しかしこれは、第３段階に至る前に見つけられなかった
自分たちが悪いと思って、自らの不徳を責めるほかありません。
「マスター直前はいじらない」
これは、プロなら守るべき鉄則です。