Killing Bugs(バグ潰し)
Written by Ond醇yej 遵ﾜpan醇Tl
2008年2月16日
原文: http://www.bistudio.com/developers-blog/killing-bugs_en.html
　
　バグ修正のプロセスについては、いくつかの”背景となるシーンの情報”があります。
　
　バグ修正は、ゲーム開発における大事な仕事です。この仕事は全く楽しくありません、なぜかと言うとほとんどの場合はクリエイティブなものではないですし、でも必要不可欠な作業だし・・これさえなければ、製品としてリリースさえしてなければ。
　
　このブログエントリーでの狙いは、Bohemia Interactiveの中でのバグ修正プロセスをどのようにして組織的に行っているかを簡単に説明することにあります。いくつかの慣習を説明していくとその中には、この産業に共通する慣習もあれば、私達の会社での特殊なやり方があるかもしれません。
　
　製品寿命においてはいくつかの異なるフェーズが存在します。そしてバグ修正にはそれぞれ少しずつ異なる方法があるのです。みなさんがバグセクションを使うことができる、あるフレキシブルな形式化は、最適化の問題としてみなされることがあります。バグを修正した時、その修正によっては、みなさんはちょっとしたボーナスを受けることになるでしょう(あるいは、未修正のバグが引き起こすペナルティといった形で、自分で見ることもあるでしょう)。バグを修正するコストとして挙げられるもの、それは時間だったり、お金だったり、作業だったり・・・。そして時としてそのコストは明白ではないかもしれません。プログラマーの側面からみたら簡単な修正でも、ゲームプレイの面では重要なインパクトであったり、更なる広範なテストが必要になったりもしますから。
　
バグの修正
　最初に、単独のバグを修正する場合を見てみましょう。これは通常、いくつかの段階を経た上で実施します。
* バグリポートを読む
* それをもう一回読んで、理解を試みる 🙂
* バグが引き起こしている原因が何かを探し出す。
* バグを修正する
* 修正バージョンを展開する
　
　素晴らしいバグレポートは、決定的な重要性を持つものです。素晴らしいバグレポートとは、人は修正に際して、その人自身の目で事象を確認しますから、それを段階的に再現してくれるものを指します(あるいはデバッガー、またはその人自身の扱うセンス)。素晴らしいバグレポートとは、再現の段階を短く区切っていること－もし再現までのステップが複雑であったり、追いかけるのが大変だったりすると、バグ修正にかかるトータルコストが増大します。（訳者注: 「バグレポートしてくれるんだったら、自分らが後で再現しやすいように、長文かつ抽象的にたらたら書いたりしないで、再現条件を簡潔に区切って報告してくれよ」と言いたい気持ちをオブラートに包んで、曖昧に書いているようです）
　
作成 – ゲームのビルド

　設計から開発された製品がベータになると、新しい機能が実装されます。
　
バグの元となるもの:
* ゲームにおけるチーム作業に起因する人の問題
* ハプリシャー(販売元)へのフィードバック
　
バグによるペナルティ:
* ワークフローへのインパクト – 作業から入ってくる何らかのバグは防げますか?
　
バグ修正にかかるコスト:
* 修正するための時間
* テストするための時間はそんなに重要ではありませんが、このステージは大規模なゲームテストはいつでも私達の前に居続けます。
　
計画されたバグ修正のキャパシティ:
* チームの各人は、週に1日はバグ修正に専念すべきです。
　
仕上げ – バグの修正フェーズ
　ベータの状態からゴールドに進むと、たいていの場合、新しい機能を実装することはありません。出てきたバグを修正するのみで、既に盛り込んだ機能をたまに改良するだけです。

　
バグの元となるもの:
* パブリッシャーの要求 – パブリッシャーは製品を受け取らないこともできます、なぜならば”クリティカル”であると彼らが考えたいくつかの事象があるからです。このような事象は修正を必要とし、あるいはいくつかのケースでは私達はパプリシャーを交えてコミュニケーションを取る必要があります。そして時として「これは重要ではないんだぜ」と納得してもらう時もあります。
* 内部テスト – 製品としてリリースすることに立ち塞がるバグを見かけることがあります。
* クローズな外部向けベータ
　
バグ修正のコスト:
* 修正に向けた時間 – これは明白なコストです。事象を修正するのに必要なものは、プログラマーであったり、アーチスト、設計者であったりします。
* 試験に依存する中身に費やす時間: AIバグは代表的です。AIの修正のいくつかは、ゲームのプレイアビリティに強烈な変更を伴うこともあります。リリース日が迫った頃にAIのバグが見つかった時は、それがリリースを遅らせるほどクリティカルなものでない時は、後日パッチとして修正することを前提に進めることもあります。
　
バグによるペナルティ:
* 製品に対する悪い評価がされることを背負うリスク、レビュー記事が悪くなり、セールスに影響する結果に繋がります。
* ワークフローへのインパクト
　
計画されたバグ修正のキャパシティ:
* バグの修正は、チームの中でも最も最優先のアクティビティです。
　
サポート – リリース後のメンテナンス
　リリース前に修正することができなかったものは別として、私達さえリリース前には知らなかったバグを修正します。
　
バグの元となるもの:
* ユーザーからのフィードバック – これこそみなさんです。様々なチャンネル(技術サポート、コミュニティのバグトラッカー、フォーラム等)によって、バグに関する不平が上がってきます。
　
バグによるペナルティ:
* 悪い評判が付いたことによるセールスへの悪影響
　
バグ修正にかかるコスト:
* 内容によって左右されるテストの時間 – これはとてもいろんな問題をはらんでいて、このステージにおいては一般的にはパブリシャーやその他からの品質保証に掛けさせてくれる資金提供はないのです。(訳者注: デベロッパーの瑕疵責任になるので、デベロッパー自身の資金の中で解決しないとならない)
* 修正にかかる時間。既に開発下にある次の製品に影響を及ぼすかは定かではありませんが、バグの修正は旧製品が新製品のスケジュールに何らかの影響を与えることもあります。新製品と関連のない修正事項などは特に。(訳者注: 例えばArmA1で出たバグが、ArmA2に影響するものだとしたらそれはコストではないけれど、ArmA1にだけ現れるバグだとしたら、それは ArmA1のコストとなってしまう、という意味)
* ここでいう興味深いシチュエーションを言うと、修正コストというものは、既に開発中にある製品に対して開発、テストされたものに修正をかけることが重要な意味を持つということです。ArmAのパッチではいくつかのバグ修正を含んでますが、これを引き合いに出すと、ArmA2の修正に繋がる時があったりするのです。こうして時々起こる修正された事象ですが、これはとても重要なやり方ではありません。移行に掛かるコストとしての修正は比較的低めですが、 ArmAの中の修正ではこれらがよく含まれていました。
　
計画されたバグ修正のキャパシティ:
　* もしもゴールドの締切日にたくさんの既知のバグがあると、これらは相当な量の時間を修正作業に割き続けることが一般的でしょう。それでユーザーへのインパクトは最小限に留める、または減らすことができるのです。時々ですが、後日、これら全てのことについてキャパシティを割り当てないままにしておいて、ある時に単独または小さなチームを編成して短期間で一気にバグの修正に専念することもあります。