「龍が如く」の高速デバッグ術～そびえ立つバグの山を踏破するための弾丸ワークフロー～
株式会社セガゲームス
第一CS研究開発部
アドバンスト・テクノロジー開発チーム
阪上 直樹

JaSST’16 Tokyo自己紹介• 関わったゲームシリーズ• 「プロサッカークラブをつくろう！」• 「プロ野球チームをつくろう！」• 「龍が如く」• ゲームプログラマから自動化や効率化の仕事に移行• QAプログラマ？
• QAエンジニア？
• ビルド職人？
• アドバンスト・テクノロジー開発チーム• 龍が如くエンジンのベース部分や各種ライブラリ・ツール等の開発
JaSST’16 Tokyo本セッションについて• KYUSHU CEDEC 2015 での同名セッション• 概要• http://kyushucedec.jp/session.html#06• 発表資料• https://cedil.cesa.or.jp/cedil_sessions/view/1398

今回は完全版です！
JaSST’16 Tokyo本セッションのゲームタイトル
龍が如く 維新！
PS3/PS4
PS Vita（無料アプリ）

2014年2月22日発売

龍が如く０ 誓いの場所
PS3/PS4
PS Vita（無料アプリ）

2015年3月12日発売

龍が如く 極PS3/PS42016年1月21日発売

複数プラットホーム×毎年リリース
JaSST’16 Tokyo

「龍が如く」を短いスパンでリリースするための秘密は？

JaSST’16 Tokyo

ないです。がんばってるだけです。
でも…

JaSST’16 Tokyoがんばる場所を限定• ゲームの面白さ• クオリティ• ユーザーに感動体験を与えるための仕掛け

他にもやることはたくさんあるよ！
理想論じゃないの？！
JaSST’16 Tokyoがんばらないために、がんばる• 自動化できるものは、ためらわず自動化• 作業の効率化を徹底して追求• ワークフローの見直し

誰でもできる作業をクリエイターにさせない

本セッションのテーマ
JaSST’16 Tokyo本セッションの用語定義• デバッグ• バグを修正する• テストプレイを含まない狭義の意味• テストプレイ• プレイチェック• バグ報告• ゲームバランス(難易度/面白さ)の指摘• 赤字の用語• 龍が如くチーム用語

JaSST’16 Tokyo本セッションの概要• 前半• 高速デバッグ術• 自動化• Jenkins• 後半• そびえ立つバグの山を踏破するための弾丸ワークフロー• バグ管理• Redmine

JaSST’16 Tokyo高速デバッグ術• 自動化• Jenkinsを使用• パイプライン

絵や音楽の中間データ

ソースコード中間データサーバ(TiVersion)

Subversionサーバ

コンバート

ビルドチェック• ビルド

データのコンバート

コンパイル・リンクエラー• コンバート

ゲーム上で動作確認

コンパイラの警告

最終データサーバ(TiVersion)

静的コード解析• エラー検出• ビルドエラー検出• 静的コード解析• 例外検出• テスト

Exe更新(Nightly Build)
最終成果物サーバ(TiVersion)

ランタイムエラー（例外・Assert）
オートテスト
人力によるテストプレイ
JaSST’16 Tokyo

Jenkinsによる自動化• Jenkinsとは• CI(Continuous Integration:継続的インテグレーション)ツールの一つ• 日々の開発に必要なビルドやコンバートを自動化し、安定した開発環境を継続していくためのもの• なぜ必要？
• ゲームの動作が安定していない状態では、実装したものをすぐに確認できないので作業が滞る• ビルドが壊れた状態で放置すると、修正コストが増大し、他のバグを生む原因にもなる

JaSST’16 Tokyoパイプラインの自動化• ビルド• コンバート

JaSST’16 Tokyoビルドの自動化 (1/2)• ビルドとは• プログラムをコンパイル・リンクして実行可能な形式に変換すること• 自動で毎日ビルドした成果物は、Nightly Buildと呼ばれる• Exe更新とは• Nightly Buildの龍が如くチーム特有の呼称• PS3/PS4/PS Vitaに加えて、それぞれのターゲットに対応したデバッグ用のWindows版の実行ファイルを定期的に生成• Windows版もあることから、「Exe更新」と呼んでいる

