本記事は、サムザップ Advent Calendar 2022 の12/17の記事です。
これまで携わってきたゲーム開発現場で効果的だったと感じた導入ツールや開発フローの一部を紹介できればと思っています。
はじめに
筆者はゲーム開発現場にて開発マイルストーンや進行の管理に携わっております。
どこの現場でも課題が尽きることはありません。
そのため日頃は「どうしたらもっと良くなるんだろう＆どこから手を付けていこう」ばかり考えて悩むことが多くなっているのですが、その反面、今は当たり前に出来るようになって気づいていないけど、実はとても有益なことも割とあるんじゃないかと思って簡単に振り返ってみようと思います。
記事には最近効果を感じるようになった学びも含んでいます。
目次
1.ドキュメント管理にNotionを採用して更新性と透明性がUP
2.主要機能はブラッシュアップを先行し、品質のトップラインを定める
3.職種横断のタスクフォースチームで集中して目的を達成
4.毎朝アプリを自動生成して最新状態を確認できる環境を
5.S/A不具合は開発と並行して直す
6.夕会を作業報告ではなく相談の場にする
1. ドキュメント管理にNotionを採用して更新性と透明性がUP
現在、各PJではドキュメント管理ツールとしてNotionを利用しています。
過去、RedmineやConfluenceなどいくつかのドキュメントツールを使ってきましたが、特にNotionは
- リアルタイム同時編集が可能
- サクサク動く/編集が楽
- 検索が楽
- データベースが簡単に作れる
という点でとても使いやすいです。
使いやすい/書きやすいというのは各自がドキュメントを書く心理的ハードルが下がるので、非常に重要な点だと思っています。
かつてあるPJでは自分が参画した時期にはドキュメント文化がなく、議事録を書く/資料を残すという行為が根付いていなかったのですが、Notion導入後しばらく経ってから各メンバー積極的に作業ログを残していくようになってきました。
他にもNotionが有用な点として、例えば議事録はカレンダー形式で可視化することができ、いつ誰がどんな内容の相談をしていたのかが可視化されてキャッチアップがしやすい環境を作ることが出来ました。
さらにはPJのマイルストーン目標やセールスポイントなどをTOPページの上部に常に配置することで、伝えたい重要な情報が日常の動線の中で自然と目に入るような工夫もしています。
2. 主要機能のブラッシュアップを先行し、品質のトップラインを定める
わかりやすさのために実際よりもかなり単純化していますが、過去担当したあるPJでは
このような形で、基本的な機能を開発した後にブラッシュアップ期間を設けて、その期間の中でできる限り品質を上げるということをしていました。
それをまた別のPJでは
- 主要機能に対して先にブラッシュアップをかけてリリース想定の品質に引き上げる
- 品質のトップラインを確定させ、他の副機能に対して横展開する
という形で開発を進めました。
こうすることで目指すべき品質のゴールが明確になり、これから先作っていく他の機能に対して求める品質ラインの意識が揃うようになりました。
また機能を量産していく際に、グラフィックや演出など基準となる要素を主要機能から横展して作ることができるようになりました。
3. 職種横断のタスクフォースチームで集中して目的を達成
これまで関わったPJでは基本的に職種ごとの縦割りが多く、マネージャーを通して開発メンバーに指示が割り振られ、忙しい時期になると1人が複数機能の開発を並行して受け持つということがよくありました。
あるとき「2ヶ月でxxxの品質を仕上げきる」というマイルストーンを掲げた際、全体作業の物量が多いこともあって、各職種から作業内容にマッチした人員を募り、少数精鋭で専念する部隊を作って対応したことがありました。
そのときの学びとして、職種ごとの縦割りに比べて、横軸のチームは
- チームとメンバーのミッションが明確になる
- 担当者間で素早くコミュニケーションが取りやすい
- 差し込みや並行作業が入らず、専念しやすい環境になる
といったメリットがありました。
専念できる環境になることで脳のスイッチングコストがかからないこともあり、普段より明らかに作業効率が上がっていました。
特定の期間の目的に対してだけでなく、日頃の開発においても「バトルチーム」「xxイベントチーム」のように出来ると理想的だと感じています。
4. 毎朝アプリを自動生成して最新状態を確認できる環境を
これは今どのPJでも当たり前のようにやっていることですが、毎朝、最新の変更が入った実機を触ることができる状態をつくっています。
ゲーム開発では実際のアウトプットを実機で触って確認することがとても重要ですが、何よりもまずその機会をつくるためには、毎日新しいアプリが触れるという環境を用意することが大切です。
その環境もあって、自発的に毎日おさわり会を実施して意見を出し合うセクションもできてきています。
5. S/A不具合は開発と並行して直す
想定した挙動でアプリを触って正しく評価するためには、進行不能など重大な不具合は必ず潰しておく必要があります。
開発途中では、まず機能を作ることが優先されて不具合は後回しにされがちですが、「すぐ直すべき不具合」とそうでないものに分類した上で前者は対応していくことがおすすめです。
不具合が多く残っていると、それが当たり前になり、引きづられてどんどん作りの品質が下がってしまうことにもなりかねません。
いま担当しているPJでは「進行不能」や「著しい表示崩れ」「操作感に関わる処理落ち」など機能の評価に関わるものは最優先で修正しています。
また主要機能については、デザイナーが意図したものと異なる挙動・見た目のものは軽微であっても優先的に修正して、品質のトップラインを正しく確認できるようにしています。
副次的効果として、開発後期に不具合が多く発見/残ってしまい工数爆発してしまうということを防ぐことにも繋がります。
6. 夕会を作業報告ではなく相談の場にする
当初、夕会では各自の作業チケットやスケジュールの確認をすることが多くなっていました。
しかし作業報告や確認を順にしてしまうと、メンバーにとって自分には直接関係のない時間が増えてしまい、会として有意義な時間の使い方をできていないなと感じていました。
そこで、作業報告は事前記入式にしてもらい、気になる内容があればピンポイントで確認したり、報告や共有事項がある人がいればお願いしますという形式に切り替えました。
作業の報告確認は短く切り上げ、残りの時間はメインで「開発中のもので相談したいことはあるか？」の時間にすることとしました。
その効果もあってなのか、成果物や作業中の動画やスクリーンショットを事前にSlackにアップロードして、
- この見た目について相談したい
- ここどうすればよいのか悩んでいる
- こんな感じで作ってみたけどどうだろう
というやり取りが増えてきたように感じました。
確認ではなく開発を前に進めるための時間がメインになることで、定例の会議において本来あるべき時間の使い方ができてきたなと思っています。
おわりに
本記事が少しでも誰かの開発現場の参考になれば幸いです。
明日は @ninomiya_shota さんの記事です。