バグ対応期間終了まであと数日しかないのに迫りくる仕様変更と要望対応、
それに伴って増えるバグ、バグ、バグ。。。。

ここのレイアウトが気に食わないから差し替えましたー
ここに演出入れたいのですが大丈夫ですかー？
ここの仕様をやっぱりこうしてもいいですかー？

というものの対応が非常に多く、また対応も大変。。。
昔からよくデザイナーとプログラマーは揉めやすいって聞いてたけどこういうことなんだろうなぁ
なんて思ったり。。。

でもみんな良いものを作りたいという気持ちからなので仕方ないところもあるのかもしれない。
しかしあれやりたいこれやりたいをいつまでも続けていたら仕事は絶対に終わらないので、やっぱり諦めどころが肝心。

ゲーム作りは技術者のセンスがどうとか技術がどうとかではなくて
一人一人のコミュニケーションと認識の合わせ方次第なんだろうなと実感している今日この頃
コミュ力は大事です。

ではでは

よくある話ですが、一言差し替えデータの準備を進めていること言って欲しいと思ったことは何回もあります。
最後に組み込みで破綻するのはプログラマーですのですので。

まぁ、リーダがーちゃんと舵取りしていれば大丈夫なんですけどね。

急な変更でプランナー的には大したことないだろう～くらいのものが、
こっちからするととんでもない内容だったりするときはちょっとゲンナリしますね。。。
そうならないようにしっかりプログラマーが設計をしなければというのもあるのですが、今回は後になってその場その場の対応が増えてしまってやや破綻してしまった感が否めないですね。

初めにしっかり作っていても、要望の対応をしていくうちに崩れてしまうのは、本当によくある話。
しかも要望の対応していく人がシステムをよくわかっていない人だと、見かけだけの補修になるので、バグがバグを呼ぶことになる。
なので、その場での対応をいちいちするのではなく、一定の期間をおいてバグと要望を収集し、設計の見直し、修正を行うのが理想ですね。

そこらへんの感覚を、プランナー、デザイナー、関係する人すべてに認識してもらいたいものですが。
認識してもらう場を用意してくれる会社は皆無に近かった気がします
!|:!|:!|: orz !|:!|:!|:

# 私がゲーム業界にいたころは、発売日を考えろよ！！と何回思ったことか…
# 最終的にそれが一番嫌で、システム開発へ転職したんだけどね

プログラムが完成することが最大目的ではなく面白く遊びやすいゲームを作ることが最大目的になるので、いい加減というより致し方ないところはあると思います。
なので「ちゃぶ台返し」やら「改良」は日常茶飯事です。

わたしはバグや要望は最低でも一日ごとに出して欲しいですね。
個々に対応すれば簡単なのに変なまとめ方をされたりする場合があったりしますから。
どちらにせよ立場を理解してコミュニケーションを密にしろって話ですが。

急な要望や仕様変更はゲーム業界に入る前にも経験してたので耐性がありました。
そこでは一般のお客さんが出してくるものでしたから。
わたしだけかもしれませんがゲーム業界に入ってからキツイと感じたことはほとんどないですね。
経験が浅かったのが大きいと思いますがシステム開発やってたころの方がキツかったです。

単純作業で打ち込んだデータとか上がったらすぐに動かして見せてやってバイトのモチベを上げたりとかしましたね。
そのためにはきっちり構造化してテストケースを用意しておいたりしなくてはならないわけですが、やればモチベも上がるし開発効率も作業効率も上がっていいことずくめですよね。

発売日をゲーム雑誌で知るというのはゲーム業界あるあるですね。

半年くらいのプロジェクトでマスターアップまであと1ヵ月くらいしかないのにぜんぜん動いてなくて前任者が夜逃げしたところにヘルプに入ったってことが何度かあります。
そこは得意分野で呼ばれたので間に合わせましたけど。

＞へにっくすさん
今回はどちらかというと設計以前に全体の認識確認が甘すぎました。。。
プランナーがデバッグ期間に入る2週間前くらいから急に大量に要望と新仕様を出して来たり
デザイナーがレイアウトを変えたいと言い出したり、てんやわんやで設計もどんどんと破綻していった感じですかね。
もともとしっかりしたつくりとも言えなかったので余計に悲惨ですが、こうなったのも余裕がある期間中にしっかり準備をしていなかった私たちにも非があるのだろうなと思っています。

当初は全体的に余裕そうだなぁと思って見ていましたが、私の会社の先輩だけ「激ヤバだよ！」と社長にグチっていたのは
こういうことになるってことをある程度予想していたんだなぁと実感しています。。。
自分がメインになって開発するときはこの辺をちゃんと気を付けて仕事していきたいですね。

＞ソフト屋さん

遊べるものを作ってこそ、ご飯のネタではあるのですが
切れる仕様は最初のうちに切ってデータ設計とフローもすべて固めたうえで後はデータ追加と調整！という風に割り切らないと
一番重要なゲーム性やクオリティアップの話に持っていく前にマスターしてしまうという悲劇を生んでしまうので
やっぱりできることなら急な変更は避けたいと考えてしまいます。

ただでさえ疲労している状態で対応をするもんだからコードも一層に泥臭くなっていくという悪循環ですね

＞ISLeさん
今回の仕事では比較的デバッガーさんはまともに仕事をしてくれる会社だったようなので、それは救いだったかもしれません。
ただまとめ方はお世辞に良いとは言えなかったと思います。
（発生頻度の数値とかが何を基準にしたものなのか、とか似たようなバグなのに一件一件別々に報告してくるからまとめるのが大変とか、その辺の不満の声が多かったですね）

私はプログラマーとしてはゲーム業界が一番初めだったので他のシステム系の事情はわからないですが
きついかどうかはチームメンバー次第だと思っています。
しっかり切るものを切って分担して平たい作りにできるとある程度余裕をもって仕事に取り組めると思うのですが、
そういう話がどこまでできるかはメインプログラマーやディレクター次第なのかなって感じました。

プロジェクト管理ツールは使ってないのでしょうか。
デバッグ会社さんって要求すればエクセルシートとかで提出してくれたりしませんでしたっけ。
直接関わったことないので詳しくないですが。

ちょいと加工してCSVファイルにしてからチケットに突っ込んでツール上でまとめると楽ではなかろうかと。
既にやってたらすみません。

プロジェクト管理はredmineを使っていましたがデバッグ期間に入ってからはＥｘｃｅｌにバグレポート表をまとめて、
ファイルサーバーで共有しながら修正対応をチェックして報告、といった感じです。
そのＥｘｃｅｌファイルは会社側で用意されているバグ管理サイトからＣＳＶファイル形式で落としてきて作成する感じだったと思います。

会社によっては誰が担当するバグなのかまでまとめてくれる会社もあるそうですが、
今回のプロジェクトではメインプログラマーとディレクターで直接コメントを書いたり担当割り当てしてましたね。

そこそこの規模のゲームの開発は初めてで私自身あまりデバッグの対応や要領は
よくわかっていないのでこんなもんなのかー、くらいに思っています