JaSST’16 Tokyoビルドの自動化 (2/2)
プログラマ
PG

ソースコードコミット

Subversionサーバ

プログラムを書く
自動化

Exe更新(Nightly Build)
TiVersionとは• 龍が如くチーム独自のバージョン管理システム• ファイルサイズの大きなものを高速でやり取り可能Subversionとは• バージョン管理システム• 上書きによる先祖がえりを防ぐため• サーバにアップロードすることをコミットと呼ぶ

プロジェクト全員が最新コードの動作を確認可能

コミット

最終成果物サーバ(TiVersion)

JaSST’16 Tokyoバイナリ管理を分けている理由
テキスト

バイナリ

数
KB

10MB～100MB（1GBを超えも！）ソース(*.cpp)

音楽(BGM/効果音)

ムービー

絵（3Dキャラ/背景/UI）

マージできなくていい！とにかく高速にやりとりしたい！
JaSST’16 Tokyoパイプラインの自動化• ビルド• コンバート

JaSST’16 Tokyoコンバートの自動化
デザイナー

背景モデルの中間データ

D

コミット
中間データサーバ(TiVersion)

背景モデルコンバート
背景モデルを作る

データのコンバート

自動化

なぜ中間データを一括でコンバートするのか？
• 各ターゲットに最適化• 圧縮やパック• 中間データをテキスト形式にすることで差分を取りやすく

ゲーム上で動作確認

メールでエラーを通知

コミット
最終データサーバ(TiVersion)

プロジェクト全員が最新の背景モデルを確認可能

自動化

Exe更新
(Nightly Build)
コミット

最終成果物サーバ(TiVersion)

JaSST’16 Tokyo

ゲーム上で動作確認• 実際にゲームを起動して、データが正しく読み込まれ、動作しているかを確認する簡易なテスト
1. ゲームをテストモードで起動
2. 背景データを読み込み
3. 背景データだけを描画
4. エラーが出ないことを確認し、終了して成功コードを返す

JaSST’16 Tokyoパイプライン（ビルド・コンバート）の自動化
D

デザイナー

絵や音楽の中間データ

ソースコード中間データサーバ(TiVersion)

Subversionサーバ

コンバート

ビルドチェック

データのコンバート

コンパイル・リンクエラー

ゲーム上で動作確認

コンパイラの警告

最終データサーバ(TiVersion)

静的コード解析

P
G

プログラマ

Exe更新(Nightly Build)

自動化
最終成果物サーバ(TiVersion)

ランタイムエラー（例外・Assert）

オートテスト
人力によるテストプレイ
JaSST’16 Tokyo

エラー検出の自動化• エラーの種類• ビルドエラー• 静的コード解析の指摘• ランタイムエラー• テストのエラー• なぜ必要？
• エラーを見つけて報告するのもコスト• 自動で不具合を見つけてくれるものは、どんどん使う• 手動だと欠落しやすいデバッグに必要なデータ（ダンプやログ、スクリーンショット等）を自動収集

JaSST’16 Tokyo

エラー検出の自動化• ビルドエラー• 静的コード解析の指摘• ランタイムエラー• テストのエラー

JaSST’16 Tokyoビルドエラー検出の自動化 (1/4)
自動化

自動化

Debug

Debug

PS3

Release(デバッグ機能有)≒Windows(32bit/720p)

Release(デバッグ機能無)Release(デバッグ機能無)
自動化

自動化

Debug

Debug

PS4

Release(デバッグ機能有)Windows≒ (64bit/1080p)

PS Vita

Release(デバッグ機能有)Release(デバッグ機能無)Release(デバッグ機能無)自動化

Release(デバッグ機能有)

自動化

Debug
Release(デバッグ機能有)DebugWindows≒ (32bit/960x544)

Release(デバッグ機能無)Release(デバッグ機能有)Release(デバッグ機能無)

