ゲームエンジニアは、新しい技術に触れやすかったり、変わった仕様の機能を作れたりとなかなかに楽しい世界です。
ただし、ゲームエンジニアは楽しい事ばかりではありません。
ゲーム開発の現場は、常に変化し続ける環境です。
その中でゲームエンジニアとして成功するためには、技術力や創造性だけでなく、予期せぬ困難や逆境に立ち向かう覚悟が必要です。
そんなわけで今回は、僕がゲーム開発の現場でよく出くわすトラブルを紹介していこうと思います。
トラブル自体を避けることは難しいかもしれませんが、あらかじめ知っておくことで、いざトラブルに遭遇した時のダメージは減らせるはずです。
仕様の変更
ゲーム開発において、最初に決めた仕様が最後までそのまま進行することはほとんどありません。
仕様の変更が発生する例として、以下のようなことはしょっちゅうあります。
- テストプレイしてみたが、全然面白くなかった
- 市場のトレンドが変わり、実装中のゲームがトレンドから大きく外れてしまっている
- 顧客または会社上層部から、対応せざるを得ない要望が出てきた
- 機能を実装している最中に、どうしても解決できない技術的な問題が発生した
これらの事態に出くわすたびに、エンジニアは設計の見直しやコードの修正を強いられます。
場合によってはプランナーやデザイナーといったエンジニア以外の職種も対応を強いられるケースも多々あります。
仕様の変更は、当初の計画を狂わせプロジェクトの進行の遅延が発生するだけでなく、チームメンバーにもかなりの負担をかけます。
単純に工数がかかるのはもちろんですが、せっかく実装した機能を変更あるいは削除するのは精神的にも辛いものです。
仕様の変更の影響はそれだけではありません。
頻繁に仕様の変更が発生すると、当初想定していなかった実装をすることになり、技術的負債が積み重なっていきます。
技術的負債が積み重なると、後々大きな不具合につながりかねません。
正直なところ、仕様の変更は避けられない場合が多いです。
ですが、仕様の変更を意識した実装をすることで、修正する際のコストを削減することは可能です。
場当たり的な実装ではなく、変更に強い実装を心掛けましょう。
※時間がないとき等の場当たり的な実装をせざるを得ないケースもあります
また、仕様に関しておかしい点や改善できそうな点を見つけた場合は、どんどん指摘・提案しましょう。
将来の仕様の変更の可能性をなくすことにつながります。
納期が短い
ゲームは基本的には早くリリースできるにこしたことはありません。
したがって、納期が短めに設定されていることは珍しくありません。
また、先に記載した仕様変更との合わせ技で「仕様変更が入ったけど、納期はそのまま」みたいなこともあるあるです。
「そもそもそんな無茶な納期やめてよ」と文句を言いたくなりますが、やらざるを得ないケースもあります。
「顧客からのプレッシャーが強い」「会社の資金繰りが厳しく、できるだけ早く売り上げ欲しい」等で、どうしようもないケースもあったりします。
(それでも無茶な納期はやめてほしいものですが…)
短い納期のプロジェクトでは、まず優先度の設定が重要です。
プロジェクトによって優先度の付け方は様々ですが、基本的には絶対に必要な機能や他のタスクの進行に影響のある機能等が優先度の高いものになります。
特に、短い納期の場合は他のタスクの進行を妨げない優先度設定が重要になります。
(ここでいう他のタスクとは、他の機能の実装や他職種の作業を指します)
ただ、優先度が適切に設定できても、短い納期は短いままです。
どうしても残業や休日出勤をする必要が出てきたりもします。
一昔前の「徹夜は当たり前」「連続○十日出勤」みたいなことは最近ではあまり見かけなくなりましたが、それでもある程度忙しくなるタイミングがあることは覚悟しておきましょう。
また、「なんとか短い納期でもリリースできた！」となっても、それで一安心とはなりません。
短い納期がもたらす最大のリスクは、品質の低下です。
「必要最低限未満のテストしかできず、不具合が残ったままリリースしてしまった」というのがよくあるパターンです。
リリース後も油断しないよう気を付けましょう。
深夜・休日の不具合対応
いくら丁寧に実装したとしても、不具合というものは出てくるものです。
そして、不具合は常に就業時間中に発生するとは限りません。
特に、ゲームだと24時間いつでも誰かしら遊んでいるユーザーがいることも珍しくありません。
誤字・脱字といった軽微な不具合であれば翌日以降の対応で問題ないことがほとんどですが、進行停止といった重大な不具合であれば迅速な対応が求められます。
そして、重大な不具合が深夜や休日に発生したのであれば、残念ながら深夜・休日の対応をする必要があります。
深夜や休日に突然呼び出され、対応を迫られることは、精神的にも肉体的にも大きな負担です。
特に、リリースや大規模なアップデート直後は呼び出される可能性が高いです。
プライベートで何か重要な予定を組む際は、そのようなタイミングは避けるのが賢明です。
どうしても予定がバッティングしてしまう時は、他のエンジニアでも対応できるようドキュメントを整備しておく等の工夫をしておくと良いです。
また、深夜や休日の対応が続くと、疲労やストレスはどんどん蓄積していきます。
休めるときにしっかり休むよう、自己管理を怠らないようにしてください。
メンテナンス対応
ゲームの種類にもよりますが、運用型のゲームであればメンテナンス対応は避けては通れません。
新機能の追加やバグ修正等を本番環境に反映する際には、メンテナンス対応が必要です。
基本的には、一時的にユーザーがゲームにアクセスできないよう制御してから行うことが一般的です。
ただし、プロジェクトによってはユーザーがゲーム内にアクセスしている状態で行うメンテナンス対応、いわゆるオンメンテをすることもあります。
メンテナンス対応は、本番環境での作業になります。
この本番環境での作業というのは、些細なミスが大規模な障害を引き起こす可能性があり、普段の開発業務とは違った独特の緊張感があります。
本番環境で発生した障害は、ユーザーに迷惑をかけることはもちろん、会社の信頼にも関わるため責任は重大です。
冷静かつ慎重に作業を進めることが大事です。
大抵は複数人で行うため、あなたの作業はしっかり他の人に確認してもらい、他の人の作業はあなたがしっかり確認するようにしましょう。
メンテナンス対応は、予測もしていなかった事態にしばしば出くわします。
「開発環境では発生しなかったエラーが発生する」みたいなことはけっこうあります。
大抵はメンテナンス対応の作業ミスだったり作業漏れだったりしますが、中には本番環境でしか再現しない珍しい不具合だった、なんてこともあります。
場合によっては緊急のプログラム修正が必要になるケースもあります。
限られた時間の中での予期せぬ対応はついつい焦ってしまいがちですが、落ち着いて冷静に対応しましょう。
辛口のフィードバック
ゲーム開発で特徴的なのが、ユーザーからの辛口のフィードバックです。
ゲームがリリースされると、ユーザーはそのゲームの体験を元に、SNSやレビューサイトに率直な意見を投稿します。
中には非常に厳しい意見もあり、エンジニアとしての努力が否定されるように感じることもあります。
もちろん他のシステムでもユーザーから辛口のフィードバックを受けることもありますが、ゲームの場合はその傾向がより顕著です。
なぜなら、ゲームはエンターテインメントとしての要素が強いため、ユーザーはゲームに対して単なる機能や性能以外の感情的な価値を求めているからです。
ユーザーはゲームの世界に没入し、物語を楽しみ、達成感を得るために多くの時間を費やしてくれます。
そのため、ゲームに対する期待が裏切られると、その失望感やストレスが直接感情的なフィードバックとして表れるからです。
※逆に、期待以上だった場合は、こちらがニヤニヤしてしまうくらいべた褒めしてくれることもあります
ユーザーからのフィードバックはかなりキツイ言葉で批判されることもあります。
そうした辛口のフィードバックを受けることは、精神的にとても辛いものです。
ですが、キツイ言葉をかけたくなるほど期待してくれていたのだと思うようにして、少しでも前向きにとらえてフィードバックを真摯に受け止めましょう。
中には面白半分の誹謗中傷もあったりしますが、そんなものは当然無視してください。
売り上げが上がらずチーム内の雰囲気が悪くなる
仕事としてゲーム開発をする場合は、そのゲームの売り上げはとても大事です。
売り上げが上がれば、人手を増やしてより大規模なアップデートができたり、より気合いの入ったイラストや3Dモデルを用意出来たりします。
会社によってはメンバーにインセンティブが入ることもあるでしょう。
一方で、どんなに努力しても売り上げが目標額に達しない場合も珍しくありません。
いくらゲームの品質が高くても、例えば以下のような理由で売り上げがあがらないことがあります。
- 大手が同ジャンルの大型タイトルを同時期にリリースした
- ゲームのターゲット層がニッチすぎて市場に刺さらなかった
- 運用コストが高すぎて、目標売上額が非現実的な数値になる
売り上げが上がらないとチーム内の雰囲気は悪化しやすいです。
特に、高い売り上げを期待されていたゲームほどひどい有様になります。
メンバー間での責任の押し付け合い、不平不満の表面化、メンバーの急な退職等々が起こります。
僕が直接経験したことではありませんが、テレビCMもバンバン打って気合いをいれてリリースしたゲームなのに全然売り上げが出ず、メンバー間の喧嘩が絶えなかったプロジェクトを知っています。
少しでもそんな事態を回避する確率を上げるために、ゲーム開発を仕事にするのであれば売り上げは常に気にするよう肝に銘じておきましょう。
サービス終了・開発中止
運用型のゲームはどんなに人気でも、いつかはサービス終了を迎えます。
あるいは、新規に開発中のゲームが諸事情により開発中止になる場合もあります。
やりたいことをやりつくした上でのサービス終了であれば、一抹の寂しさは感じつつも悔いは残らないと思います。
一方、急なサービス終了や開発中止はとてもショックが大きいです。
僕も以前、思いもよらぬタイミングでサービス終了を経験したことがあり、とてもショックを受けました。
さらに、サービス終了・開発中止に伴って、ユーザーから別れの声や悲しみの声、あるいは失望の声や怒りの声が寄せられることもあります。
そういったユーザーの声に申し訳ない気持ちを抱きつつ、サービス終了・開発中止の対応を進めていく必要があります。
特に、サービス終了の場合はメンテナンスや返金等の法的対応も必要になります。
また、燃え尽き症候群にならないよう注意も必要です。
ゲーム開発が終了しても、あなたのエンジニアとしてのキャリアはずっと続きます。
気持ちを新たにして次の現場に挑みましょう。
まとめ
以上がゲームエンジニアが覚悟しておいた方が良い出来事です。
全部が全部、全ての現場で起こる出来事ではありません。
ただし、あなたがゲームエンジニアとしてのキャリアを進める以上、いつかは出くわす出来事です。
その時になって、アワアワしないよう心構えだけは作っておくことをおすすめします。
「ちょっと自分はゲームエンジニアにはなれないかも…」なんて思った人も、もしかしたらいるかもしれません。
今回紹介したのはあくまで仕事でゲーム開発をする場合に起こる出来事です。
趣味で個人開発をする分には関係ない出来事も多いです。
まずはちょっとしたミニゲームを作ってみることからはじめてみてはいかがでしょうか。
コメント