【GTMF2011】ゲームの品質管理に力を発揮するCoverity

現世代機になって爆発的に増加したコード量と、それに比例して増える膨大なバグにどう立ち向かうか・・・。こうした中で注目を集めているソリューションが、静的コード解析ツールです。プログラムを実行することなく、ソースコードのみで機械的にバグを発見できるとあって、採用する企業が増加しています。

GTMF東京2011で事例紹介が行われた『Coverity』も、そうした静的コード解析ツールの一つ。業界トップクラスの解析率をはじめ、複数のプロジェクトで共通する不具合の識別、制御パスすべてのシミュレートなど、多彩な機能を備えています。

会場では同社ビジネスデベロップメントマネージャの安竹由起夫氏が『Coverity』の概要を紹介。その後フロム・ソフトウェア技術部の恵良和隆氏が、実際に『Coverity』を使用しての感想や、TIPSなどについて講演しました。

はじめに安竹氏はコードの不具合クイズを行い、『Coverity』で解析した場合の出力例を紹介しました。写真でもわかるとおり、単に不具合がわかるだけでなく、内容や優先順位などが日本語でわかりやすく出力される点が『Coverity』の特徴です。恵良氏もこの出力のわかりやすさが、導入の大きな決め手になったと語ります。

このように、実際にゲームをプレイすることなく、ソースコードをチェックするだけで、自動的にバグレポートが作成される点が静的解析の魅力です。中でも『Coverity』は、とても人力では追い切れない、全パスでのコードシミュレーションを行い、高い精度で認識できる点が『Coverity』の特徴だとアピールしました。

また、開発中のソースコードを定期的にチェックしていき、結果をサーバ上に蓄積するだけでなく、不具合が修正されたか否かまで、管理する機能も備えています。複数のプロジェクトでコードを流用している場合、両者にまたがる不具合を特定し、対応の優先順位を付けて表示することも可能です。

一方、コード解析にはそれなりの時間がかかるのも事実。安竹氏は「ソースコードの量や、解析用PCのマシンパワーに左右される」としながらも、大まかにソースコードをビルドする時に必要な時間の約6倍という目安を示しました。これが多いか少ないかは、プロジェクトの量によるでしょう。

■実際に使ってわかった『Coverity』の運用方法

続いてフロム・ソフトウェアの恵良氏が、実際に『Coverity』を使っている中での感想を紹介しました。同社では今まさに新規タイトルでの開発に『Coverity』を使用している最中で、採用して半年ほどになるとのことです。

『Coverity』導入の直接の決め手になったのは、会社の「プログラマ増員指令」だった・・・。恵良氏はそう述懐します。単純に人員を増やすことはできても、その力量はさまざま。コードの品質を落とすことなく、人材を増やすためには、『Coverity』のようなツールの下支えが必要だった、というわけです。

ところが最初の難関となったのが、まさに解析時間との戦いでした。どうせなら毎日コードを解析したいと考えましたが、PS3やXbox360のタイトルでは、コード数が膨大すぎて、放っておくと24時間では解析が終わらなかったのです。そこで解析用のPC環境を整備したり、コンパイラ、SDKなどの検証を行うなどして、時間の短縮がめざされました。

ちなみに同社のプロジェクトでは、11時間から23時間まで、タイトルや機種で大きな差が出ました。また同じタイトルでも、PS3よりXbox360の方が、解析に時間がかかる傾向にあるといいます。これに対して同社では解析専用のPCを4台用意し、各PC上で2〜4つのプロジェクトを同時解析することで対応。I/O負荷の低下のために、テンポラリファイルをSDD上におくなどの工夫も行われました。PCのスペックは下記のとおりです。

・CPU：Intel Core i7-2600(3.4GHz)
・RAM:8GB
・ストレージ：システム用HDD 1TB/テンポラリ用SSD 80GB
・OS:Windows XP(64bit)

続いての課題が、あまりに膨大に出力される不具合でした。現世代機向けのタイトルはソースコードの総量が200万行にも及び、1000行に1つの不具合率としても、2000件以上のバグレポートが出力されることになります。バグの内容はさまざまで、対応を判断するのは人間の役割。このような場合、往々にしてメインプログラマー級のスタッフが作業の割り振り役に投入され、人力の無駄遣いになりがちです。

そこで同社では「ソースコードの最終編集者に、デバッグを自動アサインする」という、なかば強引なルール決めが確立されました。もっとも、担当者ベースで作業内容を交代するなどはOK。こうすることで、少なくとも「誰もバグレポートを見ていない」という事態だけは避けるようにしたのです。

前述の通り、まだ使い始めて半年足らずにすぎず、「感触しか伝えられない」と恵良氏は語ります。その上で『Coverity』の長所として、「おそらくマスターアップ前の披露がピークに達している時に、最も威力を発揮するのではないか」と手応えを語りました。人間は疲れがたまると、致命的な凡ミスをしやすくなります。そこを『Coverity』がフォローしてくれると嬉しい、というわけです。

一方で微妙な点としては、解析に失敗した時の原因が良くわからないことが多く、サポートとのやりとりが頻繁に発生する点があげられました。前述の通り解析に時間がかかる点も悩みの一つです。もっとも、この点については「将来的にネットワーク上で分散解析」などのアップデートも予定されているようです。

このほか解析に成功しているか否か、結果をキチンと確認することや、Hudsonなどのツールを使って、定時にビルドする環境を構築すること。SDKのアップデート時にはコード解析に問題が出やすいので注意、などのTIPSが語られました。『Coverity』を単に導入するだけでなく、適切に運用することが肝心というわけです。恵良氏は専任の担当者をつけることを推奨するとしています。

今後は担当者の自動アサインをより高精度にしたい・・・恵良氏はそう語ります。コードの修正履歴をたどって、本当に不具合箇所修正した人に自動アサインするなどのシステムを作るというわけです。『Coverity』にはSOAP APIやCUIツールがあり、利用者側でこうした環境を構築することが可能です。

また検出された不具合の傾向から、コーディング時の悪癖がわかるため、新人教育などにも有効との所見が示されました。何か不具合が発生したら、必ず本人に修正させるシステムを作ることで、問題の少ないコードを書く癖がつくことも期待されます。一方、他人の書いたコードのチェックを行い、適切に指導する上でも『Coverity』は有効でしょう。こうした効果についても、今後継続的にチェックしていきたいと抱負が述べられました。

【GTMF2011】ゲームの品質管理に力を発揮するCoverity

関連ニュース

特集

コベリティ

品質管理

QA／品質保証

GTMF2011

GTMF