こんにちは、やまだたいし( やまだ たいし (@OrotiYamatano) | Twitter )です。
本記事はUnityゲーム開発者ギルドアドベントカレンダーの22日目の記事です。
今回はゲーム業界とIT業界の違いやゲーム業界の現在についてです。
目次
なぜ、ゲーム業界とIT業界の違いを書こうと思ったのか
ゲーム業界は現在中途募集はスマホ関連以外、大体がゲーム業界経験者を募集しているところが多い気がします。
つまり、ゲーム業界人として現在活躍している人の殆どが根っからのゲーム業界人である場合が多いです。
しかしながら、私はIT業界を2年半経験し、その後ゲームプログラマーとして4年ほど働きました。
つまり、ゲーム業界もIT業界もそこそこ知る珍しい人間。
これは私の知識を披露しないと勿体ないと思ったので本記事を書くことにしました。
ちょっとポエミーな記事になってしまうかもしれないですが、ご了承いただきたいです。
IT業界のことを忘れないうちにIT業界とゲーム業界の違いや現在のゲーム業界について語っていきたいと思います。
前提
何を語るにもゲーム業界、IT業界どちらに、どの程度足を突っ込んでいたか話しておく必要があると思います。
ゲーム業界とIT業界の違いを語る前に私の経験をざっくり書きます。
私: 現在28歳
IT業界に就職後システムエンジニアとして、
受託開発で、共済金システムや治験薬配送システムなどを作り、
部署異動してSIerとして客先常駐で某コンビニポイントサービスのスマホアプリの設計とか、
◯電力会社の土地の管理システムとかのシステム改修を行っていました。
なので、クライアントサイドからサーバーサイド、客対応までやった。
言語はJava、PHPなど。後フロントサイドもやったのでJavaScriptとHTMLも少々。
後、謎ツール(?)のMagic Unipaasとかも使える。
その後、転職しゲーム業界に入る。
言える範囲では
スマホのゲームアプリのクライアントサイドのUIとか、
コンシューマーゲーム(棋士藤井聡太の将棋トレーニング)とかに携わる
いわゆる中規模~大規模の間のデベロッパー会社
ちなみにUnity、UE4どちらも業務経験あり。
得意なのはUnity。
IT業界とゲーム業界の違い
早速違いについて書いていこうと思います。
1.資料について
IT系:資料作成は必須。納品資料であったりもする。
ゲーム系:資料はあるけれど結構適当
IT系では口酸っぱく資料作成しろと言われます。
炎上系案件では資料が存在しないこともザラだが、何かしら仕様書や要件定義書、DB設計書などが作られます。
ゲーム系に来て驚いたのは仕様書に相当するものが無いことです。
確かに仕様書と呼ばれるものはあるのだけれど、詳細には書いておらず、こういう動きにして欲しい、
などと書いてあるばかりで、システム系ならば少なくとも画面ごとに存在しそうな仕様書が存在しないです。
強いて言うなら、要件定義書に近い仕様書がゲーム系では存在しています。
しかも、会社ごとにフォーマットもあまり無いようで、好き勝手に書いてあることが多いです。
(もちろん、システム系にもフォーマットはない場合が多いが、大体が画面ベースで画面設計書が存在する、ゲームにはない場合も多い)
DB設計書もゲーム会社では見たことがない。（もちろん、内部では作ってあることがあるが、型名など厳密なものを見たことがないという意味）
2.フレームワークについて
IT系:言語ごとに様々なframeworkが存在
ゲーム系:ライブラリはあってもframeworkは殆どない
IT系ではシステム系でもフレームワークは無い場合が多いが、Web系では必ずと言っていいほど、フレームワークを利用します。
Springframework、Zendframework、BootStrapなどなど……。
しかし、ゲーム系ではライブラリは存在するが、frameworkはほぼ全くと言っていいほど存在しないです。
O/R Mapperでさえ海外の怪しいライブラリか有志が作ったものぐらいしかないです。
特に、ソシャゲなんかはタップして画面遷移みたいな流れが多いのでframeworkが少なくとも会社独自のものが存在しているのではないかと思いましたが、
そこそこ大きい会社にも関わらず存在していない場合が多いようです。(もちろん作ってあるところもあるがそういったところは技術力があるところ)
3.設計について
IT系:結構厳密に定義
ゲーム系:ほとんどどない。
ゲーム系にはframeworkが無いと聞いて嫌な予感がした人がいるかも知れない。
frameworkどころかしっかりした設計思想もないようです。
もちろん、個々の技術者はある程度の設計理念を持っていることが多いが、プロジェクト単位で統一といったことをしないため、
あちらこちらにプログラムが散乱してしまっているのが現状のプロジェクトが多みたいです。
4.仕様書を書く人について
IT系:上級SE(エンジニア)が書く
ゲーム系:プランナー(非エンジニア職)が書く
IT系において、仕様書は俗に言う上級SEが行います。
しかし、ゲーム系ではプログラマーが仕様書を書かないし、テストもしないです。
プログラマーは本当にコードを書くだけ。
じゃあ、誰が仕様書を書くのかと言うと、プランナーです。
プランナーはディレクターから要望を聞き、こうなったら面白いんじゃないかと想像しつつ詳細を仕様書に書くことになります。
もちろん、プランナーはプログラムは出来ないので、粗のある仕様書が出来ます。
プログラマーは随時プランナーに確認をしつつ、ある程度補完してプログラムを完成させることになります。
普通のIT系では設計書書く人が偉く、設計書が間違っていても、毎回お伺いをたてて作ることになります。
例え仕様書に矛盾が発生していても仕様書書く人が正と言えば正になることが多いです。
ゲーム系は逆でプランナーには権力がなく、作るプログラマーが偉く扱われる場合がほとんどです。
なので、仕様書をかいたプランナーはプログラマーから責められる……。
もちろんプランナーはプログラムを書いたことがないため、デザイナーからも責められ、ディレクターからも責められ大半が可愛そうな目にあう事が多いきがします。
話が逸れるがプランナーを目指す人はドMが良いと個人的には思う。
プランナーは、いわゆるバンド演る人で例えると「当方ボーカル他募集」のような美味しいところばかりをやりたがりプログラムもデザインも出来ない人がなる場合が多いです。
(超マレに総てに挑戦し実現したが自分が出来ることに限りがあると悟りプランナーを目指す人がいるらしいと聞いたが見たことがない)
それもあってかゲーム業界ではプランナーを軽視する人は少なくないとかなんとか……。
それも相まってか、若干酷く当たられるし、楽観的では叩き潰されてしまう。鬱になって辞める人も少なくないと聞きます。
私としては「どれも出来ないのにプランナーを目指すなんて、どうしてわざわざ修羅の道を……」という気がしてなりません。
とは言いつつもディレクターに化けれる人も居るので、プランナーになってからプログラムを勉強したりして付加価値をつけれる人は強そうだと思いました。
5.テストを行う人
IT系:エンジニアが行う
ゲーム系:テスター(デバッガー・QA)＆受け入れ先が行う
IT系において、テストはSEが行います。
お硬い案件ではエビデンスと称して、意味のないテスト結果をスクリーンショットを残し、エクセルに貼り付ける作業を行うことになります。
IT系のSEは自分でテストを行うことを嫌い、自動化出来るようにだんだんとしてきている。
テストをプログラムでするなどは日常茶飯事です。
しかしながら、ゲーム系では(小規模案件なら自分たちでやるが)特に大規模なところでは、テスター(デバッガー・QA)を雇うことが多いです。
プランナーの仕様書とプログラマーが示してきたチェック観点を元に想像しながらゲームをプレイし、チェックリストを淡々と消化していく形になります。
チェックリスト自体は残す場合もあるが、こなした証拠などは残さないことが多いです。(バグ洗い出し様に稀に動画を撮っておくことがあるぐらい?)
このテスターはゲーム好きだが、プランナーにもプログラマーにもデザイナーにも慣れなかった人がなる場合や、一時のアルバイトがなる場合があるので、
一番扱いが酷いし、バックレ率もかなり高いです。(可哀相)
ゲーム系においてそうやって役割分担されている場合が多いように感じます。
テストにおいてはゲーム業界はすごく工数を気にしない節があるように感じます。(もちろん全く気にしないというわけではないがIT会社よりは気にしていないように思う)
そもそもゲーム自体がバグが出ても人死や破産する人は出ないからかもしれないです。
個人的には工数のムダがかなり多いので、ゲーム業界にもテストがもっと導入されればいいのになと思っています。
6.知識のインプット
IT系:人によって様々。ウェブ系は結構流行に敏感
ゲーム系:ウェブ系と比べると遅い。特にコンシューマーは遅い
IT系にも知識が古いところは少なくないです。特に業務系アプリケーションなどは既存アプリを変更するのを嫌がる方も少なくないです。
Web系はかなりの最新技術をキャッチアップしている方が多い気がします。海外の記事を読み自らもコーディングをします。
しかしながら、ゲーム系は(特にコンシューマー)は開発年数が長く5年などザラです。
開発するのもゲームエンジンが対応してからのことが多いため、キャッチアップが総じて遅い印象があります。
そもそもゲーム系の場合は技術を学びたくてゲームをつくるのではなく、ゲームを実現するために技術を学ぶので総じて受け身の様な印象があります。
7.エンドクライアント
IT系:パソコンもまともに使えない方がクライアントだったりするので納期や価格に厳しい
ゲーム系:デベロッパーの場合はパブリッシャーという同じゲーム会社が顧客になるため事情に比較的優しい
コレばかりは場合にもよるが、オタクで構成されているからか、IT系の場合は非エンジニアクライアントである場合がおおく、
業務用語は愚か賃金や工数に対しても渋い人が少なくない様に思います。
ゲーム業界の場合パブリッシャーはゲーム業界の厳しさをわかっており、どのぐらい工数がかかるのか温度感をわかっている場合も多く比較的要望が通ることがあります。
(もちろんおかしな事を言う人もいるが。)
IT系だとサービス提供が遅れることは大きな問題になるがゲーム系ではさほど大きな問題にはならないというのもあるのかなと個人的には思います。
8.客対応について
IT系:エンジニアも駆り出されることがある
ゲーム系:ほとんどエンジニアが駆り出されることはない。駆り出されてもプランナーなどの企画職
これは会社の規模感にもよるとは思うが、前職のとあるサービスを作っていたとき私は電話番をさせられていました。
忙しい日では部署に10件以上の電話がかかってきて対応を迫られました。
やれPCが壊れただの、やれエクセルが変だのこんなのエンジニアがすることじゃないという面倒まで見させられた。
部署を移動した際は電話番が無くなったが、相変わらず客先に対して窓口業務をするエンジニアが必要でした。
ゲーム業界では一切エンジニアが対応しなくても良いという訳ではないが、基本的に技術的観点や工数観点から意見を求められるだけで、
折衝経験を積むようなことにはならない様子……。
9.スーツについて
IT系:カジュアルなところは必要ないが、結局フォーマルな場があったりするので一着は必要だったりする
ゲーム系:一着も必要ない
ゲーム系は面接でさえもスーツじゃなくていいです。
私は転職活動のときスーツで行動していましたが、ご丁寧にどうもと言われてしまいました。
スーツで対応するのは人事の人ぐらいのようです。
ウェブ系でもスーツを着なくてもいい場合はありますが客先対応の場合はスーツを着る場合もあります。
ゲーム業界では着ている方が不自然のようです。
ゲーム業界に入って感じていること
長くなりますが語ります。
ゲーム業界は特異な人が多い?
結構エンジニアが好き勝手やっててのびのびしているのですが、給与は少ないような感じがします。
実際良い給料を貰っているのは大手パブリッシャーさんだけだと思います。
正直IT系から転職する際に給料は減りました。
大手パブリッシャー＞大手スマホデベロッパー＞コンシューマーデベロッパー
ゲーム系は目指すのが難しい割に給与は割りに合わないです。
それなのに目指す人がその職につきます。となると全体比率で奇特な方が多い気がします。
開発の流れが古い?
売れないとお金にならないというのもあると思いますが、全体的に無駄が多い気がしています。
仕様の策定や開発の流れが洗練されていないように感じました。
また、ゲーム業界はソフトウェアを作りきりで保守してきた経験がなかったがゆえに、テストや依存性が少ないコードの書き方に慣れていない様に感じました。
スマホゲームが浸透し始めてようやく足並みが揃った感ある気がしています。
ちょっと昔までは、自社エンジンベースのシステムが多く、
システムも作りきりのものが多い時代でした。
社外には情報を出さず、秘匿化し資産として運用する時代。
しかしながら、スマホが入ってきた時に時代が変わりました。
スマホなんかゲームじゃねぇ！と高をくくっていた人たちも今はほとんどがスマホゲームを作っている現状です。
スマホゲーム市場が出来たての頃はゲーム業界の参入が少なく、普通のシステムも作っているIT系の人たちの参入してきたのが多い空気感があります。
ウェブ系は自分の知識となるものは共有し業界全体を盛り上げるとともに、自信の技術力をアピールする文化があります。
ゲーム業界は真逆でした。
そのお陰かスマホデバイスに特化していたUnity界隈は現在割りと情報共有が多い様に感じます。
UE界隈の共有も無いわけじゃないですが、スマホなんかゲームじゃねぇと高をくくっていた人たちが手を出したゲームエンジンだからか若干、情報共有が薄いような気がします。
(そもそもどこまでコードについて言及していいか分からないというのもあるとは思いますが……)
ともかく、何が言いたいかというと未だにゲーム業界は情報共有の流れが薄いんじゃないかという話です。
せっかくゲームエンジンが皆同じものを使うようになり、人員の流動性が増したのに
共通の知識を共有する文化が薄いのは勿体ないと感じました。
誰しもが分かるようにコードを書いてライブラリ化したり、するのもいいでしょう。
とにかく人にコードを見せる時代が来たのだから、わかりやすいコードを書くように心がけるようにして欲しいです。
今は機器性能面も上がってきており、極端に速度に特化し分かりづらいコードを書く必要はなくなってきました。
今後ゲーム業界は作りきりの時代ではなくサブスクリプションでゲームを提供する時代に変化していきます。
運用保守に特化したプログラムや開発の流れを行う必要があります。
IT系の世界開発標準にPMBOKというのがあるんですが、
PMBOKには見積もりの方法とか色々載っていて、日本の国家資格にも参考にされる
教科書的な由緒あるものなんですが、ゲーム開発もIT系に追従する節があるので注目したい所です。
IT系ではPMBOKが最近大幅改変されたのでチョットした騒ぎになっている。
それに追従するならゲーム系も大きく働き方が変わってくる。
何がどう変わったかと言うと、ウォータフォールベースで何をどうやれば開発できるよと言った手順書の様な内容だったのが
大幅に改変され開発する上で気をつけるべきことみたいな内容になってアジャイル、ウォータフォール関係ない内容に変わり、本の重さが重量が2kgから800gに激減したそうです。
つまり、アジャイルに内容が書き換わったという感じです。
アジャイルの根本思想
agilemanifesto.org
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。
つまり、断続的に開発するように考えられるようになった。
とすると、初めからコンテンツが全部そろっていない物が売られるのが一般的になりそう。
今でも分作やアップデートでの配信が増えてきていますが今後はその流れが加速化しそうっていうのが見て取れるわけですね。
そうなるとパッケージ買いきりじゃなく、
サブスクリプション型が主流に移ってくるのかなって考えると
クラウドゲーミングが相性が良い。
ニンテンドーがサブスクリプションでクラウドゲーミング取り入れ初めてますが、戦略の布石としてはすごく正しいなって思います。
因みにいま遊べるものでクラウドゲーミングで良さそうなのはXBOXクラウドゲーミング。
japanese.engadget.com
今後、ゲームを遊べるサブスクリプション型のストアが主流になってくる可能性もある。
だって、昔はDVDも買うだけだったのが、レンタル出てきて、
今はネットでのサブスクリプションサービスが主流です。
ゲームもそれに追従しないわけがない。
クラウドゲーミングの利点は処理が別の所にあるので、
FullHDの映像とコントローラーの情報だけリアルタイムに通信出来るようになれば
レンダリング処理が手元の端末で要らないという所。
つまり、スマホで遊ぼうが、ゲーム機で遊ぼうが通信速度さえ担保できれば体験が変わらない。
5Gでその流れが加速化するでしょう。
しいて追従出来ないのではないかという懸念点もあります。通信環境が整っていないような国があることです。
PCの様な高スペックのものを買うことも出来ないような国は
低単価で動作が保証されているコンシューマが未だに根強く売れているそうです。
そういった懸念がありつつも、サブスクリプションが主流になれば開発も断続ないし継続的になるでしょう。
ゲーム業界のエンジニアにはGoToがなぜ駄目なのかがわかっていないエンジニアも少なくないです。
そう言った現状を私は変えたいです。
一歩一歩情報共有し共にいい環境でいいゲームを日本から発信できるようにしていきたいですね。
まとめ
なんか、余計な話をメインで語ってしまったように思いますが、アドカレでもない限りこんな話は書かない気がしたので話題にあげさせてもらいました。
ゲーム業界以外ではゲーム業界は残業ばかりと思われている節があります。
現在働き方改革含めゲーム業界は変わってきています。(ちなみに私の先月の残業時間は一桁です)
勤務時間は減り、在宅ワークが定常化してきました。弊社も在宅ワークが定常制度として認められました。
今後変わりゆく中で日本ゲーム業界も変わっていかないと海外には絶対追いつけなくなると肌身に感じています。
弱小な私がいうのも何なんですが、皆さん頑張っていきましょう！
以上！やまだたいしでした。
