おつかれさまです。エンジニアの藤澤です。
自分はクラッシュフィーバーのクライアント開発を担当しているんですが、最近ふと、いまの開発チーム（開発スタイル？）が自分にあっているというか、いまの環境 恵まれてるなあ、と感じることがありまして、今回はそれをご紹介したいと思います。
チームメンバー
現在チームのメンバーは 4 人です。
おもにバトル部分を担当する人、マルチ部分を担当する人、それ以外の部分を担当する人、といった具合におおまかに担当が分かれています。
日本人は属人化を嫌う人が多いように感じますが、担当がおおまかに分かれていることで、タスクの割り振りなどイチイチ決めなくても各々が自発的に動けますし、コードもクリーンな状態に保ててよいです。（自分の担当分以外でもだいたいの機能とかは分かっているので、その人じゃないと どうしようもない、ということもないですし）
いわゆるマネージャーはおりませんが、役割分担ができていますし、各々自分で判断して動けるメンバーが揃っているので、スムーズに動けています。
タスク管理・スケジュール管理
タスクは GitHub の Issue で管理しています。
新機能や改善要望、不具合情報など、ふだんから誰でも Issue に登録しておき、次のバージョンでどのタスクを入れるかをその中から決めます。
スケジュールは
- どのタスクを入れたいかと優先度、リリース予定日をプロデューサー、ディレクターが決める
- エンジニアがそれを見て期日内に収まりそうにないタスクを省く
といった具合に決まります。細かい工数見積もりなどはせずに さくっと決めてしまいます。
GitHub の Milestone の機能でバージョンごとに Issue をグループ化し、すべての Issue が片付いたら完了です。
スケジュール表なども作っておらず、細かいスケジュール管理もしていませんが、ひとつのバージョンの実装期間が だいたい 1 〜 2 週間なので、毎朝の進捗共有だけでこと足りています。
開発スタイル
アジャイルでやろうとか ○○型でやろうとかは とくに意識していません。
開発の流れは
- プロデューサーやディレクターがおおまかにやりたいことを決める
- プランナーが仕様をつめる
- 実装
- QA
- 社内リリース（新しいバージョンを実際に本番につないで しばらくプレイしてみる）
- 本番リリース
という感じで行ないますが、エンジニアが細かい仕様を自分で判断して先に実装を進めちゃうこともありますし、QA 期間中に実際に動かしながら「やっぱりこうしたほうがいいんじゃない」ということで軌道変更したりします。
その他
コーディングルールなどはありません。（宗教の押し付けに感じられるので……）
変数の命名はキャメル形式にしようとか、既存のコードになるべくあわせようとか、その程度です。
Git の運用は git flow と github flow の中間みたいになるのでしょうか（あまり詳しくないのですが）。
- master ブランチは市場に出ている最新の状態
- develop ブランチは開発中の最新の状態
- develop から feature を切って実装を行ない、develop に Pull request
- 複数バージョンの開発が並走する場合は develop_2.0 みたいに develop ブランチが複数存在することもある。前のバージョンがリリースされたら develop にマージし、develop を最新の状態に保つ。
という感じです。master は本番環境向けの設定、develop は開発環境向けの設定にカスタマイズしてあり、リリース時の設定変更もれとかがないようにしています。
職場環境はオープンオフィスなので、まわりの会話から他のチームの状況とか分かってよいのですが、割り込みも多くて実装に集中できないのがジレンマです……。
まとめ
これだけ書くと なんだか まともな管理もしていない無秩序な集団のようにも見えますが、決してそういうわけではなく、まだ社員ぜんぶで十数人だったころの よいベンチャーらしさみたいな部分をうまく残せているんじゃないかと思っています。