手動で確認するのは大変！
JaSST’16 Tokyoビルドエラー検出の自動化 (2/4)• Exe更新とは別にSubversionサーバを監視して、コ

ミットごとにビルドが壊れていないかチェックを行う• ビルドが壊れていたら、Jenkinsからメーリングリストにメールを自動送信• ビルドエラーが出たら即時直すルール• ビルドエラーは出さないことが望ましいが、 ビルド構成が多く、各自がすべてを確認してコミットするのは無駄が多い
ため• ビルドは分散ビルドを使用• PCの台数を増やして高速化

JaSST’16 Tokyoビルドエラー検出の自動化 (3/4)
警告はエラーです• コンパイラの警告は、エラー扱い• ビルドエラーになるので、即時修正が必要• コンパイラの警告レベルは最高に設定• 例外的に使いたいものは、設定で除外するか#pragmaで局
所的に対応• まずは警告をゼロにするところから

JaSST’16 Tokyoビルドエラー検出の自動化 (4/4)• ビルドが壊れた状態を短縮するためには• 声かけが一番効果的• チェック結果を分かりやすく表示する• ビルドチェック待ちページ

このリストから
自分の名前が消えたら帰宅可能

unused variable
警告はエラー扱い
JaSST’16 Tokyo

エラー検出の自動化• ビルドエラー• 静的コード解析の指摘• ランタイムエラー• テストのエラー

JaSST’16 Tokyo

静的コード解析の自動化• 静的コード解析とは？
• プログラムを実行せずにソースコードを解析し、不具合やその可能性となるものを検出するツール• なぜ必要？
• すべてのコードを人力でレビューするのは大変• 不具合の芽を先に摘んでおく• 静的コード解析ツール• 使用ツール• Coverity（精度が高い/有償）• Visual Studioのコード分析（Visual Studioの標準機能）• Cppcheck（オープンソース）• 使用ツールは、管理できるなら多ければ多いほどいい• Jenkinsを使って毎日自動的に解析して、結果をメールやチケット

でフィードバックJaSST’16 Tokyo

エラー検出の自動化• ビルドエラー• 静的コード解析の指摘• ランタイムエラー• テストのエラー

JaSST’16 Tokyoランタイムエラー報告の自動化• エラー送信（クラッシュレポート機能の龍が如くチーム用語）
ゲームやツール
実行中に例外発生！

ネットワークドライブ

•

メール送信

デバッグに必要な情報を自動収集
• ダンプ
• ログ
• コールスタック• スクリーンショット … etc

•
•
•
•

ダンプ表示batのURL
ログ表示batのURL
コールスタック
リビジョン
ターゲット

バグ管理システム(Redmine)
JaSST’16 Tokyo

エラー送信の実装例 (Windowsの場合)• C++• 未処理例外のキャッチ• SetUnhandledExceptionFilter• コールスタック• StackWalk• C#• 未処理例外のキャッチ• System.Windows.Forms.Application.ThreadException• AppDomain.CurrentDomain.UnhandledException• System.Threading.Tasks.TaskScheduler.UnobservedTaskException• コールスタック• Environment.StackTrace• ダンプ出力• MiniDumpWriteDump• C#ではアンマネージド・コード呼び出し• ダンプを開くときは、ダンプファイル(.dmp)以外に、exeファイルと対応するpdbファ

イルが必要

