昔のゲーム開発現場は大変だった、という話はよく聞きます。
労働時間が長かったことや、体力面で厳しかったことが語られることは多いです。もちろん、それも大きな負担でした。ただ、個人的に一番きつかったのは、作業量そのものよりも、「どこまでやればOKなのか」が言葉になっていない場面が多かったことでした。
仕様書を読んで、実装して、動作も破綻していない。ロジックとしても間違っていない。それでもレビューで「何か違うなあ」「面白くないなあ」と返ってくることがありました。
そのフィードバック自体が悪いというより、何が違うのか、どこを見直せばよいのかを、自分で読み取る必要がありました。いま振り返ると、そこには技術力とは別の難しさがありました。
仕様通りでも通らない判断があった
当時の仕様書は、いまと比べるとかなり簡素でした。
画面の流れや基本的な仕様は書かれていても、その仕様をどの温度感で実装するのか、遊びとしてどこまで調整するのか、どの状態ならレビューで通せるのかまでは、細かく書かれていないことが多かったです。
ある時、実装内容としては仕様通りで、ロジックにも破綻はないはずなのに、「それじゃない」とだけ言われたことがあります。
そのとき問われていたのは、仕様書との整合性だけではありませんでした。今このタイミングで、その仕様をそのまま実装する判断が妥当なのか。プロジェクトの状況、ゲーム全体の方向性、直近のレビューで出ていた違和感、そうしたものを踏まえて動けているかが見られていたのだと思います。
仕様に書かれているから実装する。これは一見すると正しい動きです。ただ、ゲーム開発では、仕様書に書かれた内容と、実際に触ったときの面白さがずれることがあります。ボタンの反応、演出の間、UIの見え方、キャラクターの動き、音の入り方。実装前には問題なく見えたものでも、動かして初めて気づくことがあります。
そこをどう受け取るかまで、当時はかなり個人の感覚に任されていました。
求められていたのは「察する力」
昔の現場で求められていたものは、単純な根性や作業量だけではなかったと思います。
むしろ難しかったのは、「何を察すべきかを察する力」でした。さらに言えば、その察する力がどこまで求められているのかまで、自分で読まなければならない感覚がありました。
レビューで「面白くない」と言われたとき、それは演出の話なのか、操作感の話なのか、テンポの話なのか、仕様の狙いがずれているのか。言葉だけでは判断しにくい場面があります。
そこで、前回のレビューで何が話題になっていたか、チームがいま何を重く見ているか、似た機能でどの判断が通っていたかを見ながら、自分なりに直す必要がありました。
この状態は、経験者にとっては「空気を読む」「流れを見る」という言葉で済ませられることもあります。ただ、未経験者にとってはかなり厳しいです。何を見ればよいかが分からないまま、結果だけを求められるからです。
ゲーム業界が職種を問わず未経験者に厳しいと言われてきた背景にも、こうした構造があったのではないかと思います。スキルそのものの前に、暗黙の判断基準をどこまで共有できているかが、早い段階で問われていました。
開発規模の拡大で、感覚だけでは進めにくくなった
いまは、状況が大きく変わってきています。
就労環境の改善も進みましたし、先人たちの反省や試行錯誤も積み重なってきました。業界内での知見共有も増えています。昔は少人数開発の中で、時間をかけながら感覚を合わせることができた面もありました。
ただ、開発規模が大きくなると、それだけでは進めにくくなります。
関わる人数が増える。職種が分かれる。外部パートナーとのやり取りが増える。開発期間が長くなる。そうなると、「見れば分かる」「触れば分かる」「前の流れで分かる」だけでは、確認に時間がかかります。
レビューで毎回同じ話が出たり、修正意図が伝わらなかったり、テストで初めて認識のずれが出たりします。担当者の理解力だけに頼ると、実装時にもレビュー時にも負担が増えます。
だからこそ、他業界で培われてきた組織運営、マネジメント、プロセス設計の考え方が、ゲーム開発にも自然に取り入れられてきたのだと思います。
感覚やセンスを、共有できる形にする動き
特にゲームデザイン、グラフィック、サウンドのような分野では、かつて「感覚」や「センス」と言われていたものを、言葉や資料で共有する方法がかなり整理されてきました。
ゲームデザインであれば、プレイヤーにどの判断をさせたいのか。グラフィックであれば、画面上で何を目立たせたいのか。サウンドであれば、どの操作や演出に対して、どの反応を返すのか。
こうした点が言語化されていると、作業者は迷いにくくなります。レビュー担当者も、好みだけではなく、確認すべきポイントに沿って話しやすくなります。テスト時にも、仕様と実際の体験のずれを確認しやすくなります。
「察せ」ではなく「説明する」。
「背中を見ろ」ではなく「前提を共有する」。
そうしたプロジェクトが増えてきた感覚があります。
もちろん、すべてを言語化できるわけではありません。ゲームの面白さや手触りには、触ってみないと分からない部分があります。ただ、だからといって全部を個人の感覚に任せると、確認の負担が大きくなります。
どこまで仕様で決めるのか。どこから先は触って調整するのか。レビューで何を見るのか。判断が変わったときに、どこへ記録するのか。こうした確認項目があるだけで、開発メンバーはかなり動きやすくなります。
ゲーム開発手法の進歩はもっと語られていい
ゲーム開発の昔話では、労働時間の長さや体力面の厳しさが取り上げられることが多いです。
ゲーム開発の歴史を振り返ると、昔は大変だったという話に寄りやすいです。
ただ、その大変さの中には、労働時間や体力面だけではなく、判断基準が言葉になっていない難しさもありました。そして、いまのゲーム開発は、その難しさを少しずつ整理してきたのだと思います。
仕様書、レビュー、チケット、テスト観点、運用時の振り返り。そうしたものは、単に管理を増やすためのものではありません。感覚だけに頼らず、チームで判断を揃えるための道具でもあります。
昔のやり方を否定したいわけではありません。当時の開発には、少人数だからこそ成り立っていたすり合わせ方がありました。ただ、開発規模が大きくなったいま、そのままでは確認に時間がかかり、認識のずれも増えやすくなります。
ゲーム開発手法は、確実に進歩してきました。
感覚をなくすのではなく、必要な感覚を共有しやすくする。センスを否定するのではなく、レビューや実装で確認できる言葉に近づける。そこに、いまのゲーム開発の変化があるように感じます。
次にレビューで「何か違う」と感じたとき、感想だけで終わらせず、どの画面で、どの操作で、どの体験が想定とずれているのかまで確認できると、実装担当者もレビュー担当者も、次に何を直すか確認しやすくなります。
おわりに
X（旧Twitter）やBlueskyを中心に日々発信しております。
是非他のSNSもご覧いただけますと幸甚でございます。
https://x.com/itchie_tatsumi
https://bsky.app/profile/itchie-tatsumi.bsky.social
https://www.facebook.com/ichino.souta
また、辰巳電子工業SS事業部では、エンジニアが安心して長く働ける環境づくりに取り組んでおります。「今の経験で応募できるか知りたい」「案件やキャリア支援について聞いてみたい」という方は、是非カジュアル面談からお気軽にご相談願います。
