1. ゲーム開発
プロセスカイゼン
1

2. 略歴
システム系プログラマ７年
ゲームプログラマ７年
ゲームは殆どがiアプリ or スマフォアプリ
サーバ：クライアント＝７：３
サーバは主にJava（Tomcat）
クライアントは主にJava（iアプリ）、C#（Unity）
2

3. 今日のお話
ゲーム開発を行う上で、細かい所でカイ
ゼンしてきた事例のご紹介
全体的な開発プロセス（アジャイルとか
プロトタイプ等）の話ではありません
3

4. 開発プロセスカイゼン例
4

5. 作業の独立化
プランナーが、データ作成 => 確認の間
にプログラマの作業が必要だと・・・
PLデータ作る => PGデータ更新 => PL
データ変更する => PGデータ更新す
る => PLデータ変更する => PGデー
タ更新する…
5

6. 作業の独立化
プログラマ・プランナー・デザイナーは、各々独立
して作業が完結する仕組みを作ること。
プランナーのデータ作成 => 動作確認
デザイナーのデザインデータ作成 => 実機での表示
確認
バッチファイルやJenkinsのジョブなど、非技術者で
も実行できる仕組みを作る
6

7. ドキュメントより
スクリプト
プログラム更新、マスターデータ更新、DBマイグ
レーション、etc…。各々の手順がスクリプト化さ
れず、ドキュメント化されていると・・・
毎回手順を確認する作業が発生
開発者ごとに実行するバッチファイルの場所が
変わったりする
更新作業のための拘束時間が技術者に発生
7

8. 手順書よりスクリプト
手順は極力スクリプトで自動化させること
自分のPCの更新、及び共有で使用するサーバの
更新のどちらも自動化すること（バッチファイ
ル一発 or Jenkinsのジョブ化）
GUIツールを起動してメニューから実行させる
（Visual Studioのビルド等）ものは、コマンド
ラインから実行できないか必ず調べる
8

9. 動作確認は１ステップ
コーディング => 動作確認は、PGが最
も多く繰り返し行う作業。ここの手順
は最大限に簡略化するべし！
理想はショートカット一発、あるいは
ボタンクリック一発。
9

10. ビルド失敗の検知
svnを更新してビルドしたらエラー
が・・・
間違ったソースコードをコミットした場
合、コンパイルエラー・ビルド失敗を自
動で検知する仕組みがあると楽
Jenkinsで監視、チェックする
10

11. リモートデバッグ機能
サーバがうまく動作していない・・・デ
バッグログ出して解析だ！ => 古い
起動したサーバプログラムに手元の開発
環境からアタッチし、breakpointを張っ
てステップ実行してデバッグ出来る環境
を作る。（多分イマドキのサーバはほぼ
出来るようになっている）
11

12. サーバの仮想マシン化
開発環境(eclipse, プラグイン)インストー
ル、サーバ実行環境(Tomcat)構築、DB
サーバ(MySQL)構築、ユーザ・DB作
成、svnチェックアウト、etc… サーバ
の環境構築はものすごく大変
そして大抵バージョン違いでハマる
12

13. サーバの仮想マシン化
まるごとVMwareなどの仮想マシン化し
て、プログラマに仮想マシンイメージを
配布！
理想としては、新しく参加したPGが、
参入したその日に環境が整い、実行・
コーディングが開始出来るようにする。
13

14. 共有マシンで発生した
エラーの検知
共有マシンで発生したエラーは、デバッ
ガに言われる前に検出したい。
基本はlog4j/loggerによるメール通知。
14

15. サーバ・クライアント
単体での動作確認環境
サーバのみ・あるいはクライアントのみで
動作確認できるようにするべし。
ユニットテスト環境など
ログイン、ミッション受託など一連の流れ
をマクロ化しておけば、実装中の機能の即
時確認や負荷テストなどにも利用できる。
15

16. まとめ

17. 技術力と開発プロセス
基本は「明日楽をするために今日苦労
する」。繰り返し実行する作業を簡易
化する。
プロジェクトを成功に導くには、高い
技術力と洗練された開発プロセスが必
要だが、体感的には重要度は３：７
17

18. 技術力と開発プロセス
多くの技術者は、技術力の向上に多くの
力を使うが、開発プロセスの洗練をお
ろそかにする傾向がある
開発プロセスが成熟出来ているプロジェ
クトは、開発から保守運用、引き継ぎ
（運営移管）までスムーズに進む。
18

19. ご清聴、ありがとうご
ざいました
19