ツクールMVのチーム開発で役立つgitやグループウェアの使い方

> これは、RPGツクールMV Advent Calendar 2016 の16番目の記事です。
> http://www.adventar.org/calendars/1732
> 前：http://nico.ms/ar1144621
> 次：http://blog.livedoor.jp/gameofunder/archives/10569726.html

ほぼ１年ぶりの執筆ですどうも因幡です。

今年は丸１年ツクールMVの年だったような気がします。
去年11月のベータテスト当選からずっと作り続けていた短編RPG[『スナギツネと盗賊団』](http://www.whiterabbit-hutch.net/sfox/) が無事完成し、好評配信中です。
ブラウザで無料で遊べますので、ぜひどうぞ。
去年書いた記事（http://qiita.com/InabaByakko/items/a35ba0e3012d2b760e39 ）で作成したプラグインも使用しています。

[![スナギツネと盗賊団](http://www.whiterabbit-hutch.net/sfox/image/twicard.png)](http://www.whiterabbit-hutch.net/sfox/)

#MVプロジェクト共同開発のススメ

さて、本作はサークル内で共同開発していたわけですが、当然一人で開発するときには考える必要のなかった、チームメンバーとのコミュニケーションが必須となります。
企業などでチーム開発の経験が長い方は自然と意識することだとは思いますが、そのような経験が少ない方にとっては、どうすれば円滑に開発を進められるのか、迷われることも多いでしょう。
自分自身も（WILD DRIVE開発時も含めて）割りと試行錯誤でしたが、ある程度いい感じに回った手法をここで公開してみようかと思います。

※ 以下の情報は、gitの使い方にある程度慣れていらっしゃる方を対象にしています。

##チーム開発に使うもの
チームでツクールMVのゲームを開発するために、以下のツールやWebサービスを使いました。

### [RPGツクールMV本体](http://tkool.jp/mv/)
[![RPGツクールMV画面 引用元： http://tkool.jp/mv/guide/001_001.html#01 ](http://tkool.jp/mv/guide/img/001/001_001_04.png)](http://tkool.jp/mv/guide/001_001.html)

* おなじみPC版最新ツクール。


### [git for Windows](https://git-for-windows.github.io/) または [SourceTree](https://ja.atlassian.com/software/sourcetree)
[![SourceTree画面 引用元： https://blog.sourcetreeapp.com/2013/02/14/sourcetree-for-windows-beta-signup/ ](http://blog.sourcetreeapp.com/files/2013/02/st_win8_beta.png)](https://blog.sourcetreeapp.com/2013/02/14/sourcetree-for-windows-beta-signup/)

* ナウな開発者にバカウケのバージョン管理ツール
* 前者はコマンドラインツールで上級者向け
* 後者はGUIで便利に扱えますが、Attlasianアカウントの登録が必要です
* もちろん、別のgitクライアントでも全然OK
* お好みに応じてどうぞ

### [trello](https://trello.com/)
[![trello画面 引用元： https://trello.com/guide/board_basics.html ](https://d2k1ftgv7pobq7.cloudfront.net/meta/u/res/images/f556940da98ac9e209bb9fb7d7150ca2/board.jpg)](https://trello.com/guide/board_basics.html)

* タスク管理ツール
* やるべきタスクを「カード」という形で作成し、それをボードに配置
* ボード上のカードを動かして、進捗を表現する

### [Bitbucket](https://bitbucket.org/product)
[![bitbucket画面 引用元： http://japan.blogs.atlassian.com/2014/05/introducing-the-new-fluid-width-bitbucket/ ](http://blog.bitbucket.org/files/2014/05/fluid-width-bitbucket.jpeg)](http://japan.blogs.atlassian.com/2014/05/introducing-the-new-fluid-width-bitbucket/)

* gitのリポジトリ（フォルダ）を保持してくれるイケてるサービス
* 似ているサービスのgithubとの主な違いは、非公開リポジトリが無料で作成できること
* ただし無料で使えるのは５ユーザーまで

### [Slack](https://slack.com/)
[![Slack画面 引用元： https://get.slack.help/hc/en-us/articles/217626358-Cheat-sheet-for-basics-and-shortcuts ](https://get.slack.help/hc/article_attachments/209237107/cheat-sheet-preview.png)](https://get.slack.help/hc/en-us/articles/217626358-Cheat-sheet-for-basics-and-shortcuts)

* こちらも開発者に人気が高いチャットツール
* 外部サービスとの連携が豊富にあります
* メッセージを自動ポストするbotを作ったり、他サービスの状態を表示したり、URLの内容を自動展開したり
* 英語しか使えないが、基本的なUIは他チャットツールに似ているためすぐ使える（はず）

このほか、gitやphpなどが使えるWebサーバーが必要です。

trello 及び bitbucket はユーザーの招待で無料枠が増えるキャンペーンをやっている(16/12/18現在）ので、チームメンバーがまだ登録していなければ、招待して特典をゲットしちゃいましょう。

##開発体制
これらのツールを活用し、最終的に弊サークルが行き着いた開発体制の図がこちら。

![sf開発体制図](https://qiita-image-store.s3.amazonaws.com/0/104217/0fd6bf5e-787e-f25f-de63-b67258c30cf8.jpeg)

細かな違いはありますが、ざっくりこのようなサイクルで開発を進めていきました。
いわゆる、アジャイル開発に近い体制を取っています（厳密には違いますが）。
順番に解説します。

### 1. 課題を作成する

まず、実装したい機能を決め（できるだけ数日で実装できる範囲が望ましい）、Trello上にカードを作成します。
また、レビュワーがデバッグ中にバグっぽい挙動や改善すべき事項を発見した場合も、カードを作成します。

Trelloのタスクボードは、下の図のような「やる」「やってる」「やった（更新待ち）」「レビュー中」「OK」の５ラインを作成しており、新しいタスクカードは基本的に「やる」ラインに作成し、優先度順に上から並び替えておきます。

![Trello タスクボード](https://qiita-image-store.s3.amazonaws.com/0/104217/3f9afd36-d114-427f-8a38-c2cebf71af51.png)

必ずしもこのように作成する必要はありませんが、この場合各ラインにあるカードは次のようなステータスを持ちます。

* **やる**： まだ未着手の状態。上にあるものほど優先度が高い。
* **やってる**: コミッターが今着手している状態。
* **やった（更新待ち）**: 開発が完了し、次バージョンのデプロイを待っている状態。
* **レビュー中**: デプロイが完了し、レビュワーのチェック待ち状態。
* **OK**: レビュワーが修正に納得し、完了となった状態。

また、カードが新規に作成されたり、別のラインに移動されたり、コメントがついたりするとそれがSlackの特定チャンネルへ通知されるようになっています。

![Slackへの通知](https://qiita-image-store.s3.amazonaws.com/0/104217/4489824f-5a02-270b-a0ef-5eb0bb0c6923.png)

これは、Slackの Service Integration という機能を利用しており[^zouwaku]、幾つかのWebサービスはこう言ったSlackへの通知をはじめとした連携機能を持っていたりします。
詳しい設定方法などについては、こちらの記事が詳しいです。ご覧ください。

[Slackと他のアプリ/WEBサービス(今回はTrello)の連携について](http://qiita.com/yukihirai0505/items/14863655fa6bebc6f690)

[^zouwaku]: 自分が登録した当初は、無料枠では5サービスまでしか連携できませんでしたが、いつの間にか10サービスまで増枠していたようです。嬉しい。

### 2. 開発とコミット

Trelloにカードが追加されると、コミッター（実際に修正作業をする人）がそれを確認し、カードを「やってる」に移動して開発に着手します。

#### gitよもやま話

開発が進捗した、または完了した場合は、保存したプロジェクトをgitにコミットしていきます。

すでに多くの方がご存知のように、ツクールMVはJavaScriptで動いており、そのプロジェクトデータのうち画像や音声を除くほとんどがJSファイル・JSONファイルで構成されているため、gitなどのバージョン管理システムとすごく相性がいいんです[^rgss]。
例えば、特定のバージョンでバグが出て巻き戻したい場合などに、コミット履歴から拾うことで簡単に戻すことができるんですね。

ただ、ツクールエディタが保存したままでは、横に長いデータとなっているために差分が見づらいなど、ちょっと扱いづらい感じになってしまっています。
この解決法の一つとして、こちらの記事にあるようにJSONをバラして保存する方法があります。お試しください。

[RPGツクールMVプロジェクトをバージョン管理したい話](http://qiita.com/stak/items/edb9431e925d1113c78a)

#### Bitbucketにpush!push!!

gitのローカルリポジトリにコミットしたら、忘れずにBitbucket上のリモートリポジトリにpushしておきます。
リモートリポジトリにpushしておけば、外出先でもリポジトリを同じ状態に保てて便利です。

またブランチ運用について、今回はコミッターが私一人だったため常にmasterブランチ直コミット運用でしたが、gitにコミットする人が複数いる場合は、タスクごとに担当者がmasterからブランチを作成してそこにコミットし、開発が完了したら、Bitbucketのプルリクエスト機能を使ってコミット責任者がレビューを行い、masterにマージしていく運用が良いでしょう。

あ、開発が終わったタスクカードは、「やった（更新待ち）」ラインに移動しておきましょうね。

[^rgss]: 以前のPCツクールのゲームエンジンであるRGSSのプロジェクトデータは符号化(Marshal.dump)された状態で保存されているため、差分管理するためには一度外部ツールでフォーマット変換してからコミットしないといけなかったんですね。めんどい。


### 3. Webサーバーにデプロイして、レビューの準備

#### 「バージョン」と「タグ」

ある程度開発済みタスクが溜まってきたら、それらを「バージョン」にまとめて「デプロイ」します。

スナギツネの開発リポジトリでは、特定の「タグ」をコミットにつけることでそれを開発中の「バージョン」と定義しています。

![Bitbucket上のタグ（バージョン）一覧](https://qiita-image-store.s3.amazonaws.com/0/104217/00de70f3-0078-2e70-175e-1728422a3fee.png)
↑の「v1612..」とかがついたタグが「バージョン」です。基本的にはバージョンを作成した日がバージョン名になり、バグ修正などで同日に複数バージョンを作成した場合は、後ろに「_数字」がついていきます。

バージョンタグをローカルリポジトリで作成してBitbucketにpushすると、リポジトリに設定された「Webhooks」が働き、Webサーバーへデプロイを行う命令が飛びます。

![Webhook設定画面](https://qiita-image-store.s3.amazonaws.com/0/104217/2f5f7c01-ee1b-9a0c-88d6-5fc0d4a9fc69.png)[^ita]

![Webhook設定詳細](https://qiita-image-store.s3.amazonaws.com/0/104217/037ff997-ddcb-7938-eba2-06f7677b9583.png)[^ita]

[^ita]: いたずら防止のため一部URLを伏せています

#### WebhooksによるデプロイととSlack通知

この時、お使いのWebサーバーにBitbucketからのデプロイ命令を受けるためのスクリプトを配置しておくのですが、今回はこちら ([Bitbucket や GitHub で自動デプロイするためのサンプル PHP スクリプトを拾って改造してみた](http://ja.katzueno.com/2015/01/3390/)) から拝借したスクリプトをさらに魔改造し、外部のFTPサーバーに転送する機能[^ftp]、アップロード完了後にSlackにポストする機能、二重に命令が走った際に一時ブロックする機能をつけています。
拙いですがgistにアップしましたので、もしよろしければご自由にご利用ください（提供元に習いこちらもMITライセンスです。サポートは基本的に行わないのでご自身の責任において使用してください）。
https://gist.github.com/InabaByakko/82786eb4100f0a3edd9a0afeab19eb19

こちらのスクリプトの `$deploy->post_deploy` に定義してあるように、アップロードが完了した最後にSlackに投稿する機能をつけています。

![Slack更新通知](https://qiita-image-store.s3.amazonaws.com/0/104217/8dae50c2-514d-032d-6ae3-4b5c80fe6d78.png)

こちらの通知は、Slackの Service Integration の一つである「Incoming Webhooks」を利用しています。
ある程度文面を自由にいじることができるので、メッセージをキャラクター口調にしたり、お遊びbotを作るなんてこともできたりします。
ここでは、レビューの時にブラウザでアクセスするURLと、BitbucketのZIPダウンロードリンク、そしてバージョンタグに記述したコメントがあればそれを表示しています。
詳しくはこちらをご参照のこと。
[Slack API (Incoming Webhooks) が簡単すぎた](http://docs.hatenablog.jp/entry/slack-Incoming-webhooks)

デプロイが完了したら、「やった（更新待ち）」ラインにあるカードを「レビュー中」に移動しましょう。

[^ftp]: どうでもいいですが、ドメインを取得した時についてきた無料のFTPサーバー上にデプロイしたかった（sftpなんて高崇な機能は付いていない）ため、いろいろ無理やりな改造を施しています。


### 4. レビュワーがレビューをする

#### レビューOK？

デプロイが完了してSlackに通知されたら、レビュワーがその内容をチェックします。
先ほどのメッセージには `@channnel` というコマンドが付いており、これがついたメッセージは、投稿されたチャンネルにいるすべてのユーザーに通知が飛びます。
人数が多いチャンネルでやるときは注意。

RPGツクールMVで作成されたゲームはWebブラウザで動作するため、ChromeやFirefoxなど各種ブラウザでレビュワーが実際にアクセスし、テストプレイして確認します。

他には、Bitbucketから直接ZIPファイルをダウンロードするためのリンクもポストしています。
これはツクールMVのデプロイメントからWindows形式でデプロイされた時についてくる各種exe/dllファイルを同梱した状態でコミットしているため、ここからダウンロードするだけでWindowsアプリの状態でテストプレイをすることが可能です。

レビュワーがテストプレイし、課題が解決されたと思った場合は、カードを「OK」ラインに移動してそのタスクを完了させます。
満足できない場合は、その旨をコメント欄に記入し、カードを再び「やる」ラインに戻して(1)からやり直します。

#### バグを見つけた時に役立つプラグイン

もしテストプレイ中にバグを発見し、その時の状態を他レビュワーやコミッターに共有したい場合、トリアコンタンさんのプラグイン [クロスセーブプラグイン](http://triacontane.blogspot.jp/2016/05/rpgmv-bsssbackend-as.html) が役立ちます。
バグが発生した時の状況をクラウドセーブして、そのパスワードを共有するだけです。

また、こちらもトリアコンタンさんの [エラー画面表示改善プラグイン](http://triacontane.blogspot.jp/2016/05/blog-post_15.html)を使用して、エラー落ちが発生した時の画面をスクショして共有することで、コミッターのバグ調査がかなり円滑に進みます。おすすめ。

# 終わりに
今回は、「スナギツネと盗賊団」開発にあたり弊サークルが最終的に行き着いた開発の流れと、それを支える技術やサービスをご紹介しました。

もちろん、これが正解である形ではありませんし、人それぞれに最適な開発スタイルは異なってくるはずです。
もし、開発チーム内の円滑なコミュニケーションができていないと感じた時、この記事を参考にして開発・レビューのサイクルのためのシステム構築をお考えいただければ幸いです。

ではでは、 **Happy RPG Making!!** (某Y氏の受け売り)