ゲームプランナーの技術ブログ

ゲームプランナーである管理人が、仕事する上で考えたことや習得したことを書くブログです。

大規模開発を経験してわかった問題点

最近、メンバーが100名を大幅に超える開発を経験している。
大規模開発ならではなの問題点について書きたい。

スポンサードリンク

 

 

1.半年いても話したことない人がいる

相談したい人がいても、過去に話したことない人だったりすることが多いので、コミュニケーションにコストがかかる。

 

少ないメンバーであれば、働いているだけで、性格とか人となりとかがわかるので、
どういうコミュニケーションをとるかがわかるのだが、そうもいかない。

2.自分のゲームをつくっている感覚が薄くなる

100人以上いると、自分がこのゲームへの貢献度が相対的に少なくなる。
そのため、発売したとしても「XXXXは私がつくりました!」という実感は薄いだろう。
※私の作業がだいぶゲーム開発の花形から離れているというのもあるかも。

3.ゲームをよくしようとする意欲が下がる

上記の様に、自分のゲームという感覚が弱くなるので、
ゲームをよくするために、人肌脱ごう!という感覚がうすれる。
 
ゲームというのは、色々な人のちょっとしたこだわりでだいぶ改善されるので、
良くない傾向だなと感じる。
RDR2の開発者は、大規模開発であるにも関わらず、恐ろしい時間残業したらしいが、そのモチベーションがどこから来たか謎である。

4.誰に相談したらいいかわからない

バグが発生したときや、トラブルが発生したときに、誰に相談すればいいかがわからない。
組織図の様なものは用意してあるが、それでもわからない。

5.上流工程のちょっとの判断遅れによる影響範囲がエグイ

シナリオだったり、操作性だったり、UIだったりをどうするかを決める時間が長くなればなるほど、何十人の作業が遅れることになる。

6.仕様変更の影響範囲がエグイ

ちょっとした仕様変更、例えば、セリフを一言二言かえただけでも、様々な人に作業が発生してしまう。

7.バグの擦り付け合いになる

関わるスタッフが多いので、誰が原因でバグを発生させているかがわからない。
ジェンキンスも導入しているが、ジェンキンスエラーがでないバグはどうしても出てしまう。
そういったバグを誰に投げればいいかわからず、バグをそれぞれのセクションが押し付けあうことになる。

8.チームをかえようとする意欲が失われる

プロジェクトには明らかな問題があるのだが、組織が大きすぎて、それを変えようというモチベーションがわいてこない。
 

9.ちゃぶ台返しによる損害が大きい(190319追記)

十数人規模なら、仕様をひっくりかえしても影響範囲は少ない。

だが、大規模開発だと最悪億単位の損失となる。

こういった事態を避けるためにも、開発人数を抑えた段階で試作品の段階でゲーム性をしっかり練るべきだ。

10.メールやチャットの数が多すぎる

ちょっとみていないだけで、メールやチャットが大量にくる。

そして、それが自分に関係があるかどうかを判断するのが非常に煩雑だ。

単純に読んでいるだけで、けっこうな時間が消費される。

まとめ

4については、困ったことがあれば、全員がみるチャットツールに問題を記載して、誰かにひろってもらえる様にすればある程度は改善すると思う。
 
7については、全然解決できる可能性はある。
ゼルダBotWでは、バグの報告フローをきちっと設けており、気軽に報告ができるようになっている。

www.4gamer.net

ただ、そもそも、大規模開発を円滑にするためには、個々がコミュニケーションをとり問題の解決に挑むことが難しい。
そのため、なるだけ業務を分業するか、個人だけで作業を完結できるようにし、コミュニケーションをとる必要がないようにするのが最適解だと思う。

 ↓続きを書きました。

sonykichi.hatenablog.com

〈スポンサードリンク〉