現世代機では1本のゲーム開発を行うだけで、数千個というバグが発生し、これにマルチプラットフォームや多言語開発が被さる例も少なくありません。これらを漏らさず修正し、商品として出荷するためには、デバッグ作業もさることながら、バグの発見日や発見者、再現方法、修正担当者、修正履歴など、バグにまつわる多くの情報を一元管理する必要があります。
これまではデバッグシートの束をファイリングしたり、エクセルで管理するなどの例が一般的でしたが、こうした手法では追いつかず、より専門的なシステムが求められるようになりました。そのため商用システムからフリーソフトにいたるまで、数多くのBTSがリリースされていますが、これらは一般のITソフト向けに作られている場合が多く、ゲーム開発シーンでは必ずしも使い勝手が良くないことがあります。
スタジオソリューションズの伊藤正氏がGame Tools & Middleware Forumで行った講演も、自社開発のBTS「TestingStudio」のプレゼンや導入事例の紹介に留まらず、こうしたゲーム開発シーンの特殊性を、いみじくも物語るものでした。
「TestingStudio」は2005年に同社が設立されて以来、継続して開発が続いている主力商品です。「カスタマイズ性の高さ」「バグに関するすべての情報を保持」「最小のメンテナンス時間」をコンセプトに、多くのユーザー（つまりゲーム開発者／企業）からの要望を取り入れつつ、ゲーム開発に特化したBTSとして進化を続けてきました。これまでに『ブルードラゴン プラス』（AQインタラクティブ）や、カプコンでの導入事例などがあります。
「TestingStudio」の特徴として▽エクセルのインポート・エキスポート機能があり、過去のバグレポート資産が引き継げる▽開発現場に応じて徹底的にカスタマイズして使える▽ウェブサーバ上で動作し、ブラウザ経由でアクセスするウェブアプリでありながら、一部の作業をPCクライアント上でも行う分散システムになっている▽レンタル形式なので固定費ではなく、プロジェクト内の予算に計上でき、導入がしやすい、などがあげられます。両社での導入の決め手となったのも、こうした特徴からでした。
 |  |  |
実際に運用してみての感想では、AQインタラクティブから「使い勝手が良かった」「コスト見積もりがしやすかった」「発注元・開発・テストが別会社という、分散開発スタイルに適していた」などのコメントが紹介されました。
このほか伊藤氏から、これまで「TestingStudio」の改良を続けてきた中で寄せられた、さまざまなユーザーの声が紹介されました。▽開発チームに他のプロジェクトの存在を知らせたくない▽プロジェクト単位でチーム内のユーザー権限を適時変更したい▽大まかに情報を知りたい▽社内で使っている用語やスタイルはできるだけ変更したくない▽外部の企業に同じBTSを利用させたくない▽コストはかけたくない▽特定のサーバに処理を集中させたくない▽過去の資産を利用したい、などです。
中でも伊藤氏は、求められる情報の内容が、マネージャやプロジェクトリーダー、プログラマーなど、役職や権限によってマチマチだった点が大変だったと語りました。そのため▽総バグ数と修正済みの比率を棒グラフのみで表示▽報告書作成用に細かい数値を表示▽折れ線グラフでバグ推移を表示▽バグの取り扱いのワークフローを表示、などさまざまな「見せ方」が追加されていったとのことです。
 |  |  |
最後に伊藤氏は「データは保管するだけでなく、分析が必要だ」と語り、バグレポートを「失敗の記録」として、新規タイトル開発に生かしていくことの重要性に触れました。あるゲームのバグ履歴をデータベース化し、分析することで、そのジャンルに固有の落とし穴や、バグの傾向などを事前に確認するなどが考えられます。
これらは、これまで開発者個人の暗黙知として蓄積されていましたが、開発が大規模化したり、ゲームエンジンやミドルウェアの共有などで長期化していくにつれて、システムとして蓄積して、誰もが再利用可能にできることが求められます。オンラインゲームなどでは開発に終わりがなく、データは増加する一方で、開発者が入れ替わっていくことも予想されます。こうした姿勢が今後の開発には重要だと述べ、講演を締めくくりました。
