おかしいと批難されているゲームの要素が開発内で指摘されない理由
Twitterのタイムラインを眺めていると、ゲームに関する感想で次のようなポストを見かけることがあります。
これまでゲーム開発の現場をいくつか見てきましたが、ユーザーから批難される要素がゲーム中に存在していることに開発内で誰も気づいていないということはほとんど無いように思えます。しかし、誰かしらがその要素に気づいていても、開発内で指摘されないことがあります。
クリエイターなら、誰もがより良いものを作ろうと思っているはず……。
なぜ誰も指摘を行わないのでしょうか。
開発現場では、日々様々な仕様作成・アセット制作・実装業務等が進行しています。その中で各業務の関係者が内容をチェックするので、業務内容を批判する(良いところ、悪いところを見分け、評価する)ことは日常的に行われています。
しかし、何らかの理由で悪い内容のまま制作が進行してしまうことがあります。そして、その後の制作途中や物が出来上がった後のタイミングで、誰かがその悪い部分に気づいても、指摘をしないことがあります。
指摘しない理由を聞いて回ったわけではないので、筆者の経験と憶測が混じっていますが、現場の末端目線からその理由を紹介します。
雇用形態の影響を受けている
自身の雇用形態を理由に、指摘を控える場合があります。
契約終了を危惧している
まず前提してこの記事を読んでいる人に覚えておいてほしいのですが、Twitterでゲーム中のおかしな点を呟くのと、開発内でおかしな点を制作者に指摘するのでは、発言のハードルに大きな違いがあります。
Twitterでは、批難と捉えられるような発言をすることに対してリスクを考慮する必要がありませんが *1、開発現場では直接相手に対して批判する形となるからです。
開発内で何かを批判することに対して、最も高いリスクが契約の終了です。ゲーム開発者も他の職業と同じように、契約先から収入を得て生活しています。契約が終了することになった場合、次の契約先を探さなければなりません。
近年、欧米を中心としたゲーム企業の人員削減が進んでいますが、日本も例外ではありません。ゲーム業界全体でプロジェクト数が減少しているので、契約終了となった場合、次の契約先を見つけるのは困難です。
以上を踏まえて、契約終了を危惧している派遣や業務委託は、良いものを作りたいと思いつつも、他の開発メンバーとの衝突を避け始めます。このような状態に陥ると、開発への熱意も徐々に冷めていくので、場合によっては誰とも衝突しない業務でもアウトプットの質が下がっていきます。
会社間の関係性が悪化することを懸念している
昨今のゲームは大規模化が進んでいて、大規模なプロジェクトでは量産時期に数百人の開発者が常勤しています。基幹会社の社内スタッフだけでは到底開発が間に合わないので、足りない分は外部の会社に発注を掛けたり、派遣や業務委託で人員を補います。
基幹会社とは別の会社を経由してプロジェクトに参加している場合、問題を起こさないよう慎重に立ち回る必要があります。なぜなら、問題を起こしたときに会社間の関係性が悪化する可能性があるからです。
会社間の関係性が悪化した場合、会社の評判や取引にも影響が発生する可能性があるので、問題を起こした人の立場が追われることになります。また、会社に迷惑を掛けるだけではなく、一緒に現場で働いている仲間にも被害が及ぶ可能性があります。そのため、相手から問題を起こしていると捉えられるような指摘を控える場合があります。
ゲーム開発の大規模化の影響
ここまでは個人や会社のリスクを理由に指摘を控える話をしてきましたが、それらのリスクとは別に開発内で指摘が行われない理由があります。その大きな理由の1つがゲーム開発の大規模化です。
ゲーム開発は、ゲームデザイナー・アーティスト・エンジニアなど様々なセクションと連携して制作していきます。現在はゲームの規模が大きくなり、内容も複雑化しているため、開発内部の体制も細分化されています。
開発チームの規模が大きくなると、各セクション内からの指摘は一旦リードが吸い上げて、リードがディレクターに報告します。また、プロジェクトの規模に応じて、中継点が増えていきます。なので、数百人規模で開発を行っていたとしても、開発トップのディレクターに直接報告できるのは、数人~十数人といったプロジェクトが多いです。
指摘する時間がない
ゲーム開発者たちは、各々割り振られたタスクの消化や日々発生する問題解決に必死なので、時間はいくらあっても足りません。なぜそのような状況が発生するのか説明します。
ゲーム開発はプロジェクト初期の計画から、誤差が生まれる場合がほとんどです。誤差が生まれる主要因は次の通りです。
各要因の誤差が影響して、次のように作業コストが増えていきます。
増えた作業コストへの対処例は次の通りです。
この例では対処2・3で人員を60%追加投入&期間を50%延長していますが、受諾開発のプロジェクトはそんな予算もないし、人も見つかりませんし、期間延長なんてクライアントが許さないはずです。
なので、対処1・4・5の割合を増やすことで対応します。現場は文字通りデスマーチと化すので、各作業者に指摘する余裕はありません。
風通しが悪い
プロジェクト内の風通しが悪い場合、次の理由から指摘が減ります。
指摘する相手との信頼関係がまだ構築できていない
相手に信用されていない状態だと、たとえ指摘内容が正しかったとしても、指摘を受け止めてもらえないだけではなく、相手との距離がさらに開く可能性があるため、指摘を控えます。
他セクションの業務内容だから指摘しづらい
指摘先が自分と関りがない他セクションの業務だと、どこまで言っていいのか分からないので指摘を控える場合があります。
ゲーム開発の現場を家庭で例えると、家族(セクション内)のことは家族内(リードと作業者)で決めたいけど、うるさい姑(他セクションの人)が口出してくるみたいな状態が近いのかなと思います。 恐らくほとんどの人は「うるさい!黙れ!!」と思うはずです。 大規模ゲーム開発でそのような行為を許した場合、開発内にうるさい姑が数百人爆誕するので収拾がつかなくなります。
指摘する機会の場がない
会社やプロジェクトによって様々だと思います。会社の文化的に言い出しづらい、 相手との立場の違いから言い出しづらい、衝突するのが嫌だから、他にも様々な理由があります。また、誤解を恐れずに言えば「陰キャ」の特徴を持つ人は、この傾向が高いと思います。
陰キャは引っ込み事案な性格なので、指摘するのに勇気と覚悟が必要です。また、会話が得意ではないので、過去に指摘に失敗して嫌な思いをし、指摘するのが嫌だったり、怖いと思う人も居ます。筆者も陰キャの民なので、気持ちは分かります。
せっかくなので『ポプテピピック』を例に指摘の仕方を説明します。
ポプ子が指摘する人、ピピ美が指摘を受ける人です。ポプ子がピピ美を殴っていますが、ピピ美は「おこってないよ♡」と答えています。ポプ子はピピ美が怒らない力加減で殴打(指摘)しているからです。
殴打は強すぎても、弱すぎてもいけません。強すぎると、相手は怒ります。逆に弱すぎると、相手に響きません。陰キャはこの力加減が苦手なので、相手を殴り飛ばすことがあります。一度相手を殴り飛ばすと、信頼関係の再構築に時間を要します。
他セクションの立場が強い
指摘先が寵愛を受けてる他セクションだと、指摘した時に自分の身が危うくなるので指摘を控えます。
指摘するとヤバいことが起きる
契約終了や会社間の関係性悪化ほどではありませんが、指摘するとヤバいことが起きるので、指摘を控える場合があります。
デスマーチが始まる
指摘すると自分や自セクションがデスマーチに発展すると分かっている場合、過酷な労働環境が待っているので指摘を控えます。また、他セクションに影響が発生する指摘であれば、指摘内容によっては恨まれる可能性があるので、指摘するかどうか慎重に判断します。
相手が体調を崩す可能性がある
指摘先の作業負荷が高い状態でも、真面目な人や責任感が強い人であれば、真摯に指摘を受け止め、対応してもらえる可能性が高いです。しかし、限界を超えて頑張った結果、体調を崩す可能性があるため、指摘するかどうか慎重に判断します。
炎上しすぎたパターン
開発が大炎上した場合、次の理由から指摘が大きく減ります。
開発の士気が低い
開発が大炎上すると、現場の士気が落ちます。士気が落ちると、開発への熱意も下がっていくので、より良いものを作ろうという意識も無くなっていきます。その結果、淡々と業務をこなす人が増えていき、指摘をする人も少なくなっていきます。
最近流行りのメテオフォール型開発の現場に遭遇した場合は、高確率で士気が低いです。
開発途中でプロジェクトが凍結することを経験で察する
みんな目が死んでます。
思うこと…
これまで、いくつかのゲームタイトルの開発に携わってきて思うことがあります。せっかくなので、一緒にまとめておきます。
伝言ゲームやめろ
ディレクターチェックで何かフィードバックがあったとき、担当セクションのリードだけ話を受け取ることがあります。リードは調整内容やその意図を直接聞いているので、情報を十分に受け取れていますが、末端の作業者にはリードが嚙み砕いた内容が降りてきます。
「調整内容」と「意図」が分かりやすく噛み砕かれていた場合は大変助かりますが、大抵は「意図」が砕け散った状態で届きます。調整意図が十分に理解できていないと、調整する際に目指す方向を間違えることがあります。チェック会を開くのであれば、関係者を全員集めて直接フィードバックをください。
また、自セクションのリードが伝言ゲームに時間を取られると、リードの作業時間が奪われます。リードの余裕が無くなると、目先のことを対処するのに必死になり、未来のことを考えなくなっていきます。そうなると悲惨な結末が待っているので、作業者はリードの仕事を剥がし始めます。剥がした仕事分だけリードは余裕を取り戻しますが、作業者が担当しているタスクのスケジュールが遅れるか、成果物の質が下がります。
上記を踏まえた上で、伝言ゲームをしているのであれば構いませんが、そうでないのならやめてほしいです。途中からプロジェクトに参加した人は、そのプロジェクトの文化に適応するしかありません。しかし、開発最初期から居るディレクターであれば、プロジェクトに適した文化を形成できるはずです。ゲームの中身のディレクションだけではなく、チーム運営のディレクションもしてください。チーム運営の時間が確保できない or チーム運営が得意じゃない場合は、得意なPMを採用してください。
みんな気づいてるよね…?
量産時期(β)のプロジェクトに参加した場合、ほとんどの人は最新ROMをプレイして開発状態を確かめると思います。そのROMをプレイして、あることに気づくはずです。
プロジェクトによっては、上長から初プレイ時の感想を残してほしいと言われ、社内Wikiやスプシに自分の感想や気になる点を記載しますよね。そこでゲームの物語には、どこまでツッコミますか?
筆者は次の理由から、あまり深くツッコまないようにしています。
自セクションの業務がシナリオと関わっている
働き始めてまだ数日だから、どこまでツッコミが許されるか分からない
ディレクターの承認が通ってるなら……まあいいか……。
脚本術について詳しくないので、改善案が出せない
ツッコミがシナリオライターまで届いて、その人が病んでしまった場合に責任が取れない
色々理由を挙げましたが、ほとんどの人は「物語そのものにどこまでツッコミを入れていいかが分からない」というのが本音だと思います。このような理由で、物語に大きく気になる点があったとしても、鋭い指摘はしていないと筆者は想像しています。
また筆者の想像になりますが、物語について良い印象を抱いていなくても、物語にメスを入れることに対するリスクを考慮して、指摘しない人も居るのかなと記事を書いてる途中で思いました。筆者がパッと思い浮かんだリスクは次の通りです。
メスを入れても、改善されない可能性がある
上流の工程が遅れることになるので、下流の工程も全て遅れる
チームメンバーの士気が下がる
物語の変更に伴って、新たな機能やリソースが必要になる
企画書のコンセプトから方向性がずれていく可能性がある
会社やプロジェクトに対して不満が発生する
プロジェクト中止のリスク
メスを入れても、改善されない可能性がある
物語にメスを入れたとしても、あまり改善の効果がなかった場合、予算と時間が無駄になります。
上流の工程が遅れることになるので、下流の工程も全て遅れる
スケジュール遅延が起こると、次のようなことが発生します。
物語が良くなっても、下流のアウトプットの質が下がる可能性がある
仕様削減(ゲームの要素が減る)
クオリティの妥協
スケジュールの遅延を取り戻すための人員の追加投入、特急の外部発注
開発コストの増加
ゲームに対する理解不足、練度不足を起因としたクオリティの低下
デスマーチが始まるリスク
労働環境の悪化によって、アウトプットの質が下がる
モチベーションの低下によって、生産性が下がる
体調不良で人が倒れる
倒れた人員がキーマンだった場合、現場の作業の大きな支障が発生する(スケジュールとクオリティに大きな影響がある)
人員を補充できたとしても、100%抜けた人の代わりにはならない
QAの検証時間が減る
不具合の検出不足を起因としたクオリティの低下
ゲームのクオリティに対する報告が減るので、ゲームが改善されない
物語の変更に伴って、新たなリソースが必要になる
制作予定のリソースの範囲内で物語を変更するのではなく、新たなリソースや機能が必要になる場合はさらにスケジュールが遅延し、開発コストが増加します。
企画書のコンセプトから方向性がずれていく可能性がある
物語の大幅な修正が繰り返された場合、最初に設定されたコンセプトから離れていくリスクがあります。また、ゲーム全体の一貫性や魅力が失われる可能性もあります。
プロジェクトや会社に対して不満が発生する
開発の炎上を理由に、プロジェクトや会社に対して不満を抱いた人が、プロジェクト及び会社から抜けるリスクがあります。
プロジェクト中止のリスク
予算・スケジュール・クオリティに関わる様々なリスクが発生するため、最悪プロジェクトが中止となるリスクがあります。
ディレクター・プロデューサー視点では、開発途中で物語のクオリティに問題があると気づいても、物語を変更するリスクが大きすぎて、あえて指摘してない部分もあるだろうなと色々書いてて思いました。
あとがき
この記事が予想できた内容だったと思う人もいれば、全然想像で出来なかったという人も居ると思います。筆者はゲームをプレイするのが好きでゲーム開発者になりましたが、ゲーム開発の現場がこのような状態だとは全然想像できていませんでした。(デスマーチがあるのは知ってた)
みなさんがこの記事を読んで、どのように思ったのか知りたいので、よければ次のポストに返信、もしくは引用する形で感想を頂けると大変筆者が喜びます。
また、感想を書く際には自分の職種を載せてもらえると、他の会社との違いを観測できて面白いと思うので、もし可能なら教えて欲しいです。(ゲーム業界に携わってる方はポジションも知りたいです)
感想を沢山もらえたら、新たな記事を書く意欲も湧くと思うので、他にも何か記事を書いて欲しいと思った人は是非!!
おまけ
今回の記事を読んで商業ゲームの開発に興味を持った人は、ゲーム業界の仕事について描いた『チェイサーゲーム』という漫画が楽しめると思います。第4話では、ゲーム開発で制作されるリソースのクオリティに関する話が取り扱われています。本記事とも関わる内容が載っているので、興味がある人は読んでみてください。
Special Thanks
この記事を投稿するにあたって、事前に内容を確認し感想を送って頂いたみなさん!ありがとうざいました!!
どの感想も参考になるものばかりでしたし、記事を執筆する意欲がとても上がりました!みなさんの感想がなかったら、ここまでのクオリティの記事に仕上げることは出来なかったと思います。
本当にありがとうございました!!!
noteに新しい記事を投稿する気力が湧きます。