「ドラクエIX」発売延期の理由は 「油断していた」と和田社長（魚拓）
「油断していた。傲慢だったと反省している」――スクウェア・エニックスの和田社長が「ドラクエIX」発売延期の理由を説明した。
スクウェア・エニックスの和田洋一社長は2月12日、決算会見の席で、ニンテンドーDS用ソフト「ドラゴンクエストIX 星空の守り人」の発売日を3月28日から7月11日に延期した理由について、「デバッグが間に合わなかったため」と説明した。
延期の理由を問われた和田社長は、「ドラクエは、（機能の実装が）できあがったため油断していた。傲慢（ごうまん）だったと反省している」と切り出した。
実装が済み、本格的なデバッグに入った段階で「手強いバグがいくつもあることが判明した」という。バグの量は「とてもお客様に出せる状態ではない」ほど大量。「もう少しチューニングしようというレベルではなく、今出すべきでないことは明らかと判断した」
特に「ドラゴンクエストのチームとしては未開拓の通信分野」が強敵。「ゲーム全体でもまだまだバグは取り切れておらず、まして通信についてかなり掘り下げる必要があるため、十分な期間を取った」という。
その上で「ドラクエやスク・エニに固有の問題が起きているわけではない」と釈明。デバッグ作業も「バグを取りながら実装→実装完了→まとめてバグ取り」という「他社と同じ、普通のやり方」を採っているという。今後は「実装を終えてからまとめてデバッグするのではなく、実装段階でデバッグする体制を研究していきたい」とした。
デバッグにかかる時間を予見できなかった理由を問われると「開発現場に突っ込みは入れにくい」と渋りながらも、「要件定義などに問題があったのではなく、要素を実装する段階でのコンフリクトを見極められなかったのだろう」と分析した。
ドラクエIXは、2009年3月期に300万本程度の売り上げを見込んでいたが、発売延期で売り上げ計上は来期にずれ込む。これに伴い同社は、09年3月期の業績予想を下方修正している（「ドラクエIX」7月に発売延期 スク・エニは業績を下方修正）。
和田社長は、ドラクエIXの発売延期がプレイステーション 3向け「ファイナルファンタジー XIII」（2009年中に発売予定）の発売に影響する可能性があることも示唆した（ドラクエIX発売延期、FF新作「XIII」に影響も）。
糞ワロタ。
デバッグ作業も「バグを取りながら実装→実装完了→まとめてバグ取り」という「他社と同じ、普通のやり方」を採っているという。
うん、そこは普通だ。だから、問題があるのは実装作業する現場と、仕様作る堀井某の間の溝なんだろうな。
いくらゲーム業界が魑魅魍魎の住処とはいえ、そこまで無能なプログラマばかりではない。ましてや天下のレベルファイブだ（孫請けに出してるかもだけど）。バグが大量に残るケースってのは、そんなに色々思いつかない。思いつく限り書いてみようと思う。
- 開発期間が異常に短い。
これは今回のケースには当てはまらないが、俺の例を出すと、前作の使いまわしという甘言に騙されて1.5ヶ月で１本作ったことがある。マスターアップ５日前に、新しい仕様が来てブチ切れた。その新仕様は、普通に作れば５日かかると見積もった（暗に断った）のだが、「絶対入れてくれ」と言われて２徹半で入れた。普通の良くあるRPGの場合、期間は半年ぐらいが普通だと思う。
- 開発期間＆スタッフに対して、仕様が異常に多い。
２つのパターンがある。
- 「半年５人でDQの新作作って」とかいう場合。
まぁ、これも今回のケースには当てはまらないと思うが。これは、予算と発売日が確定している場合によく見られるケース。だいたい、使えるプログラマ３人も集まれば概ね同じスケジュールが出るのだが、明らかにそれを逸脱していることがある。なぜか仕様削減を飲んでくれないバカがプロデューサーをやってると、地獄を見る。
- 曖昧な仕様しかない場合。
曖昧な仕様しかないため、各人がおのおのの解釈の元に作っていく。もちろん、打ち合わせ等で仕様を明らかにしていくのだが、その過程で仕様矛盾が発生し、その矛盾を取り除くための新たな仕様が自然発生。その新たな仕様が影響を与える範囲が、すでに完成してOKの出ている部分だったりして、調整が入る。こんな事が頻繁に起こると、当初のスケジュールがガシガシ遅れていく。
- 日々仕様が変わる／追加される。
小島某や鈴木某、あるいは飯野某あたりは有名だが、とにかく思いつきで喋る。喋ったことがすべて仕様になっていないと怒り出す。昨日Ａと言ったが今日はＢ、明日はＣ。日々仕様が変わる。仕様が変われば、設計から変えねばならなくなる（ことがある）。それまで理解していたことがすべて要らなくなったり、こないだ破棄したものが今日必要になったりする。思いつきを喋っているだけで、整合性を取ることなどしていないから、現場のプログラマは混乱する。プログラマは、すべての仕様の整合性を取っておかないと、それが破綻すると『バグだ』とか言われる。整合性を取れないオマエの頭がバグってんだよ！！ と思う。PS濫作時代、飯野を始めとするビックリエイターの手によって、多くの有能な現場スタッフが心折られ消えていった。DS濫作時代の今、あのときの地獄がチラチラ顔を見せている。
- バグっててもいいから、とりあえずベータまでに全部入れて！
契約の問題で、提出期限を越えると当然違約金の話が出てくる。下請けとしてはそれは避けたいので、とにかく「バグは残ってますけど、全仕様入ってますから」というアピールをしなければならない。そのため、仕様矛盾、仮データ、バグ、未実装をバグと称して切りぬける、などが発生する。
ん、こんなトコじゃねーかな。
ということで、あくまで予想だが、３と２−２が多くあり、結果、４が発生した、だと思う。で、スクエニのｴﾛｲ人がベータの段階で初めてロムを見て、「いやいやいやいや。これはない。」と。
２−２の、仕様の整合性維持は、規模が大きければ大きいほどタイヘンである。DQ8で「『いてつくはどう』を使えないボスはザコ」という残念な仕様になってしまったのも、『きあいため』に関する仕様の整合性維持が取れなかったからだろう。
さて、現実に３が主な原因だった場合。
和田社長は、
要素を実装する段階でのコンフリクトを見極められなかったのだろう
と語っているが、これを
分析するヒトが誰なのか、っていうのは、現場にとって重要な問題である。極端に言うと、
スクエニの責任か、レベルファイブの責任かという話。
（※コンフリクトとは、衝突のこと。仕様の衝突、整合性破綻を指しているのだと思う。）
コンフリクトを見極めるヒトが現場側にいなければならないとされてしまったら、現場スタッフと、おそらく同僚であろうディレクターは揃って、堀井雄二に「
その脳味噌と直結してる口を縫い付けてくれようか！！」という思いでいるだろう。
一方、コンフリクトを見極めるヒトが管理側のヒトの場合。現場側としては落ち度は上に比べて少ない。つまり最悪の場合「おたくのコンフリクトを見極めるヒトが仕様バグ出したんでしょ」と言える。
しかし、一番ありそうなのは、コンフリクトを見極めるヒトは管理側のヒトが割り当てられているが、全くの無能で、結局現場がヒトを出してコンフリクトを修正し、そのお伺いをいちいち管理側に投げているというケース。
レスは遅い、投げたコンフリクトは拒否る、コンフリクト対策と称して投げてきた仕様が別の仕様とコンフリクトなど、どうしようもなかったりする。
おそらく、ゲーム開発現場を知らないヒトが、この和田社長のインタビューを見ても何も感じないだろうけど、アチコチの現場を見てきた俺から見ると、「現場はタイヘンなんだろうなぁ・・・」と、いらん妄想に想いを馳せて、ゲームに興じるのでした。