JaSST’16 Tokyoダンプを開いた例(C#)

JaSST’16 Tokyo

エラー検出の自動化• ビルドエラー• 静的コード解析の指摘• ランタイムエラー• テストのエラー

JaSST’16 Tokyo

テストの自動化 (1/4)• モンキーテストとは• ランダムに擬似パッド入力を行うテスト手法• オートテスト（モンキーテストの龍が如くチーム用語）
夜間の開発用PC(100～200台)

各PCの設定を一括管理• 開始シナリオ• ターゲット• 使用デバッグ機能

最新のゲームを起動してモンキーテストを行う
PC

PC

PC

PS4

PS3

VITA

明朝出社
• バグ報告• 目視でのチェック

JaSST’16 Tokyo

テストの自動化 (2/4)• Excelファイルに設定を記述

PC名

条件

開始シナリオJaSST’16 Tokyo

テストの自動化 (3/4)• 各PCでオートテストを実行
オートテストクライアントを実行

設定ファイルからiniを生成TiVersionから最新のexe更新を取得

最終成果物サーバ(TiVersion)

ゲームを自動起動(iniファイルのシナリオ/条件)
JaSST’16 Tokyo

テストの自動化 (4/4)• テストで検出されたバグを見逃さない• エラー送信• ログ出力• 動画撮影• 人力で出せないバグの検出• 1/60秒単位の特定のパッド入力で発生• 長時間同じ動作を繰り返すことで発生• 人力で出せないバグを見つける必要があるのか？
• 数十人では出ないバグも、数十万人がプレイすると出てしまう可能性がある• 人力のチェックはリソースに限りがあるため、バグを自動で検出する仕組みは、大規模ゲーム開発には欠かせない
JaSST’16 Tokyo高速デバッグ術（自動化）のまとめ
絵や音楽の中間データ

ソースコード中間データサーバ(TiVersion)

Subversionサーバ

各コンバートビルドチェック

メール

データのコンバート

コンパイル・リンクエラー

メール

エラー送信
メール

ゲーム上で動作確認

コンパイラの警告

メール

自動化！

最終データサーバ(TiVersion)

静的コード解析

メール、チケット化

Exe更新(Nightly Build)

メール

最終成果物サーバ(TiVersion)

成果物を確認ランタイムエラー（例外・Assert）

エラー送信

オートテスト

エラー送信

人力によるテストプレイ

バグ報告
JaSST’16 Tokyo

そびえ立つバグの山を踏破するための弾丸ワークフロー• バグ管理• Redmineを使用• バグ報告の掟• バグ管理システムの導入の歴史• バグ管理システムの問題と解決

JaSST’16 Tokyo

バグ報告の掟
なんかおかしいんだけど・・・

PG

ふーん（ｶﾀｶﾀｶﾀ…）

JaSST’16 Tokyo

バグ報告の掟（破り）
なんとかしてプログラマにバグの現場を見せる！

ちょっと
見て見て！
うう・・・

JaSST’16 Tokyo

バグ管理システムの必要性• 口頭でのやり取りは、数人程度が限界• バグ管理システムが必要な場合• 数百人規模のプロジェクト• それぞれが別の場所で作業している

JaSST’16 Tokyo

バグ管理システムの導入の歴史• 口頭だけ• 紙で管理• Excelで管理• オリジナルツールで管理• Mantisで管理• Redmineで管理（現在）

JaSST’16 Tokyo

バグ管理システムの導入の歴史• 口頭だけ• 紙で管理• Excelで管理• オリジナルツールで管理• Mantisで管理• Redmineで管理（現在）

JaSST’16 Tokyo

紙でバグ管理 (1/2)
バグ１つに紙１枚（チケット）
違うバグを１枚にまとめない！

報告者

発生日時

阪上直樹

バグ報告

バグ箱

2016/3/8
14:00

担当者に
振分

ラスボスのやられ演出中のモーションブラーでフリーズし
ました。

PG
修正

修正NG

済
JaSST’16 Tokyo

紙でバグ管理 (2/2)• メリット• バグの見える化• 各自の記憶に頼らない• 誰が何個バグを抱えているのか• アナログならでは• バグの報告者・担当者間のコミュニケーションがスムーズ• 少人数では一番高速• デメリット• かかわる人数が増えると、チケットの管理が煩雑• チケット全体を管理できない• 総数が分からない• バグの傾向が分からない• 各バグのステータス（対応状況）が分からない• どのバグから手をつけていいのか分からない

JaSST’16 Tokyo

バグ管理システムの導入の歴史• 口頭だけ• 紙で管理• Excelで管理• オリジナルツールで管理• Mantisで管理• Redmineで管理（現在）

JaSST’16 Tokyo

Excelでバグ管理※Office 365がなかったころの話• メリット• 情報のデジタル化• 共有設定にして、１ファイルですべてのバグを管理• デメリット• 誰が編集したのか分からない• 共有設定にすると、ファイルがたびたび壊れる• 部外とのやり取りが煩雑• マージ作業が発生してしまう• 情報が漏洩しやすい• バグのステータスが分からない
JaSST’16 Tokyo

バグ管理システムの導入の歴史• 口頭だけ• 紙で管理• Excelで管理• オリジナルツールで管理• Mantisで管理• Redmineで管理（現在）

JaSST’16 Tokyoオリジナルツールでバグ管理• メリット• サーバで一元管理• ツールの開発者が社内にいるので、要望を追加しやすい• デメリット• ツールの属人化• 開発者がいなくなったらメンテナンスできない• ツールの学習コスト• 社内システムなので、ツールに慣れてもらう時間が必要

JaSST’16 Tokyo

バグ管理システムの導入の歴史• 口頭だけ• 紙で管理• Excelで管理• オリジナルツールで管理• Mantisで管理• Redmineで管理（現在）

JaSST’16 Tokyo

Mantisでバグ管理(1/2)• Mantisとは• バグ管理システム(BTS)• Webブラウザでアクセス• オープンソース

JaSST’16 Tokyo

Mantisでバグ管理(2/2)• メリット• サーバによる一元管理• スクリーンショットやログファイルを添付できる• コメント入力やステータス、優先度を設定できる• 有名なツールなので、学習コストを削減できる• デメリット• バグ以外の管理には不向き（タスクなど）

JaSST’16 Tokyo

バグ管理システムの導入の歴史• 口頭だけ• 紙で管理• Excelで管理• オリジナルツールで管理• Mantisで管理• Redmineで管理（現在）

JaSST’16 Tokyo

Redmineでバグ管理 (1/5)• Redmineとは• バグを含めた課題管理システム• Webブラウザでアクセス• オープンソース

JaSST’16 Tokyo

Redmineでバグ管理 (2/5)• タスクも管理するためにMantisからRedmineに移行• あれがない、これがない、使いにくいと言われる• 代替手順を提示して、なんとかツールに慣れてもらう• どうしても必要と思われる機能は、プラグインとして実装• リマインダー送信
見た目もそのまま
Redmineに移植
Mantisのリマインダー送信

JaSST’16 Tokyo

Redmineでバグ管理 (3/5)• メリット• サーバによる一元管理• スクリーンショットやログファイルを添付できる• コメント入力やステータス、優先度を設定できる• 有名なツールなので、学習コストを削減できる• APIやプラグイン等の拡張機能が豊富で、開発も活発• タスクも管理できる• デメリット• 自由度の高いツールなので、運用ルール作りが必要• プラグインを多用すると、保守・メンテナンスコストが高くなる

JaSST’16 Tokyo

Redmineでバグ管理 (4/5)
バグのステータスの一例
新規

バグ報告

担当者に
振分
確認待ち

PG

修正

修正NG
差し戻し

確認済み

ワークフローは紙と同じ！
JaSST’16 Tokyo

Redmineでバグ管理 (5/5)• なぜ「確認待ち」なのか？
• 「修正完了」ではない？
• バグ修正を実装した時点で、チケットは終わっていない！
• 修正を確認して、はじめてチケットは完了する。

• ステータス名は、見ただけで次に何をしなければならないか

がすぐ分かるのがよい

JaSST’16 Tokyoツールを使えば、すべて解決？
もちろん、そんなことは無いです。

• バグ管理システムの問題点• Excel使いたいよ・・・の声• バグ報告の問題点• バグのワークフローの問題点• 各ツールにプロジェクトの情報が分散
JaSST’16 Tokyo

バグ管理システムの問題と解決• Excel使いたいよ・・・の声• バグ報告の問題点• バグのワークフローの問題点• 各ツールにプロジェクトの情報が分散

JaSST’16 Tokyo

Excel使いたいよ・・・の声 (1/2)• RedmineにExcelのインポート＆エクスポートを追加• 数百個のタスクを一括で登録したい• redmine_importプラグインを導入• Redmine 3.2で標準機能に追加• Excelで見たい人にチケット一覧をxlsファイルに変換• redmine_xls_exportプラグインを導入

JaSST’16 Tokyo

Excel使いたいよ・・・の声 (2/2)• インポート用のテンプレートを作成• Redmine REST API経由でトラッカー別に自動生成• Jenkinsで定期的に更新• カテゴリやメンバーの追加に対応するため

JaSST’16 Tokyo

バグ管理システムの問題と解決• Excel使いたいよ・・・の声• バグ報告の問題点• バグのワークフローの問題点• 各ツールにプロジェクトの情報が分散

JaSST’16 Tokyo

バグ報告の問題点• 必要な情報を入力するのは結構大変• テストプレイがメインの仕事でない時に、バグ報告を怠りがちになる• ログの添付を忘れやすい• 手動だと、必要な情報を入力・添付し忘れる• 入力ミスも発生する• リビジョン番号が違う• ターゲットの選択を間違える

JaSST’16 Tokyo

バグ報告に必要な情報
基本情報

添付ファイル

原因
結果
再現率
重要度
カテゴリ
報告者
ターゲット
(Win/PS3/PS4/VITA)• 言語(日本語/中国語)• リビジョン

• ダンプファイル• デバッグログ• 使ったデバッグ機能（設定ファイル等）• スクリーンショット• セーブデータ

•
•
•
•
•
•
•

龍が如く独自• プレイヤーキャラ(桐生/真島/秋山…)• ステージ(神室町/蒼天堀…)• プレイヤーの座標• シナリオ進行度• 時間帯(昼/夜)• 天候(晴/雨/雪)

自動入力できる！

JaSST’16 Tokyo

バグ報告の自動化• どこでもバグ報告とは• Redmine REST APIを使用して、専用アプリ経由でゲーム

アプリから直接Redmineにチケット登録• 全ターゲット(Win/PS3/PS4/PS Vitaに対応)• エラー送信からも直接バグ報告が可能• デバッグ機能がないと使えない
JaSST’16 Tokyoどこでもバグ報告 (1/3)

デバッグメニューからどこでもバグ報告をクリック！
JaSST’16 Tokyoどこでもバグ報告 (2/3)

自動入力

自動撮影＆自動添付

JaSST’16 Tokyoどこでもバグ報告 (3/3)

自動入力

自動添付

JaSST’16 Tokyo

バグ報告自動化による効果
どこでもバグ報告
使用件数

龍が如く 維新！
龍が如く０ 誓いの場所
龍が如く 極9,338件
6,307件
1,925件バグの総数

17,448件
12,955件
4,799件

３タイトル(9,338件+6,307件+1,925件) X 10分(短縮時間/件)= 約3,000時間を削減
バグ報告の質が均一化して、精度も向上

テストプレイヤーは、バグ探しに専念！
クリエイターは、バグの修正・バランス調整・クオリティの向上に専念！
JaSST’16 Tokyo

バグ管理システムの問題と解決• Excel使いたいよ・・・の声• バグ報告の問題点• バグのワークフローの問題点• 各ツールにプロジェクトの情報が分散

JaSST’16 Tokyoバグのワークフローの問題点• 修正したものがいつ反映されたか分からない• バグチケットに対して、どういう修正が入ったのか分

かりにくい

Redmineと各システム・ツールを連携してワークフローを自動化
JaSST’16 Tokyo

Redmineとパイプラインの連携 (1/4)
デザイナー

背景モデルの中間データ

D

コミット
中間データサーバ(TiVersion)

Redmine新規確認待ち

背景モデルコンバート
背景モデルを修正
８時間ごと

データのコンバート
ゲーム上で動作確認
コミット
最終データサーバ(TiVersion)

1日3～4回

Exe更新(Nightly Build)

修正したものはいつ反映？
明日くらいかなぁ・・・
修正確認が迅速にできないよ！
報

コミット

最終成果物サーバ(TiVersion)

バグ報告者

JaSST’16 Tokyo

Redmineとパイプラインの連携 (3/4)
デザイナー

背景モデルの中間データ

D

コミット
中間データサーバ(TiVersion)

Redmine新規
コンバート待ち背景モデルコンバート
背景モデルを修正
８時間ごと
バグ報告者
報

データのコンバート
ゲーム上で動作確認
コミット
最終データサーバ(TiVersion)♪
♪
1日3～4回「確認待ち」はすぐ確認が可能！

Exe更新待ち

Exe更新(Nightly Build)
コミット

最終成果物サーバ(TiVersion)

確認待ち
JaSST’16 Tokyo

Redmineとパイプラインの連携 (4/4)
コンバート予約とはコンバートの種類を選択して予約を作成「確認待ち」になったら確実に修正確認が可能
JaSST’16 Tokyo

RedmineとSubversionの連携 (1/2)• バグチケットに対して、どういう修正が入ったのか分

かりにくい→Subversionのコミットログにチケット番号を入力

バグチケットに対して、どういう変更が入ったのか
一目瞭然！
JaSST’16 Tokyo

RedmineとSubversionの連携 (2/2)
プログラマ
PG

ソースコードRedmine
新規

コミット

プログラムを修正

バグ報告者
報

♪
♪

1日3～4回「確認待ち」はすぐ確認が可能！

Subversionサーバ

Exe更新待ち

Exe更新(Nightly Build)
コミット

最終成果物サーバ(TiVersion)

確認待ち
JaSST’16 Tokyo

バグ管理システムの問題と解決• Excel使いたいよ・・・の声• バグ報告の問題点• バグのワークフローの問題点• 各ツールにプロジェクトの情報が分散

JaSST’16 Tokyo

各ツールにプロジェクトの情報が分散• 様々なツールを行き来して、作業が煩雑になる• バグとタスクの管理を分けると、チケット全体の優先順位が把握できなくなる

Redmineに情報を集約

JaSST’16 Tokyo

RedmineとCoverityの連携 (1/2)• メリット• バグやタスクと静的コード解析の不具合を一括管理• Redmineのワークフローに統一して作業を効率的に• 連携方法• RedmineとCoverityのそれぞれのAPIを使った同期ツール• セガゲームス開発技術部の粉川氏制作

JaSST’16 Tokyo

RedmineとCoverityの連携 (2/2)
Coverity(全自動)RedmineCoverityの解析
１日１回(Jenkins)
Coverity不具合
チケットを自動作成[新規]

新規の不具合検出
Coverityチケット生成

担当者を振り分け不具合の修正[確認待ち]

再解析(次の日)
NG

チケット終了[確認済]

OK

不具合の修正確認

JaSST’16 Tokyo

そびえ立つバグの山を踏破するための弾丸ワークフロー（バグ管理）のまとめ• Redmineを使ってバグを一元管理• バグ報告に必要な情報は自動入力• どこでもバグ報告• バグ管理システムと他のシステムの連携• ワークフローを自動化• コンバート予約• Subversionと連携• Redmineにプロジェクトの情報を集約

JaSST’16 Tokyo本セッションのまとめ• 大規模＆高速リリースの秘密は無い• 地道な自動化・効率化• 自動化• パイプラインの自動化• エラー検出の自動化• バグ報告の自動化• ワークフローの自動化• ためらわず、小さなことから、こつこつと• 効率化• 開発チームの規模や環境・風土に適したツールを導入• 情報を１つの場所(Redmine)に集約
JaSST’16 Tokyo

最後に私(QAプログラマ)がいないと龍が如くは毎年出せない！

JaSST’16 Tokyo参考資料• 「10ヵ月でHDゲームを開発する方法 ～龍が如くを支えたテクノロジ～」（CEDEC 2010）• 前半の高速デバッグ術の関連情報• TiVersion• エラー送信• オートテスト etc..

• 概要• http://cedec.cesa.or.jp/2010/program/PG/C10_P0064.html• 講演資料(CEDiL)• https://cedil.cesa.or.jp/cedil_sessions/view/324

JaSST’16 Tokyo